Documentation for IDWriteTextFormat1::SetLastLineWrapping() is insufficient:
Sets the wrapping mode of the last line. If [the single BOOL parameter is] set to FALSE, the last line is not wrapped. If set to TRUE, the last line is wrapped.
For IDWriteTextLayout2::SetLastLineWrapping() it is equally terse:
Set whether or not the last word on the last line is wrapped.
Some details lacking that I want to know:
Which one is the last line? In my tests, sometimes it is the last visible line that gets the extra word, but sometimes it is the next one, and then more lines follow. (Is it a bug in DirectWrite? In my code?) Here "visible" means (for horizontal lines, in the vertical direction) completely inside the layout rectangle.
How does it interact with IDWriteTextFormat::SetTrimming()? Some tests suggest that behaviour is different when trimming is set. (With SetTrimming(&DWRITE_TRIMMING{DWRITE_TRIMMING_GRANULARITY_CHARACTER,0,0}, nullptr);.)
It was intended for rectangular tiles where the last word of the application name would otherwise be hidden because it got wrapped to the next line. By default, this would yield:
"here is an example of a long application name" ->
<----------->.
here is an /|\
example of a |
long \|/
application
name
So if the tile height was short (say only 3 lines), then only none of the word "application" would be visible, but it's more useful to also show at least part of the next word.
<----------->.
here is an /|\
example of a |
long applica\|/
name
In conjunction with ellipsis character trimming, it looks like:
It always means the last visible line whether trimming is enabled or not, but when trimming is enabled, any partial lines are trimmed out, making the last "visible" the last untrimmed line. So that's the difference you're seeing.
Related
When using { or } to navigate between paragraphs, Vim appears to treat lines with white space characters as if they were part of the paragraph and skips past them. This behaviour has been discussed in a number of threads and the explanation given (based on :h paragraph) is that "a paragraph begins after each empty line", which is fine.
However, this does not appear to be consistent with the way Vim treats the ap and ip commands, which actually do treat lines with whitespace characters as paragraph breaks. For example, given the following text where the first two paragraphs are separated by a non-empty line (containing whitespace) and the second and third paragraphs are separated by an empty line (and assuming the cursor starts at the top of the buffer) the following occurs:
1 abc # next line contains spaces
2
3 def # next line is blank
4
5 jkl
}: moves the cursor to line 4 (i.e., treats lines 1-4 as a paragraph)
dap: deletes lines 1 and 2 (i.e., treats only lines 1-2 as a paragraph)
These two behaviours appear to be inconsistent with one another. Why do these two commands that operate on a paragraph object behave differently?
As mentioned in :help ap and :help ip:
Exception: a blank line (only containing white space) is also a paragraph boundary.
So the behaviour of ap was made voluntarily different from that of } and the difference is clearly documented. The exact reasoning behind that difference is explained nowhere, though, and may be lost in time. You might want to ask on Vim's official mailing list.
Anyway, we can extrapolate a little…
Vim's } is consistent with vi's }. This is expected since Vim's whole purpose is, after all, to be a convincing stand-in for vi.
ap (and the whole concept of text objects) is a Vim thing. It wasn't in vi so there is no existing behaviour to replicate and the person who added that feature decided to make it treat "paragraphs" in a slightly more intuitive fashion than }.
I am trying to print the report for each iteration. Since each iteration takes a really long time to run, therefore, I use print together with end="\r" to show the current item being processed.
Here's the dummy code:
import time
y = list(range(50))
print("epoch\ttrain loss\ttest loss\ttrain avg\ttest avg\ttime\tutime")
for e in range(10):
for i in range(50):
print("training {}/{} batches".format(i,50), end = '\r')
time.sleep(0.05)
print('{}\t{:2f}\t{:2f}\t{:2f}\t{:2f}\t{:2.1f}\t{:2.1f}'.format(y[0]+e,y[1]+e,y[2]+e,y[3]+e,y[4]+e,y[5]+e,y[6]+e))
Expected Result
This is my expected result, where the progress information is completely erased after each iteration. (I am running it in Jupyter notebook, and it looks fine)
The Result that I am getting
However, when I run it on linux terminal, the progress information is not completely erased, and the result is overlaying on top of the progress.
Why is it so? How to solve it?
\r simply moves the cursor back to the beginning of the current line. Anything printed after the \r is printed "on top of" the content previously there. On a real printer/teletype this would be literally true, with two characters getting printed in the same position ("overstruck"). On a terminal, the new characters replace the old ones (but only in positions that you actually write to).
You can take advantage of this behavior of terminals by printing spaces. You need at least as many spaces as the content you want to erase, but not enough to make the terminal wrap to the next line (this may be impossible if the line was printed all the way to the last character).
In your case, you know that the line won't be more than 22 characters long, so you could use end='\r \r' (go back to the beginning of the line, print 22 blanks, then go back to the beginning of the line again).
\r option will set (move) the cursor to start. It will not clear the text.
You have to make sure your printed data has enough space to overwrite the previous printed data or be of the same length since just moving to the same line would not automatically clear the previous contents.
This drives me really insane...
Say I have a short line of text on line 32, and a very long string on line 33, say 10,000 characters long... if I have word-wrap on, it ONLY shows line 32 and stops there, and instead of displaying 33+ it just displays # in the first column and all the rest is whitespace.
I have to move the cursor all the way to the very bottom and then the entire string appears at once.
This is extremely jarring because if you 'overshoot' when scrolling, it immediately disappears again.
I want it to behave sanely... where nothing jumps in or out of the screen all at once. It should just flow along like normal with all the other line numbers, and always be visible.
The answer was I needed to add this:
" show as much of long lines as possible
:set display+=lastline
I've been getting used to using vim for the last two weeks and am really starting to like it. There's one thing I've been wondering about - sometimes when I'm typing something, these rows with nothing but the # symbol appear at the bottom of the screen:
This has happened a couple of times but I've never paid much attention to it, but I'm curious - like in that situation, pressing enter gets rid of one of them, and pressing enter again gets rid of the other. Then another two enters after that, another # row appears. Does anyone know what they mean?
this usually happens when you open a very big file (or very long lines).
You can set display option to show all lines. (without showing those #).
lastline When included, as much as possible of the last line
in a window will be displayed. When not included, a
last line that doesn't fit is replaced with "#" lines.
e.g. in my vimrc, I have set display=lastline
if you want to know detail about it, check :h 'display'
This means you have a line larger than your terminal's height and width.
Let's say I have a file with N lines. I'm at line X and I'd like to move to line Y, where both X and Y are visible on screen. I can do that by typing :Y<cr>, but if Y>99 that's a lot of typing. I can also do abs(Y-X)[kj] (move up or down by abs(Y-X)), but for big X,Y computing this difference mentally isn't so easy.
Is there a way to exploit the fact, that both X,Y are visible on screen and move between X and Y fast?
You can :set relativenumber which does that Y-X computing for you (only in Vim >= 7.3).
You can use H, M or L to go the top, middle and bottom of the screen.
Perhaps you can make use of H, M, or L.
These keys jump the cursor to display lines:
H "Home" top of screen
M "Middle" middle of screen
L "Last" last line of screen
With a count, they offset: 4L would go to the third line above the last (1L is the same as just L).
Personally, I make heavy use of the m command to mark a line for navigation. From where I am now, hit mq to mark the position with label q; then navigate to another line, and ma to mark it with label a; and from then on I can hit 'q to jump to position q and 'a to jump to position a. (q and a are arbitrary; I use those mostly due to their position on a QWERTY keyboard.)
One you have the marks, you can use them for commands. To delete from the current position to the line marked with q, you just use: d'q
There is a variant, where instead of single quote you use back quote. This takes you to the exact position on the line where you placed the mark; the single quote uses the start of the line.
Those marks work even for ex (command line) commands. To limit search and replace to a specific set of lines, I mark the beginning and end lines respectively with labels b and e, and then do my search and replace like so:
:'b,'es/foo/bar/g
Dropping my dime in the pond:
I find that traversing code is exceptionally easy with text objects. I rarely do use jk/JK for larger jumps any more. Instead I navigate for whitespace lines using { and }
Since on any one screen there are usually only so-many whitespace delineations (and they are very easily visually recognized and counted), I find that e.g.
3}j
lands me on the intended line a lot more often than, e.g., a guesstimated
27j
To top it all, many 'brace-full' programming languages have opening braces at the start of functions. These can be reached with [[ resp. ]]. So sometimes it is just a matter of doing, e.g.
2[[}
(meaning: go to start of previous function, after the first contiguous block of lines)
My version of VIM lets you guestimate a number immediately before hitting J or K to go that many lines.
15K goes up 15 lines
The tougher vimmer you are becoming, the bigger amount of lines you can count at first glance.
Don't know, maybe there are some clever techniques, but I just type something like 17k/23j and so on.
also, searching some word on the string you want to jump works.
also, zz (center screen) is sometimes helpful in this cases.