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

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]


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)




[-- Attachment #2: bug-gnu-emacs report --]
[-- Type: application/octet-stream, Size: 4601 bytes --]

From: xxx@xxx.mail-host-address-is-not-set
To: bug-gnu-emacs@gnu.org
Subject: 30.0.91; icomplete-mode keymap back/forward completions unusable in xterm
X-Debbugs-Cc: 
--text follows this line--




In GNU Emacs 30.0.91 (build 2, x86_64--netbsd, X toolkit, cairo version
 1.18.0) of 2024-09-27 built on xxx
System Description: NetBSD xxx 10.0_STABLE NetBSD 10.0_STABLE (GENERIC) #0: Wed Oct  9 15:29:37 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

Configured using:
 'configure --srcdir=/u/xxx/src/emacs/30.0.91 --localstatedir=/var
 --disable-autodepend --with-native-compilation --without-ns --with-rsvg
 --without-imagemagick --without-xaw3d --without-toolkit-scroll-bars
 --x-includes=/usr/X11R7/include --x-libraries=/usr/X11R7/lib
 --with-x-toolkit=lu --prefix=/usr/local --build=x86_64--netbsd
 --host=x86_64--netbsd --infodir=/usr/pkg/info --mandir=/usr/pkg/man
 --enable-option-checking=yes 'CFLAGS=-O2 -I/usr/pkg/include/cairo
 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2
 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0
 -I/usr/pkg/lib/glib-2.0/include -I/usr/X11R7/include
 -I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm'
 'CPPFLAGS=-DTERMINFO -I/usr/pkg/include -I/usr/include
 -I/usr/pkg/include/freetype2 -I/usr/pkg/include/glib-2.0
 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 -I/usr/X11R7/include -I/usr/pkg/include/harfbuzz
 -I/usr/X11R7/include/libdrm' 'LDFLAGS=-Wl,-R/usr/pkg/gcc13/lib
 -Wl,-zrelro -L/usr/pkg/lib -lcairo -L/usr/lib -Wl,-R/usr/lib
 -Wl,-R/usr/pkg/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib
 -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgnutls''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2
LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE PDUMPER PNG RSVG SOUND
SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LC_COLLATE: en_AU.UTF-8
  value of $LC_CTYPE: en_AU.UTF-8
  value of $LC_MESSAGES: en_AU.UTF-8
  value of $LC_MONETARY: en_AU.UTF-8
  value of $LC_NUMERIC: en_AU.UTF-8
  value of $LC_TIME: en_AU.UTF-8
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  icomplete-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils man
ansi-color cus-start cus-load icomplete cl-loaddefs cl-lib term/xterm
xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine 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 composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
kqueue lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 73261 11139) (symbols 48 7379 0) (strings 32 18162 1988)
 (string-bytes 1 507642) (vectors 16 7683)
 (vector-slots 8 95796 10361) (floats 8 28 11897) (intervals 56 302 0)
 (buffers 992 10))

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]




-- 
vl

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

[Eli Zaretskii]

> 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@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.

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Van Ly <van.ly@sdf.org>
> Cc: 73813@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?

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Robert Pluim]

>>>>> 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@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
-- 

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

[Eli Zaretskii]

> From: Van Ly <van.ly@sdf.org>
> Cc: 73813@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?

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@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

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

[Robert Pluim]

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

    Van> Robert Pluim <rpluim@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
-- 

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <van.ly@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

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

[Robert Pluim]

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

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

    >>>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <van.ly@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
-- 

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@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

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@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

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

[Robert Pluim]

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

    Van> Robert Pluim <rpluim@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
-- 

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 12:46:36 +0000, Van Ly <van.ly@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

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

[Robert Pluim]

>>>>> On Thu, 17 Oct 2024 15:53:18 +0000, Van Ly <van.ly@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
-- 

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

[Robert Pluim]

>>>>> On Fri, 18 Oct 2024 09:59:39 +0200, Robert Pluim <rpluim@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
-- 

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

[Robert Pluim]

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

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

    >>>>>>> On Thu, 17 Oct 2024 12:46:36 +0000, Van Ly <van.ly@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
-- 

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

[João Távora]

On Fri, Oct 18, 2024 at 12:54 PM Robert Pluim <rpluim@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.

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: eliz@gnu.org,  73813@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.

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 17 Oct 2024 15:53:18 +0000, Van Ly <van.ly@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

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

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@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