emacs-devel
[Top][All Lists]
Advanced

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

Re: elib -> emacs


From: David Kastrup
Subject: Re: elib -> emacs
Date: Tue, 19 Jun 2007 14:45:13 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Andreas Röhler <address@hidden> writes:

> Am Dienstag, 19. Juni 2007 12:41 schrieb Richard Stallman:
>> I presume that tar file is the distribution of our elib package.
>> It is not part of Emacs.  The question is what parts of it to merge
>> into Emacs.
>>
>
> My attention here results from the package as such and
> an impression, it would be helpful for
> elisp-programmers to have collections of
> general-purpose resources.
>
> For novices this might be of special interest.
> Currently general-purpose functions are written again
> and again, because existing are scattered and people
> ignore them. See already mentioned string-strip
> facilities.

The solution cannot be to write even more of such functions and
scatter them into libraries with separate documentation and
interfaces.

Consolidation should happen into the existing subr.el, with
documentation in the normal Elisp manual.

> In this context also the different name of already merged
> functions matters:
>
> elib's `string-replace-match' AFAIU is easier to call
>  and remember than the (slightly changed)
>  `dired-string-replace-match' now in dired.el.

That can't be a reason to introduce a new function under a new name if
the functionality is basically the same.

If cleanup, reorganization and similar janitorial work is required
(which may very well be the case), it should not be done by heaping
cleaner code on top of existing ugliness.  We need fewer possibilities
to do the same thing, not more.

I cannot see (judging from current postings rather than actually
looking at the code) that adding elib as a separate entity is going to
help consolidating this situation.  It very much sounds like the way
to go about this would be to check whether we can get papers for it,
and if we can, break it down for reusable pieces that we pull into
subr.el and the Elisp manual.  Probably the main work would be finding
and replacing prospective callers and duplicate functions.

-- 
David Kastrup




reply via email to

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