Wandering Thoughts archives

2021-03-23

Discovering Vim's Visual (selection) mode

Usually, when I want to operate on a block of text (for example to reflow it) I can select it with one of Vim's motion commands, such as '}' for a nominal paragraph. Vim's notion of a paragraph is sufficiently all-encompassing that this works for a lot of things that aren't strictly paragraphs but are, for example, ed style diffs. When I want to select something that doesn't match up with this, such as only part of a quoted email message, my traditional solution has been marks.

Vim's Visual mode is an alternative way of making these selections. To be a bit unkind to vim, it's vim's version of what would be mouse based selection in a GUI editor such as sam. Since it has visual feedback, it has many of the advantages of mouse based selection, but it also lets you take advantage of all of Vim's motion commands for moving around. In effect it's like a version of setting a mark that visually shows me what a "`a,." address would cover, and I can back up or move forward from the results of, say, } to jump the the end of the nominal paragraph.

(More likely I will start visual mode and then move line by line until I'm where I want to be. I often take a brute force approach to editing in Vim.)

As covered in the documentation, visual mode comes in three varieties; v for character by character selection, V for line by line selection, and Ctrl-v for a block selection (which I haven't used). Even with a character by character selection, some Vim commands (including many that I use) will operate on all lines with some selected characters in them. However, I probably want to get into the habit of properly using V instead when I'm planning on doing a line-wise operation, such as using ! to reflow quoted text with par.

I'm not sure how I stumbled into actually understanding visual mode. I'm sure I've accidentally hit v periodically in command mode and been irritated by the resulting mystery highlighting (fortunately hitting ESC a couple of times makes it go away), but recently I learned what it was actually for and motivated myself to start using it in some cases where I expect it to be more convenient than the alternatives.

(This entry is one of the ones I write partly to get a Vim feature to stick in my mind and partly to do some more reading on it so I know more of what I'm talking about.)

VimVisualMode written at 23:52:48; Add Comment

2021-03-19

Remote X versus 'seamless windows' in remote desktop software

I recently said on Twitter that I expected x2go to have what I considered significant limitations for my ongoing use of remote X. This isn't because of any specific flaw in x2go; instead, it's because of a fundamental difference between remote X and what remote desktop software like x2go does even when it's implementing what the Wikipedia comparison of remote desktop software calls 'seamless windows'.

Normally, remote desktop software like x2go gives you an entire remote desktop in a large window. When the remote desktop is on a Unix machine, this is normally done by starting an X server (or perhaps a Wayland server) that's drawing on a chunk of RAM as a virtual framebuffer, instead of to a GPU and one or more physical displays. The X server then tracks changes to this virtual framebuffer and sends them to your local client, which displays them. Local X input events flow in reverse; your local X server sends them to the local client, which wraps them up in some protocol and sends them to the remote X server, which then passes them on its clients. Because what's running is a remote X server, it can run a full (X) desktop session (assuming that the remote X server supports all of the X extensions that the particular sort of desktop requires).

To implement a 'seamless window' in this model and get something like what you see when you run 'ssh -X xsomething', the straightforward approach is for the remote desktop software to still start a remote X server but only run a single X program that talks to the server, the remote program you want to start. The local RD client and the remote X server work together to only show you the area of the remote X server's virtual framebuffer that the single client's window occupies.

However, just passing the drawn pixels and the X input events back and forth is only part of having a real remote X program. A true remote X program can see and update X properties, it can participate in at least X's cut and paste systems, letting you copy things in and out of it, it will have proper window titles and desktop or taskbar icons (and it will be able to update its window title, as some programs do), it can appear and disappear (being 'mapped' or 'unmapped'), and it can ask to be placed at a specific location (and there's more). Full support for X properties requires not just access to X properties on the root window, but access to X properties on other client windows; this is how Firefox's X remote control works (cf).

If you're running a full remote desktop session, you don't want a lot of this. Perhaps you want some sort of cut and paste back and forth for convenience, but it's generally a feature that the remote desktop's root window X properties do not become your local root window X properties (and vice versa), for example. This means that a basic implementation of seamless windows with a remote X server won't support any of this. Adding some of this stuff is possible with code that's specific to the seamless window feature, but supporting everything becomes extremely difficult. In particular, a remote program seeing and updating X properties on your local windows pretty much requires an entire set of phantom windows in the remote X server.

(I was going to say that you'd also have problems if the remote program (or things started from it) wanted to open more top level windows, for example because you started GNU Emacs inside your remote xterm, but apparently at least some 'seamless window' implementations manage to handle this (or claim to).)

Pretty much all of the X programs that I run remotely require some or all of these advanced remote X features (including multiple independent top level windows). A 'remote X' system that performs better than 'ssh -X' but doesn't support most of these features isn't terribly useful to me.

(I talked about this a bit in my entry about my failure with Xpra, but I didn't get into detail about why this is hard and at odds with the 'remote desktop' approach.)

RemoteXVsSeamlessWindows written at 00:31:40; Add Comment

2021-03-17

Remote X has been a life saver over this past year

It's now been a bit over a year since I was last regularly in the office (due to still ongoing events). One of the things that has turned out to be really important to working productively from home has been the X Window System's remote support (and SSH's support for X forwarding too, let's not forget that side). Especially, what has been important for me isn't just being able to run GUI programs in some way from a remote host, but being able to have them as regular windows on my desktop instead of corralled off into their own seperate 'remote desktop' world.

(This is on my mind recently because I've been reading another round of people saying that we all have to move to Wayland real soon now. Although apparently Wayland now has some sort of general forwarding in the form of waypipe, although there doesn't seem to be much written on the Internet about experience with it.)

The largest thing remote X has let me do is keep on using my normal email environment, which relies on exmh, xlbiff, and sam. To be productive, all of these need to run in separate X windows on my desktop that I can shift around in various ways (and so that xlbiff can appear on any virtual screen I'm on and then quietly disappear), not in a single giant remote session window. General remote X also lets me have the remote exmh send URLs in email to my local Firefox through Firefox's X based remote control. As a sysadmin a lot of my work involves interacting with email and while things aren't quite as fluid as they would be at work, they're a lot better than they would be without exmh.

(If I didn't have remote X, I probably would have tried to switch to MH-E in GNU Emacs, since that could be used through a text mode SSH session. This would have at least been a bunch of yak shaving.)

The other big thing has been that my home Internet connection is good enough to run VMWare from my work desktop over remote X. Being able to spin up virtual machines as usual has been essential for testing and developing all sorts of things under conditions where doing this with real hardware is difficult and infrequent. I could not have done this on my home machine, and doing it over some sort of RDP or VNC session would have been at least awkward and possibly too bandwidth intensive for my DSL connection.

(VMWare machines can have their consoles accessed over VNC, but most of what I deal with is the regular VMWare GUI for managing VMs. I have my VMs set up so that most of the time I only need to interact with them over SSH, although developing and testing our Ubuntu 20.04 install image did require console access. Since my remote VMWare doesn't scale up the VM consoles when displaying on my local HiDPI display, the less I have to interact with the consoles the better. The usual environment variables affect the VMWare GUI but not the actual consoles.)

I've periodically used an assortment of other X programs remotely. The biggest one is GNU Emacs, which I use as my superintelligent code editor if I'm seriously digging into some program. Modern LSP-based smart code editing in Emacs really wants to be run on a graphical display; it will try to work in a pure text environment, but it just doesn't go very well. If I'm doing any serious Go editing, I need either a remote X session for GNU Emacs or to drag the Go code over to my local machine.

Of course I was already heavily using remote X at work; my normal email environment has always run on one of our login servers, not my office desktop, for example. But this past year of working from home I've generally tried to do as much as possible through SSH sessions (because they're more tolerant of my slower network), and that's really driven home the places where remote X has really mattered.

(It's interesting to look back at my entry from several years ago about what I really miss when I don't have remote X and tick off the things that I made work versus the things that I miss but not enough to do anything about. Perhaps I should make it a habit to run all of my remote logins as 'ssh -X' sessions so that I could at least spawn a new xterm from them if I wanted to, even if I mostly used the initial text mode SSH logins.)

RemoteXLifesaver written at 00:58:04; Add Comment

2021-03-15

Different views of what are basic and advanced Vim features

Although vim is now my most regularly used editor (and it really is vim, not vi), I still have lots to learn about it. Thus, every so often I wind up reading guides to Vim, which often label themselves as being for 'beginning users' or 'intermediate users' or 'advanced users'. One of the interesting things in reading these guides is hitting features labeled as basic that I don't know, or features labeled as advanced that I consider perfectly routine.

(My most recent reading is this one, which I haven't even finished yet.)

For some features that are sometimes considered advanced, like address ranges, I think a lot of this has to do with the path I took through various editors on the way to today. For instance, I've seriously used a version of Unix ed, and it's hard to use ed without getting a fairly thorough exposure to address ranges. This was reinforced by both sysadmin use of sed and my long running fondness for the sam editor. Use of ed and then sam left me completely comfortable with the idea of doing editor operations as (Ex) commands.

(I don't know if marks are generally considered an advanced concept, but as a sysadmin who uses less a lot and jumps around in various sorts of files to find things, marks are very familiar to me and I use them all the time. Sam has the idea of a mark but only a single one, which is easier to keep track of, and it's been so long since I seriously used ed that I can't remember if I really used marks in it.)

When I run into basic vim features that I don't know or haven't mastered, I generally remind myself that I basically drifted into vim instead of actively learning it (including vi). I did at one point long ago read through what was then the vi tutorial, but I did it in another editor (which didn't help get it to stick). This path into vim has left me learning things on a scattershot basis as I stumble over them and decide that they're worth it (not every vim feature is for me).

Part of this is that I use vim primarily as a sysadmin, which is to say that I'm either editing text (such as email) or I'm working with generally small amounts of code, or at least of editing code. My editing sessions tend to be short; I'm definitely not spending all day editing code. If I was, I would probably be more driven to learning vim features that improved that. Plus, right now and likely for the indefinite future, my editor for serious coding is still GNU Emacs for various reasons.

(The pattern of vim things that catches my interest is quite driven by sysadmin interests, from windows while modifying related files at once through mass commenting out references to a machine to changing a bunch of files in the same way at once.)

VimWhatIsAdvanced written at 02:21:53; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.