emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rasmus
Subject: Re: [mentoring] a darkroom/writeroom mode for Emacs
Date: Fri, 12 Dec 2014 13:09:27 +0100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.51 (gnu/linux)

Hi,

address@hidden (João Távora) writes:
>> 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.
>
> 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.

>> 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
>
> Is the image provided in the screenshot resized? What did you expect the
> image to be?

Only cropped.  I expect the margins to be less wide.  Here's a comparison
between my normal view (right) and darkroom-view.  I use visual-line /and/
auto-fill.  When disabling visual-line-mode the margins are the same, but
I have to scroll left to see the whole line.

  http://i.imgur.com/ayvHqAW.png

The correct margin would (guesstimating) be somewhere between 0 and 2
characters here...

>>     "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):
>
> We may be miscommunicating. I'm not checking for `auto-fill-mode'
> anywhere. In `darkroom-guess-margins', I'm looking at statistics for the
> real line lengths and estimating if the paragraphs are (mostly) filled
> to `fill-column', be it with manual `fill-paragraph' or `auto-fill-mode'
> maybe.
>
> The intent of `darkroom-guess-margins' is then to choose suitable
> margins to center on the window (not necessarily the "screen" or the
> "frame"), without truncation, what it thinks are the main parts of your
> text, possibly truncating (or adding "continuation lines") on any
> spurious or exceptionally long lines.

OK.  Makes sense.  I think we have different problems in mind.  You are
talking of margin-width for centering-purposes, I'm talking of
margin-width to minimize annoyance (see below).

> This it does iff visual-line-mode is inactive. If it is active, it just
> assumes that you want 0.15 (or `darkroom-margins-if-failed-guess'). It
> also uses 0.15 if the guessing somehow "fails".

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).

> Well, I'm not following your algorithm (though I admit I didn't try
> super hard). Best would be to create fixture files that we know should
> produce a certain correct behaviour. So, if I send you this very
> paragraph, and run `darkroom-guess-margins' in a window that is 100
> columns long (assuming `window-width' now knows afound font size), I
> should (at least I want to) get left and right margins of 15 columns
> each. So I could place this text in a file called
> "darkroom-fixture-a-100-15-15.txt" and use that in an automated
> test. Can you provide me with
> "darkroom-fixture-<b-z>-<window-width>-<lmargin>-<rmargin>.txt" so I can
> understand what kind of margin calculations you are talking about?

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.

> Anyway this review (also tellingly) got very sidetracked into the
> implementation details. 

I don't understand the 'tellingly' here.

> 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.

I have been working on a bug/patch for Org, but I'll look more into this
area of your code once I've tested that patch more.

I'll try to find time to go over it in the weekend and try to solve my
pet-grief as explained above (unless you bet me to it!).

> Then others that others can chime in about the implementation
> (Stefan has already been doing so).

I think they can already do so.  But everybody has got their own
constrains and issues to solve.  In general, I think the 'peer-review'
might be better in the sense that top-contributors may already have enough
on their plate as it is.

It also comes down to interest in the reviewed code.

However, the discussion aspect might be one place where GNU provides a
more compelling environment than the Github (I don't really use GH so I'm
guessing here).

—Rasmus

-- 
There are known knowns; there are things we know that we know




reply via email to

[Prev in Thread] Current Thread [Next in Thread]