Re: [mentoring-done] a darkroom/writeroom mode for Emacs

[joaotavora@gmail.com (João Távora)]

Hi List,

After some iterations with Rasmus, I have cleaned up darkroom.el library
of its most obvious problems and now consider it ready to push to
ELPA.git (as was suggested) if no-one objects.

The library lives in https://github.com/capitaomorte/darkroom if someone
is interesting in double checking or commenting.

The library still has an outstanding problem with "window-width", which
I have solved with an isolated hack. See the docstring for
`darkroom--real-window-width' for an explanation.

João

Rasmus <rasmus@gmx.us> writes:

>> I going to say this is a bug in `variable-pitch-mode', since I read
>> somewhere (Stefan?) that a minor mode should always turn itself *on* when
>> called with a nil argument, precisely to support use cases such as
>> yours.
> Perhaps, the correct name would be `toggle-variable-pitch-mode'.  Which is
> what is needed here.

I don't know if that would help you much, with just the minor-mode
hook. Saving the buffer's state and restoring is not trivial. Darkroom
implements it for the variables in the (internal)
`darkroom--saved-variables', but anything more complicated one has to
implement `darkroom-mode-hook' with some sophistication. This hook is
run when entering or leaving the minor mode.

> IMO this is wrong (but I guess what all other similar modes does as well).
> It should choose margin so that the realized line with is approximately
> the same as the real line width or so that the difference is as small as
> possible.  This matters for small windows.  So, to center you need the
> window geometry.  To choose the width, IMO, you need to look at the
> difference between line width (be it visual or not) and realized width (in
> the same of visual-line-mode).

> As above, margin should /not/ be fixed a priori.  Rather, (and IMO) they
> should be set to not be intrusive given the text.  Then centered.  what I
> want is maybe too complicated, but I think it would be nice.

I still don't understand, but I suspect it's related to your intent to
use variable pitch with darkroom-mode. In that scenario, indeed, the
concepts of "real line length" and "visual line length" start to make a
little sense to me, more or less. Also your idea of recursiveness. I'll
welcome an implementation for a "guess margins" function when you have
the time.

>> Anyway this review (also tellingly) got very sidetracked into the
>> implementation details. 
>
> I don't understand the 'tellingly' here.

In the context of the "mentoring" experiment, it's "telling" that this
discussion, initially supposed to be a relatively isolated, well-defined
and expedite step for cleaning up the proposed change in compliance with
Emacs procedures, quickly entered into the implementation details. It
"tells" me that maybe that separation may be too ambitious, at least
given the current awareness of the original "mentoring" intention. But
it's certainly not "your fault" or anything like that, it's just the way
it went.

>> Can I assume you are more or less happy with the procedural and cosmetic
>> aspects of darkroom.el that the "mentoring" part is over? Then I might
>> officially propose darkroom.el to elpa.git.n I'v already cloned the repo
>> and have a reasonable idea how to commit it.
>
> As you prefer.  Updates in ELPA are cheap.  Just change the version number
> and push.

As far as I understand it, this is the strategy to develop the upstream
on Github and publish to ELPA.git periodically. I will "git merge
--no-commit" my github repo into ELPA.git. Then issue whatever necessary
"git mv" I have to to place "darkroom.el" and any other files in the
correct place. Then commit with a suitable commit message. The following
updates also use "git merge --no commit".

> It also comes down to interest in the reviewed code.

Yes. I also suspected it, and I'll include this factor in my quick
debriefing of the "mentoring" experiment.