bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#31807: 27.0; `info-apropos' bad name or bad matching


From: Drew Adams
Subject: bug#31807: 27.0; `info-apropos' bad name or bad matching
Date: Thu, 14 Jun 2018 07:11:48 -0700 (PDT)

> > `info-apropos', as its doc string says, apparently does NOT do
> > "apropos" matching, i.e., regexp and keyword matching.  It
> apparently does literal
> > string matching against index entries in all of the manuals.
> >
> > Perhaps either the name should be changed (to not use the word
> > "apropos") or the behavior should be changed, to allow apropos
> > matching.
> 
> This command is the Emacs implementation of the "info --apropos"
> feature present in the Texinfo's stand-alone Info reader, which also
> looks for substring matches.  Apparently, "apropos" doesn't
> necessarily mean "regexps and keywords".

What matters, I think, is what Emacs means by "apropos", not
what Info might mean by it, especially not just what some
Info switch might be called.

In Emacs, "apropos" has always meant pattern matching, in
particular, regexp matching.  (Later, keyword matching was
added.)

> > I threw this together quickly, as a POC.  It does the job, but
> 
> Thanks.  The original command was introduced 11 years ago, so I don't
> think we can make radical changes in the user-visible behavior by
> default after all this time.

I disagree, here.  I think we _can_ make such a change,
and I don't think it's radical.

Plus, most literal string matches that someone might want
to make, in practice, do not involve any special regexp
chars, so they would still just "work".

If you want to keep the current behavior then I'd suggest
having two different commands AND, for the one that does
literal string matching, change the name to something that
does not include "apropos" in the name.

It's fine with me that any key-bindings (e.g., menu items)
for the literal-matching command be kept for the (newly
named) literal-matching command, if you like.  I don't
insist that that command or its keys be _supplanted_ by
a real apropos command.

The point is that (1) we can and should have an
apropos-matching command (as a replacement or in addition
to the current literal-matching command - I don't care
which), and (2) a literal-match command should not be
named `...-apropos' (in Emacs).

> This should be an opt-in optional
> behavior, controlled either by a prefix argument or by a (new) user
> variable.  Would you like to modify your suggestion along these lines?

No, I disagree that that is the right approach.
See above, for an alternative approach.

> Btw, does this really work as intended without changes to
> Info-apropos-matches?  That function calls regexp-quote on its
> argument.

Dunno.  When I get some time I'll take a closer look.
I don't insist on this code, which I threw together quickly.
Clearly, the apropos command should be made to work well.

The points are as stated above: provide a real apropos
command, and ensure that a command that matches only string
literals is not called `...-apropos'.





reply via email to

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