Shift end on wrapped line is one char too short

[OzBob]

Shift end on wrapped line is one char too short
a long line with no spaces
place the cursor at the start of the first line
press and hold shift, press end
the very last character is NOT selected

Also works on ‘broken up’ lines, e.g. <tag>blah</tag>
will be wrapped to
<tag>blah
</tag>

if you select the first line the characters that are selected are:
<tag>bla
rather than
<tag>blah

[Terry R]

@OzBob
I just tested my version (7.5.7 32 bit) and it has the same issue. I’ve never noticed it before, mainly due to not having had the need to do this at all.

I see that if the word wrap is not turned on, then shift-end will select the entire line. If word wrap on and showing on 1 row, then OK, but move just 1 character down (by shortening the window width) and it now misses the last character on the portion of the first line showing on the first row, so it now misses 2 characters, thus to my mind a bug.

May I suggest you read the FAQ, in particular:
https://notepad-plus-plus.org/community/topic/15741/faq-desk-feature-request-or-bug-report
This posting identifies where it’s best to log this so it is more readily seen (and perhaps actioned). You might even want to peruse the other postings there first in case someone else has already identified it (so no need to post again).

Terry

[Meta Chuh]

@OzBob @Terry-R

the normal behaviour with longer lines and word wrap enabled should be that you have to press shift+end twice (tested now with 7.5.1 x86 and 7.6 x64)

the first press of shift+end marks from the cursor to the end first of the wrapped lines including the last character.
the second shift+end marks to the end of the last char of this single wrapped line (complete line) including the last character (excluding line breaks cr and/or lf)

but … yes, if the line is a long wrapped line without spaces, the first shift+end misses the last character of the first wrapped line (glitch)
but the second shift+end should mark the wrapped line completely

(remark: a third or more presses of shift+end does not matter, it should stay after the last character of the last position of this single wrapped line)

[Meta Chuh]

typo:

the first press of shift+end marks from the cursor to the end of the first wrapped line including the last character.
(so if it is wrapped into 3 lines, it will mark the first line only, but with the glitch that if it doesn’t have any spaces it will miss the last char)

the second press of shift+end should work fine and mark the whole wrapped line.

[Scott Sumner]

Good documentation for what @Meta-Chuh is talking about (the general proper behavior, NOT the bug) may be found here . The SCI_... names are used directly in Notepad++ (see the Shortcut Mapper’s Scintilla commands tab).

[Meta Chuh]

@Scott-Sumner

if i read correctly in between your lines, you’re right, neither my post nor the documentation is something easy to understand unless you try out everything.
so i followed your lead and did a screen capture video:

the first shift+end marks down to the penultimate character of the first line of a long, wrapped line without any spaces

the second shift+alt marks and select the whole wrapped line block, including the last character

btw: i personally don’t see any bug in this behaviour, just the glitch that the first shift+end leaves out one character, but only if the whole wrapped line doesn’t contain any spaces or other wrap point characters, due to how the wrapper itself works.

[Meta Chuh]

https://i.imgur.com/ncGFJ9s.gif

btw: what’s the nodebb syntax to embed this animated gif so that it’s preview is animated ?
i used ![alt](https://i.imgur.com/ncGFJ9s.gif)

[Scott Sumner]

@Meta-Chuh

i personally don’t see any bug in this behaviour

I agree. I started a posting saying so but I clicked “Discard”. Now that you’ve said it, I’ll concur. :-)

[PeterJones]

@Meta-Chuh ,

btw: what’s the nodebb syntax to embed this animated gif so that it’s preview is animated ?
i used ![alt](https://i.imgur.com/ncGFJ9s.gif)

That’s the correct syntax. It is animated and embedded in your first post, for me.

[Meta Chuh]

thanks @PeterJones

at first i didn’t see it animated right away after posting it.
only a full page reload triggered the image flipping.

i think it’s probably a browser related restriction (safari)
the gif flipping does not seem to initiate if it has been loaded via ajax/xmlhttprequests to an already rendered canvas.