Caret not visible if "Go to -> Offset" is EOL

[Yaron10]

STR:
Open a file formatted in "Windows (CR LF)".
Open the "Go to" dialog.
Select "Offset", enter an EOL position and run it.
(For example: 149 in stylers.model.xml).

Result:
The caret is not visible.

(It also happens when opening NPP from the Command Line with the argument -p).

---

Notepad++ v7.9.1 (32-bit)
Build time : Nov 2 2020 - 01:03:56
Path : C---\notepad++.exe
Admin mode : ON
Local Conf mode : ON
OS Name : Windows 7 Enterprise (32-bit)
OS Build : 7601.23964
Current ANSI codepage : 1255
Plugins : ComparePlus.dll HTMLTag_unicode.dll MenuIcons.dll PythonScript.dll _CustomizeToolbar.dll

[sasumner]

(For example: 149 in stylers.model.xml).

So for Windows (CRLF) files, the position between the CR and the LF is treated specially. In other words, you can't normally "get there".
You can see an example of this by turning visible line endings on and trying to move the caret through the line-ending part.
It won't place the caret between the CR and the LF.

Maybe this is another example of "what is position, really?"
Scintilla has one notion; perhaps I have a different notion.
Notepad++ might have something different as well. :-)

I think "position" should be purely user-level. No notion of a unicode character (potentially) taking up 4 "units" of position, and perhaps no notion of CRLF in Windows files taking up 2 "units" of position?? Hmm.

More about position here: #9095
More about related things (encoding/position/bytes) here: https://community.notepad-plus-plus.org/topic/20218/tests-and-impressions-on-the-view-summary-functionality
and here: https://community.notepad-plus-plus.org/post/59379
Also maybe relevant: #9101

[Yaron10]

So for Windows (CRLF) files, the position between the CR and the LF is treated specially. In other words, you can't normally "get there".
You can see an example of this by turning visible line endings on and trying to move the caret through the line-ending part.
It won't place the caret between the CR and the LF.

I realized that.
But the caret must be visible as is the case in "trying to move the caret through the line-ending part".
Perhaps the simplest solution should be programmatically executing "Arrow-Right" and then "Arrow-Left".

Maybe this is another example of "what is position, really?"
Scintilla has one notion; perhaps I have a different notion.
Notepad++ might have something different as well.

I think that "Pos" should be "number of characters BEFORE the caret + 1".

No notion of a unicode character (potentially) taking up 4 "units" of position.

This seems correct.
And int currPos = static_cast<int>(_pEditView->execute(SCI_COUNTCHARACTERS, 0, _pEditView->execute(SCI_GETCURRENTPOS) + 1)); should be better.

no notion of CRLF in Windows files taking up 2 "units" of position

The currently implemented "Pos" is correct in this case: it shows the number of characters BEFORE the caret + 1.
(And would still be correct if changed to SCI_COUNTCHARACTERS).

[sasumner]

BTW, perhaps I shouldn't derail this issue.
It's perfectly valid.
What's your suggestion @Yaron10, for if a user enters an offset that would put the caret right in between a Windows line-ending's CR and LF?

[Yaron10]

if a user enters an offset that would put the caret right in between a Windows line-ending's CR and LF?

The caret should be visible at the end of that line. IOW: simulate manually placing the caret there.

Perhaps the simplest solution should be programmatically executing "Arrow-Right" and then "Arrow-Left".

This wouldn't work properly if there isn't a line below. :)

[sasumner]

if a user enters an offset that would put the caret right in between a Windows line-ending's CR and LF?

The caret should be visible at the end of that line. IOW: simulate manually placing the caret there.

In developing a solution for multibyte UTF-8 characters (for 9101), it made sense that if a user tries to offset into the middle of a multibyte character, the caret would be placed after that multibyte character.
The same solution works for this issue, but it places the caret after the LF when offsetting into the middle of a CRLF pair. And that means the caret will be placed at the start of the next line. I hope that isn't a critical problem for you, but I think I will move ahead with that solution.

[Yaron10]

Continued in #9101 (comment).