At least once a year for the past couple of decades I'll receive an email from a user that makes me want to modernize bfm¹. However, I've never managed to get an auto-scaling version to work with reasonable performance, which is unbelievably annoying for such a simple tool. You can sort of hit the target for gkrellm-bfm while still depending on GTK2, or for the standalone bubblefishymon wmapplet where you can use a modern GTK² or jump straight to SDL.
Never in a way that doesn't noticeably chew additional CPU though, and definitely not for both use cases. It upsets me each time I reply "no, not happening without patches". Perhaps it is time to release an Electron version or one that just burns a whole CPU core so it isn't lost forever ;)
¹ It used to just be people with crazy setups, now it is basically any screen given their higher DPI.
² As it is right now I don't even have a system that I can use last release on.
Some of the background was explained before¹, along with a heap of comments when it was posted here².
Probably still not enough information for an outside observer(like me), but they probably assume more familiarity with the project for posts on their discourse.
Might not be as direct as you'd like, but all well managed¹ GNU projects ship a NEWS file in their tarball. In this case you can also read it from savannah² without fetching the tarball.
A link to the documentation¹ and repo² to save others a few steps. Examples are helpfully linked toward the end of the page and its source in the README.
When vim plugins change the effect of K, all they're likely doing is setting keywordprg¹. You can do the same yourself, fex to display info on the commit under cursor you'd use "setl kp=git\ show". You can write little script wrappers to fetch whatever custom resources you want, or you can up your game by writing vim commands so that you can use a count prefix to influence behaviour of the fetch too.
I've actually found this before but found it hard to parse and little third party information on the subject. I've been able to get K to show things like standard Python docs but not modules and not docs from the active working project. I'm sure there has to be a way considering ctags and jumps exist but I think I need a full weekend you at least unravel all the moving parts without third party explanation.
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.
Never in a way that doesn't noticeably chew additional CPU though, and definitely not for both use cases. It upsets me each time I reply "no, not happening without patches". Perhaps it is time to release an Electron version or one that just burns a whole CPU core so it isn't lost forever ;)
¹ It used to just be people with crazy setups, now it is basically any screen given their higher DPI.
² As it is right now I don't even have a system that I can use last release on.
reply