GNU bug report logs - #73813
30.0.91; icomplete-mode keymap unusable in xterm for for/backward completions

Previous Next

To reply to this bug, email your comments to 73813 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.91; icomplete-mode keymap unusable in xterm for for/backward
 completions
Date: Tue, 15 Oct 2024 05:44:16 +0000

[Message part 1 (text/plain, inline)]

Hello,

The two keymaps "C-." and "C-," for for/backward icomplete-mode
completions do not work in xterm where emacs is run without the
graphical user interface.

See,

> icomplete.el:177:183:
> (defvar-keymap icomplete-minibuffer-map
>   :doc "Keymap used by `icomplete-mode' in the minibuffer."
>   "C-M-i" #'icomplete-force-complete
>   "C-j"   #'icomplete-force-complete-and-exit
>   "C-."   #'icomplete-forward-completions
>   "C-,"   #'icomplete-backward-completions
>   "<remap> <minibuffer-complete-and-exit>" #'icomplete-ret)

To demonstrate

 1. start at xterm shell prompt, emacs --color=no -nw -Q
 2. use, M-x icomplete-mode
 3. use, M-x man RET fe

the keymaps "C-." and "C-," are received as "." and "," when intending
to move among available icomplete completions, and the presented
completions are unexpectedly lost.

Perhaps, "C-s" and "C-r" could be used in icomplete-mode since they are
received as "C-s" and "C-r" but carry the search for/backward meaning.
The documentation says fido-mode uses the "C-s" and "C-r" keymaps.


The following keymap is a possible workaround



> (keymap-set icomplete-minibuffer-map "C-c ." #'icomplete-forward-completions)
> (keymap-set icomplete-minibuffer-map "C-c ," #'icomplete-backward-completions)

[x (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

-- 
vl

Message #8 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Tue, 15 Oct 2024 15:27:19 +0300

> Date: Tue, 15 Oct 2024 05:44:16 +0000
> From:  Van Ly via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The two keymaps "C-." and "C-," for for/backward icomplete-mode
> completions do not work in xterm where emacs is run without the
> graphical user interface.

lisp/term/xterm.el claims that C-. and C-, should be supported
starting from xterm version 216 if the modifyOtherKeys resource is set
to 1.  Did you try that?

> Perhaps, "C-s" and "C-r" could be used in icomplete-mode since they are
> received as "C-s" and "C-r" but carry the search for/backward meaning.
> The documentation says fido-mode uses the "C-s" and "C-r" keymaps.

You can bind commands to the keys you like even if by default they
stay unbound.  There's no need to make changes in the default
keybindings because users can bind keys very easily in their own local
configurations.

Message #11 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Tue, 15 Oct 2024 14:07:00 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>
> lisp/term/xterm.el claims that C-. and C-, should be supported
> starting from xterm version 216 if the modifyOtherKeys resource is set
> to 1.  Did you try that?
>

The local xterm is version 372.  Merging the following .Xresources

  > XTerm*VT100.modifyOtherKeys: 1
  > UXTerm*VT100.modifyOtherKeys: 1

does let emacs receive C-, and C-. for icomplete for/backward completes
to work as expected in the xterm.

> You can bind commands to the keys you like even if by default they
> stay unbound.  There's no need to make changes in the default
> keybindings because users can bind keys very easily in their own local
> configurations.

From the user's perspective, I recall using icomplete-mode first but
couldn't make the completion selector move in xterm,
icomplete-vertical-mode worked because C-n and C-p were received by
emacs in the xterm.

Having in the documentation the need for xterm version 216 or later
with setting "XTerm*VT100.modifyOtherKeys: 1" will help.



-- 
vl

Message #14 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Tue, 15 Oct 2024 17:47:58 +0300

> From: Van Ly <van.ly <at> sdf.org>
> Cc: 73813 <at> debbugs.gnu.org
> Date: Tue, 15 Oct 2024 14:07:00 +0000
> 
> Having in the documentation the need for xterm version 216 or later
> with setting "XTerm*VT100.modifyOtherKeys: 1" will help.

I don't know where to document this factoid.  I found it in the
comments inside xterm.el, and I supposed anyone else could find it
there.  Maybe we could add this to the Emacs FAQ?

Message #17 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Tue, 15 Oct 2024 16:46:14 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Having in the documentation the need for xterm version 216 or later
>> with setting "XTerm*VT100.modifyOtherKeys: 1" will help.
>
> I don't know where to document this factoid.  I found it in the
> comments inside xterm.el, and I supposed anyone else could find it
> there.  Maybe we could add this to the Emacs FAQ?

This Emacs FAQ link could go on the line above or below the last textblock
on the *About GNU Emacs* buffer which is the first thing a new user sees.

Without knowing anything I either search online or use the
"Info-virtual-index" function on "The Emacs Editor" Infopage.

Searching "xterm" gives

 > * Menu:
 > 
 > * xterm [Concept Index]:                 Text-Only Mouse. (line 8)
 > * background mode, on xterm [Concept Index]: General Variables. (line 137)

-- 
vl

Message #20 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Wed, 16 Oct 2024 13:03:22 +0000

There seems to be a problem for emacsclient in the xterm.

The "modifyOtherKeys: 1" xresource setting results in emacs receiving

 ";5;44~" for C-, and 
 ";5;46~" for C-. when wanting to cycle the icomplete completions

To demonstrate,

 # start graphical UI emacs from shell prompt

 1. start, emacs --init-dir=/path/name
 2. use, M-x server-start
 3. use, M-x icomplete-mode

 # at a second xterm

 x. start from wrapper script, 
    env TERM=vt100 emacsclient -f "/path/name/server/file" -ta "" "$@"
 y. M-x man RET fe
 z. use C-, and C-. shows,
    Manual entry: fe;5;44~;5;46~ [No matches]


The following are scripts for how emacs and emacsclient are launched.

I wasn't able to use the "emacs -Q" invocation with emacsclient to
produce the observed unexpected behavior.



# emacs-30x.sh

1 #!/bin/sh
2 P=/u/w/src/emacs/build-30-2/src/emacs
3 D="/u/w/sys/emacs/30x"
4 $P --init-dir="$D"

# emacsclient-plain-30x.sh

1 #!/bin/sh
2 P=/u/w/src/emacs/build-30-2/lib-src/emacsclient
3 F=/u/w/sys/emacs/30x/server/server
4 env TERM=vt100 $P -f "$F" -ta "" "$@"


-- 
vl

Message #23 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Wed, 16 Oct 2024 15:58:29 +0200

>>>>> On Wed, 16 Oct 2024 13:03:22 +0000, Van Ly via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:

    Van> There seems to be a problem for emacsclient in the xterm.

    Van> The "modifyOtherKeys: 1" xresource setting results in emacs receiving

    Van>  ";5;44~" for C-, and 
    Van>  ";5;46~" for C-. when wanting to cycle the icomplete completions

    Van> To demonstrate,

    Van>  # start graphical UI emacs from shell prompt

    Van>  1. start, emacs --init-dir=/path/name
    Van>  2. use, M-x server-start
    Van>  3. use, M-x icomplete-mode

    Van>  # at a second xterm

    Van>  x. start from wrapper script, 
    Van>     env TERM=vt100 emacsclient -f "/path/name/server/file" -ta "" "$@"
    Van>  y. M-x man RET fe
    Van>  z. use C-, and C-. shows,
    Van>     Manual entry: fe;5;44~;5;46~ [No matches]

Well yeah: youʼre telling emacsclient itʼs running in a VT100, so emacs
never sets things up to look for the xterm-specific key sequences.

Robert
-- 

Message #26 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Wed, 16 Oct 2024 17:01:19 +0300

> From: Van Ly <van.ly <at> sdf.org>
> Cc: 73813 <at> debbugs.gnu.org
> Date: Wed, 16 Oct 2024 13:03:22 +0000
> 
> 
> There seems to be a problem for emacsclient in the xterm.
> 
> The "modifyOtherKeys: 1" xresource setting results in emacs receiving
> 
>  ";5;44~" for C-, and 
>  ";5;46~" for C-. when wanting to cycle the icomplete completions
> 
> To demonstrate,
> 
>  # start graphical UI emacs from shell prompt
> 
>  1. start, emacs --init-dir=/path/name
>  2. use, M-x server-start
>  3. use, M-x icomplete-mode
> 
>  # at a second xterm
> 
>  x. start from wrapper script, 
>     env TERM=vt100 emacsclient -f "/path/name/server/file" -ta "" "$@"
>  y. M-x man RET fe
>  z. use C-, and C-. shows,
>     Manual entry: fe;5;44~;5;46~ [No matches]
> 
> 
> The following are scripts for how emacs and emacsclient are launched.
> 
> I wasn't able to use the "emacs -Q" invocation with emacsclient to
> produce the observed unexpected behavior.
> 
> 
> 
> # emacs-30x.sh
> 
> 1 #!/bin/sh
> 2 P=/u/w/src/emacs/build-30-2/src/emacs
> 3 D="/u/w/sys/emacs/30x"
> 4 $P --init-dir="$D"
> 
> # emacsclient-plain-30x.sh
> 
> 1 #!/bin/sh
> 2 P=/u/w/src/emacs/build-30-2/lib-src/emacsclient
> 3 F=/u/w/sys/emacs/30x/server/server
> 4 env TERM=vt100 $P -f "$F" -ta "" "$@"

I don't get it: you tell Emacs that your terminal is vt100, but expect
it to behave as if the terminal were xterm?  Why should it?

Message #29 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Thu, 17 Oct 2024 06:21:03 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>
> I don't get it: you tell Emacs that your terminal is vt100, but expect
> it to behave as if the terminal were xterm?  Why should it?
>

The vt100 is a shot in the dark to achieve the equivalent to
"--color=no" for emacsclient otherwise the color theme from graphical
user interface emacs carries over.  Is there a way to invoke emacsclient
without color?

-- 
vl

Message #32 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 06:30:40 +0000

Robert Pluim <rpluim <at> gmail.com> writes:

>
> Well yeah: youʼre telling emacsclient itʼs running in a VT100, so emacs
> never sets things up to look for the xterm-specific key sequences.
>

That is the workaround I use to experience emacsclient "--color=no".

icomplete.el lists fido in icomplete-fido-mode-map and there a control
prefix alphabetic sequence for previous/next completion is possible
consistent with fido's C-s, C-r or icomplete-vertical's C-n, C-p.

-- 
vl

Message #35 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 09:15:52 +0200

>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <van.ly <at> sdf.org> said:

    Van> Robert Pluim <rpluim <at> gmail.com> writes:

    >> 
    >> Well yeah: youʼre telling emacsclient itʼs running in a VT100, so emacs
    >> never sets things up to look for the xterm-specific key sequences.
    >> 

    Van> That is the workaround I use to experience emacsclient "--color=no".

Then you should use TERM=xterm-mono (or set allowColorOps to false,
although I havenʼt tested that)

    Van> icomplete.el lists fido in icomplete-fido-mode-map and there a control
    Van> prefix alphabetic sequence for previous/next completion is possible
    Van> consistent with fido's C-s, C-r or icomplete-vertical's C-n, C-p.

Iʼm not sure what youʼre asking for here.

Robert
-- 

Message #38 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 09:34:37 +0000

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <van.ly <at> sdf.org> said:
>
>
>     Van> That is the workaround I use to experience emacsclient "--color=no".
>
> Then you should use TERM=xterm-mono (or set allowColorOps to false,
> although I havenʼt tested that)
>

I confirm TERM=xterm-mono does the trick and suggest it go in the
Emacs QAF to advise people to use that for the emacsclient no color effect.

>     Van> icomplete.el lists fido in icomplete-fido-mode-map and there a control
>     Van> prefix alphabetic sequence for previous/next completion is possible
>     Van> consistent with fido's C-s, C-r or icomplete-vertical's C-n, C-p.
>
> Iʼm not sure what youʼre asking for here.
>

I can't comprehend why hoops have to be jumped through for
icomplete-mode to skip among completions using C-, and C-. where
icomplete-vertical-mode does using C-n and C-p, and, this I haven't
checked, fido-mode does using C-s and C-r.

Looking for the "fido" token in icomplete.el, I found the following

  .33 matches in 32 lines for "fido" in buffer: icomplete.el
  .    318:;;;_* Helpers for `fido-mode' (or `ido-mode' emulation)
  .    320:(defun icomplete-fido-kill ()
  .    360:(defun icomplete-fido-delete-char ()
  .    369:(defun icomplete-fido-ret ()
  .    383:(defun icomplete-fido-exit (force)
  .    394:(defun icomplete-fido-backward-updir ()
  .    409:(defvar-keymap icomplete-fido-mode-map
  .    410:  :doc "Keymap used by `fido-mode' in the minibuffer."
  .    411:  "C-k"     #'icomplete-fido-kill
  .    412:  "C-d"     #'icomplete-fido-delete-char
  .    413:  "RET"     #'icomplete-fido-ret
  .    414:  "C-m"     #'icomplete-fido-ret
  .    415:  "DEL"     #'icomplete-fido-backward-updir
  .    416:  "M-j"     #'icomplete-fido-exit
  .    424:(defun icomplete--fido-ccd ()
  .    437:(defun icomplete--fido-mode-setup ()



Until I could get emacs to receive C-, and C-. the workaround I've put
together by necessity is



1 (add-hook 'icomplete-minibuffer-setup-hook
2   (lambda ()
3     (keymap-set icomplete-minibuffer-map "C-f" #'icomplete-forward-completions)
4     (keymap-set icomplete-minibuffer-map "C-b" #'icomplete-backward-completions)
5     (keymap-set icomplete-minibuffer-map "C-n" #'icomplete-forward-completions)
6     (keymap-set icomplete-minibuffer-map "C-p" #'icomplete-backward-completions)
7     (keymap-set icomplete-minibuffer-map "C-s" #'icomplete-forward-completions)
8     (keymap-set icomplete-minibuffer-map "C-r" #'icomplete-backward-completions)))


-- 
vl

Message #41 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 12:05:13 +0200

>>>>> On Thu, 17 Oct 2024 09:34:37 +0000, Van Ly <van.ly <at> sdf.org> said:

    Van> Robert Pluim <rpluim <at> gmail.com> writes:

    >>>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <van.ly <at> sdf.org> said:
    >> 
    >> 
    Van> That is the workaround I use to experience emacsclient "--color=no".
    >> 
    >> Then you should use TERM=xterm-mono (or set allowColorOps to false,
    >> although I havenʼt tested that)
    >> 

    Van> I confirm TERM=xterm-mono does the trick and suggest it go in the
    Van> Emacs QAF to advise people to use that for the emacsclient no color effect.

I guess we could, although Iʼm not sure how frequently people want
mono support when using a colour-enabled terminal.

    Van> icomplete.el lists fido in icomplete-fido-mode-map and there a control
    Van> prefix alphabetic sequence for previous/next completion is possible
    Van> consistent with fido's C-s, C-r or icomplete-vertical's C-n, C-p.
    >> 
    >> Iʼm not sure what youʼre asking for here.
    >> 

    Van> I can't comprehend why hoops have to be jumped through for
    Van> icomplete-mode to skip among completions using C-, and C-. where
    Van> icomplete-vertical-mode does using C-n and C-p, and, this I haven't
    Van> checked, fido-mode does using C-s and C-r.

Ah, you want C-n and C-p bound in the minibuffer when using icomplete?
Thatʼs possible, I guess `next-line' and `previous-line' arenʼt that
useful in that context.

But this is an area with a lot of history regarding the bindings, so
weʼd need to be careful. Perhaps we should consider '<left>' and
'<right>' instead, like `icomplete-fido'. Iʼm sure opinions will vary
:-)

Robert
-- 

Message #44 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 23:27:13 +1100

Robert Pluim <rpluim <at> gmail.com> writes:

>
> I guess we could, although Iʼm not sure how frequently people want
> mono support when using a colour-enabled terminal.
>

A better FAQ entry would address how to overcome certain color
combinations that for some or one are unreadable, for me the darkblue on
black is illegible and I guess that default comes from the assumed white
background where darkblue as foreground would be fine.

Even using xterm-256color I find there are color combos that are
illegible, perhaps there could be a modus theme contrast model for
legible color on xterm console where the background is either white or
black.  The wombat theme works where the background is black.

People wear all black or all white or black and white.  There should be
more than 20 people on the wild internet wanting mono support who are
desensitized routinely by advertising interrupts that fuel the web with
freakin' color.

-- 
vl

Message #47 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 12:46:36 +0000

Robert Pluim <rpluim <at> gmail.com> writes:

>
> Ah, you want C-n and C-p bound in the minibuffer when using icomplete?

I'd put icomplete-mode and icomplete-vertical-mode in the same category
for binding interop.

> Thatʼs possible, I guess `next-line' and `previous-line' arenʼt that
> useful in that context.
>
> But this is an area with a lot of history regarding the bindings, so
> weʼd need to be careful. Perhaps we should consider '<left>' and
> '<right>' instead, like `icomplete-fido'. Iʼm sure opinions will vary
> :-)
>

One more gotcha.  Inside a tmux session on xterm, emacsclient won't see
C-, and C-. and maybe there are setting changes needed there.

-- 
vl

Message #50 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 15:17:21 +0200

>>>>> On Thu, 17 Oct 2024 12:46:36 +0000, Van Ly <van.ly <at> sdf.org> said:

    Van> Robert Pluim <rpluim <at> gmail.com> writes:

    >> 
    >> Ah, you want C-n and C-p bound in the minibuffer when using icomplete?

    Van> I'd put icomplete-mode and icomplete-vertical-mode in the same category
    Van> for binding interop.

So that would be this:

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 540ed2b5819..05914b24d2c 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -178,6 +178,8 @@ icomplete-minibuffer-map
   :doc "Keymap used by `icomplete-mode' in the minibuffer."
   "C-M-i" #'icomplete-force-complete
   "C-j"   #'icomplete-force-complete-and-exit
+  "C-n"   #'icomplete-forward-completions
+  "C-p"   #'icomplete-backward-completions
   "C-."   #'icomplete-forward-completions
   "C-,"   #'icomplete-backward-completions
   "<remap> <minibuffer-complete-and-exit>" #'icomplete-ret)

I donʼt use icomplete or fido, so I have no real opinion to offer
here, except that it would be nice to have bindings that work without
having to modify xtermʼs configuration.

    >> Thatʼs possible, I guess `next-line' and `previous-line' arenʼt that
    >> useful in that context.
    >> 
    >> But this is an area with a lot of history regarding the bindings, so
    >> weʼd need to be careful. Perhaps we should consider '<left>' and
    >> '<right>' instead, like `icomplete-fido'. Iʼm sure opinions will vary
    >> :-)
    >> 

    Van> One more gotcha.  Inside a tmux session on xterm, emacsclient won't see
    Van> C-, and C-. and maybe there are setting changes needed there.

They work for me when using tmux as-is, but not when I use
TERM=xterm-mono inside tmux

Robert
-- 

Message #53 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Thu, 17 Oct 2024 15:53:18 +0000

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 12:46:36 +0000, Van Ly <van.ly <at> sdf.org> said:

>
>     Van> I'd put icomplete-mode and icomplete-vertical-mode in the same category
>     Van> for binding interop.
>
> So that would be this:
>
> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> index 540ed2b5819..05914b24d2c 100644
> --- a/lisp/icomplete.el
> +++ b/lisp/icomplete.el
> @@ -178,6 +178,8 @@ icomplete-minibuffer-map
>    :doc "Keymap used by `icomplete-mode' in the minibuffer."
>    "C-M-i" #'icomplete-force-complete
>    "C-j"   #'icomplete-force-complete-and-exit
> +  "C-n"   #'icomplete-forward-completions
> +  "C-p"   #'icomplete-backward-completions
>    "C-."   #'icomplete-forward-completions
>    "C-,"   #'icomplete-backward-completions
>    "<remap> <minibuffer-complete-and-exit>" #'icomplete-ret)
>

Yes, please.

> I donʼt use icomplete or fido, so I have no real opinion to offer
> here, except that it would be nice to have bindings that work without
> having to modify xtermʼs configuration.


I agree.


>     >> Thatʼs possible, I guess `next-line' and `previous-line' arenʼt that
>     >> useful in that context.
>     >> 
>     >> But this is an area with a lot of history regarding the bindings, so
>     >> weʼd need to be careful. Perhaps we should consider '<left>' and
>     >> '<right>' instead, like `icomplete-fido'. Iʼm sure opinions will vary
>     >> :-)
>     >> 

In view-mode, are the self-insert bindings a bug or a feature?

>     Van> One more gotcha.  Inside a tmux session on xterm, emacsclient won't see
>     Van> C-, and C-. and maybe there are setting changes needed there.
>
> They work for me when using tmux as-is, but not when I use
> TERM=xterm-mono inside tmux
>



Why not enable the option to switch "emacsclient --color=no"?



-- 
vl

Message #56 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Fri, 18 Oct 2024 09:59:39 +0200

>>>>> On Thu, 17 Oct 2024 15:53:18 +0000, Van Ly <van.ly <at> sdf.org> said:


    >> >> Thatʼs possible, I guess `next-line' and `previous-line' arenʼt that
    >> >> useful in that context.
    >> >> 
    >> >> But this is an area with a lot of history regarding the bindings, so
    >> >> weʼd need to be careful. Perhaps we should consider '<left>' and
    >> >> '<right>' instead, like `icomplete-fido'. Iʼm sure opinions will vary
    >> >> :-)
    >> >> 

    Van> In view-mode, are the self-insert bindings a bug or a feature?

`icomplete-mode' is not a viewing mode.

    Van> One more gotcha.  Inside a tmux session on xterm, emacsclient won't see
    Van> C-, and C-. and maybe there are setting changes needed there.
    >> 
    >> They work for me when using tmux as-is, but not when I use
    >> TERM=xterm-mono inside tmux
    >> 

    Van> Why not enable the option to switch "emacsclient --color=no"?

That already exists. Either put '(tty-color-mode . no)' in your
`default-frame-alist', or do

(set-frame-parameter nil 'tty-color-mode 'no)

after youʼve connected.

Robert
-- 

Message #59 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Fri, 18 Oct 2024 13:48:37 +0200

>>>>> On Fri, 18 Oct 2024 09:59:39 +0200, Robert Pluim <rpluim <at> gmail.com> said:

    Van> Why not enable the option to switch "emacsclient --color=no"?

    Robert> That already exists. Either put '(tty-color-mode . no)' in your
    Robert> `default-frame-alist', or do

    Robert> (set-frame-parameter nil 'tty-color-mode 'no)

    Robert> after youʼve connected.

Iʼve now updated the emacs-30 documentation to explain this more.

Robert
-- 

Message #62 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org, Van Ly <van.ly <at> sdf.org>
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Fri, 18 Oct 2024 13:54:32 +0200

>>>>> On Thu, 17 Oct 2024 15:53:18 +0000, Van Ly <van.ly <at> sdf.org> said:

    Van> Robert Pluim <rpluim <at> gmail.com> writes:

    >>>>>>> On Thu, 17 Oct 2024 12:46:36 +0000, Van Ly <van.ly <at> sdf.org> said:

    >> 
    Van> I'd put icomplete-mode and icomplete-vertical-mode in the same category
    Van> for binding interop.
    >> 
    >> So that would be this:
    >> 
    >> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
    >> index 540ed2b5819..05914b24d2c 100644
    >> --- a/lisp/icomplete.el
    >> +++ b/lisp/icomplete.el
    >> @@ -178,6 +178,8 @@ icomplete-minibuffer-map
    >> :doc "Keymap used by `icomplete-mode' in the minibuffer."
    >> "C-M-i" #'icomplete-force-complete
    >> "C-j"   #'icomplete-force-complete-and-exit
    >> +  "C-n"   #'icomplete-forward-completions
    >> +  "C-p"   #'icomplete-backward-completions
    >> "C-."   #'icomplete-forward-completions
    >> "C-,"   #'icomplete-backward-completions
    >> "<remap> <minibuffer-complete-and-exit>" #'icomplete-ret)
    >> 

    Van> Yes, please.

João, you used "C-s" and "C-r" when adding `icomplete-fido-mode', and
`icomplete-vertical' mode uses "C-n" and "C-p". My intuition is
failing me as to which would be more consistent (adding both seems
like overkill).

    >> I donʼt use icomplete or fido, so I have no real opinion to offer
    >> here, except that it would be nice to have bindings that work without
    >> having to modify xtermʼs configuration.

    Van> I agree.

Robert
-- 

Message #65 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org, Van Ly <van.ly <at> sdf.org>
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Fri, 18 Oct 2024 13:46:03 +0100

On Fri, Oct 18, 2024 at 12:54 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> João, you used "C-s" and "C-r" when adding `icomplete-fido-mode', and
> `icomplete-vertical' mode uses "C-n" and "C-p". My intuition is
> failing me as to which would be more consistent (adding both seems
> like overkill).


Fido is for "Fake IDO" and IDO used C-s and C-r originally.  In
vertical settings
C-n and C-p is the norm, so that's the reason.

But problems with bindings are easily solved in one's .emacs I normally.

Anyway, I don't maintain this anymore, I just use it.

Message #68 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: van.ly <at> sdf.org, 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Fri, 18 Oct 2024 15:48:22 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: eliz <at> gnu.org,  73813 <at> debbugs.gnu.org
> Date: Fri, 18 Oct 2024 13:48:37 +0200
> 
>     Robert> That already exists. Either put '(tty-color-mode . no)' in your
>     Robert> `default-frame-alist', or do
> 
>     Robert> (set-frame-parameter nil 'tty-color-mode 'no)
> 
>     Robert> after youʼve connected.
> 
> Iʼve now updated the emacs-30 documentation to explain this more.

Thanks, but please always remember to mention the bug number where
relevant discussions were held, even if the main issue of the bug is
somewhat different.

Message #71 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Sat, 19 Oct 2024 00:50:54 +1100

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 15:53:18 +0000, Van Ly <van.ly <at> sdf.org> said:
>
>
>     Van> One more gotcha.  Inside a tmux session on xterm, emacsclient won't see
>     Van> C-, and C-. and maybe there are setting changes needed there.
>     >> 
>     >> They work for me when using tmux as-is, but not when I use
>     >> TERM=xterm-mono inside tmux
>     >> 
>
>     Van> Why not enable the option to switch "emacsclient --color=no"?
>
> That already exists. Either put '(tty-color-mode . no)' in your
> `default-frame-alist', or do
>
> (set-frame-parameter nil 'tty-color-mode 'no)
>
> after youʼve connected.
>

Inside xterm/tmux with environment TERM variable setting that allows
color and invoking emacsclient to disable color using the
set-frame-parameter function, at the icomplete completions mini-buffer
C-, and C-. are not seen at all and the alternative completions display
unmoved.

> Manual entry: fe{getenv(3) | getround(3) | tchMakeURL(3) | clearexcept(3) | enableexcept(3)}



-- 
vl

Message #74 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Sat, 19 Oct 2024 00:57:53 +1100

Robert Pluim <rpluim <at> gmail.com> writes:

>
> João, you used "C-s" and "C-r" when adding `icomplete-fido-mode', and
> `icomplete-vertical' mode uses "C-n" and "C-p". My intuition is
> failing me as to which would be more consistent (adding both seems
> like overkill).
>

C-s and C-r is handy for one handed use.

C-n and C-p works well when the right hand isn't at the mouse and both
hands are at the home row typing.

-- 
vl

Message #77 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: van.ly <at> sdf.org
Cc: 73813 <at> debbugs.gnu.org
Subject: Re: bug#73813: 30.0.91;
 icomplete-mode keymap unusable in xterm for for/backward completions
Date: Sat, 19 Oct 2024 12:16:17 +0300

> Cc: 73813 <at> debbugs.gnu.org
> Date: Tue, 15 Oct 2024 17:47:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Van Ly <van.ly <at> sdf.org>
> > Cc: 73813 <at> debbugs.gnu.org
> > Date: Tue, 15 Oct 2024 14:07:00 +0000
> > 
> > Having in the documentation the need for xterm version 216 or later
> > with setting "XTerm*VT100.modifyOtherKeys: 1" will help.
> 
> I don't know where to document this factoid.  I found it in the
> comments inside xterm.el, and I supposed anyone else could find it
> there.  Maybe we could add this to the Emacs FAQ?

Added to the Emacs FAQ.

Message #80 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Van Ly <van.ly <at> sdf.org>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Mon, 21 Oct 2024 11:36:00 +0200

>>>>> On Sat, 19 Oct 2024 00:50:54 +1100, Van Ly <van.ly <at> sdf.org> said:

    Van> Inside xterm/tmux with environment TERM variable setting that allows
    Van> color and invoking emacsclient to disable color using the
    Van> set-frame-parameter function, at the icomplete completions mini-buffer
    Van> C-, and C-. are not seen at all and the alternative completions display
    Van> unmoved.

Please show us exactly how youʼre invoking emacs and emacsclient.

Robert
-- 

Message #83 received at 73813 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 73813 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#73813: 30.0.91; icomplete-mode keymap unusable in xterm for
 for/backward completions
Date: Mon, 21 Oct 2024 13:21:33 +0000

Robert Pluim <rpluim <at> gmail.com> writes:

> Please show us exactly how youʼre invoking emacs and emacsclient.

The wrapper scripts used to invoke emacs and emacsclient have been posted.

The environment variable TERM=vt100 is not used.

 P. start, "emacs --init-dir=/path/to/dir" then M-x server-start
    note, I'm not able to connect emacs and emacslient calling
          "emacs -Q --init-dir=/path/to/dir"

 1. spawn an xterm, echo $TERM shows the value "xterm"
 2. invoke, tmux new-session
 3. invoke, emacsclient -f "/path/to/server" -ta "" "$@"
    color is on in emacsclient
 4. eval, (set-frame-parameter nil 'tty-color-mode 'no)
    color is off in emacsclient
 5. call, M-x man RET fe
    C-, and C-. are not seen by emacsclient at all for cycling completions

 minib-buffer shows
   Manual entry: fe{getenv(3) | getround(3) | tchMakeURL(3) | clearexcept(3) | enableexcept(3)}



-- 
vl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.