ALT character encodings [LWN.net]

ALT character encodings

Posted Nov 2, 2004 23:09 UTC (Tue) by iabervon (subscriber, #722)
In reply to: ALT character encodings by Per_Bothner
Parent article: Using Unicode in Linux (NewsForge)

Actually, looking at ANSI escape sequences, plus the fact that holding alt is considered equivalent to first typing ESC for terminals (which I'd forgotten) should give a reasonable solution for the keys. In fact, if Alt-f opens the file menu, typing ESC f instead should still make the shell go forward a word (or whatever the receiving program does with that input), since the terminal emulator is actually getting keyboard scan codes and can tell what you're really doing without escape sequence encoding.

As for the user interface standards, it is impossible to have a single clipboard between the terminal emulator and the program running in it; I often have the same program running in multiple terminal emulators on different machines, using screen. I find it useful that I can copy some text in emacs in the screen session on my login server while connected from work, log out of work, go home, log in, connect to the screen session, and paste the text. For that matter, I sometimes log into the screen session from multiple places at once, and I don't want my clipboard transferred from desktop 1 via my server to desktop 2 whenever I copy something on desktop 1. So it matters very much whether I'm copying something from the desktop into the terminal emulator or whether I'm copying something inside the terminal emulator.

(Log in to post comments)

ALT character encodings

Posted Nov 4, 2004 3:15 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link]

typing ESC f instead should still make the shell go forward a word (or whatever the receiving program does with that input)

It's not an ideal solution, though, as typing ESC f isn't quite as convenient as typing Alt-f.

I find it useful that I can copy some text in emacs in the screen session on my login server while connected from work, log out of work, go home, log in, connect to the screen session, and paste the text.

That seems rather esotheric. Few people are going to try that. (That doesn't mean it wouldn't bve nice to have.) But more important is being able to copy to the clipboard from one application, and paste into the terminal emulator. Note I can type ctrl-Y in a remote Emacs X window, and have it paste from the clipboard on my local screen. It's not unreasonable to want the same for a remote Emacs running in a terminal window - though it would take some enhancement to the terminal enulator.

It is still possible to get the effect you want: if you log out your "X-enhanced screen", it can copy the current clipboard contents to the screen session. This would be somewhat similar to the proposal "clipboard manager", except that this clipboard manager would be local to screen.

I've been dreaming of an enhanced terminal emulator, including the functionality of the abandonded XMLterm, my Emacs terminal-mode and "rlfe" front-end, but I don't see any signs of it happening, I'm sorry to say.

ALT character encodings

Posted Nov 4, 2004 6:39 UTC (Thu) by iabervon (subscriber, #722) [Link]

It's not an ideal solution, though, as typing ESC f isn't quite as convenient as typing Alt-f.

Personally, I don't like drop-down menus, and I really think they're inappropriate for terminal emulators. Particularly "File", since they don't do anything with files.

That seems rather esotheric.

I do unusual things, certainly. On the other hand, once you have the right model in your head, it works just like you'd think. It's a bit like carrying around a book and reading it in sequence regardless of where you happen to be, or having a laptop that you can pull out in different places, except that you don't have to carry it around.

Personally, I copy from one window to another with the mouse, and expect the keyboard to act internally to the program, although obviously emacs doesn't actually work entirely that way, and there's no particular reason it should. Of course, xterm and programs in them do behave the way I expect. I don't think I've ever wanted to have a remote program pull the clipboard state from the local session, or expected that to work; sending the local clipboard through the terminal to the remote program seems more natural. I've actually been more likely to expect to be able to copy and paste into a window out of real life (obviously, this didn't work).

ALT character encodings

Posted Nov 7, 2004 16:08 UTC (Sun) by pimlott (guest, #1535) [Link]

I don't think I've ever wanted to have a remote program pull the clipboard state from the local session, or expected that to work

I do this all the time with vim. Even in terminal mode, you can paste from the clipboard by typing "*p. Of course, it needs an X connection to do this, usually the one forwarded over ssh. This is not ideal, because I use a screen-like program (dtach), so that when I reattach from a different system, vim still tries to use the old X connection. So for me, a terminal-based clipboard protocol would be a big win. (One could imagine an alternate hack: put $DISPLAY into a file .display, and have vim poll that file and reinitialize its X connection when it changes. But a terminal-based protocol would be more likely to be supported by non-X-aware applications.)

sending the local clipboard through the terminal to the remote program seems more natural

Do you mean a simple paste into the terminal? This is even less ideal, because usually you want the program at the other end to accept the pasted text uninterpreted, but there's no way for it to know it's getting a paste. (Well, vim has paste mode for this purpose, but you have to turn it on and off.)

I've actually been more likely to expect to be able to copy and paste into a window out of real life (obviously, this didn't work).

:-(