Migrate to libtickit (libtermkey deprecated)

[maxzinkus]

I'm not sure if this will "just work" once libtermkey is cleaned out as a dependency, or if it'll require some deeper updating, but libtermkey is in fact deprecated and so making this project viable into the future will likely require transition.

It'd be best to do this before any extra tech debt is accrued by putting it off.

Thanks! I'm really interested to see how this project grows.

[aeosynth]

dupe of #79

[maxzinkus]

Duplicate

[martanne]

Some remarks since this has come up a couple of times:

• libtermkey is only used for terminal input handling
• terminal output / drawing the user interface is currently taken care of by curses
• libtickit merges the two i.e. it would be a replacement for both libtermkey and curses
• libtickit has not yet seen an official initial release? I'm not sure what its development state is? This would make packaging vis even more cumbersome
• I haven't yet looked at what libtickit actually does under the hood. vis currently assumes that the underlying curses library performs double buffering. That is vis always completely redraws its interface and relies on the curses library to figure out the optimal set of escape sequences to update the terminal state.
• I'm in principle not opposed to dropping ncurses. In fact its code is hideous. I would eventually like to experiment building against netbsd-curses (especially for make standalone).

[erf]

@martanne did you look at termbox ?

[ghost]

I like how termbox strives to be simple, but it requires python to build as it uses waf. On the other hand, the library only takes ~1000 lines.

I do not see why it is so hard to draw on a terminal: We need to know how much width a char takes on the screen that we can do with UTF-8 library, then just have a function that draw a single line, used to redraw the whole buffer, to scroll one line up / down...

This is an attempt of implementation, if ever interested. Still has some issues at this point.

[martanne]

As mentioned in the above list and also in a related comment: curses provides double buffering. It tries to minimize the required escape sequences used to update the terminal to the new state. For example if you move the cursor, the status bar is redrawn, but this should probably not invalidate the complete screen. Whether this is actually needed in practice (or only over slow serial lines), is another question.

Also using raw escape sequences might work in certain environments you control, but is not really portable. That is why the terminfo database exists. In theory it would be nice to ditch all this legacy cruft and only have a single (or very few) terminal descriptions. Sabotage Linux works towards that goal.

Having said all that, a ui-vt100.c backend implementing the ui.h interface using only raw escape sequences might be useful in some scenarios. Patches welcome.

[ghost]

I think I get it all now, thanks for explainations, and this makes sense to me.

By writing a text editor, with the choices made, you also contribute to fix terminal interaction, it is great.

[aeosynth]

a ui-vt100.c backend implementing the ui.h interface using only raw escape sequences might be useful in some scenarios.

isn't that what kilo does?

Kilo does not depend on any library (not even curses). It uses fairly standard VT100 (and similar terminals) escape sequences.

[ghost]

Yes, that is the idea :)

Without syntax highlighting and modal, and customizable keybindings the way vis or sandy does it...

Kilo is a proof of concept, busybox vi is casual editing, traditionnal vi is old thing fixed up, but too poor in features... And to me vis is vim done with sane choices at every levels.

So between Vim / neovim and busybox vi, there is a huge gap with only vis that seems to stand out (at least for the vi family, thery is still joe's own editor, uemacs, OpenBSD's mg and older projects like nvi)...