Zettlr: [1.8.0.beta2] vim mode shows only empty editor pane

[TS-CUBED]

Description

vim mode in new beta2 is broken (also in 1.8.0 alpha, beta, and beta1)

Reproducing

• start Zettlr 1.8.0beta2 with empty config dir
• open a directory with zettlr notes
• select a note -> editor shows note
• go to settings - Editor, select "Editor Input Mode" = "Vim"
• close and restart Zettlr
• select a note -> note opens (tab is displayed), but editor shows blank pane

Expected behaviour

• note should open in editor and vim mode active

Platform

• OS and version: Ubuntu 20.04 LTS
• Zettlr Version: 1.8.0 beta2

Additional information

[boring-cyborg[bot]]

Thanks so much for opening up your first issue here on the repository! 🎉 We would like to warmly welcome you to the community behind the app! ☺️ We'll check in soon and have a look at your issue. In the meantime, you can check your issue and make sure it aligns with our contribution guidelines! Here's the comprehensive list:

Enhancements

An enhancement takes a feature and improves or alters its behaviour. Please make sure to argue how your proposition will aid non-technical text workers, and why it can't be emulated easily with other features or apps!

Feature requests

Feature requests introduce whole new features into the app. This requires a lot of work, so these might be turned down if the implementation costs supersede the benefits we expect to see from implementing it. Please do not be disappointed if that happens. It likely has nothing to do with your great request but simply with us and our missing resources!
You can of course always ask someone to implement this feature, because a PR with a working new feature has much higher chances of being merged! :)

Bug reports

Please note that one of the main reasons for why bug reports cannot be addressed is that there's not enough information for us to find and fix the bug you describe, so make sure you try to pinpoint the bug as close as possible.
The ideal bug report for us has two qualities:

1. The bug is always reproducible, at least within a certain context. 2. We know exactly what specifically goes wrong, and there is consensus on
   what should happen instead.

Please note that if you encounter behaviour that does not align with your expectations of what would happen, this might as well be simply intended behaviour and we need to simply _clarify_ why the behaviour is the way it is. This is not to be considered a bug and such issues may be closed! Suggest an enhancement instead!
But now, have a great day and thank you again!

[TS-CUBED]

bug also manifests without restart:

• open note with editor input mode "Normal"
• note displays
• click in window allows note to be edited

• switch to editor input mode "Vim"
• click in window does not show cursor, note cannot be edited

[nathanlesage]

I've noted myself that the vim-mode exhibits some bugs. As stated on the website:

Note: The CodeMirror vim bindings do not have an active maintainer. That means that if you report bugs in it, they are likely to go unanswered.

This means I am pretty sure I cannot help you. I'm just loading the vim keybindings and using them.

[TS-CUBED]

The problem is only present in the 1.8 branch. It works fine in 1.7.5.
If the problem was with CodeMirror, wouldn't it show up in both versions?

[nathanlesage]

There have been updates to CodeMirror as well, so this might also be a reason.

[TS-CUBED]

Hmm, interesting. Based on your last comment I played around with this a bit. I am no JS developer, so take all of this with a grain of salt:

• cloned the Zettlr repo
• checked out 1.8.0-beta.2
• rolled back codemirror to version 5.56.0 (2020-07-20) - which is the same as used in v1.7.5
• yarn install, yarn start

• same problem - works without vim keybindings, but not with them.

• and on the other hand v1.7.5 works nicely with vim keybindings, if I compile it with codemirror 5.58.2 - which is the one v1.8.0-beta.2 will compile by default.

[TS-CUBED]

There seem to be a few problems with the package dependencies in 1.8.0 - could that be related?

[3/4] Linking dependencies...
warning " > @clr/[email protected]" has unmet peer dependency "@webcomponents/custom-elements@^1.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.37.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^4.0.0 || ^5.0.0".
warning " > [email protected]" has unmet peer dependency "webpack@^3.0.0 || ^4.1.0 || ^5.0.0-0".

[KarlClinckspoor]

Can confirm that this has happened to me as well. Needs to change the editing mode to Normal and restart the application. Emacs mode doesn't have this problem. Maybe the Vim mode entry should be removed until this issue is fixed in CoreMirror, for new users' sake? If someone wants to test, they change the mode like it was done before the dropdown list was added.

[nathanlesage]

Maybe the Vim mode entry should be removed until this issue is fixed in CoreMirror, for new users' sake?

I agree. The Vim mode right now doesn't have a maintainer, and I'm very much in favor of discontinuing the feature until someone has been found.

[bit-hug]

NB: This bug is now live in the stable release, and possibly quite scary for some people updating from 1.7.5 to suddenly see empty files in place of their previously open documents.

[bit-hug]

Also noted that @ianhi offered assistance with codemirror vim issues, apologies if no longer relevant!

[nathanlesage]

This bug is now live in the stable release, and possibly quite scary for some people updating from 1.7.5 to suddenly see empty files in place of their previously open documents.

You are absolutely right, and I should quickly discourage use of the VIM mode …

[bit-hug]

Maybe a comment in the release notes would be useful. I'm already missing vim mode, it's a really good feature even though it doesn't work perfectly...

[lukeallister]

For me, loss of vim mode is a dealbreaker. I'll be sticking with 1.7.5 until this is resolved.

[TS-CUBED]

Same here. I've moved on to org-mode, though.

The irony, moving back to emacs after over 20 years because my
Zettelkasten lost VIM keybindings ;-)

[lukeallister]

@TS-CUBED Too funny.

Do you have any sense of what's going on with Vim-mode, or where to look to try to fix it? I'm not a js developer (and have to finish grad school before starting any extra projects) but I might try to dig into this if we can't find anyone who actually knows what they're doing.

[TS-CUBED]

Not really. I'm also no JS developer.

I cloned and compiled 1.8 beta 2 with a rolled back version of
codemirror (the same as in 1.7.5) and the bug is there as well. So I
guess the bug is in Zettlr rather than codemirror.

The VIM bindings seem to work in other codemirror/electron apps as well.

But I don't really use Zettlr anymore - but my wife does, albeit without
VIM mode. I had already moved to NVIM with vim-wiki and vim-zettel
(which is compatible with Zettlr) and now to emacs with org-mode. But
that is a completely different beast.

[nathanlesage]

So I guess the bug is in Zettlr rather than codemirror.

That's an important thing. I'll have a look some time. But please know that VIM mode has no real priority, as the main target audience of Zettlr is non-technical folk either way, and I have worked with vim myself, and it's really only useful on the command line, not in a GUI application. That is subjective, sure, but the way it is here …

[lukeallister]

[Vim] is really only useful on the command line

That is a disappointing assessment. Obviously you need to focus on the features that you think are most important, but I would like to point out the extra value in combining markdown with Vim (or emacs).

The point of markdown is to be able to _type_ your formatting instead of switching to the mouse. The point of Vim is to make text navigation/editing as efficient as possible. Those two things stack really nicely together, saving a lot of time. On the other side, I do not think that non-technical folks have much interest in markdown anyway. Non-technical users people will gravitate towards WYSIWYG editors, happy to use the mouse to select formatting.

Ultimately you should do what you think is best, but I think that there is a significant intersection between markdown users and technical users.

[nathanlesage]

On the other side, I do not think that non-technical folks have much interest in markdown anyway. Non-technical users people will gravitate towards WYSIWYG editors, happy to use the mouse to select formatting.

This is what I intend to _change_ – and to do so is to increase the intersection between Markdown users and non-technical users, do you understand what my intention with the selection of features for me is? My aim is to get non-technical folk to get to Markdown, because certainly, the intersection between Markdown and tech is large, but my intention is to increase the intersection between Markdown and non-tech. I don't take things just as they are, but I want to change the things as they are!

[sj4nes]

This was a surprising regression to me, as having previously set Vi mode. I had to come here to look and see if I missed something about the upgrade. Unfortunately, I'm also finding that setting editor to Normal mode isn't being saved in the preferences in a restart.

Some more information: With Zettler shutdown, I digged around for the config.json file and renamed it out of the way and relaunched. Added a folder for a workspace and could view/edit files in Normal mode. Changed it to Vim and it locked up. Restarted and had the blank views again.

Chucking both of the files through JQ to pretty-print and then diffing them gives me:

Library/Application Support/zettlr 
❯ jq < config.json > jq-config.json

Library/Application Support/zettlr 
❯ jq < config.json-backup > jq-config.json-backup

Library/Application Support/zettlr 
❯ diff jq-config.json jq-config.json-backup 
2,4c2,10
<   "version": "1.8.0",
<   "openPaths": [],
<   "openFiles": [],
---
>   "version": "1.7.5",
>   "openPaths": [
>     "/Users/sjanes/Documents/Zettlr Tutorial"
>   ],
>   "openFiles": [
>     -2075400493,
>     -1535051421,
>     1432545829
>   ],
6c12
<   "lastDir": null,
---
>   "lastDir": 264121423,
13c19,23
<     "nativeAppearance": true
---
>     "x": 0,
>     "y": 23,
>     "width": 1680,
>     "height": 1027,
>     "max": true
40c50
<   "autoDarkMode": "off",
---
>   "autoDarkMode": "system",
49c59
<   "fileManagerMode": "thin",
---
>   "sidebarMode": "thin",
53,54c63,64
<   "pandoc": "",
<   "xelatex": "",
---
>   "pandoc": "pandoc",
>   "xelatex": "xelatex",
95c105
<     "inputMode": "default",
---
>     "inputMode": "vim",
302c312
<     "theme": "berlin",
---
>     "theme": "frankfurt",
322c332
<   "uuid": null
---
>   "uuid": "7817f879-8b33-4f3d-ad20-f17bb908930d"

Without knowing the setup for this JSON, the only thing that stands out as weird are the negative numbers for the "open files" branch. (inode numbers?). This is all on macOS.

[nathanlesage]

@sj4nes This indicates that the vim bug apparently imparts saving of the settings, which should not be. The negative numbers are hashes. I've re-implemented the Java hashing function, and this sometimes gives negative, sometimes positive numbers. Everything to be expected!

[nathanlesage]

There's just a new issue open, whose title is better for others who might stumble upon this, so I'll close this one for the other one, please head over here: #1473

[TS-CUBED]

So I guess the bug is in Zettlr rather than codemirror.

That's an important thing. I'll have a look some time.

I wrote that in another message on this thread.

But please know that VIM mode has no real priority, as the main target audience of Zettlr is non-technical folk either way, and I have worked with vim myself, and it's really only useful on the command line, not in a GUI application. That is subjective, sure, but the way it is here …

BTW, I must object to the statement that VIM mode is only for technical users. The modal editor concept, once mastered, is a skill that will benefit most touch-typists, in particular in the humanities. It's a bit like markdown languages. They may have originated in a more technical context, but can be beneficial to anybody who needs to write. Your statement is just perpetuating the paradigm that you need a mouse if you are editing text in a GUI program, which I'd say, is incorrect.

BTW2: I have introduced my wife (PhD student in Archaeology/Heritage management) to markdown (with Zettlr). And the one thing that would help adoption there is a preview mode, since her non-technical background causes a preference for visual confirmation/prediction of the layout. A feature that you have robustly argued against.

I agree with you that that feature should not be required, but I'd say that that is biased by our technical background, and it is only through my influence that she has not dropped Zettlr yet due to the lack of a preview pane.

[bit-hug]

Just to note, the editor is not in fact frozen under this bug, and will silently accept input and save to file, but this will not be displayed until Zettlr is restarted in normal mode. Perhaps the title of this issue is therefore more accurate than the title of issue #1473

[nathanlesage]

@bit-hug I see your objection, and for me it's more about a problem that it feels as if VIM mode editing belongs more to the command line than a GUI, but then I'm just doing this in my free time and don't have that much mental capacity to actually conduct studies and weigh things in order to deliver a good experience for everyone. My rejection of VIM mode is more based upon the fact that I need to somehow cut my work because there's so much that's still buggy, slow or not optimized, and I want to prevent myself getting burnt out. This is why I'm cutting all the purely technological stuff, it's simply a heuristic I'm applying.

As mentioned in #1473 I'll gladly accept PRs introducing such functionality, but only (!) if I do not have to maintain it. You know what I'm getting at? I don't want to disappoint anyone, but given the fact that I am right now working on the app for my whole Sunday, because I don't have time under the week, this is actually a warning sign.

[TS-CUBED]

Totally understand that. Zettlr is a great app, and definitely a huge
step towards getting markdown and Zettelkasten out to the less technical
people who can benefit from it.

Thanks for all the hard work you put in it.

[bit-hug]

@bit-hug I see your objection, and for me it's more about a problem that it feels as if VIM mode editing belongs more to the command line than a GUI, but then I'm just doing this in my free time and don't have that much mental capacity to actually conduct studies and weigh things in order to deliver a good experience for everyone. My rejection of VIM mode is more based upon the fact that I need to somehow cut my work because there's so much that's still buggy, slow or not optimized, and I want to prevent myself getting burnt out. This is why I'm cutting all the purely technological stuff, it's simply a heuristic I'm applying.

As mentioned in #1473 I'll gladly accept PRs introducing such functionality, but only (!) if I do not have to maintain it. You know what I'm getting at? I don't want to disappoint anyone, but given the fact that I am right now working on the app for my whole Sunday, because I don't have time under the week, this is actually a warning sign.

That's very understandable.

I actually wish I had more that I could offer, but any technical knowledge or skill I have in programming is minimal and only comes from using various tools in my physics work. I hope there comes a time when I can make a meaningful contribution.

As for the utility of vim mode, I don't use vim independently very much, but I simply find the keybindings and associated small functions very convenient and efficient. It's a big bonus for me if Zettlr manages to incorporate it again in the future, but it was only one of very many good things about Zettlr.

Broadly speaking, in my view, the goals of enabling people from a less technical background to use markdown, and enabling people from a less technical background to use command line tools, are harmonious and mutually aligned ones. That you have done and continue to do so much to further even one of these aims (and not in a small way) is already to be very highly commended. More power to you!

[nathanlesage]

@bit-hug Thank you very much for your kind words, and I appreciate your understanding. I really hope that with rising popularity of the app some helping hands will find their way in here and we can resume implementing those features as well :)