On Fri, J
ul 17, 2020 at 7:14 AM Eli Zaretskii <firstname.lastname@example.org
> Later it became apparent that you are doing this on purpose, because
> you have decided that certain directions of developing the package
> should be made as hard as possible, something that I think is
> completely against the spirit of Emacs development. Readers of this
> thread are invited to read
> especially under "Here are things we want third-party code to be able
> to do" and "Here are, on the other hand, things that people generally
> shouldn't do". Again, I'm interested to know how many of us here
> share those views.
I have used emacs for nearly 30 years but have rarely ventured into elisp development much
beyond maintaining my .emacs. So I look to emacs documentation as a user, not a developer.
OTOH I have been programming for just shy of 50 years. Over that time I have continually
increased the size and scope of projects I could tackle primarily by looking for ways to
build and compose ever better abstractions. Sometimes that has taken the form of adopting
a new programming language, sometimes a new methodology or disciple.
Conversely, one of the banes of my existence has been leaky abstractions. For better
or worse, based maining on the untyped nature of lisp and its culture of describing how
to interpret structures of various shapes, my overriding impression of the lisp world in
general and of elisp in particular is that they are rife with leaky abstractions.
I commend Dmitry's desire to provide an opaque abstraction for a project. Sadly, in
this instance I suspect that such an effort is an attempt to swim against an impossibly
strong tide. (If you cannot beat them, join them :-)