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: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Date: Wed, 07 Aug 2024 00:08:34 +0200 Message-ID: <87r0b15mot.fsf@dataswamp.org> References: <87sevj9b50.fsf@jeremybryant.net> <871q33rj7v.fsf@dataswamp.org> <86ed73qhly.fsf@gnu.org> <87frrjoryg.fsf_-_@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16900"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:ac6svuRqRlcMI1AiIYhQowkTcyI= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 07 04:22:53 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 1sbWKC-0004Fy-Jc for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Aug 2024 04:22:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbWJ8-0000pi-5R; Tue, 06 Aug 2024 22:21:46 -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 1sbSMW-0007GW-Ny for emacs-devel@gnu.org; Tue, 06 Aug 2024 18:09:00 -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 1sbSMN-0002W2-FI for emacs-devel@gnu.org; Tue, 06 Aug 2024 18:08:54 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sbSML-00064h-3X for emacs-devel@gnu.org; Wed, 07 Aug 2024 00:08:49 +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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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: Tue, 06 Aug 2024 22:21:44 -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:322474 Archived-At: Richard Stallman wrote: >> 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 > > That is very abstract and does not propose any change > concretely enough that we could consider it. MVC is a term from CS theory, it means "Model View Control" and you can summarize it just by saying that data, data processing, and the interface, those should be kept apart. We have an interesting situation where the processing of data with Elisp is often done directly in the buffer, i.e. _in_ that same data! This is why Elisp code often gets completely littered with commands that move point back and forth, that extracts data, modifies data, inserts it back again, and so on. What we should do - well, (1) one should be aware of it and that it is a problem. So for example, instead of sorting a region in the buffer, one should ask - what does that region represent? what outputted it? - and then modify that function, for example to make it accept an optional alternative sorter or whatever. And (2), since it is gonna be like this anyway to a huge extent, to not have Elisp code being completely overrun by such stuff, we can provide a much neater, more consistent such set of functions. So this is bad (save-mark-and-excursion (progn (forward-paragraph -2) (point))) This OTOH is much better (pos-bol &optional N) (pos-eol &optional N) So for every unit, we should have pos-unit, pos-unit-beg, pos-unit-end, and pos-unit-reg (pos-unit should probably be the same as pos-unit-beg rather than pos-unit-reg for practical reasons). -- underground experts united https://dataswamp.org/~incal