Cursor stays in place when inserting text in a new file

[erf]

Cursor now stays in the same place when inserting text in a new file.

How to recreate:

1. open a new file
2. press i to insert text
3. enter some text hello
4. cursor stays at first position h

This seem to have been introduced in commit: c22b2c2

[tosch42]

I can reproduce this.

It even gets worse. As long as there is only one line in a file, movement doesn't work properly. Pressing o works and somewhat "fixes" the restraint movement. But when I hit l after that, the cursor jumps to the beginning of the first line. I strongly recommend reverting this patch for now since it introduces more bugs than it fixes.

[Disonantemus]

Cursor now stays in the same place when inserting text in a new file.

How to recreate:

1. open a new file

2. press `i` to insert text

3. enter some text `hello`

4. cursor stays at first position `h`

This seem to have been introduced in commit: c22b2c2

I'm still experiencing the same, last git:

> vis -v
vis v0.7-74-gc9737a7 +curses +lua +acl

Box:

OS: Arch Linux x86_64
Host: MS-7816 2.0
Kernel: 6.1.14-1-lts
Terminal: tmux
CPU: Intel i7-4790 (8) @ 3.600GHz
GPU: AMD ATI Radeon RX 470/480/570/570X/580/580X/590
Memory: 2897MiB / 15939MiB

[rnpnr]

Yes, #1087 hasn't been merged yet. You can apply it locally in the meantime to get back up and running.

[mcepl]

Or you can use my fork at https://git.sr.ht/~mcepl/vis which has it merged in its master branch.

[Disonantemus]

Yes, #1087 hasn't been merged yet. You can apply it locally in the meantime to get back up and running.

I'm no programmer, I just create github account to report issues.
I don't know how to do that. Sometimes I just do: git clone <asdf>
but I don't know how to merge with git or understand that.

[mcepl]

@Disonantemus you build vis yourself, right? If so then just do git clone https://git.sr.ht/~mcepl/vis instead of cloning from this GitHub repo and build the program.

[Disonantemus]

@Disonantemus you build vis yourself, right? If so then just do git clone https://git.sr.ht/~mcepl/vis instead of cloning from this GitHub repo and build the program.

Thanks, I'm using your repo now!

[ninewise]

#1087 was merged, sorry for the wait. Do reopen should further problems ensue.

[mcepl]

Awesome, one commit merged, fourty-two to go (including massive undertakings like #1039 from Aug 31, 2022)!

[ninewise]

Matěj Cepl ***@***.***> wrote:

Awesome, one commit merged, fourty-two to go!

I've mentioned before I maintain vis for fun, mcepl. Please stop trying to take every bit of fun out of it with sarcastic comments. Being nice in your interactions with other people isn't hard. I value your contributions but this is not OK.

[mcepl]

Matěj Cepl @.***> wrote:
I've mentioned before I maintain vis for fun, mcepl. Please stop trying to take every bit of fun out of it with sarcastic comments. Being nice in your interactions with other people isn't hard. I value your contributions but this is not OK.

Being nice means also not standing in the way of others when they want to help, being nice means stepping down when you are not able to help any more, being nice means to apologise when you have not been able to click [Merge] button for two character change since August last year (perhaps you have not noticed it, but this is not https://github.com/ninewise/vis, you were entrusted with some responsibility you completely failed to honour). Being nice doesn’t mean that you are the only one who is right and everybody else have to accommodate your whims. Being nice means not to preach to others that they should behave better when it is all about your problems.

Anyway, I am done here. I will pull your master and rebase on it, but otherwise I will just work on my fork, because this one you killed.

[ninewise]

I'm sorry my lack of time is so frustrating to you, and that it comes to this.

Do you mind me checking on your fork which patches you've merged, as a guide to which I can merge more easily here?

[mcepl]

Of course, that’s the whole point of me maintaining the fork … I hoped to be able to authoritatively say which commits are if not well done (I am not that good C programmer and I don’t understand internals of vis enough to be able to say that), then at least which are harmless. master branch should be something which could be merged here in my opinion, devel is slightly more adventurous (but that’s what I am using). And that’s what makes it so frustrating … I am fairly certain that those forty-two commits to go should be at least benign (if not actually helpful, like e.g., #675 which allows whole list of interesting plugins, e.g., https://gitlab.com/muhq/vis-lspc). So, take whatever you want, those commits are not my copyright anyway.