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

[Rasmus]

address@hidden (João Távora) writes:

>> This paragraph is not clear and potentially tautologous.
>
> The opening tautology is necessary to diffentiate it from
> `darkroom-tentative-mode'. I wonder what else is not clear, but I have
> rewritten it.

It's better now.

This is how I use it BTW:

(autoload 'darkroom-mode "darkroom" nil t)
(when (fboundp 'darkroom-mode) (global-set-key [f6] 'darkroom-mode))

(with-eval-after-load 'darkroom
  (setq darkroom-text-scale-increase 3)
  (add-hook 'darkroom-mode-hook 'variable-pitch-mode))

This also shows the problem with the hook that I spoke of earlier.  If I
for some reason have variable-pitch-mode enabled I will get disabled.  Of
course, I could just make a more sophisticated λ testing the value of
darkroom-mode.  So probably just stick with the default hook.

Changing theme could be another possibility, though I'm not sure one can
load a theme for single buffer...

>>>   ;;; FIXME: broken when darkroom-text-scale-increase is anything but
>>>   ;;; 0, since window-width ignores text scaling. Otherwise, a
>>>   ;;; suitable default to put in `darkroom-margins', I guess.
>>
>> You can estimate the realized width rolling over some lines and measure.
>> Probably there's a more appropriate way of doing it.  
>>
>> (save-excursion (- (progn (end-of-visual-line) (point))
>>                    (progn (beginning-of-visual-line) (point))))
>>
>> Note, for understanding this you might get some insights from studying
>> `line-move' and `line-move-visual' (I don't know).
>
> It helped. I dealt with the FIXME with the ultra-horrible
> `darkroom--real-window-width'. It fixes `window-width' basically. Seems
> to work. The above won't work because I need to know about window
> geometry, not line geometry. Unless there's a very big line. And that's
> how `darkroom--real-window-width' hacks it.

OK.  I must have mixed up the intention of this logic.  I will recheck
this at the moment.


Dogfooding you code, I find that the margin adjustment (still?) does not
work well on small screens when font-size is increased.  And font-size
increase is pretty central, IMO.

Screenshot from 2014-12-11 18:58:51.png
Description: PNG image

In the screenshot I have Emacs take up half of my screen (1440x900).  As
you can see, for this setting the margin is way to big.  This is using the
standard setting.  So the heuristic is not very good.  You write

    "If the buffer's paragraphs are mostly filled to `fill-column',
     margins should center it on the window, otherwise, margins of 0.15 percent
     are used."

When you have at least auto-fill, the objective should be something like
this I guess (I didn't think carefully about it):

(*)  Margin* = argmin  abs{real-line-with - shown-line-width(margin; font-size)}

where ";" reads "given" or "for fixed".  Maybe with some weight on margin
itself as well for aesthetic reasons (so + λ f(margin)).  In the
screenshot the margins are definitely too wide as it hinders a good
writing environment contrary to the objective.

I guess this is why I talk about the width of virtual lines (which are
functions of font-size and actual width).  Of course, the easiest way to
solve (*) is recursively.  I don't know if that works well with the
display engine, though.

I will go through `darkroom-guess-margins' again later.  I havne't got the
time right now.

>>>                 top-quartile-avg window-width))
>>>           (visual-line-mode 1))
>>>         0.15)
>>>        ((> top-quartile-avg (* 0.9 fill-column))
>>>         (let ((margin (round (/ (- window-width top-quartile-avg) 2))))
>>>           (cons margin margin)))
>>>        (t
>>>         0.15)))))
>>
>> I think you can simplify this and you should not hardcode .15.
>
> Ideas welcome, I didn't think much about the heuristic, this one worked
> ok. I fixed the hardcoding.

See discussion above.  IMO, this is not working well (but probably *also*
*not worse* than other packages with the same objective!).

>>> (defun darkroom-compute-margins ()
>> docstring, please.  What's the *idea* of this function.
>
> It's an internal function (what version of code were you looking
> at). It, well, computes margins. This is a big discusison, but while I
> very much sympathise with your thoroughness in documentation, docstrings
> should explain the "what" carefully avoiding the "how", so you can
> change that later. For internal functions, it might be a good idea to
> leave them out, rather than risk them getting out of date, or hindering
> others from redesigning your code. I know this from experience. Anyway,

What is what I call *idea*.  It's easier for me to read the current
*implementation* when I know what the *purpose/expected outcome*
of the function is.  We are arguing for the same thing, I think. 

>>> (defun darkroom-float-to-columns (f)
>>>   (ceiling (* (let ((edges (window-edges)))
>>>                 (- (nth 2 edges) (nth 0 edges)))
>>>               f)))
>>
>> (- (line-end-position) (line-beginning-position))
>
> No. Here I'm concerned with the window geometry, not the current line's
> geometry.

OK, I have to go back and understand why you care about window geometry.
I'm clearly missing part of the idea.

>>>   (let ((map (make-sparse-keymap)))
>>>     (define-key map (kbd "C-M-+") 'darkroom-increase-margins)
>>>     (define-key map (kbd "C-M--") 'darkroom-decrease-margins)
>>>     map))
>>
>> Ideally this should be unnecessary.  Maybe it should be called after
>> changing the font size or whatnot.
>
> Well, the user might want to tweak it for some reason. But yes,
> `darkroom--set-margins' should be called from more hooks.



>>>         (t
>>>          (setq mode-line-format darkroom-saved-mode-line-format
>>>                header-line-format darkroom-saved-header-line-format)
>>>          (text-scale-decrease darkroom-text-scale-increase)
>>
>> You need to actually record the size used before the mode is entered.  I
>> could increase the width after I enter darkroom.
>
> I started to implement this, then realized, maybe it needn't be so,
> because it works by increments. Did you try it?

It's a taste question then.  Enter darkroom increase font size n times.
Leave darkroom.  Now the font size is increased by n compared to when I
entered darkroom.  It could be a feature.  Another feature could "be what
happens in the dark room stays in the dark room".


I will comment more later.

—Rasmus

PS: 
>> Some comments follow.  I did it quickly (as you may notice), but it still
>> took 1½ South Park episodes.
>
> Which ones are you watching?

The two latest episodes.

>> Why the need for hardcoding?
>
> To make time for southpark. Also it's cold, typing hurts and naming
> variables is hard. I've fixed it.

It's getting colder, yes, and it's flabbergasting how Iberian[or at least
Catalonian(?)] houses do not have heating!

> to please my mentor, I added a docstring :-)

I find the title uncomfortable as it suggests I'd have greater insights,
which is probably (as in →ₐₛ) not the case; rather it's peer reviewing.

—Rasmus

-- 
Bang bang