GNU bug report logs -
#26712
other-window/frame versions of find-library
Previous Next
Full log
Message #32 received at 26712 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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'.
[0001-New-commands-find-library-other-window-find-library-.patch (text/x-patch, attachment)]
This bug report was last modified 8 years and 61 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.