From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Elisp: 8 out of 10 problems] I think the last one! (point) Date: Sun, 11 Aug 2024 08:22:27 +0300 Message-ID: <86y153iqgc.fsf@gnu.org> References: <875xs7zzik.fsf@dataswamp.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 11 07:23:09 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 1sd12q-0007lR-Vs for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Aug 2024 07:23:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sd12G-0004Wg-VZ; Sun, 11 Aug 2024 01:22:33 -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 1sd12F-0004Uj-GI for emacs-devel@gnu.org; Sun, 11 Aug 2024 01:22:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sd12E-0006jB-DV; Sun, 11 Aug 2024 01:22:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tKFVdO+3s8zLsWzk0LCp5GridnptpFmx+Tn05WDS+OE=; b=IBP7nuEgPzrV w6s6E1xgfpfYHFkqm8sxB2tnEBNbGt8JX1QEUUIqjI/ux5dg4otjPWpcBKCJS6vXx8kKtdn90+JWn ZT2hAlDd1qJ3MxOaO/DweO0wI9Xq2vLye8zlOBePqTqZCsUwn7sGEKvnLitep2980FEMKZOQkFqqF tGGZRvoJ4U0fuPBgRQZgnBU6XW3p7D731ok+6ysyICo84Y7v0f7vdrFVtcnf5+7Ki2TS3PxQTlB+T y7c5Am8JNV0SSyKNbn/XnYlzb0wKUrIEquqQ5dLpGlqOv7tJQIoKJu5qqWRL7vyfTZG5DqvkSIvlZ bSectdKHyCktZmJhKxKTaw==; In-Reply-To: <875xs7zzik.fsf@dataswamp.org> (message from Emanuel Berg on Sun, 11 Aug 2024 02:14:43 +0200) 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:322629 Archived-At: > From: Emanuel Berg > Date: Sun, 11 Aug 2024 02:14:43 +0200 > > Take a look again at ispell.el. That function is called > `ispell-process-line'. Man, what kind of #@&%$ lines to they > have! It is insane. > > But also look closer at the code. Point is constantly moving. Why is that a problem, for a command that analyzes text in a buffer? I'd say it's only natural that we move across the buffer as we spell-check it. As one nice bonus, when we find a mis-spelled word, we are already at that word, so it is already shown in the window together with its context. Every interactive speller works like that. > So if moving around the buffer is so important to us, why > haven't we made it into an art of perfection decades ago? We did. > For every unit in Emacs that we know of, e.g. buffer, line, > region, paragraph, word, there should be a two sets > of functions. > > (word-beg) (word-len) (word-reg) (word-end) > > So same with sentence then, as 'sent-' - "sentence-" is > too long. > > (sent-beg) (sent-len) (sent-reg) (sent-end) > > This should mean _go there_ > > But there should be another set as well, that just reports the > position. This set can mirror the former but let's start from > the other end to avoid typos and make it easier to see. > > (pos-sent-beg) (pos-sent-len) (pos-sent-reg) (pos-sent-end) We have that. The difference between "going there" and "not going" is in many cases negligible, so if we have forward-word (which can move N words forward), then "Nth word from here" is just (save-excursion (forward-word N) (current-word)) For sentences, we actually have both forward-sentence and sentence-end, but that's because there's a subtle difference between moving by sentence and finding the sentence end. More generally, Emacs has functions for stuff that is (a) non-trivial and (b) done frequently enough to justify a dedicated API. Having too many functions is a disadvantage, because it is then harder to remember and find what you need, and so we don't add functions out of some theoretical principle of completeness or symmetry or consistency. > One example that we really have under-prioritized this, is as > simple as the most common of all, namely > > (goto-char (point-min)) > > But as you see that isn't optimized one bit. It is long to > type, and not atomic, it is nested even. Yuk! > > Instead we should have, again, something like > > (buf-beg) (buf-len) (buf-reg) (buf-end) all with implicity `goto-char' > > and > > (pos-buf-beg) (pos-buf-reg) (pos-buf-end) > > is my suggestion, anyway! You exaggerate the minor issues, and completely ignore the downside of introducing more and more functions for no good reason. > This is a pretty big problem, don't think it is trivial. > Who is gonna want to maintain code, that is endlessly moving > point around, in those super-long functions, very vaguely at > any point having anything to do with the interesting problems, > one thought one would solve? We are doing this for decades, and that practice shows that it is not a catastrophe you are trying to make it sound. Far from it. > So annoying thing number 8, even tho this is our game plan and > we have a lot, it doesn't seem like we have really optimized > this for speed, brevity and code clearness. Of course, we do. You haven't shown that your suggestions will make Emacs faster in any non-trivial scenario. > This kind of stuff, yeah, compare to how long I type each line! > > (progn (forward-paragraph -2) (when (eobp) (point))) On the contrary: it is quite concise and tells exactly what the code is doing. By contrast, replacing it by some special-case API would at least sometimes require the reader to go refer to the documentation, in order to understand what the implementation does. And that is a non-trivial disadvantage. > And now, more ispell.el: > > Returns a cons cell where the `car' is sum SHIFT due to changes > in word replacements, and the `cdr' is the location of the final > word that was queried about." Did you read the documentation of what the speller returns when submitted a line with possibly mis-spelled words? It communicates the results in a form of a DSL whose parsing is not trivial at all. IOW, let's keep in mind that anonymous wisdom: "Complex problems have simple, easy-to-understand wrong answers."