Re: [Elisp: 8 out of 10 problems] I think the last one! (point)

[Eli Zaretskii <eliz@gnu.org>]

> From: Emanuel Berg <incal@dataswamp.org>
> 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."