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

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

[Drew Adams]

See https://emacs.stackexchange.com/q/41993/105.

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

In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32)
 of 2018-03-21
Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3''

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

[Drew Adams]

I threw this together quickly, as a POC.  It does the job, but
probably we can do even better.  (The doc string would at least
need to be beefed up, to describe the input and search behavior.)

(defun info-apropos (pattern)
  "Grovel indices of all known Info files on your system for apropos PATTERN.
Build a menu of the possible matches."
  (interactive (list (apropos-read-pattern "index entries")))
  (apropos-parse-pattern pattern)
  (if (equal apropos-regexp "")
      (Info-find-node Info-apropos-file "Top")
    (let ((nodes  Info-apropos-nodes)
          nodename)
      (while (and nodes  (not (string-match apropos-regexp (nth 1 (car nodes)))))
        (setq nodes  (cdr nodes)))
      (if nodes
          (Info-find-node Info-apropos-file (caar nodes))
        (setq nodename  (format "Index for '%s'" apropos-regexp))
        (push (list nodename apropos-regexp (Info-apropos-matches apropos-regexp))
              Info-apropos-nodes)
        (Info-find-node Info-apropos-file nodename)))))

BTW, should the name be `Info-apropos' or `info-apropos'?

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

[Drew Adams]

> (setq nodename  (format "Index for '%s'" apropos-regexp))

Ouch!  Bitten by the crazy-quote monster.  Couldn't even save
the file I wrote it in - asked me about possibly saving with
Chinese this or that (in Emacs 27).

Naturally I meant this sane traditional, standard sexp instead:

(setq nodename  (format "Index for `%s'" apropos-regexp))

That's what comes from copy-pasting polluted Emacs code.

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

[Drew Adams]

> Ouch!  Bitten by the crazy-quote monster.  Couldn't even save
> the file I wrote it in - asked me about possibly saving with
> Chinese this or that (in Emacs 27).

This is the scary text I saw, FWIW:

These default coding systems were tried to encode text
in the buffer 'aaaaa.txt':
  (undecided-unix (768 . 8216) (771 . 8217)) (iso-latin-1-unix (768
  . 8216) (771 . 8217))
However, each of them encountered characters it couldn't encode:
  undecided-unix cannot encode these: ' '
  iso-latin-1-unix cannot encode these: ' '

Click on a character (or switch to this window by 'C-x o'
and select the characters by RET) to jump to the place it appears,
where 'C-u C-x =' will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  gb2312 shift_jis iso-2022-jp big5 utf-8 euc-kr euc-jis-2004 euc-jp
  euc-tw windows-1256 windows-1258 cp874 iso-2022-jp-2004 windows-1255
  cp869 windows-1253 iso-8859-7 adobe-standard-encoding macintosh
  windows-1257 windows-1254 windows-1252 windows-1250 windows-1251
  koi8-t gb18030 gbk big5-hkscs hz-gb-2312 utf-7 utf-16
  utf-16be-with-signature utf-16le-with-signature utf-16be utf-16le
  iso-2022-7bit utf-8-auto utf-8-with-signature eucjp-ms utf-8-hfs
  georgian-academy georgian-ps korean-cp949 japanese-shift-jis-2004
  japanese-iso-7bit-1978-irv japanese-cp932 pt154
  cyrillic-alternativnyj utf-7-imap utf-8-emacs prefer-utf-8

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

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

>> (setq nodename  (format "Index for '%s'" apropos-regexp))
>
> Ouch!  Bitten by the crazy-quote monster.  Couldn't even save
> the file I wrote it in - asked me about possibly saving with
> Chinese this or that (in Emacs 27).
>
> Naturally I meant this sane traditional, standard sexp instead:
>
> (setq nodename  (format "Index for `%s'" apropos-regexp))
>
> That's what comes from copy-pasting polluted Emacs code.

Can you explain how you produced that text?  Unless you ran the code
through message like (message (prin1-to-string (defun ...))) I'm a bit
confused as to how it could happen.

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

[Drew Adams]

> >> (setq nodename  (format "Index for '%s'" apropos-regexp))
>
> Can you explain how you produced that text?  Unless you ran the code
> through message like (message (prin1-to-string (defun ...))) I'm a bit
> confused as to how it could happen.

I copied it from `info.el'.  Bad idea, I know, now that Emacs
code has been corrupted through and through. ;-)

However, I see now that although what I copied from `info.el'
uses LEFT SINGLE QUOTATION MARK and RIGHT SINGLE QUOTATION MARK,
after the bug report was submitted what shows in the bug
description is APOSTROPHE and APOSTROPHE.

So things seem worse than I thought.  What I yanked into
the the `M-x report-emacs-bug' buffer and ended up pasting
into the mail message was apparently different from what
I copied from `info.el'.  Just where that translation occurred
(`report-emacs-bug'? pasting into the Outlook mail message?),
I don't know.

Anyway, please read it as being left and right single quotation
marks.  Those are what caused Emacs to ask me whether I wanted
to save the buffer using any of a zillion exotic encodings
(a couple of which are not so exotic, but they're buried among
others).

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

[Drew Adams]

I filed bug #31815 for those curly quotes in `info.el'.

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

[Eli Zaretskii]

> Date: Tue, 12 Jun 2018 16:01:37 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> `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".

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

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

> BTW, should the name be `Info-apropos' or `info-apropos'?

We've been through that, see the reason explained here:

  http://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00482.html

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

[Eli Zaretskii]

> Date: Tue, 12 Jun 2018 16:59:19 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This is the scary text I saw, FWIW:
> 
> These default coding systems were tried to encode text
> in the buffer 'aaaaa.txt':
>   (undecided-unix (768 . 8216) (771 . 8217)) (iso-latin-1-unix (768
>   . 8216) (771 . 8217))
> However, each of them encountered characters it couldn't encode:
>   undecided-unix cannot encode these: ' '
>   iso-latin-1-unix cannot encode these: ' '
> 
> Click on a character (or switch to this window by 'C-x o'
> and select the characters by RET) to jump to the place it appears,
> where 'C-u C-x =' will give information about it.
> 
> Select one of the safe coding systems listed below,
> or cancel the writing with C-g and edit the buffer
>    to remove or modify the problematic characters,
> or specify any other coding system (and risk losing
>    the problematic characters).
> 
>   gb2312 shift_jis iso-2022-jp big5 utf-8 euc-kr euc-jis-2004 euc-jp
>   euc-tw windows-1256 windows-1258 cp874 iso-2022-jp-2004 windows-1255
>   cp869 windows-1253 iso-8859-7 adobe-standard-encoding macintosh
>   windows-1257 windows-1254 windows-1252 windows-1250 windows-1251
>   koi8-t gb18030 gbk big5-hkscs hz-gb-2312 utf-7 utf-16
>   utf-16be-with-signature utf-16le-with-signature utf-16be utf-16le
>   iso-2022-7bit utf-8-auto utf-8-with-signature eucjp-ms utf-8-hfs
>   georgian-academy georgian-ps korean-cp949 japanese-shift-jis-2004
>   japanese-iso-7bit-1978-irv japanese-cp932 pt154
>   cyrillic-alternativnyj utf-7-imap utf-8-emacs prefer-utf-8

What's so scary about it?  It clearly identifies the problematic
characters, offers clickable buttons to go to each of them, and
explains the problem.  It should probably suggest UTF-8 as the first
alternative, but other than that I see no problem in this dialog.

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

[Drew Adams]

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

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

[Drew Adams]

> > This is the scary text I saw, FWIW:...
>
> What's so scary about it?  It clearly identifies the problematic
> characters, offers clickable buttons to go to each of them, and
> explains the problem.  It should probably suggest UTF-8 as the first
> alternative, but other than that I see no problem in this dialog.

Yes, at the very least, it should suggest utf-8 and provide
that as the default value.  Only in a separate paragraph
should it say that you can instead use any of the following
instead...

Make it simple to understand that utf-8 solves the problem,
and make it simple to choose utf-8.  You might even want
to make it a 3-way decision: (1) Yes, convert to utf-8,
(2) No, don't save, (3) Convert to an alternative encoding.

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

[Eli Zaretskii]

> Date: Thu, 14 Jun 2018 07:11:48 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31807@debbugs.gnu.org
> 
> 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.

I'm okay with a new command, but it should have a new name.  How about
info-apropos-regexp?  The old command must keep its name, for the same
reason we cannot change its behavior.

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

Thanks.

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

[Drew Adams]

> > 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.
> 
> I'm okay with a new command, but it should have a new name.  How about
> info-apropos-regexp?  The old command must keep its name, for the same
> reason we cannot change its behavior.

It's you who decide, of course.  But I disagree about the
name(s).

"Apropos", in Emacs, always has and always should mean (at
least) regexp-matching.  As a notion it is _opposed_ to
literal string matching, indicating that something more
general or more approximate is going on wrt matching.

A command name like `*-apropos-regexp' is a bad idea, IMO.
It just confuses.  And a command name `*-apropos' that
does only literal matching is an even worse idea, and it
is worse yet if accompanied by another command called
`*-apropos-regexp'.

Again, my suggestion is to "enhance" the behavior of
`info-apropos', to make it really do "apropos" matching.
For anyone who might prefer literal-matching, either it
could take a prefix arg to provide that or a separate,
literal(-only)-matching command could be added.

I seriously doubt that anyone will be upset if `info-apropos'
is enhanced to support more general matching.

Did you present the same, we-can't-enhance-because-legacy
argument when Kim (I think it was) added keyword-matching
to the `apropos*' commands?

Did you say that those commands have always accepted only
a regexp arg and just matched it directly?  Did you suggest
that alternative (new) commands be added that provide
keyword + regexp matching, and that tacked on the suffix
`-keyword' to their names (e.g. `apropos-command-regexp')?
I don't think you did - and rightfully so.  And no one
(including me) complained about that behavior enhancement.

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

You're welcome.  But I haven't done it yet. ;-)

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

[Eli Zaretskii]

> Date: Thu, 14 Jun 2018 07:42:11 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31807@debbugs.gnu.org
> 
> I seriously doubt that anyone will be upset if `info-apropos'
> is enhanced to support more general matching.

When in doubt, we should err on the safe side in these situations.

> Did you present the same, we-can't-enhance-because-legacy
> argument when Kim (I think it was) added keyword-matching
> to the `apropos*' commands?

That change was backward-compatible.

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

[Drew Adams]

> > Did you present the same, we-can't-enhance-because-legacy
> > argument when Kim (I think it was) added keyword-matching
> > to the `apropos*' commands?
> 
> That change was backward-compatible.

No more so than this one, IMO.  In fact less.

If you entered "foo bar" (without the quotes) before that
enhancement the commands would try to match only that literal
string (as a regexp).  After the enhancement, entering that
same text caused matching against a complex regexp that
matches "foo" (no space) and "bar" (no space) in either order.
Not at all the same behavior.

This change is more backward compatible.  If you enter "foo"
or "(foo)" or "%foo" you still get the same behavior.  The
only change in behavior occurs if you include regexp special
chars.

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

[Eli Zaretskii]

> Date: Thu, 14 Jun 2018 08:33:32 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31807@debbugs.gnu.org
> 
> > > Did you present the same, we-can't-enhance-because-legacy
> > > argument when Kim (I think it was) added keyword-matching
> > > to the `apropos*' commands?
> > 
> > That change was backward-compatible.
> 
> No more so than this one, IMO.  In fact less.

I don't agree, but even if you are right, you can consider my views
today the result of learning over all those years since then what such
changes mean.

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

[Drew Adams]

> > > > Did you present the same, we-can't-enhance-because-legacy
> > > > argument when Kim (I think it was) added keyword-matching
> > > > to the `apropos*' commands?
> > >
> > > That change was backward-compatible.
> >
> > No more so than this one, IMO.  In fact less.
> 
> I don't agree, but even if you are right, you can consider my views
> today the result of learning over all those years since then what such
> changes mean.

When I get some time I will test and update the code I sent.
You can then do what you will with it (e.g. rename or recode).
Thx.

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

[Drew Adams]

> > 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.
> 
> I'm okay with a new command, but it should have a new name.  How about
> info-apropos-regexp?  The old command must keep its name, for the same
> reason we cannot change its behavior.
> 
> > When I get some time I'll take a closer look.
> 
> Thanks.

Here's the code I've included in my library `info+.el'.

You may want to use it in `info.el'.  Or not.

If you want to rename `info-apropos' here to `info-apropos-regexp', do so.

And you might want other changes, too.  It should be pretty clear what
the essential changes are, versus others that you might not want to make.
(I untabify, I use `add-to-list' for backward compatibility, and I use
a separate window if invoked outside Info.)

HTH.


;; REPLACE ORIGINAL in `info.el':
;;
;; Added optional arg LITERALP.  Use apropos matching, not literal-string matching,
;; by default.  Prefix arg matches literally.
;; Use other window, unless already in Info.
;;
(defun info-apropos (pattern &optional literalp)
  "Search indexes of all known Info files on your system for apropos PATTERN.
Build a menu of the possible matches.

With a prefix arg, match PATTERN as a literal string, not as a regexp
or keywords.

Just as for commands such as `apropos', PATTERN can be a word, a list
of words (separated by spaces), or a regexp (using some regexp special
characters).  If it is a word, search for matches for that word as a
substring.  If it is a list of words, search for matches for any
two (or more) of those words."
  (interactive (list (apropos-read-pattern "index entries") current-prefix-arg))
  (apropos-parse-pattern pattern)
  (if (equal apropos-regexp "")
      (Info-find-node Info-apropos-file "Top")
    (let ((nodes  Info-apropos-nodes)
          nodename)
      (while (and nodes  (not (string-match apropos-regexp (nth 1 (car nodes)))))
        (setq nodes  (cdr nodes)))
      ;; Use another window, if not already in Info.
      (unless (eq major-mode 'Info-mode) (pop-to-buffer "*info*"))
      (if nodes
          (Info-find-node Info-apropos-file (caar nodes))
        (setq nodename  (format "Index for '%s'" apropos-regexp))
        (push (list nodename
                    apropos-regexp
                    (Info-apropos-matches apropos-regexp (and (not literalp) 'REGEXP)))
              Info-apropos-nodes)
        (Info-find-node Info-apropos-file nodename)))))


;; REPLACE ORIGINAL in `info.el':
;;
;; Added optional arg REGEXP-P.
;;
(defun Info-apropos-matches (string &optional regexp-p)
  "Collect STRING matches from all known Info files on your system.
Return a list of matches where each element is in the format
\((FILENAME INDEXTEXT NODENAME LINENUMBER)).

Non-nil optional REGEXP-P means interpret STRING as a regexp, instead
of trying to match it literally."
  ;; Emacs 23 has an `interactive' spec here, for no reason.
  (unless (string= string "")
    (let ((pattern       (format "\n\\* +\\([^\n]*\\(%s\\)[^\n]*\\):[ \t]+\
\\([^\n]+\\)\\.\\(?:[ \t\n]*(line +\\([0-9]+\\))\\)?"
                                 (if regexp-p string (regexp-quote string))))
          (ohist         Info-history)
          (ohist-list    Info-history-list)
          (current-node  Info-current-node)
          (current-file  Info-current-file)
          manuals matches node nodes)
      (let ((Info-fontify-maximum-menu-size  nil))
        (Info-directory)
        ;; `current-node' and `current-file' are nil if you invoke `info-apropos' as
        ;; the first Info command.  (`info-apropos' loads `info.el'.)  In that case,
        ;; use `(DIR)Top', to avoid an error after search is complete.
        (unless current-node (setq current-file  Info-current-file
                                   current-node  Info-current-node))
        (message "Searching indices...")
        (goto-char (point-min))
        (re-search-forward "\\* Menu: *\n" nil t)
        ;; Ensure no duplicates in MANUALS, so the `dolist' runs faster.
        (while (re-search-forward "\\*.*: *(\\([^)]+\\))" nil t)
          (add-to-list 'manuals (match-string 1)))
        (dolist (manual  (nreverse manuals))
          (message "Searching %s" manual)
          (condition-case err
              (if (setq nodes  (Info-index-nodes (Info-find-file manual)))
                  (save-excursion
                    (Info-find-node manual (car nodes))
                    (while
                        (progn
                          (goto-char (point-min))
                          (while (re-search-forward pattern nil t)
                            (let ((entry     (match-string-no-properties 1))
                                  (nodename  (match-string-no-properties 3))
                                  (line      (match-string-no-properties 4)))
                              (add-text-properties
                               (- (match-beginning 2) (match-beginning 1))
                               (- (match-end 2) (match-beginning 1))
                               '(face info-index-match) entry)
                              (setq matches  (cons (list manual entry nodename line)
                                                   matches))))
                          (setq nodes  (cdr nodes)
                                node   (car nodes)))
                      (Info-goto-node node))))
            (error (message "%s" (if (eq (car-safe err) 'error) (nth 1 err) err))
                   (sit-for 1 t)))))
      (Info-find-node current-file current-node)
      (setq Info-history       ohist
            Info-history-list  ohist-list)
      (message "Searching indices...done")
      (or (nreverse matches)  t))))

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

[Eli Zaretskii]

> Date: Thu, 14 Jun 2018 07:16:12 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31807@debbugs.gnu.org
> 
> > > This is the scary text I saw, FWIW:...
> >
> > What's so scary about it?  It clearly identifies the problematic
> > characters, offers clickable buttons to go to each of them, and
> > explains the problem.  It should probably suggest UTF-8 as the first
> > alternative, but other than that I see no problem in this dialog.
> 
> Yes, at the very least, it should suggest utf-8 and provide
> that as the default value.  Only in a separate paragraph
> should it say that you can instead use any of the following
> instead...
> 
> Make it simple to understand that utf-8 solves the problem,
> and make it simple to choose utf-8.

Done on the master branch.

> You might even want to make it a 3-way decision: (1) Yes, convert to
> utf-8, (2) No, don't save, (3) Convert to an alternative encoding.

Option (2) is already available: just type C-g.  And the other 2 is
what this dialog is about.  With this change, UTF-8 is offered as the
default, if it can encode the text, and all the other encodings are
shown in a list from which the user can select another one.

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

[Drew Adams]

> > Yes, at the very least, it should suggest utf-8 and provide
> > that as the default value.  Only in a separate paragraph
> > should it say that you can instead use any of the following
> > instead...
> >
> > Make it simple to understand that utf-8 solves the problem,
> > and make it simple to choose utf-8.
> 
> Done on the master branch.
> 
> > You might even want to make it a 3-way decision: (1) Yes, convert to
> > utf-8, (2) No, don't save, (3) Convert to an alternative encoding.
> 
> Option (2) is already available: just type C-g.  And the other 2 is
> what this dialog is about.  With this change, UTF-8 is offered as the
> default, if it can encode the text, and all the other encodings are
> shown in a list from which the user can select another one.

Sounds good; thx.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> If you want to rename `info-apropos' here to `info-apropos-regexp', do so.

I've instead made info-apropos take a prefix argument to use a regexp in
Emacs 29.

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

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

[Drew Adams]

> > If you want to rename `info-apropos' here to `info-apropos-regexp',
> > do so.
> 
> I've instead made info-apropos take a prefix argument to use a regexp
> in Emacs 29.

IOW, _won't_ fix.  Please mark the bug that way, then.

As I said:

 What matters is what _Emacs_ means by "apropos", not what
 Info might mean by it, especially not just what some Info
 switch might be called.
 ...
 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).
 ^^^^^^^^^^^^^^^^^^^

`info-apropos' should provide Emacs "apropos" behavior,
which is regexp and keyword matching, not literal string
matching.

It would be fine to have a literal-matching command,
but it should not be called `info-apropos'.

Alternatively (and what I do in info+.el), it's fine to
let a prefix arg to `info-apropos' match literally, i.e.,
override the default "apropos" matching behavior.

It's _not_ fine (by me) to do what you've done, reverse
the suggested (and Info+) behavior for a prefix arg, so
that the command name _by default_ doesn't correspond
to its behavior (name: "apropos", behavior: literal).

Please change the bug status to "won't fix", to honestly
reflect what you've done.  Thx.