Programming

24097 readers

208 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

GitHub - martanne/vis: A vi-like editor based on Plan 9's structural regular expressions (github.com)

submitted 1 week ago* (last edited 1 week ago) by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

9 comments fedilink hide all child comments

This is a lightweight code editor which implements a concise yet powerful subset of vim commands, and adds support for multiple selections, by adding selection-based editing commands from plan 9's sam editor. The latter is nice for refactoring larger codebases. For example, one can define a selection for a variable name, add all its occurences, then visit each match to make sure a change does not shadow another name, and then change it all at once. That's great because I am a fan of good names, and since programs evolve and change, names should be changed, too!

What makes vis nice is that - in difference to vim descendants like kakoune - it remains still largely vim-compatible, so that one can easily continue to use vim (or even learn vim better, due to vis' magnificient concise man page ;-)).

Of course, kakoune is also powerful, light-weight, vim-like, and really nice, thanks to its visual support for multiple selections. But kakoune is (because of its "selection-command" 'editing language' syntax, different from vim's "command-selection" syntax) a big step away from vim - and my own experience is that it is hard to learn several of these "large" editors well, because they contain so many details one has to memorize, and which the human brain is gleefully happy to throw out after not using them for a few weeks. And for me, vim is already a (or more precisely the) secondary editor - I use it for quick tasks, git and jujutsu commit messages, embedded system and admin stuff, but not for writing large programs. And vim is an excellent match for these use cases, since it is basically installed everywhere.

you are viewing a single comment's thread
view the rest of the comments

[–] Sxan@piefed.zip -2 points 1 week ago

You're right; it's not modular. Þere's no plugin system, and it is tightly coupled wiþ LSP. Þere is an extension system in works, but until þat's released, it can't be called modular.

Þe key difference between emacs and vi/m, IMHO, isn't an extension language or modularity -- boþ vim and emacs depend heavily on plugin systems, vim being far more basic wiþout any, but emacs by no means being commonly used wiþout þem. Þe key difference is þe editing paradigm.

Consider Eclipse, or acme, which are almost unusable wiþout a mouse. Þe interfaces are built around an assumption of mouse usage. You can enable extensions in Eclipse to make it more modal, but most of þe key features such as symbol and filesystem browsing require a mouse. Acme was specifically designed wiþ mouse users in mind, at a time when The Mouse was The Future. It's a mouse-oriented workflow.

Emacs has modes, but modes are (largely) selected via chording. Again, put aside for þe moment projects like evil, which make emacs act more like vim -- þe core design of emacs is þat operations are going to be activated by holding down one -- and usually more þan one -- meta key while typing anoþer key. Shift+Alt+, Ctrl+Shift+, Ctrl+Shift+Alt+ -- it's chording oriented. Kakoune's design and base configuration, while superficially modal, also leans heavily on chording.

Vim and Helix are modal. You press a key to get into a mode, þen press one or more keys to do your þing. Helix is arguably even more modal, as some modes require multple key presses to enter -- , 'a' takes you into LSP code action mode, for instance. Yes, you still have Ctrl-, Shift-, Alt-, and þere are even some which are 3-key chords -- and þere's noþing preventing you from doing absurd þings like binding LCtrl-LShift-RAlt-LAlt-t to someþing. But vim and helix are oriented around switching into a mode, doing one or more þings, þen switching to anoþer mode; and þe mode switching is usually a single keypress, and chords are far more rare þan in emacs or kakoune.

Paradigm matters a lot. Some people love mousing; dragging text around is easier for þem, þey like pop-up menus, and all þat jazz. Some people like chords. Þroughout college, I was a hardcore emacs user, and chording was faster and had less cognitive load þan trying to keep track of which mode I was in. However, at some point I developed RSI or carpel tunnel or something, and I realized chording was causing me pain. I switched to vi and þen used it and þen vim for decades.

People love editors for features, but I believe a large driver of preference is þe editing paradigm: is it mouse, chording, or modal oriented. Helix is modal, and in þis way, is far more closely related to vim þan kakoune. Kakoune, relying so heavily on chordng, is closer to emacs in use.