elib -> emacs

elib -> emacs

[Karl Berry]

Years ago, there was a package "elib" which aimed to provide generic
functionality beyond that in Emacs itself.  The last release was in
1995, and is at ftp://ftp.lysator.liu.se/pub/emacs/elib-1.0.tar.gz.

The elib maintainers (Inge Wallin and Per Cederqvist) are (obviously)
not working on it any more.  They suggested that much of what was in
elib is now in Emacs, but don't keep up with current Emacs developments,
so can't easily check if there is anything in elib which should be moved
into Emacs.

Could someone here please take a look at that elib tarball and see if
there is anything in there that could still be useful in Emacs?

Thanks,
Karl

Re: elib -> emacs

[Andreas Röhler]

Am Samstag, 16. Juni 2007 02:29 schrieb Karl Berry:
> Years ago, there was a package "elib" which aimed to provide generic
> functionality beyond that in Emacs itself.  The last release was in
> 1995, and is at ftp://ftp.lysator.liu.se/pub/emacs/elib-1.0.tar.gz.
>
> The elib maintainers (Inge Wallin and Per Cederqvist) are (obviously)
> not working on it any more.  They suggested that much of what was in
> elib is now in Emacs, but don't keep up with current Emacs developments,
> so can't easily check if there is anything in elib which should be moved
> into Emacs.
>
> Could someone here please take a look at that elib tarball and see if
> there is anything in there that could still be useful in Emacs?
>
> Thanks,
> Karl
>


For me it doesn't seem a good idea to drop elib.el,
unless it's proven buggy.

You may re-view `string-replace-match' for example as
`dired-string-replace-match', slightly changed.

However, with this new name, it's not as easy detected
as the original function.

Just checked `string-replace-match': it works fine.

Too other programs may rely on elib.el as emacspeak
does:

http://emacspeak.googlecode.com/svn/trunk/lisp/elib-readme
says:

This directory includes stack-f.el and string.el from
Elib 1.0.


Regards,

Andreas Roehler

Re: elib -> emacs

[Richard Stallman]

    For me it doesn't seem a good idea to drop elib.el,
    unless it's proven buggy.

Some of its functionality is already in Emacs.
Emacspeak is not a sharp issue, since the relevant files
of elib have been copied into it.

    http://emacspeak.googlecode.com/svn/trunk/lisp/elib-readme
    says:

    This directory includes stack-f.el and string.el from
    Elib 1.0.

Can you email me those two files?  If they are useful enough,
we could add them to Emacs.

What other elib features do programs such as Emacspeak still use?

Re: elib -> emacs

[Andreas Röhler]

Am Sonntag, 17. Juni 2007 23:49 schrieb Richard Stallman:
>     For me it doesn't seem a good idea to drop elib.el,
>     unless it's proven buggy.
>
> Some of its functionality is already in Emacs.
> Emacspeak is not a sharp issue, since the relevant files
> of elib have been copied into it.
>
>     http://emacspeak.googlecode.com/svn/trunk/lisp/elib-readme
>     says:
>
>     This directory includes stack-f.el and string.el from
>     Elib 1.0.
>
> Can you email me those two files?  If they are useful enough,
> we could add them to Emacs.

??? Sorry, but I don't understand your request. Both
files are part of elib.el, distributed with Emacs.

> What other elib features do programs such as Emacspeak still use?
>

Good question. How to find out if functions written at
some place are used by other programs? Got an
impression to have seen such thing in one of the
cl-implementation files, but don't remember
precisely. I'm afraid I can't be helpful here.

Andreas Roehler

Re: elib -> emacs

[Nick Roberts]

 > ??? Sorry, but I don't understand your request. Both
 > files are part of elib.el, distributed with Emacs.

Is it?  Which directory is elib.el in?  I can't find it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: elib -> emacs

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

Am Montag, 18. Juni 2007 08:05 schrieb Nick Roberts:
>  > ??? Sorry, but I don't understand your request. Both
>  > files are part of elib.el, distributed with Emacs.
>
> Is it?  Which directory is elib.el in?  I can't find it.


Oops, sorry. Seeing a `suse-start-elib.el' maybe it
was delivered once from Suse. 

Attached the archiv as it exists on my machine.

Thanks 

Andreas Roehler

[-- Attachment #2: elib-1.0.tar.gz --]
[-- Type: application/x-tgz, Size: 58335 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: elib -> emacs

[Stefan Monnier]

> This directory includes stack-f.el and string.el from
> Elib 1.0.

Why use stack-f.el?  This part of elib has always seemed rather pointless:
cons cells provide perfectly good stacks already.

As for string.el, which part do you use?  It seems this is equivalent
functionality in Emacs-22 for most if not all of it already.


        Stefan


PS: The only interesting part of elib seemed to me to be cookie.el (mostly
included in Emacs as ewoc.el) and avltree.el, although I haven't seen many
uses of avltree.el around.

Re: elib -> emacs

[Andreas Röhler]

Am Montag, 18. Juni 2007 17:36 schrieb Stefan Monnier:
> > This directory includes stack-f.el and string.el from
> > Elib 1.0.
>
> Why use stack-f.el?  This part of elib has always seemed rather pointless:
> cons cells provide perfectly good stacks already.
>
> As for string.el, which part do you use?  It seems this is equivalent
> functionality in Emacs-22 for most if not all of it already.
>
>
>         Stefan
>
>
> PS: The only interesting part of elib seemed to me to be cookie.el (mostly
> included in Emacs as ewoc.el) and avltree.el, although I haven't seen many
> uses of avltree.el around.
>

As it turned out meanwhile, I misunderstood OP in such,
as I assumed elib-library already part of Emacs and
doomed to drop. Question was raised different. 

Andreas Roehler

Re: elib -> emacs

[Richard Stallman]

    ??? Sorry, but I don't understand your request. Both
    files are part of elib.el, distributed with Emacs.

elib is not distributed with Emacs.
elib is a separate package.

Re: elib -> emacs

[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.

Re: elib -> emacs

[Andreas Röhler]

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.

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.


Andreas Roehler

Re: elib -> emacs

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> 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

Re: elib -> emacs

[Stefan Monnier]

> 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.

Nice theory.  But very little of elib is of any use nowadays.

> elib's `string-replace-match' AFAIU is easier to call
>  and remember than the (slightly changed)
>  `dired-string-replace-match' now in dired.el.

What's wrong with replace-regexp-in-string?


        Stefan

Re: elib -> emacs

[Richard Stallman]

What feature does cookie.el have that ewoc.el does not have?
Would it be easy to write a cookie-compatible front end for ewoc?
Or change the various programs that now use cookie.el to use
ewoc.el instead?

Re: elib -> emacs

[Richard Stallman]

    PS: The only interesting part of elib seemed to me to be cookie.el (mostly
    included in Emacs as ewoc.el) and avltree.el, although I haven't seen many
    uses of avltree.el around.

Should we install avltree.el in Emacs?

We would also want to put the part of elib.texi that concerns
avltree.el into a separate manual man/avltree.texi.

Re: elib -> emacs

[Stefan Monnier]

> What feature does cookie.el have that ewoc.el does not have?

The set of functions is slightly different.  Cookie.el has some
extra features.

> Would it be easy to write a cookie-compatible front end for ewoc?

No idea.  Doesn't seem worth the trouble.

> Or change the various programs that now use cookie.el to use
> ewoc.el instead?

Yes, that's pretty easy.  The main user of cookie.el was PCL-CVS which has
been the driving force behind ewoc.el (and I don't know if any other package
uses ewoc, to tell you the truth).  I don't know if there still exists
a package using cookie.el.


        Stefan

Re: elib -> emacs

[Richard Stallman]

    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.

We do have papers for Elib, and that's pretty much the way I think we
should handle it.  (I don't think it all has to go into subr.el.)

Re: elib -> emacs

[Richard Stallman]

      I don't know if there still exists
    a package using cookie.el.

Can someone please look around and check?
If there are none, that settles the question of cookie.el.

Re: elib -> emacs

[Andreas Röhler]

Am Mittwoch, 20. Juni 2007 19:35 schrieb Richard Stallman:
>       I don't know if there still exists
>     a package using cookie.el.
>
> Can someone please look around and check?
> If there are none, that settles the question of cookie.el.
>
>

Don't know, if it's a suitable method to find out such
things:

did several searches

find . -type f -name "*.el" -print0 | xargs -0 -e zgrep -nH -e 

with

elib-, tin-cookie, avl-tree

as search-words.

Results only in the elib directory: no one seems to use that.

Andreas Roehler

Re: elib -> emacs

[Andreas Röhler]

Am Mittwoch, 20. Juni 2007 20:07 schrieb Andreas Röhler:
> Am Mittwoch, 20. Juni 2007 19:35 schrieb Richard Stallman:
> >       I don't know if there still exists
> >     a package using cookie.el.
> >
> > Can someone please look around and check?
> > If there are none, that settles the question of cookie.el.
>
> Don't know, if it's a suitable method to find out such
> things:
>
> did several searches
>
> find . -type f -name "*.el" -print0 | xargs -0 -e zgrep -nH -e
>
> with
>
> elib-, tin-cookie, avl-tree
>
> as search-words.
>
> Results only in the elib directory: no one seems to use that.
>
> Andreas Roehler
>

-name 

should have been "*.el.gz"

Then I get results for the already mentioned

ediff-vers.el ewoc.el

nothing to be done AFAIU. 

Andreas Roehler

Re: elib -> emacs

[Richard Stallman]

    did several searches

    find . -type f -name "*.el" -print0 | xargs -0 -e zgrep -nH -e 

Does this mean you searched Emacs itself?

The point here is to search Lisp programs that are NOT included in
Emacs.

Re: elib -> emacs

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 678 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Yes, that's pretty easy.  The main user of cookie.el was PCL-CVS which
> has been the driving force behind ewoc.el (and I don't know if any
> other package uses ewoc, to tell you the truth).  I don't know if
> there still exists a package using cookie.el.

Just as a data point, DVC (which is not yet part of Emacs, but aims to
be, eventually) uses ewoc.

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: elib -> emacs

[T. V. Raman]

I included string.el so that I got string-split  --

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     For me it doesn't seem a good idea to drop
    Richard> elib.el, unless it's proven buggy.
    Richard> 
    Richard> Some of its functionality is already in Emacs.
    Richard> Emacspeak is not a sharp issue, since the relevant
    Richard> files of elib have been copied into it.
    Richard> 
    Richard>     http://emacspeak.googlecode.com/svn/trunk/lisp/elib-readme
    Richard> says:
    Richard> 
    Richard>     This directory includes stack-f.el and string.el
    Richard> from Elib 1.0.
    Richard> 
    Richard> Can you email me those two files?  If they are
    Richard> useful enough, we could add them to Emacs.
    Richard> 
    Richard> What other elib features do programs such as
    Richard> Emacspeak still use?
    Richard> 
    Richard> 
    Richard> _______________________________________________
    Richard> Emacs-devel mailing list Emacs-devel@gnu.org
    Richard> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: elib -> emacs

[Richard Stallman]

    I included string.el so that I got string-split  --

Emacs has a function split-string.
It is the same basic idea as string-split from elib.
They are not compatible, but does split-string do what you need?

Re: elib -> emacs

[T. V. Raman]

yes, split-string does what I need.

I can now eliminate string.el -- will need to confirm by deleting
code.

I used stack.el to implement myself a stack of positions for
sudoku -- sudoku.el itself is not part of emacs, so in some sense
I'm using stack.el for an external package.


>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     I included string.el so that I got string-split
    Richard> -- Emacs has a function split-string.  It is the
    Richard> same basic idea as string-split from elib.  They are
    Richard> not compatible, but does split-string do what you
    Richard> need?

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: elib -> emacs

[T. V. Raman]

The other function from string.el that I've used in a few
critical places in emacspeak is string-replace-match --- would be
nice to have that functionality in elisp built-in.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     I included string.el so that I got string-split
    Richard> -- Emacs has a function split-string.  It is the
    Richard> same basic idea as string-split from elib.  They are
    Richard> not compatible, but does split-string do what you
    Richard> need?

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: elib -> emacs

[T. V. Raman]

Apologies for the multiple messages, but shortly after reporting
that I used string-replace-match from string.el I discovered
replace-regexp-in-string from subr.el that pretty much does what
I want.

In general, it would be nice if things in subr.el were more
easily discoverable -- that modules has a lot of hidden treasures.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     I included string.el so that I got string-split
    Richard> -- Emacs has a function split-string.  It is the
    Richard> same basic idea as string-split from elib.  They are
    Richard> not compatible, but does split-string do what you
    Richard> need?

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: elib -> emacs

[Thien-Thi Nguyen]

() "T. V. Raman" <raman@users.sf.net>
() Sun, 24 Jun 2007 15:44:43 -0700

   In general, it would be nice if things in subr.el were more
   easily discoverable -- that modules has a lot of hidden treasures.

a programmer w/ full source
 complains: "incomplete course!"
i demand spoon-to-mouth service!
 digging around makes me nervous!
will waiting for slow plate
 make sating a doomed fate?
will twitching finger velocity
 always thwart curious precocity?

thi

Re: elib -> emacs

[Richard Stallman]

Would someone please install avl-tree.el from Elib
into Emacs, in the trunk?

Re: elib -> emacs

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

() Richard Stallman <rms@gnu.org>
() Mon, 25 Jun 2007 09:19:52 -0400

   Would someone please install avl-tree.el from Elib
   into Emacs, in the trunk?

assuming you mean avltree.el (without hyphen), please find below an
avl-tree.el (with hyphen) that is standalone-compilable.  it comprises:

 - elib-node.el inlined
 - new defuns: elib-stack-{create,push,pop}
 - avltree.el (slightly modified -- see "HACKS")

i plan to add this to the repo as lisp/emacs-lisp/avl-tree.el then do
further integration, along the lines of:

 - style stuff (comments, indentation, eldoc)
 - remove new defuns; use cl push/pop directly
 - do s/elib-node/avl-tree-node/g

these changes would leave us in a position to be able to easily
(re-)separate the node-* funcs should there arise a future need.
another approach is to skip the initial checkin, but i would prefer
two steps to keep some vc-visible (diff-able) history.  comments?

thi



[-- Attachment #2: avl-tree.el --]
[-- Type: application/emacs-lisp, Size: 19478 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: elib -> emacs

[Thien-Thi Nguyen]

() Thien-Thi Nguyen <ttn@gnuvola.org>
() Sun, 26 Aug 2007 16:13:27 +0200

    - new defuns: elib-stack-{create,push,pop}

drat, thinko.
here are two revised definitions:

(defmacro elib-stack-push (stack object) `(push ,object ,stack))
(defmacro elib-stack-pop (stack) `(pop ,stack))

thi

Re: elib -> emacs

[Stefan Monnier]

> these changes would leave us in a position to be able to easily
> (re-)separate the node-* funcs should there arise a future need.
> another approach is to skip the initial checkin, but i would prefer
> two steps to keep some vc-visible (diff-able) history.  comments?

Sounds good to me,


        Stefan