GNU bug report logs -
#73813
30.0.91; icomplete-mode keymap unusable in xterm for for/backward completions
Previous Next
Full log
View this message in rfc822 format
>>>>> 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
--
This bug report was last modified 239 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.