GNU bug report logs -
#33852
26.1; unhighlight-regexp unnecessary prompt
Previous Next
Reported by: Xiansheng Ca <caxiansheng <at> gmail.com>
Date: Sun, 23 Dec 2018 18:19:02 UTC
Severity: minor
Tags: moreinfo
Found in version 26.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 33852 <at> debbugs.gnu.org (full text, mbox):
> 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?
Thanks.
This bug report was last modified 4 years and 286 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.