Re: Windows' "split status"

[Nix <nix@esperi.org.uk>]

On 25 Nov 2011, Eli Zaretskii verbalised:

>> From: Nix <nix@esperi.org.uk>
>> Emacs: resistance is futile; you will be assimilated and byte-compiled.
>> Date: Fri, 25 Nov 2011 12:00:30 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@gnu.org, monnier@iro.umontreal.ca,
>> 	emacs-devel@gnu.org
>> 
>> I thought this was documentation for Lisp developers, not for Emacs
>> maintainers.
>
> It's both, actually.  There's no other place to look for documentation
> of Emacs internals except the ELisp manuals, because the comments
> never tell enough.  When you want to change some complex piece of
> code, and look for a comprehensive documentation of its contract, the
> ELisp manual is the only place you can find something close.

Yes indeed. I'm not saying it's not *useful* for Emacs maintainers!

> But I don't think this invalidates your point.

Quite. Lots of docstrings talk about invariants, because this is really
useful. Even something like the description of what `right-char' or
`newline' do are invariants. None of them should eschew talking about
those invariants simply because they are not atomic from the POV of the
Emacs core. Heck, `newline' is written in Lisp: from the POV of the
Emacs core, `newline' inserts soft newlines and then later marks them
hard, but nonetheless we talk about `newline' always inserting hard
newlines.


Where this suddenly does become urgent is if we ever find a way to
multithread Emacs -- but I strongly suspect that an Emacs with locking
fine-grained enough to maintain useful invariants would be
unmaintainable, as would an Emacs in which none of those invariants were
maintained cross-thread. What we'll need for multithreading is some sort
of transactional-memory scheme where Lisp in separate threads sees no
change to the state of Emacs from other threads until it (exits|returns
to the command loop|executes some special thread-yield function), and
even then the only changes it should see are those that have been done
in other threads that have reached the same point.

-- 
NULL && (void)