[Top][All Lists]

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

Re: Emacs Lisp's future

From: Rasmus
Subject: Re: Emacs Lisp's future
Date: Thu, 18 Sep 2014 18:18:00 +0200
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)

address@hidden (Phillip Lord) writes:

> Rasmus <address@hidden> writes:
>>> Yep, upgrades will be downloads. A number of packages on there are used
>>> for integration testing. So, I pull down dash on every checking for
>>> several of my projects. In time, I am sure dash will become the most
>>> downloaded package because of this.
>> I don't "get" dash and s, but lots of people developing more
>> impressive things than I will ever be able to do seem happy with it so
>> who am I to judge?  When I write a patch, I intend it to become part
>> of core, so dash/s are not options.
> I think dash just makes list operations a lot easier. So, I use this,
> for instance, to nil a tree of markers.
> (defun m-buffer-nil-marker (markers)
>  (-map
>    (lambda (marker)
>      (set-marker marker nil))
>    (-flatten markers)))

Flatten in nontrivial, but assuming you got something similar there's
no difference from mapcar or mapc, no?

> I could also have done
> (--map (set-marker it nil) 
>       (-flatten markers))
> or even
> (--tree-map
>      (set-marker it nil)
>    markers)

That is cool, yes, but not really (much) easier, and perhaps a bit
less readable.

Anyway, we're getting off topic here.

> I always found list operation in emacs a bit low-level. Dash also uses a
> lot names familar to people from other languages which help. I agree
> about getting into core, but with package.el coming on a-pace this might
> be less of a worry in future.

But this drives good stuff into external packages.  When search-costs
are non-nil this could be bad. . .  It's bad enough that, say, AUCTeX
is not part of the Emacs tarball.



reply via email to

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