% should not move cursor

[losnappas]

It's really inconvenient to press % and get taken to the last line.

And if I do <c-s>% and then hit <c-o>, my selection clears...

[alexherbo2]

It’s not possible. The main cursor is always visible.

[eraserhd]

Then the question might be, "should the main cursor always be visible"? Or perhaps, "are there other ways to keep the main cursor visible (e.g. some kind of folding) without losing the user's place?" There are some ideas in #2727 that might be relevant here.

[jbomanson]

This issue is something that has bothered me a bit also.

Recently, I have been using the below mapping as a workaround in v2019.01.20. The mapping selects all lines separately in such a way that the cursor stays on the same line. That way the view port does not move. It is not a 100% replacement of % though.

map global normal <pick-some-key> %[:execute-keys "%%<lt>a-s<gt>%val(cursor_line))"<ret>]

[losnappas]

It’s not possible. The main cursor is always visible.

But if it didn't move the cursor and just selected text? Is that possible? Might be a nice feature for selecting other text objects as well. However, I can't think of a way to do this right now, so maybe the capability is not there. And I can see it opening a Pandora's box: "why does x not move but y does?"

[losnappas]

Actually, I figured it out.

1st select from cursor to start, save selection, then go to selection end , go forwards one, select to end and combine the selections, go forwards one selection, and BAM you're where you started with everything selected in 2 selections.

[jbomanson]

@losnappas Perhaps you already implemented your idea, but I could not resist giving it a try myself. The following selects everything until the cursor and everything after it.

execute-keys -save-regs a '<space><a-:>Zgg<a-z>uZl"aZge"a<a-z>u<a-z>a)'

EDIT: Originally this post contained the following code, but I found that it is buggy. It worked only when the anchor preceded the cursor and the cursor was not on a newline.

select "1.1,%val(cursor_line).%val(cursor_column)" "%val(cursor_line).%sh(expr $kak_cursor_column + 1),%val(buf_line_count).2147483648"

[nonumeros]

select "1.1,%val(cursor_line).%val(cursor_column)" "%val(cursor_line).%sh(expr $kak_cursor_column + 1),%val(buf_line_count).2147483648"

@jbomanson I like it, but what is.. if you could tell me what does the digit one means after the incremental operator? the arabic numeral one from +1. I have problems with numbers overall. What does it stand for? It limits jumping.

[lenormf]

The main selection has to be always visible, the same way the view always follows the cursor in other editors. It's consistent with other primitives moving the view as they are expected to, e.g. j, k, and making an exception for a primitive whose point is to create a selection would break that consistency.

You could map % to %<a-\;>, which would send the cursor back to the beginning of the file without losing the selection.

[mawww]

In the current design, we cannot select anything without moving the cursor, a selection is defined by two positions, the cursor and the anchor, and contains everything in-between (them included).

[alexherbo2]

One amelioration possible is to recenter the cursor when the view shifts horizontally.

Example – Press x twice on the following text:

some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line some-very-long-line
a-short-line

[lenormf]

Specific changes in the view like aligning in the middle of the window can be done with the v primitive, for instance v-m. It's also a different topic than the one discussed here.

[andreyorst]

The issue can be solved if we change the title little bit:

The view should not move when selecting contents with %

Kakoune has the v feature that goes into this View Mode, and I find it practically useless because it can't move anywhere beyond the cursor. Sure it is good for re-centering cursor, but that's not view mode. View mode should allow to view the file without moving the cursor, like in any modern GUI editor. It would be even better if we could evaluate commands while staying in view mode, like % or s. It will not move our viewpoint anywhere.

If View mode would allow this, we will be able to map % to v% or V% and simply select whole file after entering view mode.

[lenormf]

@andreyorst the current view mode's entire point is to shift the current view in relation with the position of the cursor, its purpose is entirely bound to the editor's paradigm (which is that the main cursor is always visible).

Your definition of "view mode" points to a different paradigm, and just because we put both paradigms under the same generic term "view" doesn't mean that one is useless and the other not, regardless of what "modern GUI editors" implement.

Implementing a free-flowing view mode is non-trivial I reckon, since the server really expects to have the precise dimensions of the area whose data it will handle, and the code would have to be made not to assume selections need to be moved around upon shifting the view. Maybe this could be hacked around in a PoC entirely implemented in the UI (report a very tall rendering area to the server, but only display parts of it according to the user's scroll level).

[andreyorst]

@andreyorst the current view mode's entire point is to shift the current view in relation with the position of the cursor, its purpose is entirely bound to the editor's paradigm (which is that the main cursor is always visible).

This makes it more like positioning mode, not view mode, because you can't view past the cursor but able to position the view in different ways.

So for example, if I want my cursor to be first line of the screen, last, or center line, this mode is good, but if I want to view long lines without wrapping and my cursor is sitting on the very first cell, I can't view without moving. I rarely using anything from view mode but vt, vb and vv because of that.

However, by allowing view mode to go past the cursor we will not loose any essential functionality, like view positioning, and only get new possibilities like ones I've described in the previous comment. Therefore I disagree with the next statement:

Your definition of "view mode" points to a different paradigm

This is not different paradigm. This is not a stripped down paradigm.

Implementing a free-flowing view mode is non-trivial I reckon, since the server really expects to have the precise dimensions of the area whose data it will handle, and the code would have to be made not to assume selections need to be moved around upon shifting the view.

I've thought it's long term goal not to tie to the visual information at all.

[lenormf]

Keeping the main cursor in the view at all times is a paradigm, what you're describing is just part of your different interpretation of what "view mode" is - we don't need to replace anything currently existing, but rather add to it.

[jbomanson]

select "1.1,%val(cursor_line).%val(cursor_column)" "%val(cursor_line).%sh(expr $kak_cursor_column + 1),%val(buf_line_count).2147483648"

@jbomanson I like it, but what is.. if you could tell me what does the digit one means after the incremental operator? the arabic numeral one from +1. I have problems with numbers overall. What does it stand for? It limits jumping.

I updated the code that I posted because I found bugs in it. The +1 was supposed to make the second selection start from the character after the cursor.

[andreyorst]

Keeping the main cursor in the view at all times is a paradigm

I've stumped through various Kakoune materials and didn't found where this was explicitly stated. If you can point me to this information I'll be glad, because it means that I'm missing some essentials.

The "Improving on the editing model" section of "Why Kakoune?" only states that you're always see the feedback of the thing you're editing, and this doesn't interfere with what I've proposed, because if you do V%s you'll see whole selection of current buffer in the same manner when you see it normally with only difference that your point of view will not move. And when you select something with s and hit ret the view will be moved to the main cursor, much like it is currently done.

[andreyorst]

You're welcome #2982 (comment)

How your comment is related to what I'm asking for?

[andreyorst]

Your are looking for

3.1. Selections

The main concept in Kakoune is the selection. A selection is an inclusive, directed range of character. A selection has two ends, the anchor and the cursor.

There is always at least one selection, and a selection is always at least one character (in which case the anchor and cursor of the selections are on the same character).

I've referenced this text too, and I don't see how does this say that cursor must always be visible? The selection must be visible, sure, but it doesn't explicitly mean that we must see the cursor. Here's whole buffer selected with anchor on the first char and cursor on the last. The view scope is what we see:

[A]nchor

--------- view scope start

--------- view scope end

[C]ursor

Selection is still visible in the view scope, so it still meets these conditions:

• inclusive, directed range of character;
• two ends, the anchor and the cursor;
• always at least one selection, and a selection is always at least one character.

What else do you need to know? If not the link I provided?

Ideally some place in Kakoune docs, design choices, e.t.c. where is stated that cursor must be visible always. Because I'm not sure that it is so.

No one on this project is probably able to tap into this as I am.

I don't really understand what you're talking about in this statement. The issue is that % should not move the cursor. It isn't possible because selection is everything between the anchor and the cursor. So to select whole buffer we need to move both cursor and anchor. However I don't see why view should be moved with the cursor. And the main problem in this issue that the view is moved to the end of the file:

t's really inconvenient to press % and get taken to the last line.

So by allowing view mode to be independent from cursor position this issue could be solved by mapping % to V%.

[andreyorst]

The issue is that % should not move the cursor.

Can't follow you.

Then consider following the original text of the issue.

However I don't see why view should be moved with the cursor.

You want the view to be moved with an anchor? By itself. That's funny as in far-fetched.

I do not know how you came up with this statement when I clearly said that the idea is that view mode isn't moved with anything, as was shown in the example.

Which goes back to the chicken egg causal dilemma of

Implementing a free-flowing view mode is non-trivial I reckon, since the server really expects to have the precise dimensions of the area whose data it will handle,

Once again, if Kakoune will not be tied to visual information this will not be a problem. And AFAIKS it's one of the long term goals, so considering this is an option.

What editor is this? Please don't say Visual Studio... Sublime?

Any GUI editor actually, with some exceptions of really old editors like Emacs or Acme, because of it's terminal origins, where hardware cursor must be on screen. Kakoune hides hardware cursor and draws its own cursor, so this isn't a problem here. But to answer your question, here's a brief list of editors, not including the ones that you've already mentioned (Visual Studio is an IDE, not editor): Gedit, Kate, VSCode, Atom, Brackets, Notepad, Notepad++, Pluma, Scratch, the list can go on and on.

Please, don't try to have new ideas. Your necessity is not a necessity. And whoever else convinced you to do so, give them a lollipop.

I'll consider this. Never thought of having not to have new ideas. It's cool new idea actually. Wait...

But given that this isn't new idea of mine, and I'm not only one who thinks about this feature for a long time already, I do not know who deserves a lollipop.

---

This starts to look like a more personal discussion that goes away from the topic. If you want to continue it, we better move it to the discuss.kakoune.com if you don't mind.

[andreyorst]

What part about

selection with c-o clears

didn't you quite understand?

This works correctly: user saves the one character selection with <c-s>, then selects the whole buffer with %, and restores one-char selection with <c-o> that was previously saved dismissing the selection of the whole buffer.

If you had a request of getting a buffer selection positioning aligned, then another issue must have been opened accordingly.

I do not have this particular request, I just propose a solution of different problem that will also fix this issue, and instead of breaking what already works as it should, we need to extend the abilities of the view mode. Because the main part of the issue is that the View moves with the cursor.

I'm not saying your particular issue is not as important, but I don't think there was a need to suggest a title change, and I'm assuming that if a title change would have occurred, I wouldn't be the least surprised if further editing may have followed soon after.

I meant that if we look on the problem from the different angle, as I did, and proposed this solution, then this isn't a problem really.

[andreyorst]

What gets dismissed? nothing should be dismissed, you have to get that idea of dismissal out of your head altogether. With c-o and c-i respectively, and as long as c-s is used accordingly, no dismissal should have occurred along the way.

who said you have to clear the selection?

Now I see it. You expect <c-o> to work in a different way. Here's what documentation says about saving and restoring selections:

Some commands, like the goto commands, buffer switch or search commands, push the previous selections to the client's jump list. It is possible to skim through the jump list using:

<c-i> jump forward

<c-o> jump backward

<c-s> save selections

So, let's apply this to the original problem.

• User saves current selection, which is only the cursor, which means that cursor and anchor share the same position. This selection goes into jumplist.
• User selects whole buffer, creating new selection with anchor at the beginning of the file, and cursor in the end of the file.
• User presses <c-o>, telling Kakoune to restore selections from the jump list. Kakoune restores previous state of selections from the jump list.

What do you expect from existing selections to do in this situations? To stay? We are loading saved state of selections from the list of selection states. You can't load one selection state on top of another in current implementation. If that's what you want, then you should describe the problem in this way.

It's like you play a game with quicksave option, and you do a quicksave, then go through the game, complete the quest, and load your previous quicksave. Your progress will not be added on top of that save state, your progress will be dismissed.

Also another thing is that selection can't overlap, so you can't have selection in the middle of another selection like so:

[   {}   ]

Only like so:

[   ]{}[   ]

So if you want <c-o> to split your current selection in two or more selections in order to add previous selections to it, that's again another problem that doesn't possible in current implementation, because we do not have such operators that has Vis editor, which allow to take difference of two sets. Besides, if you save multiple selections, and select whole buffer, do you expect all these selections to be restored inside main selection? This again needs the some kind difference operator which we do not have currently.

Don't assume and you should know better by now that the buffer may or may not have been cleared - or as you said 'dismissed'.

Buffer contents getting cleared has nothing to do with current situation and a completely different case.

The problem with selections start at another level whenever these selections are consequently saved, and whenever newlines come into play

Newlines aren't related to the fact that selection restored from the jumplist effectively clears current selection. If you save your selection in the middle of the line, and select whole line with <a-h><a-l> and restore your previous selection, or more precisely go to the previous position in the jumplist with <c-o>, your selection of the line will be dismissed.

[Delapouite]

No wonder I left discuss.kakoune.org for good

You're getting insulting here. If you can't restrain from this kind of remark in the future, I don't think you're a welcome addition in the community.

[daboross]

@nonumeros sad to see you go!

From what I can tell, you and @andreyorst had different, conflicting ideas for solving this problem, and that got fairly heated?

You believe that the way forward is to separate "what's selected" and "where is the cursor". This would allow having <c-s>%<c-o> have the whole screen selected, but the cursor(s) in the same place as before the key combo. The screen would be looking at a similar part of the file, as the cursors would be in the same place.

@andreyorst wants to keep "what's selected" and "where is the cursor and anchor" intimately connected. They believe the way forward is to separate "what part of the screen is showing" and "where the cursor is". This would allow <some unknown key combo>%<some unknown key combo> to select the whole buffer (and clear selections) but keep looking at the code that was being looked at before.

@nonumeros, If you don't mind commenting one more time, would you mind confirming if I have your idea written down correctly?

I want to understand both sides of this, since they both look like valid (but very different) solutions to the problem at the top of this thread. Looking at the merits of both seems like a good idea. But if the ideas are misunderstood, then that isn't possible.

If I'm butting in on this issue (and argument?), my apologies for that.

@andreyorst I'm slightly more confident I understand your proposal. But if I've written it down incorrectly, could you correct it?

(edit: @Delapouite, apologies for incorrectly pinging you on this! I somehow got you and @andreyorst confused for a second when writing this post and trying to understand the different solutions to this.)

[nonumeros]

@daboross thank you for the constructive remarks amid my own self-destructive posts. But is no secret that some decisions have been made in the past, that have not been the wisest and I despise when someone just might say ' shit happens' because is not just shit that happens, but is their shit that happened, and not mine.

On the other hand @Delapouite reacted prematurely, as if I was getting insulting, which I wasn't, but rather apprehensive cautious towards all sort of suggestions such as let's-reframe-the-title of the issue to reppity-mappity-do solutions.

I just don't understand why on this time and age , the discussion should be constrained to a silly remapping of some keys, be it with an infamous v% or much less V% as suggested by @andreyorst or whoever planted that idea onto him. The real problem - or so I naively think - is the design decision by which cursor and anchor begin and end.

For example, if you were to look at the selections on the screen - assuming of course, that multiple selections were even combined onto one - , some common sense tells me that most likely you'd be looking at the centered area of that screen. Or you' would certainly try to, as I'm sure is the case with most users. What 'good' does it do, notwithstanding the validity where the cursor and/or the anchor should be visible at all. I personally can care less if is at cursor' s end, where the selection must begin, as long as the view is not at the bottom's end.

Wih the same token even a blinking cursor or a scrollbar as mentioned at https://github.com/mawww/kakoune/issues/2727 are also irrelevant here if the first issue is not resolved accordingly.

[mawww]

I am always sorry to see users go away from Kakoune, especially at this time where I cannot dedicate as much time to it as I used to (young kid in the house, second one on the way...)

There are two issues conflated into one here:

• The representation of selections as an inclusive (cursor, anchor) pair: this is a relatively early decision which most of the editing code assumes, there are definitely trade-offs there, such as the long discussion we had about the impossibility of empty selections in Kakoune. It is not perfect, but it is very unlikely to change at this time, and I think it did prove quite practical.

• The fact that the cursor must always be visible. This is not as strongly embedded into Kakoune but is still not that easy to change (we place the hardware terminal cursor at this position to allow for "over-the-spot" style IM methods). This is much more up for debate, the current logic is simple (always keep it visible), we could have some commands that do force visibliity (mutation to the buffer for example, rotating the main selection...) and some that do not (select the whole buffer). But I am afraid it would be hard agree on which should and which should not.

[nonumeros]

I am always sorry to see users go away from Kakoune,

Don't need to be sorry for an end-user @mawww ...But I appreciate your lead camaraderie.. and I can hang around

(young kid in the house, second one on the way...)

My grandparents also had no TV and thus had the same issues than yours.

force visibliity (mutation to the buffer for example, rotating the main selection...) and some that do not (select the whole buffer

I find folding decrepit by all counts. I don't even use it on vim, since it might lead to error-prone during a simple editing. But I must confess that I'm at a loss when you say 'rotating the main selection'

[cskujbus]

Related to %: It would be nice to have a go to previous cursor position, like in other editors. I know that there is g. which goes to the last modification position, but that's not the same. The g- could be: go to the previous cursor position. When editing a large file and I want to type a % character in the text, but I forget that I'm in normal mode, I'm screwed.