Copying discussion from #640.

From avih:
Somewhat related, I don't see it documented (neither in the help page nor the manpage, that I can tell), but apparently the HOME key jumps to the first line, but not the first column.

If I may suggest, make HOME jump to the first column (just like in line edit mode), and ctrl+HOME jump to the first column of the first line, which is a common key combination in GUI apps.

Similarly, currently END goes to the curret column at the last line, so it might be replaced with ctrl+END going to the first column of the last line, and maybe END should go to the end of the current/top line if it's not shown fully, i.e. scroll right or left so the the end of the line is at the last column, and if the line fits at the terminal width without scrolling, then goto first column.

The "or left" part is in case we're scrolled right beyond the end of that line, so this will make the end of the line visible.

I guess it can be debatable whether ctrl+ HOME/END should also go to the fist column, but oherwise HOME/END affecting the column while ctrl+ HOME/END affects the line feels more useful and consistent (with line editing and other applications) to me compared to the current behavior.

From gwsw:
Regarding the HOME/END issues, there are already commands to go the first column (ESC-{ or ctrl-LEFTARROW) and to go to the last column (ESC-} or ctrl-RIGHTARROW). Using ctrl plus the arrow keys for the maximum shift seems consistent with using the arrow keys for incremental shifts. ctrl-HOME and ctrl-END could be defined as aliases, except that I don't think there are terminfo entries for these key combinations, so it would be difficult for less to define actions for them.

I'm not sure about making HOME and END (which are aliases for g and G) go to the first column. The user might be viewing a table with long lines, shifted to make, say, columns 100-180 visible. Obviously scrolling up and down should retain the shift. Moving a page up or down should also retain the shift. I would argue that doing a larger jump to a specific line number should also retain the shift, since the user may be wanting to continue viewing lines 100-180 of the table at the new position. And jumping to the beginning or end of the file are special cases of jumping to a line number. Treating a jump to the start of the file differently than jumping to any other line seems unexpected behavior. In any case, the behavior of g is long-standing, and making it behave differently in different versions of less seems like it would lead to confusion.

From avih:

I agree with the first point about --incsearch. This is fixed in 342a086.

Thanks. Confirmed working after courtesy testing.

Regarding the HOME/END issues, there are already commands to go the first column (ESC-{ or ctrl-LEFTARROW) and to go to the last column (ESC-} or ctrl-RIGHTARROW).

I know, and I wasn't asking to remove those.

But since HOME/END are not yet documented in "less" (except line editing where they control column), and in the vast majority of applications they're control the column, I think people expect HOME/END to control the column in "less" too, but currently they control the line.

ctrl-HOME and ctrl-END could be defined as aliases, except that I don't think there are terminfo entries for these key combinations, so it would be difficult for less to define actions for them.

Not sure whether you refer to user-defined aliases or builtin aliases (and same goes for plain HOME/END without ctrl), and obviously the user can define preferred aliases for anything they want, these functionalities included (nav to first/last line/column).

But the goal of this suggestion is to improve the default behavior our of the box, to better match user expectations, and allow them to use these common navigaion keys without having to read the docs to know, for instance, that ^{ does "HOME", and shift+g does "ctrl+END".

And since HOME/END and ctrl+ HOME/END are not yet documented, "less" can help new users (and long time users too) by maping those to their common functionality elsewhere, and in "less too" (in editing more).

As for ctrl + HOME/END not easy to identify/bind, you know this better than me. If it's not possible then that's it.

I'm not sure about making HOME and END (which are aliases for g and G) go to the first column. The user might be viewing a table with long lines, shifted to make, say, columns 100-180 visible.

Yeah, that's why I said it can be debatabe. I understand this use case and don't intend to debate it.

However, they don't have to be aliases to g/G. g/G can go to first/last line without changing the column, while ctrl + HOME/END (if it's possible to bind them) could match the common behavior of these combos.

But I did test it again elsewhere (few editors, and the Firefox text input box where I write this message), and it appears that ctrl+HOME is like I requested - the begining of the document, i.e. first column of the first line, while ctrl+END is the end of the document, i.e. LAST column of the last line (in contrast to what I requested previously - first column of last line).