#416 First block copy/move attempt sometimes fails with "No block"
I have run into this problem many-many times. Unfortunately I have no reproducible test case yet.
I have configured my joe to highlight text on Shift+Arrows. I believe this operation is bound to Ctrl+Arrows by default, but I modified to match the behavior of the vast majority of apps out there. The relevant part of my .joerc is:
begin_marking,rtarw,toggle_marking ^[ [ 1 ; 2 C Mark right Xterm
begin_marking,ltarw,toggle_marking ^[ [ 1 ; 2 D Mark left
begin_marking,uparw,toggle_marking ^[ [ 1 ; 2 A Mark up
begin_marking,dnarw,toggle_marking ^[ [ 1 ; 2 B Mark down
Most likely this bit is irrelevant and the bug is identical with default config and Ctrl+Arrow keypresses.
I open two existing files, as in "joe file1 file2". These are plain text files of reasonable length, maybe about a hundred or thousand lines or so, ending in a newline character (as every well-behaved text file should).
In the first file, I use Shift+Arrows to highlight a block, ending at the file's end. I'm only moving vertically, the cursor stays in the first column. I'm not sure if I start highlighting at some middle line and move with Shift+Down all the way to the file's bottom, or if I start highlighting at the very end of the file and move a little upwards by Shift+Up.
Then I switch to the bottom window (Ctrl+K N) and try to move or copy that block there (Ctrl+K M or Ctrl+K C).
Instead of executing the said operation, I get a "No block" error message.
It only seems to happen if the highlighted area ends at the very end of the file.
It only seems to happen if I use Shift+Arrows for highlighting text; I think it does not occur if I use the more old-fashioned Ctrl+K B to start and Ctrl+K K to end the selection.
It only seems to happen at the beginning of the editor's lifetime. If it misbehaves then subsequent attempts, with tiny adjustments on the selection's beginning, also fail. However, if I move or copy a non-trailing block, which is also successful, then from then onwards moving/copying the desired trailing block also succeeds. Also, according to my vague memories, re-selecting the said area using Ctrl+K B, Ctrl+K K also fixes the behavior (I'm not entirely sure about it).
John, I see you're working towards a 4.7. Not sure what your planned timeline is. I'd truly appreciate if you could include a fix of this issue in 4.7.
I'll try in the next couple of days to come up with a reproducible test case. My previous attempts of trying to reproduce the bug by remembering and replaying the exact same keystrokes always failed. Combined with the fact that the faulty behavior occurs at the beginning of the editor's lifetime, I can't exclude the possibility of an uninitialized variable having a random value and the behavior depending on that random, until the first successful copy when it's no longer random but has the desired value. So maybe it won't be easy to reproduce.
Oh, stupid me.
I can finally reliably reproduce. The issue happens when I try to extend the selection too much, beyond the end of the file by pressing Shift+Down at least one too many times. Or the same thing at the top of the file, trying to extend upwards.
For some reason, my definititon of these macros differs from the one in the default config, which goes something like
That right-left (or up-down, etc.) dance at the beginning seems to be exactly the workaround for the problem I'm having.
I'm not sure why a workaround is needed in the config file, rather than it being in the binary, but nevermind.
Feel free to close as invalid.