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

From: Robert Pluim <[email-masked]>
Date: Thu, 17 Oct 2024 12:05:13 +0200

>>>>> On Thu, 17 Oct 2024 09:34:37 +0000, Van Ly <[email-masked]> said:

    Van> Robert Pluim <[email-masked]> writes:

    >>>>>>> On Thu, 17 Oct 2024 06:30:40 +0000, Van Ly <[email-masked]> 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
--