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: João Távora
Subject: Re: [mentoring] a darkroom/writeroom mode for Emacs
Date: Fri, 12 Dec 2014 11:16:24 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (darwin)

Rasmus <address@hidden> 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.

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

I don't think one can, at least with "custom themes". I think "color
themes" used to provide that possibility, so the needed functionality
should be in Emacs. Perhaps someone wants to open that can of worms.

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

Can you provide a specific example?

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

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

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

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

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?

I can then create automated tests from this with ert-deftest.

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

If we later find that we disagree in the heuristic, we can provide two
and let the user decide which one he wants.

Anyway I have a big thinko in darkroom.el. Window margins must be
calculated by window, not by buffer, because they're a property of
windows. I'm fixing that first.

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

Iberian peninsula is big and has many weather types. The coldest it gets
in portugal is about +5c for about a month, so unless you're rich and
enjoy tshirting in the winter and think global warming is a cool new
club, you don't have heating and pine for the summer. I'm just lazy to
get a blanket.

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

Sorry, but play along. Though I'll include this factor in the mentoring
conclusions, perhaps "[peer review]" would make a better tag.

Anyway this review (also tellingly) got very sidetracked into the
implementation details. 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've
already cloned the repo and have a reasonable idea how to commit
it. Then others that others can chime in about the implementation
(Stefan has already been doing so).

J



reply via email to

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