[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
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, (continued)
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, Stefan Monnier, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, martin rudalics, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, João Távora, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, martin rudalics, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, João Távora, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs, martin rudalics, 2014/12/15
- Re: [mentoring-done] a darkroom/writeroom mode for Emacs,
João Távora <=
- RE: [mentoring] a darkroom/writeroom mode for Emacs, Drew Adams, 2014/12/12
- Re: [mentoring] a darkroom/writeroom mode for Emacs, Stefan Monnier, 2014/12/12
- Re: [mentoring] a darkroom/writeroom mode for Emacs, Phillip Lord, 2014/12/09
- [mentor-request] Ecco - a literate programming documentation generator, João Távora, 2014/12/08
- Results of the "mentoring" experiment Re: Metaproblem, part 3, João Távora, 2014/12/21
- Re: Results of the "mentoring" experiment Re: Metaproblem, part 3, Rasmus, 2014/12/21
- Re: Results of the "mentoring" experiment, Stephen Leake, 2014/12/22
- Re: Results of the "mentoring" experiment, João Távora, 2014/12/22
- Re: Results of the "mentoring" experiment, João Távora, 2014/12/22
- Re: Metaproblem, part 3, Phillip Lord, 2014/12/05