unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>
Cc: "larsi@gnus.org" <larsi@gnus.org>, "rms@gnu.org" <rms@gnu.org>,
	"46627@debbugs.gnu.org" <46627@debbugs.gnu.org>
Subject: bug#46627: [External] : bug#46627: [PATCH] Add new help command 'describe-command'
Date: Fri, 26 Feb 2021 21:34:21 +0000	[thread overview]
Message-ID: <SA2PR10MB4474BA98F2FB35725045861BF39D9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CO1PR10MB4466E6EBDF7E0058565B9BE7F3839@CO1PR10MB4466.namprd10.prod.outlook.com>

Apropos...

Coming back to this, as I just happened to be reading
Paul Graham's essay "Novelty and Heresy" today, and
it rang a bell...

http://paulgraham.com/nov.html

> > AFAIR, Emacs never meant completion to be a means
> > of discovery.  The discovery was always meant to
> > be through "apropos" commands.
> 
> Emacs never originally meant a lot of things that
> were later expanded (or repurposed to some degree)
> to advantage.  This is normal for many processes
> of change.
>   Exaptation: [Wikipedia URL]
>   Spandrel:   [Wikipedia URL]
> 
> > > So the idea is to combine searching for commands
> > > with looking up their documentation.
> >
> > I'm not sure this is a good idea, FWIW.  For starters,
> > it is limited: if you spot a command whose name sounds
> > relevant, you have no simple way getting details about
> > it.  Unlike apropos commands, which do provide such ways.
> 
> "You have no such simple way" ... until you do.


From "Novelty and Heresy":

  One common way for a good idea to be non-obvious is
  for it to be hidden in the shadow of some mistaken
  assumption that people are very attached to.

  But anything you discover from working on such an
  idea will tend to contradict the mistaken assumption
  that was concealing it.  And you will thus get a lot
  of heat from people attached to the mistaken assumption.
  ...
  This phenomenon [is] probably always an ingredient
  in the resistance to new ideas.
  ...
  Every cherished mistaken assumption has a dead zone
  of unexplored ideas around it.

In this case, the usefulness of completion for discovery
has been pointed out by several people.  But it's _not_
the original intention for completion.  As you put it,
"Emacs never meant completion to be a means of discovery."
And the legitimate, intended means of discovery in Emacs
was apropos.

But completion _is_, accidentally or not, a means to
discovery - and it can be a good one.

That original intention corresponds to a "mistaken
assumption" in this context: the assumption that
completion is not for discovery _because_ that isn't
why it was added to Emacs (and something else was
added to aid discovery).

Saying that completion is, or it can be, useful for
discovery?  Heresy.

The usefulness of 3rd-party code that has fruitfully
explored the "dead zone" around the assumption that
the only purpose of completion is to return completed
input is pretty clear to those acquainted with it.

The positive takeaway, beyond the case of using
completion for discovery?

  The depressingly large dead zones around mistaken
  assumptions [can] become excitingly large mines of
  new ideas.

That puts exaptation in an active light - it need not
be an entirely accidental process.





  parent reply	other threads:[~2021-02-26 21:34 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19  1:06 bug#46627: [PATCH] Add new help command 'describe-command' Stefan Kangas
2021-02-19  8:42 ` Eli Zaretskii
2021-02-19 17:42   ` Stefan Kangas
2021-02-19 18:38     ` bug#46627: [External] : " Drew Adams
2021-02-20  3:25       ` Stefan Kangas
2021-02-20  4:25         ` Drew Adams
2021-02-20  8:20           ` Eli Zaretskii
2021-02-20  7:44         ` Eli Zaretskii
2021-02-19 20:05     ` Eli Zaretskii
2021-02-20  4:10       ` Stefan Kangas
2021-02-20  8:18         ` Eli Zaretskii
2021-02-20 17:10           ` Stefan Kangas
2021-02-21 13:08             ` Lars Ingebrigtsen
2021-02-22 15:58             ` Eli Zaretskii
2021-04-28 13:58               ` Stefan Kangas
2021-04-28 14:17                 ` Stefan Kangas
2021-05-02 13:14                 ` Stefan Kangas
2021-02-20 12:56     ` Lars Ingebrigtsen
2021-02-20 12:59       ` Eli Zaretskii
2021-02-20 16:16         ` Eli Zaretskii
2021-02-20 14:04       ` Stefan Kangas
2021-02-20 16:06     ` Richard Stallman
2021-02-20 16:09       ` Eli Zaretskii
2021-02-20 20:06         ` bug#46627: [External] : " Drew Adams
2021-02-20 20:17           ` Eli Zaretskii
2021-02-20 20:54             ` Drew Adams
2021-02-20 16:39       ` Stefan Kangas
2021-02-20 16:49         ` Eli Zaretskii
2021-02-20 20:35           ` bug#46627: [External] : " Drew Adams
2021-02-20 20:46             ` Eli Zaretskii
2021-02-20 21:16               ` Drew Adams
2021-02-21 15:07                 ` Eli Zaretskii
2021-02-21 17:55                   ` Drew Adams
2021-02-21 18:11                     ` Eli Zaretskii
2021-02-21 18:30                       ` Drew Adams
2021-02-26 21:34             ` Drew Adams [this message]
2021-02-27  8:04               ` Eli Zaretskii
2021-02-27 17:46                 ` Drew Adams
2021-02-21  6:19         ` Richard Stallman
2021-02-21  7:18           ` Stefan Kangas
2021-02-21 15:27             ` Eli Zaretskii
2021-02-21 16:39               ` Howard Melman
2021-02-21 18:01                 ` bug#46627: [External] : " Drew Adams
2021-02-21 17:01               ` Stefan Kangas
2021-02-21 17:36                 ` Eli Zaretskii
2021-02-21 18:02                   ` Stefan Kangas
2021-02-21 18:21                     ` Eli Zaretskii
2021-02-21 19:57                       ` Dmitry Gutov
2021-02-21 20:13                         ` Eli Zaretskii
2021-02-21 23:46                           ` Dmitry Gutov
2021-02-22 15:18                             ` Eli Zaretskii
2021-02-27 20:38                               ` Dmitry Gutov
2021-02-28 17:27                                 ` Eli Zaretskii
2021-02-28 21:40                                   ` Dmitry Gutov
2021-03-01  6:05                                     ` Eli Zaretskii
2021-03-02  1:40                                       ` Dmitry Gutov
2021-03-02  5:31                                         ` Eli Zaretskii
2021-03-02 12:55                                           ` Dmitry Gutov
2021-03-02 13:47                                             ` Eli Zaretskii
2021-02-21 17:57               ` bug#46627: [External] : " Drew Adams
2021-02-21 17:33             ` Drew Adams
2021-02-21 13:06           ` Lars Ingebrigtsen
2021-02-21  6:27         ` Richard Stallman
2021-02-21  6:10     ` Richard Stallman
2021-02-21  6:27     ` Richard Stallman
2021-02-19 13:12 ` Lars Ingebrigtsen
2021-02-19 18:27   ` bug#46627: [External] : " Drew Adams
2021-02-19 18:43     ` Eli Zaretskii
2021-02-21  6:18     ` Richard Stallman
2021-02-21  6:27     ` Richard Stallman
2021-02-20  6:56 ` Richard Stallman
2021-02-20  7:14   ` Stefan Kangas
2021-02-21  6:19     ` Richard Stallman
2021-02-21  6:27     ` Richard Stallman
2021-02-21  7:17       ` Stefan Kangas
2021-02-22  6:23         ` Richard Stallman
2021-02-24  3:28           ` Stefan Kangas
2021-02-27 18:58           ` Dmitry Gutov
2021-03-01  5:18             ` Richard Stallman
2021-03-01 16:13               ` bug#46627: [External] : " Drew Adams
2021-03-02  6:29                 ` Richard Stallman
2021-03-02  6:50                   ` Eli Zaretskii
2021-03-03  5:55                     ` Richard Stallman
2021-03-03 15:26                       ` Drew Adams
2021-03-03 16:14                         ` Eli Zaretskii
2021-03-02 16:52                   ` 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=SA2PR10MB4474BA98F2FB35725045861BF39D9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=46627@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rms@gnu.org \
    --cc=stefan@marxist.se \
    /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).