Re: Emacs Lisp's future

[Rasmus <rasmus@gmx.us>]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Rasmus <rasmus@gmx.us> 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.

Cheers,
Rasmus

-- 
⠠⠵