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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33852 in the body.
You can then email your comments to 33852 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Xiansheng Ca <caxiansheng <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; unhighlight-regexp unnecessary prompt
Date: Sun, 23 Dec 2018 04:49:30 -0600

Hello,

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.

From c7918a6a09e91fc033a7288429ed4c466fba5e7c Mon Sep 17 00:00:00 2001
From: Ca Xiansheng <caxiansheng <at> gmail.com>
Date: Sun, 23 Dec 2018 03:30:50 -0600
Subject: [PATCH] * lisp/hi-lock.el (unhighlight-regexp): Do not prompt if one
 choice.

---
 lisp/hi-lock.el | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index 6eadd59..9377d84 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -602,13 +602,13 @@ then remove all hi-lock highlighting."
      ;; Infer the regexp to un-highlight based on cursor position.
      (let* ((defaults (or (hi-lock--regexps-at-point)
                           (mapcar #'car hi-lock-interactive-patterns))))
-       (list
-        (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))))))
+       (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)))))))
   (dolist (keyword (if (eq regexp t) hi-lock-interactive-patterns
                      (list (assoc regexp hi-lock-interactive-patterns))))
     (when keyword
-- 
2.20.1

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Xiansheng Ca <caxiansheng <at> gmail.com>
Cc: 33852 <at> debbugs.gnu.org
Subject: Re: bug#33852: 26.1; unhighlight-regexp unnecessary prompt
Date: Sat, 05 Jan 2019 10:56:30 +0200

> 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.

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 33852 <at> debbugs.gnu.org, Xiansheng Ca <caxiansheng <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#33852: 26.1; unhighlight-regexp unnecessary prompt
Date: Thu, 01 Oct 2020 03:57:42 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

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

There was no followup here, so it seems unlikely that there'll be
further progress made in this bug report, and I'm closing it.  If
progress can be made, please respond to the debbugs address and we'll
reopen the report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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