extension to mouse capabilities within xterm TTY frame

extension to mouse capabilities within xterm TTY frame

[Olaf Rogalsky]

Hi all,

I would like to bring to your attention two extensions I wrote, relating
the mouse support, when used inside a xterm TTY frame.

1) a replacement for the official xt-mouse.el:

   https://github.com/olaf-rogalsky/xt-mouse

   The official xterm-mouse-mode does not highlight the selection during
   mouse dragging. This version creates mouse-movement events while
   dragging the mouse. A direct visual feedback of the selected text is
   given.


2) a minor mode, which enables access to the X11 clipboard/selection
   from within xterm:
   
   https://github.com/olaf-rogalsky/xterm-clip
   
   This extension is very similar to xclip.el from Leo Shidai Liu. But
   instead of using an external program to access the clipboard, this
   code uses xterm control sequences.

   Advantages: no external programm needed, no access to X11-server via
   DISPLAY variable is neccessary.
   
Comments are welcome.

Regards,
Olaf

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany

Re: extension to mouse capabilities within xterm TTY frame

[Emanuel Berg]

Olaf Rogalsky <olaf.rogalsky@gmail.com> writes:

> I would like to bring to your attention two
> extensions I wrote, relating the mouse support, when
> used inside a xterm TTY frame.

The "TTY"s are usually meant to be the Linux virtual
terminals (VTs), or ttys, or simply "the console":
those you get with Ctrl-Alt-F1, for example, for
/dev/tty1, from X. (In a tty, you only need, say,
Alt-F2 to go to tty2. Even that is bulky so check out
[1] for how to rebind that.)

Try tty(1) in a VT and it'll tell you /dev/tty3 for
the third one, and so on (and in reverse).

On many systems /dev/tty7 is used for X. If you
disable the login manager (that will automatically
start X) you get /dev/tty1 instead... and you can
start X manually with xinit(1), after login! (Actually
there is autologin - no password - for the ttys as
well, for the bold and the impatient.)

xterm, on the other hand, is... <drumroll> a terminal
emulator for X! To confirm that xterm isn't a "real"
tty, hit tty again (in xterm) and it says, perhaps,
/dev/pts/9.

> 1) a replacement for the official xt-mouse.el:
>
>    https://github.com/olaf-rogalsky/xt-mouse
>
> The official xterm-mouse-mode does not highlight
> the selection during mouse dragging. This version
> creates mouse-movement events while dragging the
> mouse. A direct visual feedback of the selected text
> is given.

Cool! I would think most mouse users use the GUI Emacs
in X. But as is evident, not all, so good work!

> 2) a minor mode, which enables access to the X11
> clipboard/selection from within xterm:
>    
>    https://github.com/olaf-rogalsky/xterm-clip
>    
> This extension is very similar to xclip.el from Leo
> Shidai Liu. But instead of using an external program
> to access the clipboard, this code uses xterm
> control sequences.

...*and* the xsel.el from yours truly! :) Actually, I
used xclip to do that as well at first. It was one of
the very first things I published on this group. But
then I was in several flame wars so I would
disencourage anyone from using Google to verify that
claim... Anyway the reason was that I still used a
browser in X (indeed a long time ago) so I needed the
interface back and fourth, and with xclip it was
possible, and later, with xsel, even better. But soon
I found RMAIL, later Gnus, as well as Emacs w3m, so I
could do without X altogether. Somewhere around I
noticed the xclip package in ELPA, so I put my stuff
into a package as well not to be any worse [2] and
there is even a zsh companion [3]. But there was still
one use case for it, namely to Emacs from the ttys.
Again, soon I put tmux(1) over all ttys except the
Emacs one (naturally in /dev/tty1), and so with tmux I
found an even better way [4].

> Advantages: no external programm needed, no access
> to X11-server via DISPLAY variable is neccessary.

That it doesn't use an external program is not an
advantage, exactly. It depends.

And the DISPLAY variable is only needed for the "real"
ttys? So does that apply to xterm?

Anyway, good work! Keep it up.

[1] http://user.it.uu.se/~embe8573/conf/remap.inc
[2] http://user.it.uu.se/~embe8573/conf/emacs-init/xsel.el
[3] http://user.it.uu.se/~embe8573/scripts/xi
[4] http://user.it.uu.se/~embe8573/conf/.tmux.conf
    http://user.it.uu.se/~embe8573/conf/emacs-init/linux-shell.el

-- 
underground experts united

Re: extension to mouse capabilities within xterm TTY frame

[Olaf Rogalsky]

embe8573@student.uu.se writes:

> Olaf Rogalsky <olaf.rogalsky@gmail.com> writes:
>
>> I would like to bring to your attention two
>> extensions I wrote, relating the mouse support, when
>> used inside a xterm TTY frame.
>
> The "TTY"s are usually meant to be the Linux virtual
> terminals (VTs), or ttys, or simply "the console":
> those you get with Ctrl-Alt-F1, for example, for
> /dev/tty1, from X. (In a tty, you only need, say,
> Alt-F2 to go to tty2. Even that is bulky so check out
> [1] for how to rebind that.)
>
> Try tty(1) in a VT and it'll tell you /dev/tty3 for
> the third one, and so on (and in reverse).
>
> On many systems /dev/tty7 is used for X. If you
> disable the login manager (that will automatically
> start X) you get /dev/tty1 instead... and you can
> start X manually with xinit(1), after login! (Actually
> there is autologin - no password - for the ttys as
> well, for the bold and the impatient.)
>
> xterm, on the other hand, is... <drumroll> a terminal
> emulator for X! To confirm that xterm isn't a "real"
> tty, hit tty again (in xterm) and it says, perhaps,
> /dev/pts/9.
Yes, I know, xterm provides a pseudo-tele-type (pty). But in the source
code of emacs, all functions, which deal with tty's and pty's, have a
"tty" in their name. A very nice article, which explains the internals
and the history of the tty subsystem in UNIX can be found here:
http://www.linusakesson.net/programming/tty/index.php

> Cool! I would think most mouse users use the GUI Emacs
> in X. But as is evident, not all, so good work!
I never use the gui emacs. I am switching back and forth between several
instances of emacs and the shell with the job control commands from the
bash. I could do it the other way round with shell-mode, but I like it
as it is.

> That it doesn't use an external program is not an
> advantage, exactly. It depends.
Xclip (or xsel, or any of the other variants) is not installed
everywhere.  But I agree, its mostly a matter of taste. I just dislike
having a seperate program for such a fundamental thing like access to
the clipboard.

> And the DISPLAY variable is only needed for the "real"
> ttys? So does that apply to xterm?
The DISPLAY variable is needed to make a connection to the X-server. For
example, xsel uses DISPLAY to find out, to which X-server it shall
connect to (there may be several X-servers running, the X-server may be
on a remote computer). There is no X-server in a "real" tty, but if you
set DISPLAY to a running X-server (start X11 on vt7, switch back to vt1,
enter "export DISPLAY=:0" on the shell prompt), then xsel running on the
tty can access the X-servers clipboard (which of cause isn't very
usefull).

In a purly tty environment without X11, tmux probably is a better
solution.

On the other hand, if I ssh to a remote host from a xterm without X11
forwarding (no DISPLAY), then xterm-clip still can access the clipboard
via xterm's control sequences.

> Anyway, good work! Keep it up.
Thanks

Olaf

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany

Re: extension to mouse capabilities within xterm TTY frame

[Emanuel Berg]

Olaf Rogalsky <olaf.rogalsky@aol.de> writes:

>> Cool! I would think most mouse users use the GUI
>> Emacs in X. But as is evident, not all, so good
>> work!
>>
> I never use the gui emacs. I am switching back and
> forth between several instances of emacs and the
> shell with the job control commands from the bash. I
> could do it the other way round with shell-mode, but
> I like it as it is.

OK, but why do you use several instances of Emacs? If
you only use one, you don't need X's clipboard at all
but can stick to the much more powerful Emacs kill
ring.

>> That it doesn't use an external program is not an
>> advantage, exactly. It depends.
>>
> Xclip (or xsel, or any of the other variants) is not
> installed everywhere.

No, they aren't.

> But I agree, its mostly a matter of taste. I just
> dislike having a seperate program for such a
> fundamental thing like access to the clipboard.

I don't see the "inter-program" clipboard as
fundamental anymore as I moved browsing and
Usenet/mails (and IRC, tho I don't use that a lot), I
moved all of that to Emacs. Of course, the kill ring
is fundamental to Emacs, and its importance increases
the more stuff you bring from the rest of the system
into Emacs. Not only the things I mentioned but
documentation (the man pages, info, possibly more),
and the file system (dired)... (The only thing I'll
never bring to Emacs is the shell itself - I use zsh -
because I have hundreds of shell functions by now, and
I have a very fast transition between the zsh/tmux
panes, and Emacs, so it would be unproportionally an
effort for a small gain.)

If, however, there *is* need for an inter-program
clipboard I would actually like that to be an external
program, because then different programs could hook
into that (like indeed xclip/xsel), so there wasn't a
need to set this up for every program: X's clipboard,
Emacs' kill ring, readline(3) of the shell, and
whatever else does this.

>> And the DISPLAY variable is only needed for the
>> "real" ttys? So does that apply to xterm?
>
> The DISPLAY variable is needed to make a connection
> to the X-server. For example, xsel uses DISPLAY to
> find out, to which X-server it shall connect to
> (there may be several X-servers running, the
> X-server may be on a remote computer). There is no
> X-server in a "real" tty, but if you set DISPLAY to
> a running X-server (start X11 on vt7, switch back to
> vt1, enter "export DISPLAY=:0" on the shell prompt),
> then xsel running on the tty can access the
> X-servers clipboard (which of cause isn't very
> usefull).

Yes, what I mean is, in X, where you use xterm, you
don't need that for normal usage. Try, for example:

    echo "Didn't mention DISPLAY" | xsel -i -b; xsel -o -b

In the ttys (that aren't occupied by X), you *do* need
it, but there you don't use xterm anyway.

> On the other hand, if I ssh to a remote host from a
> xterm without X11 forwarding (no DISPLAY), then
> xterm-clip still can access the clipboard via
> xterm's control sequences.

Yes, for complicated situations like that, and/or with
several X servers, I can't tell you how my stuff would
work because I never did it.

-- 
underground experts united