bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Dr. Michael L. Dowling]

I don't believe that emacs can send this report as my ISP expects SASL to port 578.  I therefore
send it using an appropriately configured "mutt" as user agent.

The Report:

If I  use X-windows, there is  no problem with cutting  and pasting from
outside an emacs  buffer into an emacs buffer and  vice versa.  But this
no  longer works  when  in a  text  console.  When  on  a Linux  virtual
console, pasting into an emacs buffer results in the message:

"No selection available"

in the mini-buffer.   Conversely, marking text in  an emacs buffer and pasting  into a virtual
console yields no error, but it does not paste.

I have been using Linux and emacs for decades,  and this used to work until recently, but just
how recently, I cannot say, probably a month or two.

I've  searched the  Internet, but  the only  mention  of something  similar said  that it  was
fundamentally impossible, but this  is not true.  I've been using that  feature for years.  (I
had the impression  that the author was using Windows  and wanted to cut
and paste to and to and from a DOS box.)

I use Arch Linux with the latest packages updated every day.  Nothing self compiled.


My tests were as follows:

  1. Try emacs -q -- still does not work.
  2. Set up a new user with no special  environment, just out of the box.  No .emacs file, and
     no bash init files.  Same behaviour.
  3. Now  the strange bit: login  using my normal userid  "mike" and change user  to the newly
     created user "joe", and cut and paste works for joe.  ("su - joe" was used for that.)
  4. Logout, and log back in again as joe (no su -; joe logs in from the
     text terminal), cut and paste no longer works for joe, But change user user
     using "su - mike", and it works for mike!
  5. Is it a shell problem?  Change shell to zsh, same behaviour.
  6. Login as mike  or joe, and call the bash  again.  Now I'm not in a  login shell, but same
     behaviour, no cut and paste.

I cannot say for sure that this is an emacs  problem.  It could be a Linux problem, or an Arch
Linux problem.   It might even  be a shell  problem, although with  the above tests  that seem
unlikely.




In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-16 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
Configured using:
 'configure   --prefix=/usr    --sysconfdir=/etc   --libexecdir=/usr/lib
 --localstatedir=/var  --with-x-toolkit=gtk3  --with-xft  --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt'                                  CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG  TIFF GIF PNG RSVG  IMAGEMAGICK SOUND GPM DBUS  GCONF GSETTINGS
NOTIFY   ACL  GNUTLS   LIBXML2   FREETYPE  M17N_FLT   LIBOTF  XFT   ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LC_CTYPE: en_NZ.UTF-8
  value of $LC_MONETARY: en_IE.UTF-8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  Info-breadcrumbs-in-mode-line-mode: t
  icicle-mode: t
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  on-screen-global-mode: t
  display-time-mode: t
  global-highlight-parentheses-mode: t
  highlight-parentheses-mode: t
  minibuffer-depth-indicate-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Function icicle-repeat-complex-command is already compiled
Turning OFF Icicle mode...done
Turning ON Icicle mode...done
Turning OFF Icicle mode...done
Turning ON Icicle mode...done
Turning ON Icicle mode...done
Appointment reminders enabled (no diary file found)
Loading /usr/share/emacs/25.3/lisp/textmodes/table.elc...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Computing completion candidates...

Load-path shadows:
None found.

Features:
(shadow  sort org-rmail  org-mhe org-irc  org-info org-gnus  org-docview
doc-view subr-x jka-compr image-mode  org-bibtex bibtex org-bbdb org-w3m
org-table  org org-macro  org-footnote org-pcomplete  org-list org-faces
org-entities  org-version  ob-emacs-lisp   ob  ob-tangle  ob-ref  ob-lob
ob-table  ob-exp org-src  ob-keys ob-comint  ob-core ob-eval  org-compat
org-macs  org-loaddefs  find-func  flyspell  ispell  mail-extr  emacsbug
sendmail face-remap table  browse-kill-ring+ browse-kill-ring mouse-drag
mouse-copy appt diary-lib  diary-loaddefs cal-menu calendar cal-loaddefs
warnings  two-column   info+  info  icicles   icicles-mode  icicles-cmd2
icicles-cmd1   second-sel   frame-cmds  frame-fns   avoid   icicles-mcmd
image-dired  icicles-fn icicles-var  apropos-fn+var apropos  icicles-opt
ffap  url-parse   url-vars  fuzzy-match  cus-theme   cus-edit  cus-start
cus-load   bookmark+    bookmark+-key   derived    dired-x   bookmark+-1
bookmark+-bmu  bookmark+-lit  pp+   icicles-face  ring+  edmacro  kmacro
julia-shell  loccur  crosshairs  lacarte  synonyms  thingatpt+  hl-line+
hl-line col-highlight  vline doremi psvn wid-edit  log-edit message idna
dired rfc822  mml mml-sec  epg mm-decode mm-bodies  mm-encode mail-parse
rfc2231  rfc2047  rfc2045  ietf-drums  mailabbrev  mail-utils  gmm-utils
mailheader pcvs-util add-log diff-mode ido ess-toolbar ess-mouse mouseme
ess-menu ess-swv ess-noweb  ess-noweb-font-lock-mode ess-bugs-l essd-els
ess-sas-d  ess-sas-l  ess-sas-a   ess-sta-d  ess-sta-l  cc-vars  cc-defs
make-regexp  ess-sp6-d ess-dde  ess-sp3-d  ess-julia julia-mode  ess-r-d
ess-r-syntax   ess-r-completion   ess-roxy  essddr   hideshow   ess-help
ess-r-package  ess-s-l  ess   ess-inf  ess-tracebug  tramp  tramp-compat
auth-source   gnus-util  mm-util   help-fns  mail-prsvr   password-cache
tramp-loaddefs trampver ucs-normalize shell pcomplete format-spec advice
ess-mode ess-noweb-mode ess-utils  ess-generics cl ess-custom executable
ess-compat  ess-site bookmark+-mac  bookmark filladapt  dabbrev tex-site
auto-loads   on-screen   hexrgb   ack   quail   math-symbol-lists   time
slime-editing-commands     slime-scratch      slime-repl     slime-parse
slime-autoloads slime compile etags xref cl-seq project eieio eieio-core
cl-macs arc-mode archive-mode noutline outline pp comint ansi-color ring
hyperspec   thingatpt   browse-url  blinking-cursor   pager   easy-mmode
highlight-parentheses mb-depth+  mb-depth finder-inf  package epg-config
seq byte-opt gv bytecomp  byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs  pcase cl-lib  time-date  mule-util  tooltip eldoc  electric
uniquify    ediff-hook    vc-hooks    lisp-float-type    mwheel    x-win
term/common-win  x-dnd  tool-bar  dnd fontset  image  regexp-opt  fringe
tabulated-list newcomment  elisp-mode lisp-mode prog-mode  register page
menu-bar rfn-eshadow  timer select  scroll-bar mouse  jit-lock font-lock
syntax  facemenu font-core  frame  cl-generic  cham georgian  utf-8-lang
misc-lang vietnamese tibetan thai  tai-viet lao korean japanese eucjp-ms
cp51932  hebrew greek  romanian  slovak czech  european ethiopic  indian
cyrillic  chinese  charscript  case-table  epa-hook  jka-cmpr-hook  help
simple  abbrev minibuffer  cl-preloaded  nadvice  loaddefs button  faces
cus-face macroexp  files text-properties overlay sha1  md5 base64 format
env  code-pages mule  custom  widget hashtable-print-readable  backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 523402 14043)
 (symbols 48 51189 1)
 (miscs 40 664 299)
 (strings 32 129144 19036)
 (string-bytes 1 3827730)
 (vectors 16 68310)
 (vector-slots 8 1193079 2274)
 (floats 8 557 274)
 (intervals 56 370 0)
 (buffers 976 106))

-- 
Dr. Michael L. Dowling
Gaußstr. 27
38106 Braunschweig
Germany

-- 
Dr. Michael L. Dowling
Gaußstr. 27
38106 Braunschweig
Germany

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Stefan Kangas]

[Please use "Reply to all" so the discussion is in the bug tracker.]

Hi Michael,

Thanks for replying back with details.  I'm hoping that the information
you have provided will help someone who knows more about this stuff
investigate this.

Best regards,
Stefan Kangas

"Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:

> Hello Stefan!
>
> Thanks for  replying.  This  is an  old bug  report but  is nevertheless
> still valid.
>
> On Mon, Aug 10, 2020 at 09:14:36AM -0700, Stefan Kangas wrote:
>> "Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:
>
>> > The Report:
>> >
>> > If I  use X-windows, there is  no problem with cutting  and pasting from
>> > outside an emacs  buffer into an emacs buffer and  vice versa.  But this
>> > no  longer works  when  in a  text  console.  When  on  a Linux  virtual
>> > console, pasting into an emacs buffer results in the message:
>> >
>> > "No selection available"
>
> This continues to be the case to this day.
>
>> > Conversely, marking text in  an emacs buffer and pasting  into a virtual
>> > console yields no error, but it does not paste.
>
> This has apparently been fixed.  It now works.
>
> Of  course, cut-and-paste  never worked  when it's  from an  xterm to  a
> virtual console, and vice versa, and I have never expected it to.
>
>> How do you cut and paste in the Linux virtual console?  Are you using
>> gpm?
>
> Yes, I use gpm.
>
>> Could you please provide a recipe for reproducing this?
>
> Simple!
>
> /usr/lib/systemd/system$grep gpm *
> gpm.service:ExecStart=/usr/bin/gpm -m /dev/input/mice -t imps2
>
> However  I mark  that text,  for example,  with a  depressed left  mouse
> button on the '/'  of '/usr', and dragging the mouse  to '2' of 'imps2',
> and then  releasing the left button,  with a right button  click in this
> text as I write, I get that error.  The same goes for any other means of
> cutting and pasting, for example, simply  double clicking on a word, and
> pasting with a single right button click, the same error.
>
> (I copied this text using emacs; start a shell process in emacs, and cut
> and  paste using  emacs, works.   This  doesn't use  the mouse,  though,
> namely with the set-mark-command (C-SPC) and append-next-kill (M-C-w).)
>
>> >
>> > My tests were as follows:
>> >
>> >   1. Try emacs -q -- still does not work.
>> >   2. Set up a new user with no special  environment, just out of the box.  No .emacs file, and
>> >      no bash init files.  Same behaviour.
>> >   3. Now  the strange bit: login  using my normal userid  "mike" and change user  to the newly
>> >      created user "joe", and cut and paste works for joe.  ("su - joe" was used for that.)
>> >   4. Logout, and log back in again as joe (no su -; joe logs in from the
>> >      text terminal), cut and paste no longer works for joe, But change user user
>> >      using "su - mike", and it works for mike!
>
> I had forgotten about this.  So I made some more tests.
>
> Login from a virtual console as  "joe", and cut-and-paste does not work.
> (Joe  has  a  completely  empty  home  directory;  no  .bash*  except  a
> .bash_logout that deletes everything except .bash_logout)
>
> Login as "mike" and "su - joe" and it does work.
>
> Login as "mike" and "su - mike" and it doesn't work.
>
> Login as "joe" and "su - mike", and cut-and-paste works!!!
>
> Give "joe"  with ksh as  login shell  and login as  "joe", cut-and-paste
> doesn't work.
>
> It doesn't work for  root either when root logs in as  root on a virtual
> console.
>
> Weird!
>
> BTW, this  computer is not  one year old and  has a completely  new ARCH
> installation.
>
>> >   5. Is it a shell problem?  Change shell to zsh, same behaviour.
>> >   6. Login as mike  or joe, and call the bash  again.  Now I'm not in a  login shell, but same
>> >      behaviour, no cut and paste.
>> >
>> > I cannot say for sure that this is an emacs  problem.  It could be a Linux problem, or an Arch
>> > Linux problem.   It might even  be a shell  problem, although with  the above tests  that seem
>> > unlikely.
>>
>> Are you seeing this outside of Emacs?
>
> No!   Cut-and-paste  works  fine  everywhere else,  within  and  between
> virtual consoles, from virtual consoles to postgresql (psql), to python,
> etc, etc.  The (frustrating) odd man out is emacs.
>
> As I recall,  at the time cut-and-paste ceased to  work for emacs, there
> had been a major upgrade of emacs.
>
> There  is  something   about  that  initial  login   that  affects  that
> cut-and-paste.
>
> My Linux boots to text-mode virtual  consoles.  I manually start X using
> startx.  This might be one reason  why cut-and-paste works in X, just as
> it works when first logging in as another and changing user works.
>
> Cheers,
>
> Mike

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Alan Mackenzie]

Hello, Michael and Stefan.

In article <mailman.2142.1597447084.2739.bug-gnu-emacs@gnu.org> you wrote:
> [Please use "Reply to all" so the discussion is in the bug tracker.]

> Hi Michael,

> Thanks for replying back with details.  I'm hoping that the information
> you have provided will help someone who knows more about this stuff
> investigate this.

> Best regards,
> Stefan Kangas

> "Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:

>> Hello Stefan!

>> Thanks for  replying.  This  is an  old bug  report but  is nevertheless
>> still valid.

>> On Mon, Aug 10, 2020 at 09:14:36AM -0700, Stefan Kangas wrote:
>>> "Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:

>>> > The Report:

>>> > If I  use X-windows, there is  no problem with cutting  and pasting from
>>> > outside an emacs  buffer into an emacs buffer and  vice versa.  But this
>>> > no  longer works  when  in a  text  console.  When  on  a Linux  virtual
>>> > console, pasting into an emacs buffer results in the message:

>>> > "No selection available"

>> This continues to be the case to this day.

Forgive me for not answering each point individually.

The problem with GPM and Emacs had been annoying me so much that I got
into the GPM source code in early 2016 to try and fix it.  The conclusion
I came to then was that the GPM mouse works in two exclusive incompatible
ways: (i) it works on the virtual terminal; (ii) it works under the
control of an application, such as Emacs.  These two modes don't interact
with eachother.

Unfortunately, I didn't note down any of the precise details in GPM, but
the _only_ way to transfer text into or out of Emacs with GPM is first to
do M-x gpm-mouse-mode (to disable "application" mode), followed by normal
GPM operations on the screen.  I actually have gpm-mouse-mode disabled by
default, since I don't need to use mouse facilities in Emacs.

I did make a note about this in the Emacs manual on the page "Text-Only
Mouse".

There are several annoyances with this way of working - if you've got
side-by-side windows, you've really got to get rid of all but the
pertinent window before being able to mark text with the mouse; when you
yank text in with the middle button, linefeeds misbehave, giving
indentation where none is wanted.  For all that, having GPM is better
than not having it.
 
[ .... ]

>> Cheers,

>> Mike

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> The problem with GPM and Emacs had been annoying me so much that I got
> into the GPM source code in early 2016 to try and fix it.  The conclusion
> I came to then was that the GPM mouse works in two exclusive incompatible
> ways: (i) it works on the virtual terminal; (ii) it works under the
> control of an application, such as Emacs.  These two modes don't interact
> with eachother.
>
> Unfortunately, I didn't note down any of the precise details in GPM, but
> the _only_ way to transfer text into or out of Emacs with GPM is first to
> do M-x gpm-mouse-mode (to disable "application" mode), followed by normal
> GPM operations on the screen.  I actually have gpm-mouse-mode disabled by
> default, since I don't need to use mouse facilities in Emacs.
>
> I did make a note about this in the Emacs manual on the page "Text-Only
> Mouse".
>
> There are several annoyances with this way of working - if you've got
> side-by-side windows, you've really got to get rid of all but the
> pertinent window before being able to mark text with the mouse; when you
> yank text in with the middle button, linefeeds misbehave, giving
> indentation where none is wanted.  For all that, having GPM is better
> than not having it.

This is very useful information, thank you.  If I understand you
correctly, this is a limitation in GPM, and not in Emacs.  Maybe some
interested party could report this as a feature request to GPM.

BTW, maybe someone could test and see if this works with some other
program that also splits the display to see if it has the same problem.

I suppose that means that this bug should be closed?  Or is there
anything more we should do?

Best regards,
Stefan Kangas

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Dr. Michael L. Dowling]

On Sun, Aug 16, 2020 at 08:46:40AM -0700, Stefan Kangas wrote:
> > There are several annoyances with this way of working - if you've got
> > side-by-side windows, you've really got to get rid of all but the
> > pertinent window before being able to mark text with the mouse; when you
> > yank text in with the middle button, linefeeds misbehave, giving
> > indentation where none is wanted.  For all that, having GPM is better
> > than not having it.
> 
> This is very useful information, thank you.  If I understand you
> correctly, this is a limitation in GPM, and not in Emacs.  Maybe some
> interested party could report this as a feature request to GPM.
> 
> BTW, maybe someone could test and see if this works with some other
> program that also splits the display to see if it has the same problem.

If I can be of any further assistance I would be willing to try, but I'd
need somebody to suggest how.

> I suppose that means that this bug should be closed?  Or is there
> anything more we should do?

I  had come  to the  conclusion  that I  was  one of  the last  die-hard
Linux/text-mode/command line users.  Were that  to be the case, it would
be unreasonable of me to expect people to work to fix it. But apparently
I'm not the last die-hard user.  But then, why have others not also made
bug reports?

This is a very old bug report.   Since nobody reacted to it, I concluded
that nobody was using text-mode.  Then truecrypt stopped development, so
I adopted  veracrypt instead.  It  worked fine,  except in text  mode it
yielded error messages  from a graphics library.   Since it nevertheless
worked,  I  did not  make  a  bug  report.   I expected  somebody  would
eventually fix it,  but nobody did, until a few  weeks ago, years later.
But that reinforced my conclusion that text-mode was not being used.

If I  can help in any  way, please let  me know.  I personally  have not
noticed any other strange behavious of  GPM, but, with a pointer or two,
I could investigate this.

Cheers,

Mike

-- 
Dr. Michael L. Dowling
Gaußstr. 27
38106 Braunschweig
Germany

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Stefan Kangas]

"Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:

> If I can be of any further assistance I would be willing to try, but I'd
> need somebody to suggest how.

My idea was simply to test e.g. vim (or some $FOO text editor) and see
how well it works with regards to split screen support.  But I guess
they would have to do something similar to us according to what Alan has
reported.  So I'm actually not sure that testing it will help much...

> I  had come  to the  conclusion  that I  was  one of  the last  die-hard
> Linux/text-mode/command line users.

(You might enjoy hearing that RMS also uses Emacs on the Linux console.)

Best regards,
Stefan Kangas

bug#29357: Cut and paste problems on Linux on a text virtual console no longer works

[Dr. Michael L. Dowling]

Hello, Stefan!

On Sun, Aug 16, 2020 at 01:48:30PM -0700, Stefan Kangas wrote:
> "Dr. Michael L. Dowling" <Mike.Dowling@t-online.de> writes:
> 
> > If I can be of any further assistance I would be willing to try, but I'd
> > need somebody to suggest how.
> 
> My idea was simply to test e.g. vim (or some $FOO text editor) and see
> how well it works with regards to split screen support.  But I guess
> they would have to do something similar to us according to what Alan has
> reported.  So I'm actually not sure that testing it will help much...

I've just downloaded vim, and, yes, cut-and-paste works with vim.

Personally, I prefer vi  as it is POSIX conforming.  You  can use the vi
on any  UNIX machine, and  cut-and-paste works with  the vi on  my Linux
computers.

The  trouble  with  the  vi  is  that  it  screws  up  indentation  with
cut-and-paste.  So I've used nano  instead, and cut-and-paste works with
that, too.

For me, the  burning question is whether or not  others can replicate my
experience with emacs.

The great thing  about Arch Linux is that we  configure stuff ourselves.
But the danger is that a  configuration that is continually being copied
with every  new computer  might well  propagate problems  resulting from
incompatibilities between various software releases.

I  try to  be cautious.   On this  machine, I  copied my  old /etc  to a
subdirectory  of /root,  and  inspected every  file  before copying  and
editing.

The problem  cannot lie with  individual user configuration, as  my user
"joe" only has a .bash_logout that deletes everything except itself, and
"joe" suffers  from the  same problem.  ("joe"  doesn't have  a ~/.emacs
file

> > I  had come  to the  conclusion  that I  was  one of  the last  die-hard
> > Linux/text-mode/command line users.
> 
> (You might enjoy hearing that RMS also uses Emacs on the Linux console.)

Interesting!  I have always had a great deal of respect for RMS.

Cheers,

Mike

-- 
Dr. Michael L. Dowling
Gaußstr. 27
38106 Braunschweig
Germany