unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Nicolas Richard <theonewiththeevillook@yahoo.fr>
Cc: "Emacs-Devel \(emacs-devel@gnu.org\)" <emacs-devel@gnu.org>
Subject: RE: Why do apropos commands match only pairs of words in a word-list pattern?
Date: Mon, 11 May 2015 07:06:01 -0700 (PDT)	[thread overview]
Message-ID: <fb8ad237-c97f-4ec9-94b4-6937e4d01abc@default> (raw)
In-Reply-To: <87pp671ygs.fsf@yahoo.fr>

> > Instead of matching each word in the list you provide it, apropos
> > commands match each pair of words from the list.
> 
> > Why is this the design?  Wouldn't users more typically want *each*
> > of the words they type to be matched?
> 
> My own experience is that I both sometimes liked and sometimes hated
> the behaviour. Often the latter, though. I think it would be nice to
> sort by relevance (e.g. the number of words that matched). How
> easy/difficult would that be ?

That's not the answer, IMO.  Better is to give users control over the
behavior.  A user option is one approach.

(I've done that in my library `apu.el': `apu-match-word-pairs-only-flag', 
http://www.emacswiki.org/emacs/download/apu.el).

Another possibility is to have an option to define the default behavior,
but to let users decide immediately which behavior to get when they use
the command.  That is the approach taken by apropos commands for DO-ALL.
That's the way to go, I think.

It's not just about ordering things.  Order is a separate choice axis,
and yes, users should be able to order the output in different ways.
But simply always combining the two matching approaches mentioned, and
relegating the "looser" pair-matching candidates to the end of the
buffer is not a good design.  (IMHO.)

But I would still like to hear from someone who gives a good reason
for the current design.  You've said that you sometimes like it, but
that doesn't tell why.  And why pairs and not triplets or...?

My guess so far is that this is just historical - a vestige of the
fact that apropos was implemented to use a regexp, so we cobbled
together a regexp that, while not doing what one would expect for
keyword matching, at least covers all of the true positives, even
if it also throws in a lot of false positives.

But I would like to hear arguments of why this is TRT for apropos.



  reply	other threads:[~2015-05-11 14:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-09 19:16 Why do apropos commands match only pairs of words in a word-list pattern? Drew Adams
2015-05-11  5:21 ` Nicolas Richard
2015-05-11 14:06   ` Drew Adams [this message]
2015-05-11 14:51     ` Nicolas Richard
2015-05-11 14:59     ` Eli Zaretskii
     [not found] <<eb17cadb-6235-4c3f-919a-6ca8dcc1da6d@default>
     [not found] ` <<87pp671ygs.fsf@yahoo.fr>
     [not found]   ` <<fb8ad237-c97f-4ec9-94b4-6937e4d01abc@default>
     [not found]     ` <<83lhgvma79.fsf@gnu.org>
2015-05-11 17:01       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb8ad237-c97f-4ec9-94b4-6937e4d01abc@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=theonewiththeevillook@yahoo.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).