Re: [dev] [vis] vis editor status update

From: Silvan Jegen <s.jegen_AT_gmail.com>
Date: Fri, 4 Dec 2015 09:55:18 +0100

On Fri, Dec 4, 2015 at 12:17 AM, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> On Wed, Dec 02, 2015 at 10:35:54AM +0100, Silvan Jegen wrote:
>> As far as embedable scripting languages go Lua seems like the most
>> suckless solution. For me the much lauded simple "stack-like" Lua-C
>> interface is not *that* easy to understand though.
>
> Conceptually it is really simple, it just requires some time to get
> used to the adressing modes (either from top or bottom of the stack)
> and to become familiar with the most important functions.

Yeah, I think me not being familiar with the addressing modes nor the
functions make things harder to grasp without looking at it some more
in-depth.


>> The advantages of the libtermkey input handling were not immediately
>> evident to me when briefly looking at the code. What was the
>> motivation for using the library?
>
> Basically to get keyboard input in a vim like a symbolic key format.
> Therefore the default key binding configuration in config.def.h
> looks something like:
>
> { "<Backspace>", ... },
> { "<C-w>j", ... },
>
> instead of
>
> { KEY(BACKSPACE), ... },
> { CONTROL('w'), NONE('j'), ... },
>
> which makes them useable for the :help output and will eventually
> enable run time key bindings i.e. some sort of :map command.

I see.


> Not strictly related, but key binding lookup was also simplified by
> storing these strings in a crit-bit tree based map.

Key binding lookup in vis always bothered me and I was thinking about
how to put them into a crit-bit tree after you added it. I must have
missed this change but the code below looks like it would be the
relevant part.

vis.c:758

for (Mode *mode = vis->mode; mode && !binding && !prefix; mode = mode->parent) {
  binding = map_get(mode->bindings, start);
  /* "<" is never treated as a prefix because it is used to denote
   * special key symbols */
  if (strcmp(cur, "<"))
    prefix = !binding && map_contains(mode->bindings, start);
}

we are still iterating over the modes which I assume is some kind of fallback?

Thanks for the info!


Cheers,

Silvan
Received on Fri Dec 04 2015 - 09:55:18 CET