Re: New package `typewriter.el'

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