Related: There is an in-development Wayland compositor for the Window Maker look and feel called wlmaker¹. It is already quite usable, but is very barebones right now.
X11's architecture, on the other hand, is arguably better than Wayland's. Server-side rendering is a great way to
It also has lots of flaws. "Mechanism, not policy" has to go, because you are trying to make a desktop environment, not draw arbitrary rectangles to the screen. It is already a given that there is one special client called the window manager; it would serve the architecture well to know that's the window manager instead of treating every client as if it could potentially be a window manager. But Wayland goes even further in this direction, eschewing things like icons, title bars and resize borders, which are basic expectations of a desktop environment. While X11's way of doing these things is esoteric, at least it has one. (If it were up to me, standardized window properties would be promoted to requests, so you'd just call xcb_set_window_title instead of fussing with atoms and window properties).
Another anecdote is HDR: Wayland seems to still have not standardized how it should work; meanwhile on X11, there is already protocol support for multiple pixel formats (1-bit, 4-bit, 8-bit, 16-bit, 24-bit displays) and you could just add 48-bit color to that list. That would be one of the things Wayland stripped out while striving for simplicity (since everyone had 24-bit colour at the time) that turned out to actually be important.
---
At some time before the heat death of the universe, I will get around to trying to fork Xorg and remove all the cruft and see where that goes. (Server-side rendering is not cruft. User-mode SVGA drivers are.)
I did minimal work on this already - as in, I downloaded Xorg's source code and had a look through. The whole configuration system has to go. The XFree86 driver code and driver abstraction has to go, and the DRM driver hard-wired in place. Using dlsym to locate compiled-in modules makes tracking dependencies impossible.
I suspect this has something to do with the state of Xorg: Nobody knows what it should and shouldn't do, and the module API for Xorg is the entirety of Xorg, so changing anything is liable to break someone's external module that wasn't on the "it should do this" list.
It wouldn't be the first time the X server was forked with the intention of cleaning it up: Xorg is a fork of XFree86, which was a fork of X386, which was based on something I don't remember.
There are some advantages and disadvantages of the approach.
However, there's just stuff that X assumes that isn't true anymore. A good example is how it handles input. How many cursors does a screen have? One machine? okay, One input device?
I'll have to see the talk later. If a new input model is needed, why can't it be an incremental upgrade? I know that UI frameworks still have the traditional mouse down/up/move events, so they've been able to make it an incremental upgrade in that layer. If it's so incompatible that it can't coexist with the old model in the same connection, we make it an option for the client to request. If we're very very sure it's the future, we make it X11R8 or even X12 (the difference between X10 and X11 was smaller than this), we allow the server to support X11 and X12 clients and deprecate X11, and remove it after a very long time (if ever). All of this is still less invasive than Wayland.
It did have some of the worst code in open source. We didn't need to abandon the protocol, ABI & backwards compatibility (fuck Wayland sideways a broom) but a rewrite was sorely needed
x11 doesn't do much of anything to begin with, these days. It will still exist for the people that want to use it, but distros are right to not default to it anymore.
Why can't we have a wayland server that can run different window managers like X did? That way, we only need one wayland compositor, and everyone can just write their own window managers.
This looks doable. Create a Wayland compositor that does not do visible window management itself, but exposes an API to help relatively easily port and run an ICCCM-compliant WM.
This looks so obvious that it ought to have been tried.
It's the first, and hopefully the only, time I will say I'm glad I see something on Wayland. I had some nasty visual issues once with WindowMaker, I feel like such a fundamental move is needed.
Stolen, thanks! I just played around with something like that in vim¹, and it works great.
I have a tooling issue with your method, perhaps in the same manner as you feel about C-i. To me "italicize $count previous words" makes far more sense than expanding the region on repeated calls. Although to be fair I can wrap over visual mode for that functionality which would feel more comfortable to me; "ge" end of previous word, "v", $navigation, ...
My point - to the extent I have one - is that there is probably a degree of personal comfort that colors our reactions to people using C-i.
¹ Basically "imap <C-S-8> <Esc>bcw*<C-r>-*<C-o>w". I'll give it some more thought, along with adding v:count and non-* support, before it hits my vimrc.
If you're a zsh user there is a fun^wquirky way to achieve similar functionality using the MULTI_FUNC_DEF¹ option. zsh allows you to define multiple functions at the same time, so you can parametrize functions with something like:
[In the spirit of elucidation, and not general meanness…]
Like jojo14 points out Python has the shlex module, and it is definitely useful in these situations even if just for quote(). And, os.system() is basically never safe with external input. Without proper escaping you're one click from code execution, for example with the input "file:///etc/issue%3Becho%20whoops" or "http://example.com/';echo whoops'".
It doesn't appear to matter in this instance, but you can feed check_output() with the stdin argument, which removes the need for using shell=True. shell=True in other paths could easily lead to unwanted code execution without thorough escaping.
You could maybe find out where the delay is by using st's Xembed support? Create a window with tabbed¹ in a tiling layout, open st in to it with "st -w <xid> -e true". If it is close to the monocle time, it is probably the other windows handling the resize event that is causing the slowdown not the layout choice.
To prove it to myself: I'm using river² and I can see a doubling-ish of startup time with foot³, iff I allow windows from heavier apps to handle the resize event immediately. If the time was a little longer(or more common) I'd be tempted to wrap the spawn along the lines of "kill -STOP <other_clients_in_tag>; <spawn & hold for map>; kill -CONT <other_clients_in_tag>" to delay the resize events until my new window was ready. That way the frames still resize, but their content resize is delayed.
You can choose the behaviour with the --shell option¹. The default behaviour is nice because it allows you to benchmark pipelines easily, but if you want to change it you can.
If we're handing out tips, then as noted in a few examples from the article hyperfine is even more useful when called with multiple commands directly. It presents a concise epilogue with the information you're probably trying to gleam from a run such as yours:
$ hyperfine -L arg '1,2,3' 'sleep {arg}'
…
Summary
sleep 1 ran
2.00 ± 0.00 times faster than sleep 2
3.00 ± 0.00 times faster than sleep 3
If your commands don't share enough in common for that approach then you can declare them individually, as in "hyperfine 'blib 1' 'blob x y' 'blub --arg'", and still get the summary.
i once used hyperfine to micro-bench elisp functions. i se $SHELL to a script that evaluated it's arguments in emacs by talking to a long-running session over a named pipe. Hyperfine runs a few no-ops with $SHELL and factored out the overhead, though it was still helpful to run a nested loop in elisp for finer results.
There is also viddy¹ for a slightly more featureful watch alternative, if you're open to a new non-default package. Being able to recall old output and search within it can be extremely useful.
Admittedly, it isn't quite a drop in replacement, but the usage is close enough that even aliasing it is unlikely to cause [many] problems.
Zsh users get a bundled curses module; see zsh/curses¹ in zshmodules(1). It is a very thin wrapper, so it works how you'd expect from other uses. There is a tetris implementation using zsh/curses that ships with zsh², and you can use it as a nice comparison to the non-curses implementation that also comes with zsh³.
I've used zsh/curses a few times to hack together little interfaces, and it is quite workable. It makes things far simpler once you start reaching for terminfo's capabilities that require you to think about state too much. A friend of mine wrote a little mblaze⁴ frontend using it, and it felt like using single mailbox mutt with less than a hundred lines of code.
I was expecting the linked project to be a loadable module too given that bash also supports them, but it is actually a little more interesting to look at given it implements a bunch of the behaviour itself on top of tput calls.
"Some sort of surfing game" immediately screams California Games¹ to me. There was surfing² plus a few other sports, and it is still good fun if you find yourself at a museum/nerd house that has one.
¹ https://github.com/phkaeser/wlmaker
reply