Fix not ending at correct point after <return> #5
Conversation
the <END> is needed to cement the additions, apparently but we need to issue a '^' and then start insert mode, so we're on the first char of the new line with insert mode active Note that 'r' to insert a newline does not go through our extension in any way, so user has to be "aware" to do it using insert and return
we need to distinguish between the <CR> having been pressed at the end of The line -- in which case, we'll be positioned correctly already -- and in the middle of the line -- in which case, we have to reposition at the beginning of text on the line, because the cursor is "behind" the text that used to be in front of it prior to the <CR>
|
added a commit which behaves differently depending on whether the happened at the end of a line (ie it will insert a brand new line of text) or in the middle of a line (there will be some text we bring with us hanging after the new cursor position). the repositioning at first nonblank now only occurs in the latter case. |
Otherwise, it can result in strange artifacts in quickfix, and in the cmdline-window mode. Any buffer with a buffer-local '&buftype' that's an empty string, is a regular file being edited, where we would like to be enabled. Other buftypes, there's no reason for stabs to be enabled on CR (mostly these are file types which are ephemeral read-only buffers, cmdline-window mode is really still line-based and enter modifications don't make sense). The only one maybe is scratch buffer, but <CR> would still be usable there and it's better than maintaining a list of exceptions since just empty buftype solves 99% of use cases
|
Added a commit that only implements the extra |
|
<comment copied from #3 @intelfx>
At first glance, that seems like it might work. I tried it just now, and it does seems to work fine. Although, it does the same thing (just more concise). I can update my patch if it matters, but it looks like you're using your own version anyways (with other changes), so I'll probably just leave it if you have no plan to use my patch directly, as I'm indifferent about the verbosity of that operation. |
Not necessarily, the plugin I'm using now interacts badly with other things I have — there might be need for further patching, and given so, I guess I'll switch to the better-maintained version (this one). EDIT: yes, I'm definitely switching to vim-stabs as it offers more control over mappings 😅 |
|
(Yeah, sorry, I should not have posted that question on the issue...) Replying to you over at #3:
So I've tried this example and I can't reproduce the problem if I remove FWIW, my Vim is $ vim --version
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Aug 01 2024 20:46:30)
Included patches: 1-648
Compiled by Arch Linux
Huge version without GUI. Features included (+) or not (-): |
* commit '7fbb97ff3dec9607525b20824718ab469d3741d9': Make sure <CR> does not do anything except on regular buffers After <CR> behaves differently whether at end of line already Fix after CR we should be at the new inserted position with insert on [intelfx: cleanup, use less verbose map rhs]
After `<CR>` in insert mode, the indent is corrected, but we do not resume insert at the beginning of the corrected line, instead we resume at the end of the line, which is not what we want (for cursor to be positioned exactly where we split the line, but on the new line). See complaints in Thyrum#1. This patch attempts to fix only the `<CR>` case; we still might want to fix other cases later. * commit '7fbb97ff3dec9607525b20824718ab469d3741d9': Make sure <CR> does not do anything except on regular buffers After <CR> behaves differently whether at end of line already Fix after CR we should be at the new inserted position with insert on [intelfx: cleanup, use less verbose map rhs]
It does not _seem_ to do anything in my tests... Link: Thyrum#5 (comment)
|
I'm pretty sure the maintainer of this repo is not going to merge my PRs since they already merged a typo fix written at the same time, but made no comment on the other ones I submitted. 🤷 The toggle/on/off one in particular is essential for me, as there are many cases that come up where it needs to be disabled. The function I gave a sample of was from the https://github.com/gwsw/less repo I just tried it again with vim-stabs master, removing only the In any case, if my version of the patched function works for you also, then I would question the reason to use a simpler one, since in that case my version covers more variants. |
Submodule .vim/bundle/vim-stabs 66a4520..d54457a: > plugin: get rid of superfluous `<END>` > Merge pull request Thyrum/vim-stabs#5
After
<CR>in insert mode, the indent is corrected, but we do not resume insert at the beginning of the corrected line, instead we resume at the end of the line, which is not what we want (for cursor to be positioned exactly where we split the line, but on the new line). See complaints in #1. This patch attempts to fix only the<CR>case; we still might want to fix other cases later.