From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Date: Mon, 05 Aug 2024 18:27:35 +0200 Message-ID: <87frrjoryg.fsf_-_@dataswamp.org> References: <87sevj9b50.fsf@jeremybryant.net> <871q33rj7v.fsf@dataswamp.org> <86ed73qhly.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:2rgl1y0CmJ7ubXddDox+J8LlGYo= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 05 18:31:05 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sb0bx-0008wp-Bb for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Aug 2024 18:31:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sb0bl-0005Pb-QK; Mon, 05 Aug 2024 12:30:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sb0Yn-00055Y-4R for emacs-devel@gnu.org; Mon, 05 Aug 2024 12:27:49 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sb0Yk-0001Jf-VE for emacs-devel@gnu.org; Mon, 05 Aug 2024 12:27:48 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sb0Yi-0005RF-Rv for emacs-devel@gnu.org; Mon, 05 Aug 2024 18:27:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 05 Aug 2024 12:30:48 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322393 Archived-At: 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