GNU bug report logs - #33852
26.1; unhighlight-regexp unnecessary prompt

Previous Next

Full log

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33852 <at> debbugs.gnu.org, Xiansheng Ca <caxiansheng <at> gmail.com>
Subject: Re: bug#33852: 26.1; unhighlight-regexp unnecessary prompt
Date: Thu, 13 Aug 2020 05:14:56 -0700

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

>> From: Xiansheng Ca <caxiansheng <at> gmail.com>
>> Date: Sun, 23 Dec 2018 04:49:30 -0600
>>
>> In hi-lock-mode, after highlighting a single regular expression such
>> as by M-s h r regexp <RET> <RET>, then unhighlighting with M-s h u,
>> I'm prompted "Regexp to unhighlight (default regexp):", but any choice
>> other than the default is rejected with the message "[No Match]". I
>> would prefer not to be prompted if there is only a single acceptable
>> choice.
>>
>> I believe the patch below implements this proposed behavior. Thank you
>> for taking the time to consider this.
>> [...]
>> +       (list (if (and (consp defaults) (null (cdr defaults))) (car defaults)
>> +               (completing-read (if (null defaults)
>> +                                    "Regexp to unhighlight: "
>> +                                  (format "Regexp to unhighlight
>> (default %s): "
>> +                                          (car defaults)))
>> +                                hi-lock-interactive-patterns
>> +                        nil t nil nil defaults)))))))
>
> What happens if the command is invoked with point on a portion of text
> that is highlighted by a hi-lock regexp?  Wouldn't the command then
> silently unhighlight only that regexp, and won't allow the user to
> specify any other regexp?
>
> IOW, if the list of completions has only one element (btw, this fact
> can be more elegantly established by calling 'length'), it does not
> necessarily mean that there's only one hi-lock regexp defined in the
> buffer.  Should we consider that as well?

That was 1.5 years ago.  Any updates here?  Xiansheng Ca, did you have a
chance to look at Eli's questions above?

Best regards,
Stefan Kangas

Previous Next

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