Re: New package `typewriter.el'

Enrico Flor <[email protected]> Mon, 31 Aug 2026 12:45:32 -0400
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Hi,

Attached is the new minor mode version.
As for the name, I really have no
preference (although I'm still partial
to "typewriter-mode").  I'm fine with
anything.  Suggestions in the thread so
far:

+ strict-type-mode
+ insert-only-mode
+ insert-at-eob-mode

Summary of changes (all meant to address
Philip's recommendations):

+ Commentary section made shorter
+ Removed redundand :groups tags
+ variable types from integer to natnum
  whenever appropriate
+ removed typewriter-silent and the
  --ding wrapper
+ used substitute-command-keys in
  docstring
+ Removed all (let ((message-log-max
  nil)) .. ) wrappers
+ no more dedicated commands for
  quitting the mode
+ the mode now saves the values of a
  bunch of buffer-local variables (the
  ones stored in
  `typewriter--overridden-variables')
  and restores them when quit
+ the temporary lifting of
  inhibit-read-only is now done simply
  by dedicated -self-insert and -newline
  command that typewriter-mode-map
  remaps the standard ones to
+ with the switch to minor-mode, the
  optional character counter is now
  appended to mode-line-misc-info

Enrico



Philip Kaludercic <[email protected]>
writes:

> Enrico Flor <[email protected]> writes:
>
>>> 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?
>
> Ah OK I didn't immediately understand this.  I think it would be good to
> check if inhibit-read-only was already enabled and ensure that you don't
> set it to a fixed value, but try to restore the previous value.  You can
> use another buffer local variable to that end.  Also, it would be good
> to add a comment that explains this in the source code, because the
> connection to the other parts of the code are not obvious in isolation.
>
>>>>> 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.
>
> OK, just ping this thread when you are ready.  I think there were also a
> few other suggestions for the package name that could be interesting, so
> it makes sense to wait with adding the package for now.  If you have any
> further questions about what I wrote or just need a second opinion, feel
> free to shoot me or the mailing list a message :)
>
>> Enrico
signature.asc (application/pgp-signature, 857 B)
typewriter.el (application/emacs-lisp, 12.8 KB) - not displayed