I have been using Emacs at work for whole week

Complaints & Improvements
,
21

I’m asking because tools like tree sitter provide coordinates. This code:

fn foo(x: i32) {
    println!("x is {}", x);
}

Produces such tree in tree-sitter’s playground:

source_file [0, 0] - [3, 0])
  function_item [0, 0] - [2, 1])
    name: identifier [0, 3] - [0, 6])
    parameters: parameters [0, 6] - [0, 14])
      parameter [0, 7] - [0, 13])
        pattern: identifier [0, 7] - [0, 8])
        type: primitive_type [0, 10] - [0, 13])
    body: block [0, 15] - [2, 1])
      macro_invocation [1, 4] - [1, 26])
        macro: identifier [1, 4] - [1, 11])
        token_tree [1, 12] - [1, 26])
          string_literal [1, 13] - [1, 22])
          identifier [1, 24] - [1, 25])

On every keypress code is being reparsed by tree-sitter down the tree from modified leaf and coordinates change. We should update all changed region highlighters. If we could do so on every keypress we could have very nice highlighter with tree-sitter. There’s plugin already that uses tree-sitter to provide structural selections by @ulis, but I believe it doesn’t re-parse on every keypress, am I right?

22

It doesn’t on every keypress but it does on every tree-* command invocation. This plugin is stateless and doesn’t leverage incremental parsing.

However I use it to highlight scopes which means it’s called and does re-parse on NormalIdle and I didn’t notice any problems with it, tree-sitter is fast enough even in non-incremental mode for my case.

23

Here is interesting talk about Xi editor design. Its author mentions that syntax highlighter is regex based and acknowledges that it’s probably not the best technique.

24

This is a nice talk. What stood out for me is JSON RPC syntax highlighters, which might be something we could use.

25

I think that ultimate goal should be not just syntax higlighting, but editor understanding the code. Indentation, folding, and syntax are close friends. Local variable highlighting can be based on syntax tree as well, and so forth. Emacs does this for several languages and I find it super convenient.

26

We do have tree based highlighting using the region and group system, I am conflicted about exposing this outside of highlighting. It would solve some issues but greatly complexify the mental model of Kakoune commands (if we decide that text objects need to start/end in the same region type).

Improving the design of the region system to make it easier to express grammars would be worthwhile though.

3 Likes
27

I’ve been using Emacs for years, and had been switching from regular Emacs keys to Evil on and off for years. I’ve used Doom Emacs for awhile and just decided to stick with the Evil keys.

One of the things I will say is that, in my opinion, modal editing is useless if you don’t know the way to select text objects and other advanced stuff.

Vim is awful at this, because search around you learn there’s a lot of way to select certain text and operate on it in certain ways that aren’t exposed to you.

I will say this is one of the things that I would want different for Kakoune: be upfront about the advanced key combinations. Watching a gif isn’t helpful. You (also) should write it out somewhere.

This is something I’ll say for Kakoune: document. as much. as possible. I don’t care if you think “well people should know this.” No. No they will not know “this.” You have to dummy proof things. Because if it’s not documented somewhere where people will find it fairly easily, then they will ask about it. This doesn’t mean “check out muh config” or “muh source code” or “check muh forum post.”
It has to be written down.

5 Likes
28

I think the colorscheme matters as well.

image
image878×1474 86.1 KB

Top: Nord; Average Highlighting
Middle: Dracula (Transparent); Best highlighting in my experience
Bottom: Gruvbox; Does some things better than Nord and some things worse.