10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg <incal@dataswamp.org>]

Eli Zaretskii wrote:

> Please, everybody, take the Lisp vs Python argument off this
> list, it is off-topic here. If you must discuss this, please
> use the emacs-tangents@gnu.org mailing list instead.

Sure, but we are allowed to discuss how to make Elisp better?

Since Python has had enormous success, and Lisp hasn't - or if
it had, it lost it - it might be a good ide to analyze what
they (Python) did good.

You might think this is some bängalow discussion just because
certain people are in it. But it doesn't have to be like
that, it can be very hands-on.

Ten things that are annoying with Emacs Lisp from the holster,
and what to do about them:

10. Moving point around all the time. Whatever program, what
    you do is, it feels like, not solving your problem
    algorithmicly, you are just doing endless

    (goto (point-min))
    (prong (end-of-paragraph) (current-column))
    (pos-eol -1)

    (setq exists-after-point (unless (re-search-forward re nil t) (point)))

    Frustration: What has this to do with my problem and
    proposed solution? I understand Emacs grew around its
    function as a text editor, but "everything is in the
    buffer" and "the buffer is the data structure of Emacs",
    that has goon too far and we see a lot of code being
    virtually a very, very long traversal of buffers moving
    around point. So what ought to have been a tolerable
    exception, has become the norm and hailed model to the
    point, as I said earlier, interfaces toward programming
    are so weak it is considered normal that ispell can't even
    to (spell "word") without first outputting it somewhere
    and to the operation on that surface.

    Solution: MVC-ish separation of the interface, the
    computation, and the presentation of the result. To solve
    a problem, get the data into modern data structures with
    modern access methods, apply known algorithms by the book
    known specifically to help this problem rather than
    "Everything goes" Elisp hackin. (Yes you find that stuff
    in libraries, often. Apply on data in data structures, not
    on data as it appears in Emacs buffers.) But how ever well
    one does, it is gonna be _a lot_ of of moving point around
    in Emacs Lisp, so don't worry :)
   
Example of problem from my favorite part of Emacs, ispell.el:

(defun ispell-mime-multipartp (&optional limit)
  "Return multipart message start boundary or nil if none."
  ;; caller must ensure `case-fold-search' is set to t
  (and
   (re-search-forward
    "Content-Type: *multipart/\\([^ \t\n]*;[ \t]*[\n]?[ \t]*\\)+boundary="
    limit t)
   (let (boundary)
     (if (looking-at "\"")
	 (let (start)
	   (forward-char)
	   (setq start (point))
	   (while (not (looking-at "\""))
	     (forward-char 1))
	   (setq boundary (buffer-substring-no-properties start (point))))
       (let ((start (point)))
	 (while (looking-at "[-0-9a-zA-Z'()+_,./:=?]")
	   (forward-char))
	 (setq boundary (buffer-substring-no-properties start (point)))))
     (if (< (length boundary) 1)
	 (setq boundary nil)
       (concat "--" boundary)))))

Moving point around, looking, searching, seeing or not seeing.
This is boring and error prone to write, and error prone to
take over from someone else, or return to after x years.

You don't think in terms of the problem, or the solution for
that matter, you are just somewhere in the buffer and
according the the map you are completely lost!

That is why I have, at place 10 annoying things about Elisp,
excessive movement of point around the buffer, often involving
manual retrieving and editing data from a buffer that, in
execution, might not even look like what you thought it would,
and that was 25 lines ago!

Okay, I know - if only I could be passionate about it.

-- 
underground experts united
https://dataswamp.org/~incal