FS#49864 - [emacs] Cut and paste to and from emacs buffers in virtual consoles (without X11) no longer works
Attached to Project:
Arch Linux
Opened by Mike Dowling (mdowling) - Monday, 27 June 2016, 07:20 GMT
Last edited by Jürgen Hötzel (juergen) - Monday, 10 December 2018, 16:07 GMT
Opened by Mike Dowling (mdowling) - Monday, 27 June 2016, 07:20 GMT
Last edited by Jürgen Hötzel (juergen) - Monday, 10 December 2018, 16:07 GMT
|
Details
Description:
In virtual consoles WITHOUT X11 or graphics, the mouse can no longer be used to cut and paste to and from emacs buffers. Typically, I would use the mouse to cut and paste from the command line or other virtual consoles into an emacs buffer but this no longer works. instead, one sees the message: "x selection is unavailable for this frame", o, indeed for any other frame. I have tested this with "emacs -q", thereby demonstrating that the problem does not lie with my .emacs init-file. But just to make sure, I created a new user with no configuration files at all, and I get the same response. I have used a recursive zgrep on all .el.gz files in /use/share/emace/24.5 to find an elisp file containing that message but found none. I also attempted a grep on the output from "strings /usr/bin/emacs" but found no match. The message is upsetting as it referrs to "x selection" although I am in a virtual (text) console without X11. This used to work! I don't kno when it stopped working. Cut and paste with the mouse works fine using xterms and X11. Of course, for virtual consoles, gpm must be running. Cut and paste using the mouse works fine when cutting and pasting to and from anything except emacs buffers. Additional info: * package version(s) emacs-24.5.1 * config and/or log files etc. No log output; the problem is reproducible without any config files, emacs or otherwise. The *Messages* buffer contains no extra information. Steps to reproduce: You can start without a .emacs file or with emacs -q in a text mode virtual console (no X11, no graphics). Enter $ emacs on the command line and you will see the emacs welcome page. Double click on any word, and paste with mouse-2. The paste will not work. Instead you will see the message "x selection is unavailable for this frame" You get the same message regardless of the buffer, and regardles as to where you try to cut from. I have checked with the emacs docs and can find no reference to the problem. This might be an unfortunate feature where the emacs developers proceed on the assumption that nobody in their right mind these days would ever want to work without graphics mode. In which case, I would just have to accept the sad reality. But a mere confirmation of the problem by somebody would be of some benefit to me. |
This task depends upon
To enable mouse in tty (emacs -nw), one has to issue M-x 'xterm-mouse-mode'.
Then select the text using mouse and M-w to copy. Switch to buffer C-x b *scratch* and C-y to insert the copied text.
I've tried opening a virtual console on tty2 ( ctrl+alt+F2 ). Then I started gpm.service (via systemctl) to enable mouse movement in virtual console.
The result, I can select text on emacs (emacs -q -nw), killing some text (ctrl-w), copying text (M-w), and yanking from kill-buffer (C-y). Everything works as expected. I didn't enable 'xterm-mouse-mode' since the mouse is already works. Note that copying and pasting is done via keyboard. Using mouse click doesn't work at all.
About pasting into *GNU Emacs* buffer, it doesn't work because the buffer is 'read only'. Pasting into other non read-only buffer from killed text works fine, though (e.g. *scratch*).
Yes, killing text and yanking it again works. Mouse can be used withing virtual consoles; this has been possible from 1980s. It works on the consoles themselves, and for the vi editor, and pretty much anything capable of editing, except emacs.
Now for something strange; for a while starting emacs hung for quite a while. Eventually, it would start. This problem can occur in X11 and virtual consoles. I noted that some elisp files were read-only for root; I fixed that, and it appeared to solve the problem. But it has not. Sometimes emacs will start quickly, and at other time it can take a minute or so. The problem also occurs with 'emacs -q'. Using strace, I could see that emacs was waiting for some resource, but wich resource, I could not determine.
The connection? When it hangs and I am impatient, Ctrl-G. When I do that, prest, cut and paste works once again in virtual consoles! Also, when I interrupt whatever emacs is doing on a vconsole, I cannot use the mouse to operate the scroll-bar; if I wait patiently, then even the scroll-bar works in the vconsole. Just now cut-and-paste.
Finally, the error message itself I find unsettling. Why "X selection" in a vconsole? Worse, vconsoles don't have frames; frames only exist in graphics modes. For me, it looks like an emacs bug but I could be wrong. It is strange that you cannot reproduce this.
When I reset the virtual console TERM variable to 'linux' (TERM=linux; reset), Emacs (emacs -q -nw) started fast and there was no bug with emacs kill buffer with mouse selection. The only thing I encounter is the right mouse button (gpm) doesn't paste the selected text, but I think it's okay since the text selection is affecting cursor/mark position. M-w and C-y is needed to put selected text into emacs killbuffer and pasting the killbuffer into cursor/mark position.
Have you checked any of shell startup files (.bashrc, .profile, .zshrc, etc) that forces TERM variable to be set to some value?
I increasingly suspect a bug in emacs. The error message appears to refer to X11 properties ("X selection", "frams") when no X11 is running. Moreover, traditionally there were two modes of selection: PRIMARY and SECONDARY, but as of emacs version 24 a third one has been created, namely CLIPBOARD that is suppoed to work more intuitively with desktop software.
Since I get the problem with a freshly compiled version, I deduce that this is probably not an Arch problem. But it is so strange that I can reproduce this error in so many ways, with and without .emacs, or configured environment variables (beyond those that are automatically defined by Arch) and yet nobody else can reproduce it.
This is just my effort to reproduce the problem. I don't know if mdowling can reproduce the problem inside a qemu/virtualbox vm.
Thanks again,
Mike Dowling
Thanks again,
Mike Dowling
I compute between Braunschweig an Hamburg, and have Arch Linux computers in both cities, each acting ad a backup og the other. In Braunschweig, I had installed some elisp packages. My site-lisp directory had therefore been altered in Braunschweig. Starting emacs with the -q flag ought not to use the site-lisp directory, surely? But in Braunschweig I still had the problems. I compile my own emacs, still the problems. Go to Hamburg, no problem. Rename the Hamburg site-lisp, and unpack my Braunschweig version, and bingo; the same problem as Braunschweig.
So, successively delete the new packages until only the older ones were left; still the problem. Change tactic; restore the Hamburg site-lisp, and successively add the new packages. Strangely, no problems.
I do not understand this, but the problems have gone away.
Thanks again for the help. (I feel somewhat silly after all this.)
Cheers,
Mike Dowling