GNU bug report logs - #31094
25.2: Feature Reuqest: apropos-value: limit scope [CODE INCLUDED]

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 31094 in the body.
You can then email your comments to 31094 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: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: 25.2: Feature Reuqest: apropos-value: limit scope [CODE INCLUDED]
Date: Sun, 8 Apr 2018 03:39:16 -0400

[Message part 1 (text/plain, inline)]

I've begun using function apropos-value, and find that its ouput is
undesirably huge, because the feature prints out the entire value of
each variable that contains a match.

Some of this can be reduced when considegring that in most cases, I know
in advance that a value will be present in some very commonly used huge
variables, that won't be of use to me (eg. kill-ring,
minibuffer-history).f

A better solution would be an option to initially print only the names
of symbol that contain a match. The user can then easily view any value
of interest, because the output buffer already includes a feature that
pressing return on any symbol in the output list will display the
documentation for the symbol, which will include the variable's value.

Attached was my first thought at a solution, using an exclude list to
exclude certain variables from a search. As I said, upon further
consideration, I decided it would be better to abbreviate the output
buffer to just a list of symbol names, but I came to that conclusion
after writing the snippet.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[apropos-value.el (text/plain, attachment)]

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: 31094 <at> debbugs.gnu.org
Subject: Code for second solution
Date: Sun, 8 Apr 2018 07:09:01 -0400

[Message part 1 (text/plain, inline)]

Attached is code for the second solution idea that I mrentioned in my
first post. Note that these approaches are complementary and
independent; I would advocate for both being adopted.

Do note that this 'breaks' a feature formerly available. Prior, pressing
return on an entry would display documentation for that entry; Now one
must press `C-h v' / `C-h f' etc.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[apropos-print.el (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: Code for second solution
Date: Sun, 08 Apr 2018 16:06:25 +0300

> Date: Sun, 8 Apr 2018 07:09:01 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> 
> Attached is code for the second solution idea that I mrentioned in my
> first post. Note that these approaches are complementary and
> independent; I would advocate for both being adopted.
> 
> Do note that this 'breaks' a feature formerly available. Prior, pressing
> return on an entry would display documentation for that entry; Now one
> must press `C-h v' / `C-h f' etc.

Why not do this the other way around: make apropos-value present a
shorter list when invoked with some special value of the prefix
argument?  Or even make this a new command?  That way, people's muscle
memory doesn't need to change, which I think is a Good Thing, given
that I think we never had any complaints about the current behavior.

Thanks.

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: Code for second solution
Date: Sun, 8 Apr 2018 09:17:01 -0400

On 2018-04-08 16:06, Eli Zaretskii wrote:
> Why not do this the other way around: make apropos-value present a
> shorter list when invoked with some special value of the prefix
> argument?  Or even make this a new command?  That way, people's muscle
> memory doesn't need to change, which I think is a Good Thing, given
> that I think we never had any complaints about the current behavior.

If either or both proposed changes are adopted, there will be no need to
change muscle memory for those who want the behavior to remain the same.

The first code snippet already only changes behavior when the function
is called with either two or three universal prefix args.

The second snippet is controlled by a boolean defcustom variable,
defaulting to the current long print-out behavior.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: Code for second solution
Date: Sun, 08 Apr 2018 16:54:51 +0300

> Date: Sun, 8 Apr 2018 09:17:01 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: 31094 <at> debbugs.gnu.org
> 
> The first code snippet already only changes behavior when the function
> is called with either two or three universal prefix args.

I was under the impression that the first variant was not what you were
promoting.

> The second snippet is controlled by a boolean defcustom variable,
> defaulting to the current long print-out behavior.

That sounds sub-optimal to me: completely changing the behavior of a
command given an option is not the best UI, IMO.  Two different
commands are better.

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: Code for second solution
Date: Sun, 8 Apr 2018 10:13:30 -0400

On 2018-04-08 16:54, Eli Zaretskii wrote:
> > Date: Sun, 8 Apr 2018 09:17:01 -0400
> > From: Boruch Baum <boruch_baum <at> gmx.com>
> > Cc: 31094 <at> debbugs.gnu.org
> >
> > The first code snippet already only changes behavior when the function
> > is called with either two or three universal prefix args.
>
> I was under the impression that the first variant was not what you were
> promoting.

Different strokes for different folks. Personally, I would end up using
the second variant, but I wouldn't begrudge anyone the first option and
they can co-exist peacefully in the code. Both are minor tweaks.

> > The second snippet is controlled by a boolean defcustom variable,
> > defaulting to the current long print-out behavior.
>
> That sounds sub-optimal to me: completely changing the behavior of a
> command given an option is not the best UI, IMO.  Two different
> commands are better.

You're over stating the behavior change of the second snippet; it
changes the detail level of the output. True, as written, it 'breaks'
the response to <RET> keybinding, but I consider that trivial, because
the same functionality is available with `C-h v` or `C-h f', and to the
benefit that the snippet is much leaner on memory. If you insist that
you absolutely need that <RET> key to display the symbol's complete
documentation, that can be done without rejecting the idea of the
snippet, but it's a minor coding hassle for no real reason; Everyone
knows `C-h v' and `C-h f' describe the symbol at point.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: Code for second solution
Date: Sun, 08 Apr 2018 19:32:25 +0300

> Date: Sun, 8 Apr 2018 10:13:30 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: 31094 <at> debbugs.gnu.org
> 
> > > The second snippet is controlled by a boolean defcustom variable,
> > > defaulting to the current long print-out behavior.
> >
> > That sounds sub-optimal to me: completely changing the behavior of a
> > command given an option is not the best UI, IMO.  Two different
> > commands are better.
> 
> You're over stating the behavior change of the second snippet; it
> changes the detail level of the output. True, as written, it 'breaks'
> the response to <RET> keybinding, but I consider that trivial, because
> the same functionality is available with `C-h v` or `C-h f', and to the
> benefit that the snippet is much leaner on memory. If you insist that
> you absolutely need that <RET> key to display the symbol's complete
> documentation, that can be done without rejecting the idea of the
> snippet, but it's a minor coding hassle for no real reason; Everyone
> knows `C-h v' and `C-h f' describe the symbol at point.

I hear you.  Let's see what others think about this.

Thanks.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Sun, 23 Jan 2022 15:45:06 +0100

Boruch Baum <boruch_baum <at> gmx.com> writes:

> A better solution would be an option to initially print only the names
> of symbol that contain a match. The user can then easily view any value
> of interest, because the output buffer already includes a feature that
> pressing return on any symbol in the output list will display the
> documentation for the symbol, which will include the variable's value.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Instead of adding a special user option for this, I think it makes sense
to allow using outline-minor-mode in *Apropos* buffers.  So I've now
added support for that in Emacs 29.

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Sun, 23 Jan 2022 20:02:08 +0200

> Instead of adding a special user option for this, I think it makes sense
> to allow using outline-minor-mode in *Apropos* buffers.  So I've now
> added support for that in Emacs 29.

I see you added support for that, but not activated outline-minor-mode.
Is this intentional?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Sun, 23 Jan 2022 19:29:25 +0100

Juri Linkov <juri <at> linkov.net> writes:

>> Instead of adding a special user option for this, I think it makes sense
>> to allow using outline-minor-mode in *Apropos* buffers.  So I've now
>> added support for that in Emacs 29.
>
> I see you added support for that, but not activated outline-minor-mode.
> Is this intentional?

Yes, I think using outline mode by default here isn't what most people
would expect, but outline mode fans can switch it on from a hook if they
want.

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Sun, 23 Jan 2022 22:02:07 +0200

>>> Instead of adding a special user option for this, I think it makes sense
>>> to allow using outline-minor-mode in *Apropos* buffers.  So I've now
>>> added support for that in Emacs 29.
>>
>> I see you added support for that, but not activated outline-minor-mode.
>> Is this intentional?
>
> Yes, I think using outline mode by default here isn't what most people
> would expect, but outline mode fans can switch it on from a hook if they
> want.

Maybe then the apropos docstrings could mention this feature?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Mon, 24 Jan 2022 10:26:48 +0100

Juri Linkov <juri <at> linkov.net> writes:

> Maybe then the apropos docstrings could mention this feature?

Sure, but on the other hand -- we do want to allow using outline
everywhere it makes sense, so I'm not sure it makes sense to mention it
everywhere -- it should Just Work.

(Outline minor mode should grow support for non-regexp outlines,
though -- in these read-only buffers where we're generating the
contents, it would be way more convenient if the generator did the
markup.  I.e., put a `outline-header' text property on the header, or
something like that.)

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Mon, 24 Jan 2022 19:58:25 +0200

> (Outline minor mode should grow support for non-regexp outlines,
> though -- in these read-only buffers where we're generating the
> contents, it would be way more convenient if the generator did the
> markup.  I.e., put a `outline-header' text property on the header, or
> something like that.)

In read-only buffers outline-minor-mode-highlight-buffer currently does:

    (let ((regexp (concat "^\\(?:" outline-regexp "\\).*$")))
      (while (re-search-forward regexp nil t)
        (let ((overlay (make-overlay (match-beginning 0) (match-end 0))))

but can use anything including special properties instead of regexps.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Mon, 24 Jan 2022 19:33:34 +0100

Juri Linkov <juri <at> linkov.net> writes:

> In read-only buffers outline-minor-mode-highlight-buffer currently does:
>
>     (let ((regexp (concat "^\\(?:" outline-regexp "\\).*$")))
>       (while (re-search-forward regexp nil t)
>         (let ((overlay (make-overlay (match-beginning 0) (match-end 0))))
>
> but can use anything including special properties instead of regexps.

Well, we'd add a separate loop with (text-property-search-forward
'outline-header) or something?

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Mon, 24 Jan 2022 21:19:07 +0200

>> In read-only buffers outline-minor-mode-highlight-buffer currently does:
>>
>>     (let ((regexp (concat "^\\(?:" outline-regexp "\\).*$")))
>>       (while (re-search-forward regexp nil t)
>>         (let ((overlay (make-overlay (match-beginning 0) (match-end 0))))
>>
>> but can use anything including special properties instead of regexps.
>
> Well, we'd add a separate loop with (text-property-search-forward
> 'outline-header) or something?

Whether to use a re-search-forward loop or a text-property-search-forward
loop could depend on a new buffer-local variable, like
hi-lock-use-overlays added to hi-lock.el.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 31094 <at> debbugs.gnu.org
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Tue, 25 Jan 2022 03:06:18 +0100

Boruch Baum <boruch_baum <at> gmx.com> writes:

> Some of this can be reduced when considegring that in most cases, I know
> in advance that a value will be present in some very commonly used huge
> variables, that won't be of use to me (eg. kill-ring,
> minibuffer-history).

If you are interested in alternative approaches:

In my config I have added a query for a maximal length of the (printed)
value.  0 means "use any", but a positive value filters all variables
with bindings wider than the given limit.

I chose this way because typically you get lots of results, too many to
view them one by one, so most of the time I use isearch to find the
stuff I'm interested in.  With a folding approach, the output looks
nicer, but it still contains a lot of stuff I'm surely not interested
in.  Most of the time these huge list values are irrelevant for what you
are searching for.

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 31094 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#31094: 25.2: Feature Reuqest: apropos-value: limit scope
 [CODE INCLUDED]
Date: Tue, 25 Jan 2022 13:03:34 +0100

Juri Linkov <juri <at> linkov.net> writes:

> Whether to use a re-search-forward loop or a text-property-search-forward
> loop could depend on a new buffer-local variable, like
> hi-lock-use-overlays added to hi-lock.el.

Yes, that'd be OK.  But I'm not sure it's really necessary --
outline-minor-mode could just do that always?  Or perhaps modes that do
this could just set outline-regexp to nil (or some other special value)...

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