Re: Semantics of text virtual console vs. xterm

On Sun, 24 Feb 2008 17:12:46 -0500 Bill Marcum <marcumbill@xxxxxxxxxxxxx> wrote:

| In most GUI software, when you drag the cursor, the starting and ending
| positions are considered to be between characters. Imagine that you are
| physically cutting paper with the cursor as the blade. If you don't like
| that you can use a text-mode editor such as nano or vim, and ignore the
| mouse cursor unless you want to paste from one window to another.

I do a lot of text copy and paste in text console now, with gpm as the
mouse handler. The semantics work great. You are "on" some character.
You click it with the left button. Move to another character. Click
on that next character with the right button. You have now copied all
the characters from one to the other, inclusive. It's exactly what I
want to do.

I take it in X the cursor is treated as being at the nearest the point
in between characters. So if it is on the 4 in "0123456789", but is
closer to the 3, then it is effectively "between" the 3 and 4. But if
it is closer the 5, then it is effectively "between" the 4 and 5.

The "I-bar" cursor certainly seems to suggest this concept.

It is this between-ness that I want to change. Is this imposed by the
design of X itself? Or the window manager? Or the application? Can
it be changed in the application?

So if I change it (however that might be accomplished), it would seem
that changing the cursor from "I-bar" to something like a block or box
would make sense. And visually, for me, it would be comfortable as well.

In text mode, copying selected text is just so easy. In X, which I do
use quite a lot for other things, it is not so easy. So when I do the
kinds of editing of text where I need it to be easy, such as writing C
code, I drop out to a text console and fire up my editor, and fly with
it.

An ability to have a program or script "stuff" characters into a session
would be a plus. I do that now in text mode via a kernel patch. It
used to be possible with ptys by finding the right /dev/ptyXX, but Linux
has changed they way this works, so there is no simple way for some
program to parallel open a pty side as the original pty process (xterm).


| Double clicking selects a "word", defined as a series of characters of
| the same class. See "Character Classes" in the xterm man page.

It seems it defines this through X resources. Unfortunately, that is a
rather awkward mechanism when dealing with a data definition as large
as character classes. It needs to be a separate file (maybe with the
X resource used to name the file).


|> The third issue is to find a way to rapidly switch between different screens
|> of text. In text mode, the traditional virtual console involves Alt+FX,
|> where FX is one of the "F" function keys on the top row of the keyboard.
|> I have, through keyboard mapping, expanded that to so that Alt+X, where X
|> is either one of the function keys or one of just about any other key on
|> the main part of the keyboard (including space and ESC). I have 63 such
|> mappings to virtual consoles, and use them all. Alt+F10, Alt+F11, and
|> Alt+F12 are each going to X Windows (I run three instances of X at the
|> same time). The rest go to one of 60 different virtual consoles, all of
|> which are logged in and used. When I press Alt+X the switch is very rapid.
|> Some people have suggested using screen, but it is awkward to use for this
|> kind of rapid switching (I sometimes switch back and forth a few times a
|> second). I would thus want to have some kind of means to do such rapid
|> keyboard based switching while in X. That would not be switching between
|> the different instances of X (that's way too slow, anyway). It could be
|> switching between different windows of xterm, or subwindows within xterm,
|> or different virtual desktops within the same instance of X. Whichever is
|> the fastest is the way to go. But how to set that up? Maybe it needs a
|> new window manager? Or is one already available that can do that.
|>
| You can use screen, which also works in console mode, or you can use
| the alt-tab key or a terminal with multiple tabs.

This doesn't accomplish the rapidity I'm accustomed to. It needs to be a
a single keystroke to jump around multiple desktops (while holding one other
key continuously). I can do that now in text mode by holding down ALT and
flipping through for example F5, F6, and F7 and back to F5 again. Actually
I have it set for many other characters besides function keys. But the idea
is the rapidity of moving around.

Also, direct access is needed. Merely stepping through a cycle of displays
is not good enough. That's too slow, and requires recognizing whether or
not I am in the correct displays (among many that often look very much alike).

I am very used to the efficient speed I can get with text mode. In the past
much of that speed was due to speed differences in text vs. graphic updates
in the video buffer. Today, video buffers are fast enough that should not be
an issue. But the actually user interface itself is still slower in X than
it is in text mode, for text stuff (it's obviously absent in text mode for
graphical stuff).

If the window manager can be programmed to recognize the same ALT keystrokes
as text mode works with, that may do the job. If X can buffer the desktops
in different areas of a video card with LOTS of memory (256MB to 1GB), that
would do even better as it eliminates the expose delays for sluggish apps.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-0119@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Quantcast