5 ms·

I've been trying some vim "alternatives" recently. Onivim has been on my radar for years, but I only recently started trying it out. No real opinion on it yet

I've been trying some vim "alternatives" recently. Onivim has been on my radar for years, but I only recently started trying it out. No real opinion on it yet other than: I like the idea of VSCode plugins (the Ansible plugin is apparently quite good, and I've been wanting to try it). Other alternatives I'm playing with: Kakoune, SpaceVim, and LunarVim. The last two are vim configs with plugins. LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting. Kak needs a plugin for it. Kak has a fairly interesting multi-cursor setup that reminds me in some ways of "sam" (the little I've played with it). For doing some sorts of macro-like functions to modify many lines, it's pretty slick.

0xdeadb00f 5y ago
If you like Kak and are vaguely familiar with Sam I suggest trying out vis: > Vis aims to be a modern, legacy-free, simple yet efficient editor, combining the strengths of both vi(m) and sam. https://github.com/martanne/vis https://github.com/martanne/vis "Differences from Kakoune": https://github.com/martanne/vis/wiki/Differences-from-Kakoune https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
- linsomniac 5y ago
  Thanks, that was the other one I was actually trying to remember but could only come up with sam. Went through the Wikipedia text editors page a few times and just couldn't remember it.
arp242 5y ago
> LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting. While Vim's regexp-based syntax highlights certainly has limitations even in fairly simple cases, and I would love to see something better, the downside of these things is that people get carried away and add colours to everything. A little bit of colour is very helpful. Ten different colours seemingly chosen at random is not. I tried that LunarVim thing, which was a somewhat frustrating experience as it doesn't work on light terminals at all (setting background=light and :colorscheme default seems completely broken), somewhat ironic that a project which bills "better colours" as one of its main points doesn't actually work with a common background colour, but okay. The colours for Go are ... not great. Is there any point in highlighting string literals in a different colour than numbers, and bools yet another colour? What extra information does that convey? Or what's the point of highlighting operators in blue? Giving _ its own special colour? That doesn't make it easier to read – quite the opposite as there's an overload of information. There are 10 unique colours with the default Go colorscheme (vs. 4). This alone is noisy and distracting, but they're not even especially well chosen as there's significant overlap with completely unrelated things highlighted in a different colour (escape sequences the same as functions, or nil the same as func; no idea what the point of that is as it's not even a keyword). In short, these tools are nice, but I fear it will lead to an explosion of extremely badly designed colour schemes where people add stuff "because they can" and "ohhh, colours!" without actually thinking if it's a good idea or not. I saw this with vim-go where people constantly sent in patches for dubious colour scheme changes, and you spend forever argueing why it's not a good idea, and at least "it's very slow and will complicate things a lot" was a meaningful barrier. Darn I sound like a grumpy old man... But really, these are design issues I don't see enough consideration of. No colours is bad; some colours is super helpful, but loads of random colours is even worse than no colours. There's some research on it too; NASA did research for colour usage in flight control systems for example and came to the same conclusion (which I can't seem to find right now). Another fun example is the "count the triangles" vs "count the red shapes" in [1]; counting the red shapes is easier, but counting the triangles is easier in the monochrome version vs. the coloured one. [1]: https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/ https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/
- mihaifm 5y ago
  Fully agree on the color issue. Most color schemes in any editor today look like rainbows, very distracting for day to day usage. I ended up building my own color scheme for vim using only 4 colors.
  - toastal 5y ago
    I've used lapis256 for ages because it's built on subtle differences in the shades of blue instead of so much hue contrast.
- konart 5y ago
  Well, that's not the problem with TreeSitter. There is enough of this even with the default regexp-based syntax highlights. Anyway - one can always create a perfect scheme for them to use.
  - arp242 5y ago
    No, it's not; I never intended to imply it was. Like I said: "I would love to see something better". Making a syntax file right now that's 1) truly fully correct, and 2) fast is often quite hard to create and maintain. Most Vim defaults are fairly timid in comparison to what I've seen of tree-sitter. Right now the limitations often prevent too much "shizzle" from being added, which is useful in a kind of perverse sort of way. > Anyway - one can always create a perfect scheme for them to use. It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future.
    - konart 5y ago
      >It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future. Why would you need this (unless your language is not in https://github.com/nvim-treesitter/nvim-treesitter#supported-languages https://github.com/nvim-treesitter/nvim-treesitter#supported... ?)
pikelet 5y ago
Does Kakoune really have a plugin for syntax highlighting with Tree-sitter? I was under the impression that there was only a plugin for structural selections (kak-tree). I would really like more accurate syntax highlighting in Kakoune, particularly in Markdown.
- linsomniac 5y ago
  I guess I misunderstood kak-tree. Seems like you are correct. Thanks for that pointer.

0xdeadb00f 5y ago

If you like Kak and are vaguely familiar with Sam I suggest trying out vis: > Vis aims to be a modern, legacy-free, simple yet efficient editor, combining the strengths of both vi(m) and sam. https://github.com/martanne/vis https://github.com/martanne/vis "Differences from Kakoune": https://github.com/martanne/vis/wiki/Differences-from-Kakoune https://github.com/martanne/vis/wiki/Differences-from-Kakoun...

linsomniac 5y ago
Thanks, that was the other one I was actually trying to remember but could only come up with sam. Went through the Wikipedia text editors page a few times and just couldn't remember it.

arp242 5y ago

> LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting. While Vim's regexp-based syntax highlights certainly has limitations even in fairly simple cases, and I would love to see something better, the downside of these things is that people get carried away and add colours to everything. A little bit of colour is very helpful. Ten different colours seemingly chosen at random is not. I tried that LunarVim thing, which was a somewhat frustrating experience as it doesn't work on light terminals at all (setting background=light and :colorscheme default seems completely broken), somewhat ironic that a project which bills "better colours" as one of its main points doesn't actually work with a common background colour, but okay. The colours for Go are ... not great. Is there any point in highlighting string literals in a different colour than numbers, and bools yet another colour? What extra information does that convey? Or what's the point of highlighting operators in blue? Giving _ its own special colour? That doesn't make it easier to read – quite the opposite as there's an overload of information. There are 10 unique colours with the default Go colorscheme (vs. 4). This alone is noisy and distracting, but they're not even especially well chosen as there's significant overlap with completely unrelated things highlighted in a different colour (escape sequences the same as functions, or nil the same as func; no idea what the point of that is as it's not even a keyword). In short, these tools are nice, but I fear it will lead to an explosion of extremely badly designed colour schemes where people add stuff "because they can" and "ohhh, colours!" without actually thinking if it's a good idea or not. I saw this with vim-go where people constantly sent in patches for dubious colour scheme changes, and you spend forever argueing why it's not a good idea, and at least "it's very slow and will complicate things a lot" was a meaningful barrier. Darn I sound like a grumpy old man... But really, these are design issues I don't see enough consideration of. No colours is bad; some colours is super helpful, but loads of random colours is even worse than no colours. There's some research on it too; NASA did research for colour usage in flight control systems for example and came to the same conclusion (which I can't seem to find right now). Another fun example is the "count the triangles" vs "count the red shapes" in [1]; counting the red shapes is easier, but counting the triangles is easier in the monochrome version vs. the coloured one. [1]: https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/ https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/

mihaifm 5y ago
Fully agree on the color issue. Most color schemes in any editor today look like rainbows, very distracting for day to day usage. I ended up building my own color scheme for vim using only 4 colors.
- toastal 5y ago
  I've used lapis256 for ages because it's built on subtle differences in the shades of blue instead of so much hue contrast.
konart 5y ago
Well, that's not the problem with TreeSitter. There is enough of this even with the default regexp-based syntax highlights. Anyway - one can always create a perfect scheme for them to use.
- arp242 5y ago
  No, it's not; I never intended to imply it was. Like I said: "I would love to see something better". Making a syntax file right now that's 1) truly fully correct, and 2) fast is often quite hard to create and maintain. Most Vim defaults are fairly timid in comparison to what I've seen of tree-sitter. Right now the limitations often prevent too much "shizzle" from being added, which is useful in a kind of perverse sort of way. > Anyway - one can always create a perfect scheme for them to use. It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future.
  - konart 5y ago
    >It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future. Why would you need this (unless your language is not in https://github.com/nvim-treesitter/nvim-treesitter#supported-languages https://github.com/nvim-treesitter/nvim-treesitter#supported... ?)

pikelet 5y ago

Does Kakoune really have a plugin for syntax highlighting with Tree-sitter? I was under the impression that there was only a plugin for structural selections (kak-tree). I would really like more accurate syntax highlighting in Kakoune, particularly in Markdown.

linsomniac 5y ago
I guess I misunderstood kak-tree. Seems like you are correct. Thanks for that pointer.