unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Philipp Stephani <p.stephani2@gmail.com>,
	"Charles A. Roelli" <charles@aurox.ch>,
	26712@debbugs.gnu.org
Subject: bug#26712: other-window/frame versions of find-library
Date: Sun, 7 May 2017 08:07:37 -0700 (PDT)	[thread overview]
Message-ID: <fdb8c28e-aa1a-4630-b791-fa31ff6aa742@default> (raw)
In-Reply-To: <CAArVCkTSbWZQ-7rOHyak0GC7QiJkFzW0LfuNcTZvHzcgzc8AQg@mail.gmail.com>

> - Consider renaming `find-library-read' to
>   `find-func--read-library' to make it internal.
>   It's probably not intended as a public API.

Why?  No.  Please do not consider that.  Not for a moment.

FWIW, I completely disagree with this point of view and
approach to Emacs Lisp.  Just the opposite.  Unless there is
some _very_ important reason why something _must_ be branded
as "internal", it should not be.

It may be a hard habit to break, but the notion of a "public
API" is generally inappropriate for Emacs Lisp.  Emacs users
are also Emacs-Lisp developers. And yes, they do write their
own libraries that read input.

Just imagine, if an input-reading function such as
`ffap-read-file-or-url', `read-file-name', `completing-read',
`read-face-name', or `read-char' were declared at the outset
to be "internal".  What's the point of such an artificial 
separation?

In fact, I'd suggest that the library prefix be removed from
`find-library-read' - just call it `read-library-name'.
Elevate it; don't hide or suppress it.

GNU Emacs in particular, and free software in general, have
the explicit intention that users _are_ developers and that
they look under the hood, tinker with engine parts, modify
or make their own use of them, to create new and better
things.

And yes, Emacs development is driven not only by its
maintainers or those most active in its C code or fixing
its bugs.  It is driven also, and importantly, by users,
who write their own code for their own uses, and who
sometimes extend that code into 3rd-party libraries.

Some such development even finds its way into distributed
Emacs itself - either directly, by incorporating it, or
indirectly, by copy or inspiration.  The latter happens
more than most people, including Emacs maintainers, are
aware of.

Emacs would not be what it is today if it did not offer
features written by its users (think Org).  And this has
been true of Emacs since Day One - even before GNU Emacs.

So let's please stop with the tendency to view Emacs
development as an internal-vs-external thing: we core
developers and the code we maintain vs you "lusers" and
your customizations.

If we are to have _any_ "internal" functions or variables
then the burden should be to demonstrate strongly why
a given one really _needs_ to be internal.  A priori,
every single one should be "external" or, more exactly, 
"nil-ternal".

I see no good reason why a general function that reads a
library name should be flagged "internal".  Why should
anyone be discouraged from using it in their code?  Why
shouldn't everyone be encouraged to use it, if they want
to read a library name?

This kind of not-for-the-users attitude smacks of
elitism, or at least seems control-freakish, even if it
is unconscious.  Open the corral, please.  Emacs, and
all of its code, belongs to its users.

There is nothing special about this function.  It is
useful generally.  And it should be called something
like `read-library-name'.





  reply	other threads:[~2017-05-07 15:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 19:46 bug#26712: other-window/frame versions of find-library Charles A. Roelli
2017-04-29 20:33 ` Drew Adams
2017-04-30 18:16   ` Charles A. Roelli
2017-05-01 11:11     ` Philipp Stephani
2017-05-06  9:56 ` Charles A. Roelli
2017-05-07 12:08   ` Philipp Stephani
2017-05-07 13:36     ` Charles A. Roelli
2017-05-07 13:45       ` Philipp Stephani
2017-05-07 15:07         ` Drew Adams [this message]
2017-05-16 19:08           ` Charles A. Roelli
2017-05-16 19:36             ` Eli Zaretskii
2017-05-17 19:16               ` Charles A. Roelli
2017-05-20  0:54                 ` Howard Melman
2017-05-20  2:04                   ` Drew Adams
2017-05-20  3:24                     ` Howard Melman
2017-05-21  3:23                   ` Richard Stallman
2017-05-29 19:39                     ` Charles A. Roelli
2017-05-31  4:23                       ` Richard Stallman
2017-06-02 18:39                         ` Charles A. Roelli
2017-06-04  2:54                           ` Richard Stallman
2017-06-11 10:44                             ` Charles A. Roelli
2017-05-20 11:47                 ` Eli Zaretskii

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=fdb8c28e-aa1a-4630-b791-fa31ff6aa742@default \
    --to=drew.adams@oracle.com \
    --cc=26712@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    --cc=p.stephani2@gmail.com \
    /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).