emacs-devel
[Top][All Lists]
Advanced

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

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


From: João Távora
Subject: Re: [mentoring-done] a darkroom/writeroom mode for Emacs
Date: Mon, 15 Dec 2014 22:10:29 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (darwin)

martin rudalics <address@hidden> writes:

>> Yes I got it: I can collect pixelwise statistics about the line
>> lengths and then use window width. (with one problem I can circumvent:
>> window-width does not count *existing* margins).
>
> You can always get the margins of a window via (window-margins).
> Multiply the result with (frame-char-width) and you get the pixels
> (beware of a nil return value).

That works too. I temporarily set margins to (0 . 0) then restore them.
>
>> But to do comparisons with column based variables like `fill-column',
>
> `fill-column' might be a problem, indeed.  Do you really need it?

Yes. Well, I guess. I estimate if "most" columns are filled to this
column, and if so set the window margins according to this length.

>> I
>> still need the character (assumed fixed) pixel width, which I need to
>> extract like this.
>>
>>    (window-text-pixel-size (selected-window)
>>                            (point-min) (1+ (point-min)))
>
> This will fail miserably with variable character widths.

I'm aware of that, the centering algorithm assumes fixed widths.

>> The code is much cleaner now, so thanks.
>>
>> Anyway, its a bit confusing that `window-width' can't take the font size
>> in consideration, while `window-text-pixel-size' can.
>
> It can't.  Nobody can, so far ... Eli might fix this eventually.
>> Though it probably
>> makes sense since a window can display chars of many widths. But then
>> using it without PIXELWISE should be deprecated.
>
> For a human being it's easier to think in terms of columns rather than
> in pixels.

I agree. But the contract for the new/fixed function must state that the
column value returned is only valid for one particular character width,
presumably the "main" size.

>> It might *become* its intent, if you wish to explain what you had in
>> mind.
>
> I only thought that if you add/remove characters to/from the longest
> line you might also consider recentering the entire text on the fly.

Oh, that's interesting indeed (and not tremendously hard to do.)

João



reply via email to

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