[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33852: 26.1; unhighlight-regexp unnecessary prompt

From: Eli Zaretskii
Subject: bug#33852: 26.1; unhighlight-regexp unnecessary prompt
Date: Sat, 05 Jan 2019 10:56:30 +0200

> From: Xiansheng Ca <address@hidden>
> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]