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

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

bug#26712: other-window/frame versions of find-library


From: Charles A. Roelli
Subject: bug#26712: other-window/frame versions of find-library
Date: Tue, 16 May 2017 21:08:07 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

I agree. Not sure if the `read-library' function should go in a different file, but in any case it makes sense to let users take advantage of it in their code.


Attached is a revised patch with Philipp's other suggestions taken into account.


On 07/05/2017 17:07, Drew Adams wrote:
- 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'.

Attachment: 0001-New-commands-find-library-other-window-find-library-.patch
Description: Text Data


reply via email to

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