I'm using Geany as a graphical text editor, and I installed the vimode plugin so I can use Vim shortcuts. However, whether or not I have the "Enable Vim Mode" box under Tools checked, none of the shortcuts work. The editor behaves as if Vim Mode doesn't exist, so there's no command mode or insert mode, just a regular text editor. The only thing that changes is the cursor, so it looks like I'm in insert mode even when I'm not.
I couldn't find anything regarding this issue in the Git repository, so I'm not sure if this is intended behavior and I'm simply missing something or if there's a legitimate problem. Starting it from a terminal doesn't show any error output related to Vim Mode either, so I'm not sure where to look for more info or how to proceed from here.
_Linux debhejm 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) x86_64 GNU/Linux OS: Debian GNU/Linux 12 (bookworm) x86_64 Host: HP Pavilion g6 Notebook PC Shell: bash 5.2.15 DE: Cinnamon 5.6.8_
I seem to understand. The problem is NumLock. If I turn off numlock, then vim mode works. If I enable NumLock, then vim mode doesn't work. Obviously this is a bug. We'll have to put up with it until this problem is fixed. It would be nice to write about this problem in the README so that other users are aware of its solution.
Closed #1248 as completed.
Reopened #1248.
Confirm hjkl insert do not move cursor, and : inserts even after esc or ctrl+c (and thats all the vi I remember, my "vimit" you might say). Current git Geany and plugin.
Confirm hjkl insert do not move cursor, and : inserts. Both even after esc or ctrl+c (and thats all the vi I remember, my "vimit" you might say). Current git Geany and plugin.
[Edit: AFAIK my Linux Mint Cinnamon window manager does not eat esc or ctrl+c]
I can't test the "hjkl" keys because I can't get into command mode. The "esc" key and "^C" do not work. I can't get into command mode anyway. However, when I disabled numpad, Vimode worked. When numpad is enabled, Vimode does not work. Obviously this is a bug that needs to be fixed.
@techee #1141 does not appear to have been merged yet?
Closing this as duplicate of #1136.
Closed #1248 as completed.
@techee https://github.com/geany/geany-plugins/pull/1141 does not appear to have been merged yet?
I was waiting for for @frlan if he wants to merge it or have a look at it but I guess he doesn't have time.
I think both #1139 and #1141 are quite important as they are serious regressions - should I merge them myself?
IIUC the geany-plugins project manages the collection parts, the individual plugins are the maintainers responsibility.
So I would say after more than a year its ok to merge to your own plugins, but not other peoples plugins without discussion with them.
@frlan could give his opinion, but I agree with @elextr : the plugins themselves are the responsibility of their maintainers, not really @frlan that can't know them all inside out anyway.
And as a maintainer, although I am fine with people merging stuff to plugins I maintain when I clearly don't have time (which I clearly don't 😅), I'd still rather review and merge myself when I can so I know what I'm maintaining kinda.
The only gray area would be quality control as the bundle is kind of a whole expected to behave, but we didn't have this kind of problems in the past I think (but for the unfortunate yet expected bugs that will sneak their way in no matter what anyway, but none of it was gross negligence nor malice), so I don't think there's any reason to be rigid in this area yet.
Yeah, I merged all I could from projectorganizer and vimode yesterday ;-)
Regarding quality control I think I could have prevented some of the vimode problems before the release if the PRs got merged to master earlier as I didn't notice the issues when I worked on the individual PRs and then never checked out later myself. So having things merged earlier before the release could improve the quality because someone, including me, is more probable to notice the problems.
github-comments@lists.geany.org