On 20 April 2011 21:36, Claudio <smo...@gmail.com> wrote: > Line buffer editing/positioning shouldn't be handled by st itself, it > should be delegated to an external tools (most likely the shell). Else > none of ^e, ^a, and such keystrokes should be available/hardcoded into > the terminal emulator. We should think in terms of "shell container" > rather than "terminal emulator". > Well, I'm pretty aware it's a bit extreme but hope someone else will > agree with me.
There is always the danger of designing something for re-use, that isn't actually reused at all later on. In dwm/dmenu and probably st I see some potential to share a single implementation of draw.c. At first I wanted to create a lib for this, but when Connor tested this approach in dmenu we concluded, that additional library dependencies suck. The best compromise we came up with is having a shared draw.c among dwm and dmenu at least, which is on the agenda for dwm 6.0. Probably this could also be used for st. The idea is to allow different draw.c implementations, by default it will hook on top of plain old xlib, but other backends are probably worth to be considered as well. In a second step I also see the potential to exclude all X related functionality into ws.c, but this won't be a shareable implementation, as the purpose of a WM is quite different to a classic X client like dmenu. With a separate ws.c and a platform independent dwm.c core, it will be easy to implement ws.c on top of wayland. However, it might turn out, that the ws.c idea is crap. There are also the projects libswk (pancake referred to) and the idea of a libsuckless lurking around. As for libswk: I'm a bit undecided which way this lib should go. Currently it is designed as portable interface that pancake implemented for different backends. I have not a great feeling about the current libswk state tbh, I think if something with a broader scope like libswk becomes a portable interface it will suck. I tend to wait what wayland comes up with this summer and then I can imagine designing a minimalist UI interface on top of wayland. The original idea of libswk in my understanding was more like curses than a traditional UI toolkit -- in theory one could implement curses on top of a graphical user interface, and still have a tty fallback. But the details are quite hard and the ideas of the people involved a bit different I guess. As for libsuckless: The idea was to put commonly shared stuff of the most popular suckless projects into such a library. But I think this might be a something far-away in the future thing to achieve. Kind regards, Anselm