Re: New package `typewriter.el'

Enrico Flor <[email protected]> Thu, 20 Aug 2026 23:13:43 -0400
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
> How sever is this flooding?  The Messages buffer already has some
> duplication.  I would generally advise to not be too clever with things
> like these, in case the user has customizations use the Messages buffer.

Fair point.  You've convinced me.

> [...]
>
>>> Can you explain why you do this?
>>
>> You mean instead of simply
>>
>>   (setq-local inhibit-read-only nil)
>>   
>> ?  I actually don't remember but it would do the same thing.  If it's
>> preferable, I have no issue.
>
> No, I meant as in why are you setting inhibit-read-only to nil at all.
> Are you ensuring that it is nil, or are you deactivating something set
> somewhere else.
>

Oh, this is in the "post-command"
function, and it's because the major
mode sets buffer-read-only to t, and the
"pre-command" function, when insertion
is licit, sets inhibit-read-only to t.
So this is to restore the read only
state.  I thought this was the cleanest
way of enforcing the general ban on any
buffer modification that has only very
narrow exceptions.  Is this bad design?

>>> This is my main gripe, why is this a major mode and not a minor mode?
>>> And as a major mode, why does it inherit from fundamental-mode and not
>>> text-mode?
>>
>> Hah, I pondered this too actually.  I landed on the major mode for a
>> few reasons.  This mode imposes really fundamental restrictions on
>> things.  I don't see why someone would use activate this while working
>> on an org-mode buffer, or latex-mode, let along any of the prog-modes.
>> It doesn't really provide any supplementary feature, it's more a
>> radical zero-features state.
>
> What about text-mode?  Or something for a lightweight language like
> markdown-mode?  Generally it is good to assume an open-world model: you
> don't know much about the Emacs that will load this file, or what other
> packages, hooks, minor modes, etc. the user has installed for their
> particular workflow.  Reducing assumptions, including things like "I
> don't know why someone would do this" is one such example.  But this is
> just personal advice, opinions might differ.
>
>> And this is also, in part, why fundamental mode.  The typewriter is so
>> "dumb" that it has no use for text-specific syntax tables, awareness
>> about paragraphs, and stuff like that.  I just thought it was simpler
>> to have no default to "undo"?  But you'll note that text-mode is where
>> the user will be if they want to quit the mode and do some editing on
>> the text they wrote, because of course they will be treating the
>> buffer content as text.
>
> It seems like an orthogonal concern.  If the user really wants to keep
> it dumb, they can use fundamental-mode, but I don't see why this had to
> be a package-deal.  Also, major modes are fundamentally for the type of
> file you are dealing with, while minor modes are supposed to provide
> "well defined" modifications to the base behavior.
>

Ok, you're making a convincing case.
I'll think about it and come back with
all your suggestions implemented,
including the switch to minor mode.

Enrico
signature.asc (application/pgp-signature, 857 B)