Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Juanma Barranquero]

Before this change

> ------------------------------------------------------------
> revno: 103444
> committer: Chong Yidong <cyd@stupidchicken.com>
> branch nick: trunk
> timestamp: Sun 2011-02-27 18:53:41 -0500
> message:
>  * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).
> modified:
>  lisp/ChangeLog
>  lisp/facemenu.el

emacs -Q -f temp-buffer-resize-mode -f list-color-display

shows *Colors* in a window `temp-buffer-max-height' lines tall. After
the change, the buffer is `window-min-height' lines tall.

    Juanma

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > Before this change
 >
 >> ------------------------------------------------------------
 >> revno: 103444
 >> committer: Chong Yidong <cyd@stupidchicken.com>
 >> branch nick: trunk
 >> timestamp: Sun 2011-02-27 18:53:41 -0500
 >> message:
 >>  * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).
 >> modified:
 >>  lisp/ChangeLog
 >>  lisp/facemenu.el
 >
 > emacs -Q -f temp-buffer-resize-mode -f list-color-display
 >
 > shows *Colors* in a window `temp-buffer-max-height' lines tall. After
 > the change, the buffer is `window-min-height' lines tall.

What happens is that in the new code

   (with-help-window buffer-name
     (with-current-buffer standard-output
       (erase-buffer)
       (setq truncate-lines t)))
   (let ((buf (get-buffer buffer-name))
	(inhibit-read-only t))
     ;; Display buffer before generating content, to allow
     ;; `list-colors-print' to get the right window-width.
     (with-selected-window (or (get-buffer-window buf t) (selected-window))
       (with-current-buffer buf
	(list-colors-print list callback)
	(set-buffer-modified-p nil)))
     (when callback
       (pop-to-buffer buf)
       (message "Click on a color to select it."))))

`with-help-window' eventually ends up calling `fit-window-to-buffer'
which, since the buffer is still empty at that time, makes the window
`window-min-height' lines tall.  Unfortunately, we can't fill the buffer
_before_ calling `with-help-window' because, as the comment above
indicates, `list-colors-print' wants to know the width of the window
_before_ filling the buffer.

We could fix this, slightly hacky, by rewriting the last part as

     ;; Display buffer before generating content, to allow
     ;; `list-colors-print' to get the right window-width.
     (with-selected-window (or (get-buffer-window buf t) (selected-window))
       (with-current-buffer buf
	(list-colors-print list callback)
	(when temp-buffer-resize-mode
	  ;; Take real buffer size into account when
	  ;; `temp-buffer-resize-mode' is on.
	  (resize-temp-buffer-window))
	(set-buffer-modified-p nil)))

Note that binding `temp-buffer-resize-mode' around the call to
`with-help-window' won't help - we'd have to remove
`resize-temp-buffer-window' from `temp-buffer-show-hook' which doesn't
strike me as elegant either.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Juanma Barranquero]

On Mon, Feb 28, 2011 at 10:28, martin rudalics <rudalics@gmx.at> wrote:

> We could fix this, slightly hacky, by rewriting the last part as

Yeah, that obviously works.

> Note that binding `temp-buffer-resize-mode' around the call to
> `with-help-window' won't help - we'd have to remove
> `resize-temp-buffer-window' from `temp-buffer-show-hook' which doesn't
> strike me as elegant either.

That was my first thought too.

    Juanma

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

> What happens is that in the new code

>   (with-help-window buffer-name
>     (with-current-buffer standard-output
>       (erase-buffer)
>       (setq truncate-lines t)))
>   (let ((buf (get-buffer buffer-name))
> 	(inhibit-read-only t))
>     ;; Display buffer before generating content, to allow
>     ;; `list-colors-print' to get the right window-width.
>     (with-selected-window (or (get-buffer-window buf t) (selected-window))
>       (with-current-buffer buf
> 	(list-colors-print list callback)
> 	(set-buffer-modified-p nil)))
>     (when callback
>       (pop-to-buffer buf)
>       (message "Click on a color to select it."))))

The above should be changed so the whole code is surrounded by
with-help-window.

> Unfortunately, we can't fill the buffer _before_ calling
> `with-help-window' because, as the comment above indicates,
> `list-colors-print' wants to know the width of the window _before_
> filling the buffer.

That's a common need, so with-help-window should display the buffer
before running the code.

Of course, another way to look at it is that the buffer's content should
be independent from the window, and if it needs to be displayed
differently according to the window size, then this should be done
within the redisplay so that if that same buffer is displayed in several
windows, they all look "right".  But the current redisplay features
probably aren't sufficient for that.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > The above should be changed so the whole code is surrounded by
 > with-help-window.

That's easier said than done :-(

 >> Unfortunately, we can't fill the buffer _before_ calling
 >> `with-help-window' because, as the comment above indicates,
 >> `list-colors-print' wants to know the width of the window _before_
 >> filling the buffer.
 >
 > That's a common need, so with-help-window should display the buffer
 > before running the code.

Hmmm...  This means that either `with-help-window' can no longer rely on
`with-output-to-temp-buffer' or the latter has to be changed.  Neither
of these appear overly difficult but the interaction with
internal_with_output_to_temp_buffer would have to be examined.

And we should keep in mind the following: If the decision whether a
window for displaying the buffer can be split off from an existing
window should be based on the number of lines of the buffer, only the
current solution works.

So if you could provide some pointers wrt to the "common need" we might
be able to judge which approach is preferable.

 > Of course, another way to look at it is that the buffer's content should
 > be independent from the window, and if it needs to be displayed
 > differently according to the window size, then this should be done
 > within the redisplay so that if that same buffer is displayed in several
 > windows, they all look "right".  But the current redisplay features
 > probably aren't sufficient for that.

It's merely that code like `list-colors-print' would get confused.  We'd
have to run it for every window where the buffer is shown so an overlay
with a window property inserting the necessary amount of spaces would be
needed.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> Of course, another way to look at it is that the buffer's content should
>> be independent from the window, and if it needs to be displayed
>> differently according to the window size, then this should be done
>> within the redisplay so that if that same buffer is displayed in several
>> windows, they all look "right".  But the current redisplay features
>> probably aren't sufficient for that.
>
> It's merely that code like `list-colors-print' would get confused.  We'd
> have to run it for every window where the buffer is shown so an overlay
> with a window property inserting the necessary amount of spaces would be
> needed.

One possibility is to improve the redisplay engine to provide a way to
specify a stretch glyph that stretches as far as possible.  The logic
should be pretty similar to the implementation of word wrap, though I'm
not sure how it would interact with word wrap, or with bidirectional
display.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 28 Feb 2011 13:39:11 -0500
> Cc: Juanma Barranquero <lekktu@gmail.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> >> Of course, another way to look at it is that the buffer's content should
> >> be independent from the window, and if it needs to be displayed
> >> differently according to the window size, then this should be done
> >> within the redisplay so that if that same buffer is displayed in several
> >> windows, they all look "right".  But the current redisplay features
> >> probably aren't sufficient for that.
> >
> > It's merely that code like `list-colors-print' would get confused.  We'd
> > have to run it for every window where the buffer is shown so an overlay
> > with a window property inserting the necessary amount of spaces would be
> > needed.
> 
> One possibility is to improve the redisplay engine to provide a way to
> specify a stretch glyph that stretches as far as possible.

I'm not following your line of thought -- is this about aligning
display of text "nicely" for the current window width?  If so, why a
display property whose value is like `(space :align-to POS)' or maybe
`(space :width WIDTH)' will not do this job?  Its implementation in
the display engine is exactly to produce a stretch glyph.  You can
even use something like `(0.4 . text)' to mean 40% of the width of the
text area, see the node "Pixel Specifications" in the ELisp manual.

If these facilities don't fit the bill, can someone explain what is
missing?

> The logic should be pretty similar to the implementation of word
> wrap, though I'm not sure how it would interact with word wrap, or
> with bidirectional display.

Bidirectional display simply lays out characters for display in the
order that is different from the logical (a.k.a reading) order they
are stored in the buffer.  Bidirectional display doesn't care a bit
about other display features that are produced from something other
than text.  Or am I missing something?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> One possibility is to improve the redisplay engine to provide a way to
>> specify a stretch glyph that stretches as far as possible.
>
> I'm not following your line of thought -- is this about aligning
> display of text "nicely" for the current window width?  If so, why a
> display property whose value is like `(space :align-to POS)' or maybe
> `(space :width WIDTH)' will not do this job?

Because POS and WIDTH have to be specified.  I'm thinking of something
like `(space :width maximum)', i.e. a way to specify a stretch glyph
that's exactly wide enough to align the end of the current line with the
right edge of the text area.

Then the redisplay engine would be able to DTRT when the buffer is shown
in any window.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> I'm thinking of something like `(space :width maximum)', i.e. a way to
> specify a stretch glyph that's exactly wide enough to align the end of
> the current line with the right edge of the text area.

    (insert (propertize
             " " 'display
             '(space :align-to (- text 8))) "#123456")

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: rudalics@gmx.at, lekktu@gmail.com, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> Date: Mon, 28 Feb 2011 14:58:10 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> One possibility is to improve the redisplay engine to provide a way to
> >> specify a stretch glyph that stretches as far as possible.
> >
> > I'm not following your line of thought -- is this about aligning
> > display of text "nicely" for the current window width?  If so, why a
> > display property whose value is like `(space :align-to POS)' or maybe
> > `(space :width WIDTH)' will not do this job?
> 
> Because POS and WIDTH have to be specified.  I'm thinking of
> something like `(space :width maximum)', i.e. a way to specify a
> stretch glyph that's exactly wide enough to align the end of the
> current line with the right edge of the text area.

You can use `text' to mean the width of the text area, AFAIK.
Subtract the width of the text you want to display from it, and you
have your WIDTH.  Would that do the trick?

Alternatively, maybe `(space :align-to (- right-fringe 9))' will do
what you want?  (9 being the number of characters in "#XXXXXX " that
you want to end at the right margin.)

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Chong Yidong]

Johan Bockgård <bojohan@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> I'm thinking of something like `(space :width maximum)', i.e. a way to
>> specify a stretch glyph that's exactly wide enough to align the end of
>> the current line with the right edge of the text area.
>
>     (insert (propertize
>              " " 'display
>              '(space :align-to (- text 8))) "#123456")

Ah yes, I think this will work.  Thanks.

In the general case, the stuff after stretch glyph could have arbitrary
width, so this wouldn't work; but it's certainly good enough for what
list-colors-display needs.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

>> (insert (propertize
>> " " 'display
>> '(space :align-to (- text 8))) "#123456")

> Ah yes, I think this will work.  Thanks.

> In the general case, the stuff after stretch glyph could have arbitrary
> width, so this wouldn't work; but it's certainly good enough for what
> list-colors-display needs.

Won't work right for proportional fonts.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 >>> I'm thinking of something like `(space :width maximum)', i.e. a way to
 >>> specify a stretch glyph that's exactly wide enough to align the end of
 >>> the current line with the right edge of the text area.
 >>     (insert (propertize
 >>              " " 'display
 >>              '(space :align-to (- text 8))) "#123456")
 >
 > Ah yes, I think this will work.  Thanks.
 >
 > In the general case, the stuff after stretch glyph could have arbitrary
 > width, so this wouldn't work; but it's certainly good enough for what
 > list-colors-display needs.

But for one minor detail.  `list-colors-print' produces output of the
form

ghost white	       ghost white, GhostWhite               #f8f8ff

where the number of color aliases listed in the middle is currently
adjusted according to the actual window width.  If the window is wide
enough, more aliases are displayed.  So we'd still need to know the
width of the window _before_ filling the buffer in order to emulate the
old behavior faithfully (personally I don't think we should care much).

Maybe we could provide a display specificier, say "truncate", so we
could do something like

(insert (propertize string 'display '(truncate (- text 9))))

to assert that any such string never extends past the ninth column
before the end of the text area.

martin

RE: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Drew Adams]

> `list-colors-print' produces output of the form
> ghost white	       ghost white, GhostWhite               #f8f8ff
> where the number of color aliases listed in the middle is currently
> adjusted according to the actual window width.  If the window is wide
> enough, more aliases are displayed.  So we'd still need to know the
> width of the window _before_ filling the buffer in order to 
> emulate the old behavior faithfully (personally I don't think we should 
> care much).
> 
> Maybe we could provide a display specificier, say "truncate", so we
> could do something like
> (insert (propertize string 'display '(truncate (- text 9))))
> to assert that any such string never extends past the ninth column
> before the end of the text area.

IIUC what the intention is, it assumes that the user wants to fit the buffer to
the window and not vice versa.  In my case (dedicated window in a separate
frame), I do not want the buffer display to expand to fill the window.  Instead,
I want it to remain as compact as practical, and I then fit the frame to the
buffer.

Since there can be different user preferences and use cases, can you please
provide for those too when designing such a change (e.g. for the default case)?
IOW, let's not just assume that the window size is to be fixed and
predetermined, and that the buffer text should be fit to that window size.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > IIUC what the intention is, it assumes that the user wants to fit the buffer to
 > the window and not vice versa.  In my case (dedicated window in a separate
 > frame), I do not want the buffer display to expand to fill the window.  Instead,
 > I want it to remain as compact as practical, and I then fit the frame to the
 > buffer.

We are talking about `with-output-to-temp-buffer' based macros here
which (1) erase the buffer, (2) fill it (in the body) with some text,
and (3) call `display-buffer'.  If you "fit the frame to the buffer" in
a separate fourth step, nothing would change for the particular case you
describe.  However, if you do something like

(let ((special-display-buffer-names special-display-buffer-names))
   (with-help-window buffer
     (with-current-buffer buffer
       (insert text)
       (setq special-display-buffer-names ...))))

and specify the frame's height for `special-display-buffer-names' from
the height of the buffer, things would change.  But you can still resize
the frame in a separate step.  The more annoying problem is how to
constrain the window splitting behavior.  Currently you can write

(let ((split-height-threshold split-height-threshold))
   (with-help-window buffer
     (with-current-buffer buffer
       (insert text)
       (setq split-height-threshold
	    (* (count-lines (point-min) (point-max)) 2)))))

thus modulating the window splitting behavior of `display-buffer'.  If
we display the buffer _before_ filling it, you can't do such things any
more.

 > Since there can be different user preferences and use cases, can you please
 > provide for those too when designing such a change (e.g. for the default case)?
 > IOW, let's not just assume that the window size is to be fixed and
 > predetermined, and that the buffer text should be fit to that window size.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 28 Feb 2011 23:53:04 -0500
> Cc: emacs-devel@gnu.org
> 
> >> (insert (propertize
> >> " " 'display
> >> '(space :align-to (- text 8))) "#123456")
> 
> > Ah yes, I think this will work.  Thanks.
> 
> > In the general case, the stuff after stretch glyph could have arbitrary
> > width, so this wouldn't work; but it's certainly good enough for what
> > list-colors-display needs.
> 
> Won't work right for proportional fonts.

Would it help to have a primitive that returns the width in pixels
that a given buffer substring would take on the screen?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> Date: Tue, 01 Mar 2011 10:47:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  >>     (insert (propertize
>  >>              " " 'display
>  >>              '(space :align-to (- text 8))) "#123456")
>  >
>  > Ah yes, I think this will work.  Thanks.
>  >
>  > In the general case, the stuff after stretch glyph could have arbitrary
>  > width, so this wouldn't work; but it's certainly good enough for what
>  > list-colors-display needs.
> 
> But for one minor detail.  `list-colors-print' produces output of the
> form
> 
> ghost white	       ghost white, GhostWhite               #f8f8ff
> 
> where the number of color aliases listed in the middle is currently
> adjusted according to the actual window width.  If the window is wide
> enough, more aliases are displayed.  So we'd still need to know the
> width of the window _before_ filling the buffer in order to emulate the
> old behavior faithfully (personally I don't think we should care much).

Couldn't you try adding more aliases until the gap between the color
name on the left and the first alias in the middle is small enough?
You could use current-column to measure the gap.  Would that work?

> Maybe we could provide a display specificier, say "truncate", so we
> could do something like
> 
> (insert (propertize string 'display '(truncate (- text 9))))
> 
> to assert that any such string never extends past the ninth column
> before the end of the text area.

But that's not what we want here.  We don't want to truncate, we want
to insert text that fits without truncation.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> But for one minor detail.  `list-colors-print' produces output of the
>> form
>>
>> ghost white	       ghost white, GhostWhite               #f8f8ff
>>
>> where the number of color aliases listed in the middle is currently
>> adjusted according to the actual window width.
>
> Couldn't you try adding more aliases until the gap between the color
> name on the left and the first alias in the middle is small enough?
> You could use current-column to measure the gap.  Would that work?

Are you referring to checking current-column using Lisp code in the
display spec?  (Remember, we don't know what's the limiting column when
generating the buffer; we only find out at redisplay time.)  I don't
think it's a good idea to make the color names anything but ordinary
text.  I would just discard the "fitting aliases" feature, if it's too
much work to implement properly (it's new to the trunk anyway).

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> (insert (propertize
>>> " " 'display
>>> '(space :align-to (- text 8))) "#123456")
>
>> Ah yes, I think this will work.  Thanks.
>
>> In the general case, the stuff after stretch glyph could have arbitrary
>> width, so this wouldn't work; but it's certainly good enough for what
>> list-colors-display needs.
>
> Won't work right for proportional fonts.

If we give it an extra character worth of whitespace, it ought to work
for most :-P

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
> Date: Tue, 01 Mar 2011 16:42:55 -0500
> 
> >> But for one minor detail.  `list-colors-print' produces output of the
> >> form
> >>
> >> ghost white	       ghost white, GhostWhite               #f8f8ff
> >>
> >> where the number of color aliases listed in the middle is currently
> >> adjusted according to the actual window width.
> >
> > Couldn't you try adding more aliases until the gap between the color
> > name on the left and the first alias in the middle is small enough?
> > You could use current-column to measure the gap.  Would that work?
> 
> Are you referring to checking current-column using Lisp code in the
> display spec?

Not in the display spec, just current-column.

> (Remember, we don't know what's the limiting column when
> generating the buffer; we only find out at redisplay time.)

AFAIK, current-column and indent-to-column work without displaying as
well.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Juanma Barranquero]

On Tue, Mar 1, 2011 at 22:42, Chong Yidong <cyd@stupidchicken.com> wrote:

> I would just discard the "fitting aliases" feature, if it's too
> much work to implement properly (it's new to the trunk anyway).

Give just one color name, and put all the aliases in a tooltip.

    Juanma

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > Would it help to have a primitive that returns the width in pixels
 > that a given buffer substring would take on the screen?

Not really.  But in general, a primitive that returned the displayed
pixel height/width of a substring of any buffer line for some given
window would be great.  Actually, it would be nice if redisplay could
cache these values on demand for each line it (virtually) displayed.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > Couldn't you try adding more aliases until the gap between the color
 > name on the left and the first alias in the middle is small enough?
 > You could use current-column to measure the gap.  Would that work?

The current algorithm already does something along these lines.  It's
just that it has to know the width of the window first.

 >> Maybe we could provide a display specificier, say "truncate", so we
 >> could do something like
 >>
 >> (insert (propertize string 'display '(truncate (- text 9))))
 >>
 >> to assert that any such string never extends past the ninth column
 >> before the end of the text area.
 >
 > But that's not what we want here.  We don't want to truncate, we want
 > to insert text that fits without truncation.

If the text doesn't fit, we have to truncate anyway.  But if we were
able to adjust rigid text (that is, truncate-lines equals t text) during
redisplay we'd be able to selectively display more important parts of a
text when the window is narrow and the entire text when the window is
wide.  This would also allow to implement line numbers for rigid text.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 >> I would just discard the "fitting aliases" feature, if it's too
 >> much work to implement properly (it's new to the trunk anyway).
 >
 > Give just one color name, and put all the aliases in a tooltip.

You're collectively throwing out this child with the bathwater.  IIUC
the aliases are (also) supposed to fill the empty space between color
names and values for wide windows.  Hence I think we should simply call
`fit-window-to-buffer' another time when temporary buffers shall be
resized ;-)

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 >> (Remember, we don't know what's the limiting column when
 >> generating the buffer; we only find out at redisplay time.)
 >
 > AFAIK, current-column and indent-to-column work without displaying as
 > well.

... but not when there's nothing to display.  `list-colors-print' wants
to know the width of the window before putting something in the buffer.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

> Would it help to have a primitive that returns the width in pixels
> that a given buffer substring would take on the screen?

Not if we want it to work without knowing the window (and hence
terminal) on which the buffer is going to be displayed (i.e. the
computation should be done by the redisplay, the buffer data needs to be
agnostic to the font used).


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> Date: Wed, 02 Mar 2011 09:09:33 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, cyd@stupidchicken.com, 
>  emacs-devel@gnu.org
> 
>  > Would it help to have a primitive that returns the width in pixels
>  > that a given buffer substring would take on the screen?
> 
> Not really.

Why not?  Especially since you go one explaining why it _would_ be
helpful ;-)

> But in general, a primitive that returned the displayed pixel
> height/width of a substring of any buffer line for some given window
> would be great.

What's a window got to do with this?  How can a window affect display
of a buffer substring?

> Actually, it would be nice if redisplay could cache these values on
> demand for each line it (virtually) displayed.

What for?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  emacs-devel@gnu.org
> Date: Wed, 02 Mar 2011 12:03:18 -0500
> 
> > Would it help to have a primitive that returns the width in pixels
> > that a given buffer substring would take on the screen?
> 
> Not if we want it to work without knowing the window (and hence
> terminal) on which the buffer is going to be displayed (i.e. the
> computation should be done by the redisplay, the buffer data needs to be
> agnostic to the font used).

Sorry, I'm not following.

On a TTY, each character is a single pixel and all characters have the
same width.  So calculating this for a TTY display is trivial.

On a GUI display, the calculation cannot be easily done in Lisp,
without actually displaying the text, but should be fairly easy to
implement in C, using the move_it_* family of functions; they are
already used internally by redisplay, precisely for these purposes: to
traverse glyphs generated for display without actually displaying
them.  Font information (and everything else that is pertinent to
displaying text) is already present in the buffer and the associated
data structures (faces, text properties, overlays, etc.).  What the
window's got to do with this, I'm unclear; perhaps I'm missing
something.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 >>  > Would it help to have a primitive that returns the width in pixels
 >>  > that a given buffer substring would take on the screen?
 >>
 >> Not really.
 >
 > Why not?  Especially since you go one explaining why it _would_ be
 > helpful ;-)

I meant it would not help in the case at hand.  It would be helpful in
many other cases ;-)

 >> But in general, a primitive that returned the displayed pixel
 >> height/width of a substring of any buffer line for some given window
 >> would be great.
 >
 > What's a window got to do with this?  How can a window affect display
 > of a buffer substring?

What I meant was the size in pixel of the displayed text.  If we have an
overlay with a window property plus other text properties - suppose
someone wants to look at the plain buffer text in one window and the
same text outlined or magnified in another window - then we might get
different displayed sizes for the same "buffer substring".

 >> Actually, it would be nice if redisplay could cache these values on
 >> demand for each line it (virtually) displayed.
 >
 > What for?

Because redisplay is costly and running such a function can amount to
doing a redisplay.  If I had such a function, I could synchronize the
text of two side-by-side windows in the presence of characters of
different heights.  This would be useful for side-by-side displayed
diff-windows or for showing line numbers in a side window.  In such
cases a cache would avoid to run what is essentially the same function
twice over the entire text displayed in a window.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Tom Tromey]

>>>>> "martin" == martin rudalics <rudalics@gmx.at> writes:

>> Would it help to have a primitive that returns the width in pixels
>> that a given buffer substring would take on the screen?

martin> Not really.  But in general, a primitive that returned the displayed
martin> pixel height/width of a substring of any buffer line for some given
martin> window would be great.  Actually, it would be nice if redisplay could
martin> cache these values on demand for each line it (virtually) displayed.

FWIW, for my scenario it would be sufficient if this was doable in a
display property.

For my presentation program, I would like to be able to center some
text.  I'd like to do this in the display spec, so that I don't have to
write code to do anything special if, say, the user changes the font or
the text, or resizes the frame, during the presentation.

I don't think this is doable today.  One way would be to allow a string
in a pixel specification, and take that to mean the pixel width of the
string using the font/etc of the propertized character.

That is:

    (insert (propertize " " 'display '(space (- center (0.5 . "the text"))))
            "the text")

Tom

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > > Unfortunately, we can't fill the buffer _before_ calling
 > > `with-help-window' because, as the comment above indicates,
 > > `list-colors-print' wants to know the width of the window _before_
 > > filling the buffer.

 > That's a common need, so with-help-window should display the buffer
 > before running the code.

Suppose we rewrote `with-output-to-temp-buffer' in Elisp then we would
probably come up with something like the following code:

      (let ((standard-output buffer))
        (setq value (progn ,@body)))

      (with-current-buffer buffer
        (set-buffer-modified-p nil)
        (goto-char (point-min)))

      (if (functionp temp-buffer-show-function)
	 (funcall temp-buffer-show-function buffer)
        (let ((window (display-buffer buffer)))
	 (when window
	   ;; Temporarily select window (and implicitly make the buffer
	   ;; current).
	   (with-selected-window window
	     (setq minibuffer-scroll-window window)
	     (set-window-start window (point-min))
	     (set-window-point window (point))
	     (run-hooks 'temp-buffer-show-hook)))))

      ;; Return last value of BODY.
      value))

If we now wanted to display the buffer _before_ evaluating BODY, we'd
have to splice in the evaluation into `temp-buffer-show-function'.  I
don't have the slightest idea how this could be reasonably done :-(

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > For my presentation program, I would like to be able to center some
 > text.  I'd like to do this in the display spec, so that I don't have to
 > write code to do anything special if, say, the user changes the font or
 > the text, or resizes the frame, during the presentation.
 >
 > I don't think this is doable today.  One way would be to allow a string
 > in a pixel specification, and take that to mean the pixel width of the
 > string using the font/etc of the propertized character.
 >
 > That is:
 >
 >     (insert (propertize " " 'display '(space (- center (0.5 . "the text"))))
 >             "the text")

This seems hardly practical.  What would happen when the window must be
scrolled to bring `point' back to it?  How would you show a buffer
containing such a specification in two windows?

You should be able to visualize the effect by putting a marker on that
text and adding a `recenter' call with `point' temporarily set to that
marker in your `post-command-hook'.

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

> Suppose we rewrote `with-output-to-temp-buffer' in Elisp then we would

Find below the definition of with-output-to-temp-buffer on the
lexbind branch (which BTW is getting pretty close to ready for
inclusion).


        Stefan


(defmacro with-output-to-temp-buffer (bufname &rest body)
  "Bind `standard-output' to buffer BUFNAME, eval BODY, then show that buffer.

This construct makes buffer BUFNAME empty before running BODY.
It does not make the buffer current for BODY.
Instead it binds `standard-output' to that buffer, so that output
generated with `prin1' and similar functions in BODY goes into
the buffer.

At the end of BODY, this marks buffer BUFNAME unmodifed and displays
it in a window, but does not select it.  The normal way to do this is
by calling `display-buffer', then running `temp-buffer-show-hook'.
However, if `temp-buffer-show-function' is non-nil, it calls that
function instead (and does not run `temp-buffer-show-hook').  The
function gets one argument, the buffer to display.

The return value of `with-output-to-temp-buffer' is the value of the
last form in BODY.  If BODY does not finish normally, the buffer
BUFNAME is not displayed.

This runs the hook `temp-buffer-setup-hook' before BODY,
with the buffer BUFNAME temporarily current.  It runs the hook
`temp-buffer-show-hook' after displaying buffer BUFNAME, with that
buffer temporarily current, and the window that was used to display it
temporarily selected.  But it doesn't run `temp-buffer-show-hook'
if it uses `temp-buffer-show-function'."
  (let ((old-dir (make-symbol "old-dir"))
        (buf (make-symbol "buf")))
    `(let ((,old-dir default-directory))
       (with-current-buffer (get-buffer-create ,bufname)
         (kill-all-local-variables)
         ;; FIXME: delete_all_overlays
         (setq default-directory ,old-dir)
         (setq buffer-read-only nil)
         (setq buffer-file-name nil)
         (setq buffer-undo-list t)
         (let ((,buf (current-buffer)))
           (let ((inhibit-read-only t)
                 (inhibit-modification-hooks t))
             (erase-buffer)
             (run-hooks 'temp-buffer-setup-hook))
           (let ((standard-output ,buf))
             (prog1 (progn ,@body)
               (internal-temp-output-buffer-show ,buf))))))))

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > Find below the definition of with-output-to-temp-buffer on the
 > lexbind branch (which BTW is getting pretty close to ready for
 > inclusion).

The problem is with `internal-temp-output-buffer-show' which you did not
include.  `temp-buffer-show-function' would have to

(1) display the empty buffer,

(2) run BODY, and

(3) mark the buffer as unmodified, run `temp-buffer-show-hook' ...

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

> The problem is with `internal-temp-output-buffer-show' which you did not
> include.  `temp-buffer-show-function' would have to

As I said, it's in the lexbind branch.
It's actually written in C, i.e. it's just the Lisp-export of the
temp_output_buffer_show function.  The reason for the change was to
reduce the number of special forms (currently defun and defmacro are
still special forms, tho :-().


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

 > As I said, it's in the lexbind branch.
 > It's actually written in C, i.e. it's just the Lisp-export of the
 > temp_output_buffer_show function.  The reason for the change was to
 > reduce the number of special forms (currently defun and defmacro are
 > still special forms, tho :-().

Sorry I must be missing something.  The temp_output_buffer_show in
window.c of the lexbind-new branch is the same as in the trunk.  It
can't deal with the problem that evaluating BODY should be spliced in
between (1) displaying the buffer and (2) marking the buffer as
unmodified and running `temp-buffer-show-hook' from a user-defined
`temp-buffer-show-function' :-(

martin

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[Stefan Monnier]

>> As I said, it's in the lexbind branch.
>> It's actually written in C, i.e. it's just the Lisp-export of the
>> temp_output_buffer_show function.  The reason for the change was to
>> reduce the number of special forms (currently defun and defmacro are
>> still special forms, tho :-().

> Sorry I must be missing something.  The temp_output_buffer_show in
> window.c of the lexbind-new branch is the same as in the trunk.  It
> can't deal with the problem that evaluating BODY should be spliced in
> between (1) displaying the buffer and (2) marking the buffer as
> unmodified and running `temp-buffer-show-hook' from a user-defined
> `temp-buffer-show-function' :-(

Indeed, the lexbind branch is not meant to solve those problems, I just
turned the special form into a macro, preserving all the (mis)behavior
as best as I could.  I just pointed out that that branch (which should
be merged soon) has already started to move with-output-to-temp-buffer
to Elisp, so we don't get conflicting changes on this front.


        Stefan