bug#18195: 24.3.92; window-screen-lines is not accurate

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry]

If I have line-spacing set, the value the above function returns is
smaller than the actuall number of screen lines the window can contain.

For example, when I have the current Emacs frame maximized and
line-spacing set to 0.2, (window-screen-lines) returns 46.66(6), whereas
there are 48 fully-visible lines in the given window and one
partially-visible one.

Here's my default font:

  (set-face-attribute 'default nil :height 105 :family "Fira Mono")

Related:
http://lists.gnu.org/archive/html/help-gnu-emacs/2014-08/msg00026.html

In GNU Emacs 24.3.92.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-07-24 on axl
Repository revision: 117398 stephen.berman@gmx.net-20140722213204-51v7bp0chfei6wbx
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > If I have line-spacing set, the value the above function returns is
 > smaller than the actuall number of screen lines the window can contain.
 >
 > For example, when I have the current Emacs frame maximized and
 > line-spacing set to 0.2, (window-screen-lines) returns 46.66(6), whereas
 > there are 48 fully-visible lines in the given window and one
 > partially-visible one.
 >
 > Here's my default font:
 >
 >    (set-face-attribute 'default nil :height 105 :family "Fira Mono")
 >
 > Related:
 > http://lists.gnu.org/archive/html/help-gnu-emacs/2014-08/msg00026.html

IIUC

https://github.com/company-mode/company-mode/issues/160#issuecomment-51022508

mentioned in that thread, all you want is to display all lines of a
completion buffer.  Is that correct?  If so, then why can't/don't you
use `fit-window-to-buffer'?

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/05/2014 12:38 PM, martin rudalics wrote:
> IIUC
>
> https://github.com/company-mode/company-mode/issues/160#issuecomment-51022508
>
> mentioned in that thread, all you want is to display all lines of a
> completion buffer.  Is that correct?

Not at all. Have you tried Company?

This issue is about completion popup, which displays completions in the 
current buffer and window, in a rectangle rendered using an overlay. 
There are screenshots in that issue thread.

Before the popup is rendered, we need to determine how much of it would 
fit below the current line, and if there's not enough space, we render 
it above the current line.

Even if the buffer is shorter than the window, we can temporarily pad 
it, so when calculating the height of the window, we need to take the 
whole of it into account. That's why `count-screen-line' doesn't seem 
like a good approach either.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > Have you tried Company?

No.

 > This issue is about completion popup, which displays completions in the current buffer and window, in a rectangle rendered using an overlay. There are screenshots in that issue thread.
 >
 > Before the popup is rendered, we need to determine how much of it would fit below the current line, and if there's not enough space, we render it above the current line.

Aha... Could you try whether `window-text-pixel-size' could be used for
that?  IIUC you'd have to call it twice: Once for calculating how much
space you need and once for how much space is left below the current
line.  `window-text-height' with PIXELWISE t should give you the overall
height of the window.

 > Even if the buffer is shorter than the window, we can temporarily pad it, so when calculating the height of the window, we need to take the whole of it into account. That's why `count-screen-line' doesn't seem like a good approach either.

If things like line spacing are involved you really should calculate
pixelwise.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/05/2014 02:16 PM, martin rudalics wrote:

> Aha... Could you try whether `window-text-pixel-size' could be used for
> that?

It won't help to determine how much space is left below the current line 
if the current line is the last in the buffer but not in the window, right?

 > `window-text-height' with PIXELWISE t should give you the overall
 > height of the window.

`count-screen-lines' already helps with "space above the current line", 
and we can find out the total height of the window in pixels. So if I'm 
going to do the arithmetics myself, the one thing missing is the 
accurate value of the height of a line in the buffer.

How do I obtain it (let's consider it mostly-constant)?

> If things like line spacing are involved you really should calculate
> pixelwise.

The docstring of `window-screen-lines' seems to claim that it's 
suitable. The implementation looks kinda right, too, but the result it 
returns is not accurate.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > It won't help to determine how much space is left below the current line if the current line is the last in the buffer but not in the window, right?

You have to calculate the height of the text from window start till the
end of the buffer and subtract the result from the window's text height.

 >  > `window-text-height' with PIXELWISE t should give you the overall
 >  > height of the window.
 >
 > `count-screen-lines' already helps with "space above the current line", and we can find out the total height of the window in pixels. So if I'm going to do the arithmetics myself, the one thing missing is the accurate value of the height of a line in the buffer.

`count-screen-lines' doesn't return a pixel value.  How do you get that
with lines of different heights and line spacing?

 > How do I obtain it (let's consider it mostly-constant)?
 >
 >> If things like line spacing are involved you really should calculate
 >> pixelwise.
 >
 > The docstring of `window-screen-lines' seems to claim that it's suitable. The implementation looks kinda right, too, but the result it returns is not accurate.

It again just returns a line value.  IIRC someone has set the font size
to 1 pixel to make this return something reasonable.  But why do all
these acrobatics?  `window-text-pixel-size' should give you everything
you need in a uniform way.  And if something's missing we can easily add
it.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/05/2014 04:20 PM, martin rudalics wrote:
>  > It won't help to determine how much space is left below the current
> line if the current line is the last in the buffer but not in the
> window, right?
>
> You have to calculate the height of the text from window start till the
> end of the buffer and subtract the result from the window's text height.

Suppose I do that. When do I convert any of the resulting values to 
number of lines?

Please remember, we're using an overlay for popup rendering. Overlays 
work with lines of text.

> `count-screen-lines' doesn't return a pixel value.  How do you get that
> with lines of different heights and line spacing?

As above, we really don't need a pixel value in the end result. If the 
overlay is made to span over lines with different heights and lines 
spacing, we can either make it follow all those dimensions, or override 
them to the same values.

But while we can do that, ignoring the global value of line-spacing 
wouldn't be comfortable for users that have it set.

> It again just returns a line value.  IIRC someone has set the font size
> to 1 pixel to make this return something reasonable.  But why do all
> these acrobatics?  `window-text-pixel-size' should give you everything
> you need in a uniform way.  And if something's missing we can easily add
> it.

See above.

By the way, `window-screen-lines' not being accurate doesn't seem to be 
directly caused by pixel-perfect positioning. If I copy the necessary 
definitions (the 3 new function) to Emacs 24.3, it exhibits the same 
problem.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >>  > It won't help to determine how much space is left below the current
 >> line if the current line is the last in the buffer but not in the
 >> window, right?
 >>
 >> You have to calculate the height of the text from window start till the
 >> end of the buffer and subtract the result from the window's text height.
 >
 > Suppose I do that. When do I convert any of the resulting values to number of lines?

IIUC you want to check whether some text of pixel height O would fit
into the rest of a window with pixel height W when the upper part of
that window is occupied by text with pixel height T.  So if O <= W - T
holds, you can put the overlay below the current line, and do something
else otherwise.  Why would you ever want to convert a resulting value to
a number of lines?

 > Please remember, we're using an overlay for popup rendering. Overlays work with lines of text.

Overlays don't know about newlines.  I suppose the overlay starts at the
beginning of some line after text T and has as many characters as there
are in the text with height O.  If you want to cover any text with the
overlay do that.

 >> `count-screen-lines' doesn't return a pixel value.  How do you get that
 >> with lines of different heights and line spacing?
 >
 > As above, we really don't need a pixel value in the end result. If the overlay is made to span over lines with different heights and lines spacing, we can either make it follow all those dimensions, or override them to the same values.
 >
 > But while we can do that, ignoring the global value of line-spacing wouldn't be comfortable for users that have it set.

IIUC you neither need pixels nor lines in the end result.  You just want
to know whether a given overlay fits into a given window at a given
position.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 15:50:34 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> IIUC you want to check whether some text of pixel height O would fit
> into the rest of a window with pixel height W when the upper part of
> that window is occupied by text with pixel height T.

There's currently no way to determine the pixel height of arbitrary
text string from Lisp, without actually displaying it in some window.
So there's no way to know the value of O, except in some simple
scenarios.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/05/2014 05:50 PM, martin rudalics wrote:

> Overlays don't know about newlines.

We're using a multiline overlay: it both spans several lines, and its 
`before-string' property contains a multiline string when it's "on".

> I suppose the overlay starts at the
> beginning of some line after text T and has as many characters as there
> are in the text with height O.  If you want to cover any text with the
> overlay do that.

Sorry, I don't understand.

> IIUC you neither need pixels nor lines in the end result.  You just want
> to know whether a given overlay fits into a given window at a given
> position.

We don't have the overlay at that point in time yet: when it's created, 
it's constructed using the underlying buffer text, too.

Being able to just show a rectangle would require some dedicated API, 
like Eli mentioned.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >> Overlays don't know about newlines.
 >
 > We're using a multiline overlay: it both spans several lines, and its `before-string' property contains a multiline string when it's "on".

Still, an Emacs overlay is a display object that replaces a possibly
empty buffer string with a possibly empty string.  Any of these strings
can contain newlines but the overlay is specified only by the buffer
positions and the replacement string.

 >> IIUC you neither need pixels nor lines in the end result.  You just want
 >> to know whether a given overlay fits into a given window at a given
 >> position.
 >
 > We don't have the overlay at that point in time yet: when it's created, it's constructed using the underlying buffer text, too.

But you have the underlying buffer text at the time you create the
overlay I suppose.  So what hinders you to get the size of the overlay
by using a temporary buffer, inserting the underlying buffer text, put
the overlay there, and calculate the resulting height?

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 17:05:20 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> If the overlay is made to span over lines with different heights and
> lines spacing, we can either make it follow all those dimensions, or
> override them to the same values.

No, you can't do that.  Unless an overlay entirely obscures a screen
line, it can never make the line height smaller, only larger.

Besides, even if you could do what you hint here, that would cause
unpleasant effects on display, whereby the text would jump up and down
when the overlay is popped up/down.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 14:20:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > The docstring of `window-screen-lines' seems to claim that it's suitable. The implementation looks kinda right, too, but the result it returns is not accurate.
> 
> It again just returns a line value.

But that value is a floating-point number, so accuracy is not lost.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

> But that value is a floating-point number, so accuracy is not lost.

Text displayed may be of completely different height.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 16:08:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
> > But that value is a floating-point number, so accuracy is not lost.
> 
> Text displayed may be of completely different height.

Of course.  But that's of no importance for window-screen-lines,
because its contract is to count lines in units of the height of the
font used by the default face.

The fact that the metrics of the default face is used is the reason
why I wrote that this is a slippery slope, see my other message.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 14:24:59 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> `count-screen-lines' already helps with "space above the current line", 
> and we can find out the total height of the window in pixels.

How do you convert the line count returned by count-screen-lines into
pixels, if the lines are of non-constant height.

Also note the caveats in the doc string of that function: the value is
not 100% reliable.

> So if I'm going to do the arithmetics myself, the one thing missing
> is the accurate value of the height of a line in the buffer.

Line of what font?

> The docstring of `window-screen-lines' seems to claim that it's 
> suitable. The implementation looks kinda right, too, but the result it 
> returns is not accurate.

It is accurate now.  But, as I wrote elsewhere in this thread, that
will only solve some of your problems.  In general, we don't support
layout of arbitrary text from Lisp.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 12:16:40 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> If things like line spacing are involved you really should calculate
> pixelwise.

He can't: we currently don't expose enough information for Lisp
programs to perform layout.  E.g., the metrics of glyphs and lines
that use arbitrary fonts and display images are not easily available
on the Lisp level, and neither are dimensions and line counts of
arbitrary regions of the screen (although you could write some clunky
Lisp to do the latter).  Likewise with dimensions of text in overlays
and display properties, and with images.

This was never supposed to be needed, and thus was never designed and
implemented.  If we want to allow such jobs from Lisp, we need to
close these gaps.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > He can't: we currently don't expose enough information for Lisp
 > programs to perform layout.  E.g., the metrics of glyphs and lines
 > that use arbitrary fonts and display images are not easily available
 > on the Lisp level, and neither are dimensions and line counts of
 > arbitrary regions of the screen (although you could write some clunky
 > Lisp to do the latter).  Likewise with dimensions of text in overlays
 > and display properties, and with images.
 >
 > This was never supposed to be needed, and thus was never designed and
 > implemented.  If we want to allow such jobs from Lisp, we need to
 > close these gaps.

Why would `window-text-pixel-size' fail to provide that?  It might be a
bit clumsy to work with because you have to temporarily show another
buffer in its window but apart from that I see no problems ...

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 15:57:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > He can't: we currently don't expose enough information for Lisp
>  > programs to perform layout.  E.g., the metrics of glyphs and lines
>  > that use arbitrary fonts and display images are not easily available
>  > on the Lisp level, and neither are dimensions and line counts of
>  > arbitrary regions of the screen (although you could write some clunky
>  > Lisp to do the latter).  Likewise with dimensions of text in overlays
>  > and display properties, and with images.
>  >
>  > This was never supposed to be needed, and thus was never designed and
>  > implemented.  If we want to allow such jobs from Lisp, we need to
>  > close these gaps.
> 
> Why would `window-text-pixel-size' fail to provide that?

Because there's no way of calculating the pixel size of arbitrary text
(in this case: the list of completion candidates to be popped up
overlaid on the buffer text), except if that text is displayed in some
window.

> It might be a bit clumsy to work with because you have to
> temporarily show another buffer in its window

That _is_ the problem.  Momentarily flashing some text in some window
is not my idea of a good application.  It simply looks like a bug.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >> It might be a bit clumsy to work with because you have to
 >> temporarily show another buffer in its window
 >
 > That _is_ the problem.  Momentarily flashing some text in some window
 > is not my idea of a good application.  It simply looks like a bug.

Well, nobody asked for such a feature so far.  Can you fix it so it
simply works on the current buffer instead of the window's buffer?

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 16:12:53 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  >> It might be a bit clumsy to work with because you have to
>  >> temporarily show another buffer in its window
>  >
>  > That _is_ the problem.  Momentarily flashing some text in some window
>  > is not my idea of a good application.  It simply looks like a bug.
> 
> Well, nobody asked for such a feature so far.  Can you fix it so it
> simply works on the current buffer instead of the window's buffer?

Fix what exactly?  What is "it" in this context?

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >>   >> It might be a bit clumsy to work with because you have to
 >>   >> temporarily show another buffer in its window
 >>   >
 >>   > That _is_ the problem.  Momentarily flashing some text in some window
 >>   > is not my idea of a good application.  It simply looks like a bug.
 >>
 >> Well, nobody asked for such a feature so far.  Can you fix it so it
 >> simply works on the current buffer instead of the window's buffer?
 >
 > Fix what exactly?  What is "it" in this context?

`window-text-pixel-size'.  Never mind.  I'll find a fix.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 16:38:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  >> Can you fix it so it simply works on the current buffer instead
>  >> of the window's buffer?
>  >
>  > Fix what exactly?  What is "it" in this context?
> 
> `window-text-pixel-size'.  Never mind.  I'll find a fix.

You'll need to designate a window anyway, since layout is impossible
without knowing in which window it will be done.

There's also the issue of the buffer text on which the text will be
overlaid: the dimensions of the screen lines to be (partially)
overlaid affect the pixel dimensions of the overlaying text.  So if
the buffer text uses different fonts, the text overlaid on it will
have different dimensions than the same text when displayed in its own
buffer.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 4267 bytes --]

 > You'll need to designate a window anyway, since layout is impossible
 > without knowing in which window it will be done.

`window-text-pixel-size' works on any life window, by default the
selected.

 > There's also the issue of the buffer text on which the text will be
 > overlaid: the dimensions of the screen lines to be (partially)
 > overlaid affect the pixel dimensions of the overlaying text.  So if
 > the buffer text uses different fonts, the text overlaid on it will
 > have different dimensions than the same text when displayed in its own
 > buffer.

This would have to be done on the Lisp level by selecting some font
before calculating the size of the overlay.  But I have problems with
the attached patch.  If I invoke `window-text-pixel-size' with a
different buffer than that displayed in the window I get an arguments
out of range error.  Any ideas?

martin

A backtrace goes as follows:

#0  args_out_of_range (a1=..., a2=...) at data.c:217
#1  0x011eadda in validate_interval_range (object=..., begin=0x82b310, end=0x82b310, force=false) at textprop.c:182
#2  0x011ec8a4 in Ftext_properties_at (position=..., object=...) at textprop.c:601
#3  0x011ec931 in Fget_text_property (position=..., prop=..., object=...) at textprop.c:621
#4  0x010f5806 in face_at_buffer_position (w=0x17b8bf8, pos=82, endptr=0x82b438, limit=182, mouse=0, base_face_id=0) at xfaces.c:5976
#5  0x0102eb20 in handle_face_prop (it=0x82e180) at xdisp.c:3923
#6  0x0102db70 in handle_stop (it=0x82e180) at xdisp.c:3427
#7  0x0103a40c in next_element_from_buffer (it=0x82e180) at xdisp.c:8242
#8  0x01036f16 in get_next_display_element (it=0x82e180) at xdisp.c:6874
#9  0x0103aec6 in move_it_in_display_line_to (it=0x82e180, to_charpos=311, to_x=-1, op=MOVE_TO_POS) at xdisp.c:8582
#10 0x0103d080 in move_it_to (it=0x82e180, to_charpos=311, to_x=-1, to_y=-1, to_vpos=-1, op=10) at xdisp.c:9149
#11 0x0103ec0d in Fwindow_text_pixel_size (window=..., from=..., to=..., x_limit=..., y_limit=..., mode_and_header_line=..., buffer=...) at xdisp.c:9833
#12 0x0118d7f5 in eval_sub (form=...) at eval.c:2202
#13 0x0118cf36 in Feval (form=..., lexical=...) at eval.c:1996
#14 0x0118e9e6 in Ffuncall (nargs=3, args=0x82ebdc) at eval.c:2811
#15 0x011d01d6 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82ef10) at bytecode.c:918
#16 0x0118f18c in funcall_lambda (fun=..., nargs=1, arg_vector=0x82ef0c) at eval.c:2976
#17 0x0118ebde in Ffuncall (nargs=2, args=0x82ef08) at eval.c:2857
#18 0x011d01d6 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f33c) at bytecode.c:918
#19 0x0118f18c in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f338) at eval.c:2976
#20 0x0118ebde in Ffuncall (nargs=2, args=0x82f334) at eval.c:2857
#21 0x01186548 in Ffuncall_interactively (nargs=2, args=0x82f334) at callint.c:270
#22 0x0118e8ac in Ffuncall (nargs=3, args=0x82f330) at eval.c:2789
#23 0x01188170 in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:872
#24 0x0118ea15 in Ffuncall (nargs=4, args=0x82f54c) at eval.c:2815
#25 0x011d01d6 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f894) at bytecode.c:918
#26 0x0118f18c in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f890) at eval.c:2976
#27 0x0118ebde in Ffuncall (nargs=2, args=0x82f88c) at eval.c:2857
#28 0x0118e4a5 in call1 (fn=..., arg1=...) at eval.c:2607
#29 0x010ffcee in command_loop_1 () at keyboard.c:1545
#30 0x0118b92a in internal_condition_case (bfun=0x10ff67c <command_loop_1>, handlers=..., hfun=0x10feee7 <cmd_error>) at eval.c:1347
#31 0x010ff332 in command_loop_2 (ignore=...) at keyboard.c:1169
#32 0x0118aede in internal_catch (tag=..., func=0x10ff30e <command_loop_2>, arg=...) at eval.c:1111
#33 0x010ff2ec in command_loop () at keyboard.c:1148
#34 0x010fea83 in recursive_edit_1 () at keyboard.c:769
#35 0x010fec40 in Frecursive_edit () at keyboard.c:840
#36 0x010fcdaf in main (argc=1, argv=0xa327e8) at emacs.c:1650

Lisp Backtrace:
"window-text-pixel-size" (0x82ea80)
"eval" (0x82ebe0)
"eval-last-sexp-1" (0x82ef0c)
"eval-last-sexp" (0x82f338)
"funcall-interactively" (0x82f334)
"call-interactively" (0x82f550)
"command-execute" (0x82f890)

[-- Attachment #2: window-text-pixel-size.diff --]
[-- Type: text/plain, Size: 2497 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2014-08-01 13:10:07 +0000
+++ src/xdisp.c	2014-08-05 15:28:23 +0000
@@ -9713,7 +9713,7 @@
 	  && it->dpvec + it->current.dpvec_index != it->dpend);
 }

-DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pixel_size, 0, 6, 0,
+DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pixel_size, 0, 7, 0,
        doc: /* Return the size of the text of WINDOW's buffer in pixels.
 WINDOW must be a live window and defaults to the selected one.  The
 return value is a cons of the maximum pixel-width of any text line and
@@ -9746,9 +9746,13 @@
 include the height of the mode- or header-line of WINDOW in the return
 value.  If it is either the symbol `mode-line' or `header-line', include
 only the height of that line, if present, in the return value.  If t,
-include the height of both, if present, in the return value.  */)
+include the height of both, if present, in the return value.
+
+Optional argument BUFFER, if non-nil, means to work on another buffer
+than that displayed in WINDOW.  If BUFFER denotes a live buffer, use
+that buffer.  If BUFFER equals t, use the current buffer.  */)
   (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_limit, Lisp_Object y_limit,
-   Lisp_Object mode_and_header_line)
+   Lisp_Object mode_and_header_line, Lisp_Object buffer)
 {
   struct window *w = decode_live_window (window);
   Lisp_Object buf;
@@ -9760,14 +9764,25 @@
   void *itdata = NULL;
   int c, max_y = -1, x = 0, y = 0;

-  buf = w->contents;
-  CHECK_BUFFER (buf);
-  b = XBUFFER (buf);
-
-  if (b != current_buffer)
+  if (!EQ (buffer, Qt))
     {
-      old_buffer = current_buffer;
-      set_buffer_internal (b);
+      if (NILP (buffer))
+	{
+	  buf = w->contents;
+	  CHECK_BUFFER (buf);
+	  b = XBUFFER (buf);
+	}
+      else
+	{
+	  CHECK_BUFFER (buffer);
+	  b = XBUFFER (buffer);
+	}
+
+      if (b != current_buffer)
+	{
+	  old_buffer = current_buffer;
+	  set_buffer_internal (b);
+	}
     }

   if (NILP (from))
@@ -15814,6 +15829,17 @@
 	 left.  */
       whole = max (whole, w->hscroll + box_width);
       whole = max (whole, end - start);
+      if (it.bidi_p)
+	{
+	  Lisp_Object pdir;
+
+	  pdir = Fcurrent_bidi_paragraph_direction (Qnil);
+	  if (EQ (pdir, Qright_to_left))
+	    {
+	      end = whole - w->hscroll * FRAME_COLUMN_WIDTH (WINDOW_XFRAME (w));
+	      start = end - box_width;
+	    }
+	}

       if (old_buffer)
 	set_buffer_internal (old_buffer);

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 17:45:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > There's also the issue of the buffer text on which the text will be
>  > overlaid: the dimensions of the screen lines to be (partially)
>  > overlaid affect the pixel dimensions of the overlaying text.  So if
>  > the buffer text uses different fonts, the text overlaid on it will
>  > have different dimensions than the same text when displayed in its own
>  > buffer.
> 
> This would have to be done on the Lisp level by selecting some font
> before calculating the size of the overlay.

Which font would you select?  I'm talking about a situation where the
text over which the candidate list will be popped uses several
different fonts, and so each line of the buffer text has a different
height.

> But I have problems with the attached patch.  If I invoke
> `window-text-pixel-size' with a different buffer than that displayed
> in the window I get an arguments out of range error.  Any ideas?

You switched the current buffer, but not the buffer pointed to by
w->contents.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >> This would have to be done on the Lisp level by selecting some font
 >> before calculating the size of the overlay.
 >
 > Which font would you select?  I'm talking about a situation where the
 > text over which the candidate list will be popped uses several
 > different fonts, and so each line of the buffer text has a different
 > height.

I would pop up that list in a temporary buffer and run
`window-text-pixel-size' over it.

 >> But I have problems with the attached patch.  If I invoke
 >> `window-text-pixel-size' with a different buffer than that displayed
 >> in the window I get an arguments out of range error.  Any ideas?
 >
 > You switched the current buffer, but not the buffer pointed to by
 > w->contents.

That was the problem, indeed.

Thanks, martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 11:41:26 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
> >> This would have to be done on the Lisp level by selecting some font
> >> before calculating the size of the overlay.
> >
> > Which font would you select?

You didn't answer this question.  The only trivial answer is the font
of the default face, a choice which has the problems described below.

> > I'm talking about a situation where the text over which the
> > candidate list will be popped uses several different fonts, and so
> > each line of the buffer text has a different height.
> 
> I would pop up that list in a temporary buffer and run
> `window-text-pixel-size' over it.

And therein lies the problem.  You will get the size of the text under
the assumption that the text will be displayed using a single font,
the one used by the frame's 'default' face.  But if the text in the
region over which you will pop the candidate list uses a different
font, or shows images on some of the lines, the pixel height needed to
display the popped list will be different.  That's because the
candidates are displayed by Company by putting overlays on consecutive
lines of text, each overlay showing one candidate.  However,
displaying such overlays in the middle of a line of buffer text cannot
decrease the height of the line, it can only increase it.  Therefore,
if the line of buffer text was taller than what is required for the
default face's font, the displayed overlay string will take up more
pixels than what you measured in the temporary buffer.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 06:39 PM, Eli Zaretskii wrote:

> That's because the
> candidates are displayed by Company by putting overlays on consecutive
> lines of text, each overlay showing one candidate.

Not really. We have a pull request that changes the code to do what 
you're describing, but for the moment we only use one overlay at a time.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 18:41:21 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18195@debbugs.gnu.org
> 
> On 08/06/2014 06:39 PM, Eli Zaretskii wrote:
> 
> > That's because the
> > candidates are displayed by Company by putting overlays on consecutive
> > lines of text, each overlay showing one candidate.
> 
> Not really. We have a pull request that changes the code to do what 
> you're describing, but for the moment we only use one overlay at a time.

I'm talking about a kind of menu of candidates, which definitely takes
more than one line.  That cannot be done with a single overlay, unless
you copy the buffer text into the overlay string, and completely cover
the buffer text itself.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 08:23 PM, Eli Zaretskii wrote:

>> Not really. We have a pull request that changes the code to do what
>> you're describing, but for the moment we only use one overlay at a time.
>
> I'm talking about a kind of menu of candidates, which definitely takes
> more than one line.  That cannot be done with a single overlay, unless
> you copy the buffer text into the overlay string, and completely cover
> the buffer text itself.

Indeed, that's what we do currently.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 20:26:44 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> On 08/06/2014 08:23 PM, Eli Zaretskii wrote:
> 
> >> Not really. We have a pull request that changes the code to do what
> >> you're describing, but for the moment we only use one overlay at a time.
> >
> > I'm talking about a kind of menu of candidates, which definitely takes
> > more than one line.  That cannot be done with a single overlay, unless
> > you copy the buffer text into the overlay string, and completely cover
> > the buffer text itself.
> 
> Indeed, that's what we do currently.

But that will break if the buffer text has other display properties,
because Emacs doesn't support display strings on display strings.
IOW, this solution only works for relatively simple text in the
buffer.

And what do you do with line-prefix and wrap-prefix?

That's really crazy design (no offense)!

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 09:24 PM, Eli Zaretskii wrote:

> But that will break if the buffer text has other display properties,
> because Emacs doesn't support display strings on display strings.
> IOW, this solution only works for relatively simple text in the
> buffer.

Multiple overlays aren't much easier to work with: you can't position 
them in the middle of a piece of text that's on `display' property, 
can't position them after the end of the buffer or overlapping the 
`line-prefix' value. And if the desired column is in the middle of a 
multiple-width character like \t, you're forced to do unnatural things 
with it anyway.

> And what do you do with line-prefix and wrap-prefix?

The former is incorporated into the "replaced" text and set to "" on the 
overlay; the latter, so far, has been ignored.

> That's really crazy design (no offense)!

I didn't design it personally, just fixed some corner cases. But it has 
its advantages, see above. For example, otherwise I'm having hard time 
imagining what to do if the target column is inside the line-prefix.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 22:02:51 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> On 08/06/2014 09:24 PM, Eli Zaretskii wrote:
> 
> > But that will break if the buffer text has other display properties,
> > because Emacs doesn't support display strings on display strings.
> > IOW, this solution only works for relatively simple text in the
> > buffer.
> 
> Multiple overlays aren't much easier to work with: you can't position 
> them in the middle of a piece of text that's on `display' property, 

But you could copy the display string into the overlay.

> can't position them after the end of the buffer

Yes, you can: you can include newlines in the overlay string.

> or overlapping the `line-prefix' value.

Why do you need that?  No buffer text will ever appear in the prefix,
so your drop-down list doesn't need to invade the prefix area, because
it is aligned with some buffer text.

> And if the desired column is in the middle of a multiple-width
> character like \t, you're forced to do unnatural things with it
> anyway.

Yes, which is why I asked why not use tooltips and text-mode menus
instead.  AFAICT, they solve all those problems seamlessly.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 10:36 PM, Eli Zaretskii wrote:

>> Multiple overlays aren't much easier to work with: you can't position
>> them in the middle of a piece of text that's on `display' property,
>
> But you could copy the display string into the overlay.

I don't see how this could work with overlays that don't spread over 
multiple visual lines if the aforementioned text on `display' property 
is multiline.

Going back to one-overlay approach, this could work. But then, oh joy, 
instead of "go down 10 lines, collect them and add required pieces at 
between columns 5 and 20", I'll have to see if there's maybe a display 
property on line 3 that spans 15 lines, stop after it, include the 
display property in the text-to-be-replaced. Or, if the text with the 
`display' property starts before the supposed beginning of the overlay, 
I'll have to measure the place where to start replacing the lines 
from... somewhere. If there are multiple pieces of text with `display', 
all the merrier.

All of the above really sounds like a job for a display engine.

>> can't position them after the end of the buffer
>
> Yes, you can: you can include newlines in the overlay string.

Guess so. If another package tries the same with its own overlays, it'll 
be a mess, but here I'm going over into fantasy territory.

>> or overlapping the `line-prefix' value.
>
> Why do you need that?  No buffer text will ever appear in the prefix,
> so your drop-down list doesn't need to invade the prefix area, because
> it is aligned with some buffer text.

The prefixes can be different between lines. They also can be of 
different lengths. `org-indent-mode' is fairly popular, and it indents 
headings of different levels and their contents using `line-prefix'. 
This way, if the completion is initiated on the first column before the 
first header, the popup has to cover line-prefixes below. See 
https://github.com/company-mode/company-mode/issues/24.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >>>> This would have to be done on the Lisp level by selecting some font
 >>>> before calculating the size of the overlay.
 >>>
 >>> Which font would you select?
 >
 > You didn't answer this question.  The only trivial answer is the font
 > of the default face, a choice which has the problems described below.

I probably did no understand it.  I do not want to select any font.  The
application has to know which font the overlay should appear in.  If its
the font of the buffer where the overlay finally appears, it should take
this.  If it wants to use any other font, it should take that.

 >>> I'm talking about a situation where the text over which the
 >>> candidate list will be popped uses several different fonts, and so
 >>> each line of the buffer text has a different height.
 >>
 >> I would pop up that list in a temporary buffer and run
 >> `window-text-pixel-size' over it.
 >
 > And therein lies the problem.  You will get the size of the text under
 > the assumption that the text will be displayed using a single font,
 > the one used by the frame's 'default' face.  But if the text in the
 > region over which you will pop the candidate list uses a different
 > font, or shows images on some of the lines, the pixel height needed to
 > display the popped list will be different.  That's because the
 > candidates are displayed by Company by putting overlays on consecutive
 > lines of text, each overlay showing one candidate.  However,
 > displaying such overlays in the middle of a line of buffer text cannot
 > decrease the height of the line, it can only increase it.  Therefore,
 > if the line of buffer text was taller than what is required for the
 > default face's font, the displayed overlay string will take up more
 > pixels than what you measured in the temporary buffer.

But as I explained in my mail to Dmitry this is the problem of the
application.  Whatever it wants to do in the target window it has to
emulate in the temporary buffer: Put the original text there, apply any
font or property settings from the original buffer to that buffer, put
any overlays there, apply any font or property settings for the overlays
there, and have move_it_to get the overall height.  What am I missing?

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 18:15:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  >>>> This would have to be done on the Lisp level by selecting some font
>  >>>> before calculating the size of the overlay.
>  >>>
>  >>> Which font would you select?
>  >
>  > You didn't answer this question.  The only trivial answer is the font
>  > of the default face, a choice which has the problems described below.
> 
> I probably did no understand it.  I do not want to select any font.  The
> application has to know which font the overlay should appear in.

If the popped up text overlays existing buffer display, it should
ideally use the same fonts as the overlaid text uses.  But if that
overlaid text uses several different fonts, shadowing that in the
overlay is all but trivial.

> If its the font of the buffer where the overlay finally appears, it
> should take this.  If it wants to use any other font, it should take
> that.

I'm talking about "fonts", plural.  When the buffer text uses several
different fonts, selection of font for the overlay is complicated at
best.

>  >> I would pop up that list in a temporary buffer and run
>  >> `window-text-pixel-size' over it.
>  >
>  > And therein lies the problem.  You will get the size of the text under
>  > the assumption that the text will be displayed using a single font,
>  > the one used by the frame's 'default' face.  But if the text in the
>  > region over which you will pop the candidate list uses a different
>  > font, or shows images on some of the lines, the pixel height needed to
>  > display the popped list will be different.  That's because the
>  > candidates are displayed by Company by putting overlays on consecutive
>  > lines of text, each overlay showing one candidate.  However,
>  > displaying such overlays in the middle of a line of buffer text cannot
>  > decrease the height of the line, it can only increase it.  Therefore,
>  > if the line of buffer text was taller than what is required for the
>  > default face's font, the displayed overlay string will take up more
>  > pixels than what you measured in the temporary buffer.
> 
> But as I explained in my mail to Dmitry this is the problem of the
> application.  Whatever it wants to do in the target window it has to
> emulate in the temporary buffer: Put the original text there, apply any
> font or property settings from the original buffer to that buffer, put
> any overlays there, apply any font or property settings for the overlays
> there, and have move_it_to get the overall height.  What am I missing?

You are talking about things that are possible only on the C level,
not from Lisp.  My point was that we don't expose enough APIs to Lisp
to allow such applications, and you now agreed with me.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > You are talking about things that are possible only on the C level,
 > not from Lisp.  My point was that we don't expose enough APIs to Lisp
 > to allow such applications, and you now agreed with me.

I was over-complicating things.  The solution is much simpler and all
tools are already on board.  Dmitry just has to insert his overlays
where he wants them and run `window-text-pixel-size' over that window.
If the text including the overlays fits he's done.  Otherwise, he has to
remove the overlays and proceed with whatever alternate solution he has.
No hands needed.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 19:46:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > You are talking about things that are possible only on the C level,
>  > not from Lisp.  My point was that we don't expose enough APIs to Lisp
>  > to allow such applications, and you now agreed with me.
> 
> I was over-complicating things.  The solution is much simpler and all
> tools are already on board.  Dmitry just has to insert his overlays
> where he wants them and run `window-text-pixel-size' over that window.

I obviously fail to explain to you why this will not work in general.
Never mind.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > I obviously fail to explain to you why this will not work in general.
 > Never mind.

If by "in general" you mean that he won't be able to align his overlays
properly with varying font sizes, prefixes, line warping and the like if
he continues to use the original text, I obviously agree.

My point is that he can have a large overlay replace the original text
with the same text minus any unwanted side-effects introduced by text
properties, fonts, or other overlays.  Within that overlay he can then
additioanlly show whatever his original overlays were supposed to show.

Whether this is nice is a different issue.  But since he wants to draw
some text arbitrarily over some other text anyway, this sounds like a
neglible inconvenience to me.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Thu, 07 Aug 2014 17:08:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > I obviously fail to explain to you why this will not work in general.
>  > Never mind.
> 
> If by "in general" you mean that he won't be able to align his overlays
> properly with varying font sizes, prefixes, line warping and the like if
> he continues to use the original text, I obviously agree.

No, I mean that it is generally unreliable to measure the pixel
dimensions of some text in one buffer, then assume that the dimensions
will be the same when displayed as overlay in another buffer.  This is
only true when both buffers use the same single font and the same line
spacing; otherwise, it's simply false.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > No, I mean that it is generally unreliable to measure the pixel
 > dimensions of some text in one buffer, then assume that the dimensions
 > will be the same when displayed as overlay in another buffer.  This is
 > only true when both buffers use the same single font and the same line
 > spacing; otherwise, it's simply false.

There is no other buffer.  Everything is done in the buffer where the
overlay is supposed to appear.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Thu, 07 Aug 2014 17:39:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > No, I mean that it is generally unreliable to measure the pixel
>  > dimensions of some text in one buffer, then assume that the dimensions
>  > will be the same when displayed as overlay in another buffer.  This is
>  > only true when both buffers use the same single font and the same line
>  > spacing; otherwise, it's simply false.
> 
> There is no other buffer.  Everything is done in the buffer where the
> overlay is supposed to appear.

How do you prevent the overlay from momentarily flashing in the
window?

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 >> There is no other buffer.  Everything is done in the buffer where the
 >> overlay is supposed to appear.
 >
 > How do you prevent the overlay from momentarily flashing in the
 > window?

I'd instantaneously file a bug report.  Seriously, why should

(let ((overlay (make-overlay (point-min) (point-max))))
   (overlay-put overlay 'display "???????")
   (prog1
       (window-text-pixel-size)
     (delete-overlay overlay)))

cause a "momentarily flashing in the window"?

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Fri, 08 Aug 2014 10:41:13 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
> Seriously, why should
> 
> (let ((overlay (make-overlay (point-min) (point-max))))
>    (overlay-put overlay 'display "???????")
>    (prog1
>        (window-text-pixel-size)
>      (delete-overlay overlay)))
> 
> cause a "momentarily flashing in the window"?

It shouldn't.  But AFAIU, this is not what is wanted here, because the
problem is where in the buffer to put the overlay.  In the above
example, you put it at point-min, but that position needs to be
_computed_ based on the pixel-size of the text to be put in the
overlay.

IOW, your suggested solution is incomplete, unless you intend the
application to do some iterative process, each time changing the
position where it puts the overlay and adjusting it in the next
iteration based on the results of window-text-pixel-size.

bug#18195: 24.3.92; window-screen-lines is not accurate

[martin rudalics]

 > It shouldn't.  But AFAIU, this is not what is wanted here, because the
 > problem is where in the buffer to put the overlay.  In the above
 > example, you put it at point-min, but that position needs to be
 > _computed_ based on the pixel-size of the text to be put in the
 > overlay.

I'd put the overlay at the desired position right away and check whether
it fits (usually it should).  If it doesn't, I'd have to remove it and
put it somewhere else.  I can't imagine a solution where multiple
attempts could be avoided.  After all, one prior aim seems to be that a
certain line of the original text must not be covered by the overlay.
Hence, neither aligning the overlay at the bottom or top line of a
window seem to work always.

 > IOW, your suggested solution is incomplete, unless you intend the
 > application to do some iterative process, each time changing the
 > position where it puts the overlay and adjusting it in the next
 > iteration based on the results of window-text-pixel-size.

This precisley formulates what the application should do and cannot be
avoided IMHO.  After all, tooltips and menus seem to face exactly the
same problem when the frame is at the bottom of the display.  Otherwise,
these are better off since they can are not constrained by the edges of
the window.

martin

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Fri, 08 Aug 2014 12:10:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 18195@debbugs.gnu.org
> 
>  > IOW, your suggested solution is incomplete, unless you intend the
>  > application to do some iterative process, each time changing the
>  > position where it puts the overlay and adjusting it in the next
>  > iteration based on the results of window-text-pixel-size.
> 
> This precisley formulates what the application should do and cannot be
> avoided IMHO.

We should provide an API that allows applications to avoid that.

> After all, tooltips and menus seem to face exactly the same problem
> when the frame is at the bottom of the display.

No, we never do any iterations or multiple trials when displaying
menus and tooltips.  We compute the required space and then compare it
with what is available to make the decision.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Tue, 05 Aug 2014 14:03:37 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 08/05/2014 12:38 PM, martin rudalics wrote:
> > IIUC
> >
> > https://github.com/company-mode/company-mode/issues/160#issuecomment-51022508
> >
> > mentioned in that thread, all you want is to display all lines of a
> > completion buffer.  Is that correct?
> 
> Not at all. Have you tried Company?
> 
> This issue is about completion popup, which displays completions in the 
> current buffer and window, in a rectangle rendered using an overlay. 
> There are screenshots in that issue thread.
> 
> Before the popup is rendered, we need to determine how much of it would 
> fit below the current line, and if there's not enough space, we render 
> it above the current line.

I fixed window-screen-lines.

However, please note that you are on a slippery slope doing this.
Emacs currently doesn't provide Lisp interfaces that would allow to
perform such layout tasks from Lisp with reliable results.  Overlays
and text properties were never supposed to be used for layout
purposes.

For example, AFAIU, your code currently assumes that the font used for
popup is the same as the one used for the underlying buffer text.  But
since you provide faces for the popup, a user could legitimately
customize those faces to use a different font, and thus invalidate
your calculations, because window-screen-lines uses the metrics of the
default face's font.

And that is just an example of what could go wrong when you try to do
what in Emacs can only be done reliably by the display engine.

IMO, instead of overloading existing display features with jobs they
were never designed to do, and then live forever with the situation
where development breaks the resulting applications (like the
pixel-wise resizing of windows did with this one), it would be a much
better investment of energy to come up with requirements for Lisp APIs
that could be used by applications for laying out text.  These
requirements, when implemented, would then benefit everybody, and
allow solid dependable applications that don't break that often.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/05/2014 05:46 PM, Eli Zaretskii wrote:

> I fixed window-screen-lines.

Thanks!

> For example, AFAIU, your code currently assumes that the font used for
> popup is the same as the one used for the underlying buffer text.  But
> since you provide faces for the popup, a user could legitimately
> customize those faces to use a different font, and thus invalidate
> your calculations, because window-screen-lines uses the metrics of the
> default face's font.

Sure. This doesn't add any constraints over what we've been living with 
for years.

> IMO, instead of overloading existing display features with jobs they
> were never designed to do, and then live forever with the situation
> where development breaks the resulting applications (like the
> pixel-wise resizing of windows did with this one)

pixel-wise resizing wasn't actually the culprit: I've just never tested 
the code with non-zero line-spacing. Even with it, the bug wasn't too 
easy to notice.

 > it would be a much
> better investment of energy to come up with requirements for Lisp APIs
> that could be used by applications for laying out text.

That sounds great, but I don't even know where to start. What we're 
trying to emulate, though, is multi-layered display. That sounds 
somewhat different from a "text layout API" to me.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 01:21:56 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> > For example, AFAIU, your code currently assumes that the font used for
> > popup is the same as the one used for the underlying buffer text.  But
> > since you provide faces for the popup, a user could legitimately
> > customize those faces to use a different font, and thus invalidate
> > your calculations, because window-screen-lines uses the metrics of the
> > default face's font.
> 
> Sure. This doesn't add any constraints over what we've been living with 
> for years.

Until some user would ask to lift them.

But if you never want to lift them, why not define colors instead of
full-fledged faces?  Then those restrictions are really carved in
stone and clear for all.

> > IMO, instead of overloading existing display features with jobs they
> > were never designed to do, and then live forever with the situation
> > where development breaks the resulting applications (like the
> > pixel-wise resizing of windows did with this one)
> 
> pixel-wise resizing wasn't actually the culprit: I've just never tested 
> the code with non-zero line-spacing.

The bug had two parts; one of them _was_ due to pixel-wise resizing.

>  > it would be a much
> > better investment of energy to come up with requirements for Lisp APIs
> > that could be used by applications for laying out text.
> 
> That sounds great, but I don't even know where to start. What we're 
> trying to emulate, though, is multi-layered display. That sounds 
> somewhat different from a "text layout API" to me.

I don't mind how it is called and what is the correct abstraction.  I
do know that we need some abstraction and APIs to support it.  If you
already know what the correct abstraction is, then you are in a good
position to formulate the requirements.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 06:52 AM, Eli Zaretskii wrote:

> Until some user would ask to lift them.

Apparently, every user that tried to change the font understood that any 
resulting problems stemmed from their actions, and so we've never had 
any bug reports about that.

> But if you never want to lift them, why not define colors instead of
> full-fledged faces?  Then those restrictions are really carved in
> stone and clear for all.

Well, there are also text decorations, and users should be able to add 
(most of) them without running into problems.

Faces seem to be a natural fit for themes, and they're supported by 
quite of a few of existing themes out there. Making the 
backward-incompatible change you're suggesting will break that.

Finally, who's to say the current limitations will stay with us forever? 
If Emacs defines a suitable API, the current faces should be able to 
transition seamlessly, while users will also gain the ability to change 
the fonts.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 16:09:41 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> On 08/06/2014 06:52 AM, Eli Zaretskii wrote:
> 
> > Until some user would ask to lift them.
> 
> Apparently, every user that tried to change the font understood that any 
> resulting problems stemmed from their actions, and so we've never had 
> any bug reports about that.

AFAIU, you are developing infrastructure.  It is generally expected
from infrastructure, at least that in Emacs core, to support
everything that wasn't explicitly documented as forbidden or
unsupported.

OTOH, perhaps next time someone complains about some weird combination
of display features that happen not to work, I should respond
"restriction" and see what happens.

> > But if you never want to lift them, why not define colors instead of
> > full-fledged faces?  Then those restrictions are really carved in
> > stone and clear for all.
> 
> Well, there are also text decorations, and users should be able to add 
> (most of) them without running into problems.

Which decorations are those?

> Finally, who's to say the current limitations will stay with us forever? 
> If Emacs defines a suitable API, the current faces should be able to 
> transition seamlessly, while users will also gain the ability to change 
> the fonts.

Nothing like that will happen in Emacs without motivated individuals
driving the development.  IMO, we should either push development in
the direction I suggested (or similar), or explicitly forbid using
different fonts in Company completion, at least in the documentation,
if not by error messages.  Anything else is unwise, IMO.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 06:45 PM, Eli Zaretskii wrote:

> AFAIU, you are developing infrastructure.  It is generally expected
> from infrastructure, at least that in Emacs core, to support
> everything that wasn't explicitly documented as forbidden or
> unsupported.

I'm inclined to consider this a missing feature, of which Emacs display 
engine has plenty. But documenting using different fonts in faces as 
prohibited sounds fine to me as well.

Anyway, I've written to emacs-devel about features which would make my 
life easier.

>> Well, there are also text decorations, and users should be able to add
>> (most of) them without running into problems.
>
> Which decorations are those?

Underline, bold, italic..?

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 19:07:32 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> >> Well, there are also text decorations, and users should be able to add
> >> (most of) them without running into problems.
> >
> > Which decorations are those?
> 
> Underline, bold, italic..?

They all use fonts that are different from the default one, and thus
change the height of the screen lines, if only by a few pixels.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 08:25 PM, Eli Zaretskii wrote:

>> Underline, bold, italic..?
>
> They all use fonts that are different from the default one, and thus
> change the height of the screen lines, if only by a few pixels.

Not necessarily. At least, I can change my default face's :bold and 
:underline properties to t, and the line height doesn't change.

This probably depends on whether you have bold, underline, etc, variants 
of the same font installed in the system.

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 20:37:02 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, 18195@debbugs.gnu.org
> 
> On 08/06/2014 08:25 PM, Eli Zaretskii wrote:
> 
> >> Underline, bold, italic..?
> >
> > They all use fonts that are different from the default one, and thus
> > change the height of the screen lines, if only by a few pixels.
> 
> Not necessarily. At least, I can change my default face's :bold and 
> :underline properties to t, and the line height doesn't change.

Sheer luck.

> This probably depends on whether you have bold, underline, etc, variants 
> of the same font installed in the system.

No, it depends on the font design AFAIK.  In general, you cannot
expect the bold, underline, and italics variants to have the same
metrics, IME.

Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate)

[Dmitry Gutov]

On 08/06/2014 06:52 AM, Eli Zaretskii wrote:

 >> That sounds great, but I don't even know where to start. What we're
 >> trying to emulate, though, is multi-layered display. That sounds
 >> somewhat different from a "text layout API" to me.
 >
 > I don't mind how it is called and what is the correct abstraction.  I
 > do know that we need some abstraction and APIs to support it.  If you
 > already know what the correct abstraction is, then you are in a good
 > position to formulate the requirements.

I don't know much of the other use cases (only in-buffer calltips come 
to mind).

Basically, we'd like to be able to display a rectangle with propertized 
text inside, at an arbitrary position (I would say pixel coordinates, 
but that might not work well in terminal), so that it would be displayed 
above the buffer contents.

This would solve two issues we currently have:

1. If the buffer ends (shortly) after the current line, we're forced to 
pad it with a newline, and then carefully undo that and restore the 
buffer modification status.

2. If the buffer is already heavily using the `display' text property, 
or other similar ones, our tooltip positioning also breaks or works 
unexpectedly. Example: the `report-emacs-bug' buffer 
(https://github.com/company-mode/company-mode/issues/136).

Somewhat relatedely, I'd love to be able to sanely display smooth 
graphics spanning multiple lines in the fringe (or in the area that 
would replace it), to indicate the buffer lines that changed from the 
last VCS commit, without conflict with flymake-style warning/error 
indicators. Code folding packages might also use it to indicate the 
bounds of the function or block at point. Maybe even support buttons?

Here's an illustration from a proprietary editor: 
http://wiki.jetbrains.net/i/images/6/68/Git_general_branches_updated_code.png

Re: Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate)

[Eli Zaretskii]

> Date: Wed, 06 Aug 2014 16:40:37 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel <emacs-devel@gnu.org>
> 
> Basically, we'd like to be able to display a rectangle with propertized 
> text inside, at an arbitrary position (I would say pixel coordinates, 
> but that might not work well in terminal), so that it would be displayed 
> above the buffer contents.

That you already have, don't you?  The problem is not display, AFAIU,
the problem is the decision where exactly to display it, and the
answer depends on the dimensions of the text and the window.

If some features are missing to achieve the above (and they are not
the 2 mentioned below), then please spell them out, because I thought
the display part was already solved, once the layout is decided.

(And pixel units work quite well on text terminals, except that each
character position is 1 pixel.)

> 1. If the buffer ends (shortly) after the current line, we're forced to 
> pad it with a newline, and then carefully undo that and restore the 
> buffer modification status.

Why can't you include the newline in the overlay string instead?

> 2. If the buffer is already heavily using the `display' text property, 
> or other similar ones, our tooltip positioning also breaks or works 
> unexpectedly. Example: the `report-emacs-bug' buffer 
> (https://github.com/company-mode/company-mode/issues/136).

This is indeed a missing feature.  It should be easy enough to provide
some special kind of display property that would overlay any other
displayed content, but won't that introduce the kind of arms race we
already have with overlay priorities?  IOW, what if more than one
feature wants to have its string displayed on top of everything?

Btw, why doesn't company use normal tooltips on GUI frames and
text-mode menus on a TTY?  Wouldn't that be better?

> Somewhat relatedely, I'd love to be able to sanely display smooth 
> graphics spanning multiple lines in the fringe (or in the area that 
> would replace it)

How is this different from displaying bitmaps that fill the whole
height of a screen line, so that adjacent bitmaps don't leave any
pixels between them?

> Maybe even support buttons?

Clicking on the fringes already works.

Re: Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate)

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

> How is this different from displaying bitmaps that fill the whole
> height of a screen line, so that adjacent bitmaps don't leave any
> pixels between them?

With a positive value of line-spacing, this approach doesn't suffice:
you'll get gaps between the bitmaps.

[-- Attachment #2: Type: text/html, Size: 414 bytes --]

Re: Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate)

[Eli Zaretskii]

> Date: Wed, 6 Aug 2014 14:20:01 -0400
> From: Alp Aker <alptekin.aker@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, martin rudalics <rudalics@gmx.at>, Emacs devel <emacs-devel@gnu.org>
> 
> > How is this different from displaying bitmaps that fill the whole
> > height of a screen line, so that adjacent bitmaps don't leave any
> > pixels between them?
> 
> With a positive value of line-spacing, this approach doesn't suffice:
> you'll get gaps between the bitmaps.

Something that should be easy enough to fix, no doubt.

Re: Layered display API

[Stefan Monnier]

>> > How is this different from displaying bitmaps that fill the whole
>> > height of a screen line, so that adjacent bitmaps don't leave any
>> > pixels between them?
>> With a positive value of line-spacing, this approach doesn't suffice:
>> you'll get gaps between the bitmaps.
> Something that should be easy enough to fix, no doubt.

Currently, it's rather hard, since the height of a line depends on many
other things (such as the content of the line) and there's no
functionality to re-compute the pixmap to display in the margin once we
know the line height.


        Stefan

Re: Layered display API

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alp Aker <alptekin.aker@gmail.com>,  rudalics@gmx.at,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Wed, 06 Aug 2014 16:48:12 -0400
> 
> >> > How is this different from displaying bitmaps that fill the whole
> >> > height of a screen line, so that adjacent bitmaps don't leave any
> >> > pixels between them?
> >> With a positive value of line-spacing, this approach doesn't suffice:
> >> you'll get gaps between the bitmaps.
> > Something that should be easy enough to fix, no doubt.
> 
> Currently, it's rather hard, since the height of a line depends on many
> other things (such as the content of the line) and there's no
> functionality to re-compute the pixmap to display in the margin once we
> know the line height.

We redisplay the fringe bitmaps every time we redisplay their lines,
so it should be easy to extend the bitmap to cover all of its height.

Re: Layered display API

[Dmitry Gutov]

On 08/06/2014 09:19 PM, Eli Zaretskii wrote:

> That you already have, don't you?  The problem is not display, AFAIU,
> the problem is the decision where exactly to display it, and the
> answer depends on the dimensions of the text and the window.

"Below or above" are just the main choices. Correctly positioning it at 
the right line and column, without disturbing the text around, can still 
be a problem in advanced cases, like you mentioned here and in another 
thread.

> If some features are missing to achieve the above (and they are not
> the 2 mentioned below), then please spell them out, because I thought
> the display part was already solved, once the layout is decided.

Only if we use 1 overlay (the "crazy" approach) and only if we can 
easily get the text contained on the target rows, and there are physical 
buffer positions corresponding to the first and last lines where we want 
to display the popup (or thereabouts). If the whole text in the window 
is already rendered with `display' property, and we want to display the 
popup above only some part of it... good luck with that.

> (And pixel units work quite well on text terminals, except that each
> character position is 1 pixel.)

Ok.

>> 1. If the buffer ends (shortly) after the current line, we're forced to
>> pad it with a newline, and then carefully undo that and restore the
>> buffer modification status.
>
> Why can't you include the newline in the overlay string instead?

Haven't tried yet. And in the overlay-a-line case, each of them would be 
zero-length, then? Guess that could work...

>> 2. If the buffer is already heavily using the `display' text property,
>> or other similar ones, our tooltip positioning also breaks or works
>> unexpectedly. Example: the `report-emacs-bug' buffer
>> (https://github.com/company-mode/company-mode/issues/136).
>
> This is indeed a missing feature.  It should be easy enough to provide
> some special kind of display property that would overlay any other
> displayed content

That would leave a question where will it have to be set on. Would that 
new kind of overlay be able to be displayed far from the position it's 
set on?

 > , but won't that introduce the kind of arms race we
> already have with overlay priorities?  IOW, what if more than one
> feature wants to have its string displayed on top of everything?

I've only read about this "arms race" here on emacs-devel, instead of 
seeing it in practice. When we want to have layered display, using some 
kind of priorities system is probably a fact of life. I don't think 
there's a way around it.

> Btw, why doesn't company use normal tooltips on GUI frames and
> text-mode menus on a TTY?  Wouldn't that be better?

I'm not 100% sure what's text-mode menu is (by tooltip, do you mean 
`tooltip-show'?), but maybe because when active, they take over event 
handling, so you can't move up and down the list with M-n/M-p (or any 
other bindings the user prefers), press another combination of keys and 
see a doc buffer pop up, or just continue typing in the buffer and see 
the popup with completion candidates get updated unobtrusively.

And, at least in the tooltip's case, they can't be styled.

>> Somewhat relatedely, I'd love to be able to sanely display smooth
>> graphics spanning multiple lines in the fringe (or in the area that
>> would replace it)
>
> How is this different from displaying bitmaps that fill the whole
> height of a screen line, so that adjacent bitmaps don't leave any
> pixels between them?

That's what I've been trying to do in diff-hl (see ELPA), and failing to 
do the arithmetics just right when line-spacing and zoom factor and 
present. It should be easier with the recently added functions, though.

Still, this way you can only use 2 colors, each line can only contain 
one bitmap, and the way you have to define the bitmaps globally is 
pretty simplistic.

* Supporting vector graphics would be nicer, instead of having to 
redefine the bitmaps when zoom level changes.

* If two visible buffers have different zoom levels, I don't know how 
display the required bitmaps in both of their fringes right. Include the 
line height in the bitmap names, maybe? Speaking of crazy approaches.

> Clicking on the fringes already works.

We do support buttons in buffers, even though we probably could add 
click handlers and then look up coordinates. Suppose there are multiple 
modes using the fringe, and they all want to handle clicks. How would 
they handle that without conflicts?

Re: Layered display API

[Eli Zaretskii]

> Date: Thu, 07 Aug 2014 00:49:01 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
>     That you already have, don't you?  The problem is not display, AFAIU,
>     the problem is the decision where exactly to display it, and the
>     answer depends on the dimensions of the text and the window.
> 
> 
> "Below or above" are just the main choices. Correctly positioning it at the right line and column, without disturbing the text around, can still be a problem in advanced cases, like you mentioned here and in another thread.

So what would be the requirements for "correct positioning"?

>     If some features are missing to achieve the above (and they are not
>     the 2 mentioned below), then please spell them out, because I thought
>     the display part was already solved, once the layout is decided.
> 
> 
> Only if we use 1 overlay (the "crazy" approach) and only if we can easily get the text contained on the target rows, and there are physical buffer positions corresponding to the first and last lines where we want to display the popup (or thereabouts). If the whole text in the window is already rendered with `display' property, and we want to display the popup above only some part of it... good luck with that.

So text with display properties is one problem.  Any others?

>         1. If the buffer ends (shortly) after the current line, we're forced to
>         pad it with a newline, and then carefully undo that and restore the
>         buffer modification status.
> 
> 
>     Why can't you include the newline in the overlay string instead?
> 
> 
> Haven't tried yet. And in the overlay-a-line case, each of them would be zero-length, then? Guess that could work...

Sorry, I don't understand the question: what would be zero-length?

What I meant is this: if you need to display below the last line of
the buffer text, put the overlay at EOB, and include newlines in the
overlay string when you need to move to the next screen line.  To
align text horizontally you could use spaces or align-to display
properties in the string.

>         2. If the buffer is already heavily using the `display' text property,
>         or other similar ones, our tooltip positioning also breaks or works
>         unexpectedly. Example: the `report-emacs-bug' buffer
>         (https://github.com/company-mode/company-mode/issues/136).
> 
> 
>     This is indeed a missing feature.  It should be easy enough to provide
>     some special kind of display property that would overlay any other
>     displayed content
> 
> 
> That would leave a question where will it have to be set on. Would that new kind of overlay be able to be displayed far from the position it's set on?

No, I meant conceal the text produced by other display properties, and
display your overlay string instead.

>     Btw, why doesn't company use normal tooltips on GUI frames and
>     text-mode menus on a TTY?  Wouldn't that be better?
> 
> 
> I'm not 100% sure what's text-mode menu is

A normal menu, created by x-popup-menu, which now works on TTYs.  You
can pop up the menu at any place in the window text area.

> (by tooltip, do you mean `tooltip-show'?)

Yes, a real tooltip.

> maybe because when active, they take over event handling, so you can't move up and down the list with M-n/M-p (or any other bindings the user prefers)

Text-mode menus support navigation with cursor movement keys, like
C-p, C-n, up-arrow, and down-arrow.  More accurately, any key bound to
next/previous-line will navigate through the menu items as you'd
expect.

> press another combination of keys and see a doc buffer pop up

Help-echo in menus is supported, and shown in the echo area
automatically, so you could have all that documentation in the
help-echo string.

> or just continue typing in the buffer and see the popup with completion candidates get updated unobtrusively.

This can be achieved programmatically, by refreshing the menu when the
user types.

> And, at least in the tooltip's case, they can't be styled.

What do you mean by "styled"?

In any case, if something is missing in tooltip frames to support this
kind of applications, we had better added that.  IMO, showing
completion candidates in a tooltip will look much more professionally
than the current text emulation.  AFAIK, other IDEs do use tooltips in
these cases.

> Still, this way you can only use 2 colors

Why only 2?

> each line can only contain one bitmap

Fringe real estate is limited, so yes, there are limits to this.

An alternative is to use line-prefix or display margins, and display
images there.

>     Clicking on the fringes already works.
> 
> We do support buttons in buffers, even though we probably could add click handlers and then look up coordinates.

Again, you can display images in the margin or the line-prefix, and so
a button could be displayed there, I think.

> Suppose there are multiple modes using the fringe, and they all want to handle clicks. How would they handle that without conflicts?

The click on the fringe is interpreted in the context of the selected
window's buffer, AFAIR.

Re: Layered display API

[Dmitry Gutov]

On 08/07/2014 07:39 PM, Eli Zaretskii wrote:

> So what would be the requirements for "correct positioning"?

Display some strings in the buffer starting with the given line and 
column, correctly lining all following lines up vertically, to form a 
rectangle

Something like the following would work:

(make-popup :x-coord 340 :y-coord 200 :width ... :height ... :contents 
"foo\nbar\nbaz" :default-face ...)

  The keyword arguments are just for show, and the above assumes that 
popups aren't tied to specific buffers (or window, I guess). Making it 
buffer-local would be fine, too, I guess, then :x-coord and :y-coord 
might be replaced with :x-offset and :y-offset, specified relative to 
the popup's reference position in the buffer's contents.

> So text with display properties is one problem.  Any others?

- `line-prefix', as discussed.

- Different values of `line-height', `line-spacing', images in the buffer.

- Changes in some lines' appearance done some other way, like the 
separator line in `log-edit' buffers.

- The `intangible' property would probably also cause some problems for 
our current implementation.

- Proportional fonts, obviously.

- Not being able to display the popup over the mode-line and window 
separators. This would be useful for completion when typing in the 
minibuffer.

- The "one big overlay" approach conflicts with other packages that use 
overlays to put information on the margins or fringes, such as linum and 
diff-hl. The lines displaying our popup lose the linum and diff-hl 
indicators.

> Sorry, I don't understand the question: what would be zero-length?

An overlay where BEG = END. It wasn't a very meaningful question, I guess.

> What I meant is this: if you need to display below the last line of
> the buffer text, put the overlay at EOB, and include newlines in the
> overlay string when you need to move to the next screen line.  To
> align text horizontally you could use spaces or align-to display
> properties in the string.

Yes, I might try this, as soon as there's some suggestion how to handle 
the problem of `line-prefix' in this multi-overlay approach.

>>      This is indeed a missing feature.  It should be easy enough to provide
>>      some special kind of display property that would overlay any other
>>      displayed content
>>
>>
>> That would leave a question where will it have to be set on. Would that new kind of overlay be able to be displayed far from the position it's set on?
>
> No, I meant conceal the text produced by other display properties, and
> display your overlay string instead.

It doesn't seem to be solving much: if I want to display something in 
the middle of, say, large `display' text, there's no specific span of 
text to set that new property on.

> Text-mode menus support navigation with cursor movement keys, like
> C-p, C-n, up-arrow, and down-arrow.  More accurately, any key bound to
> next/previous-line will navigate through the menu items as you'd
> expect.

We have different commands that move up and down, with specific logic 
behind them. Allowing the menu to handle those keys doesn't sound like a 
good idea.

>> press another combination of keys and see a doc buffer pop up
>
> Help-echo in menus is supported, and shown in the echo area
> automatically, so you could have all that documentation in the
> help-echo string.

It _might_ help with displaying the one-line help we already show in the 
echo area (although the programmatic interface seems to be incompatible: 
we only ask the backend for that information when the candidate is 
selected), but it definitely won't help with popping up the 
documentation buffer.

>> or just continue typing in the buffer and see the popup with completion candidates get updated unobtrusively.
>
> This can be achieved programmatically, by refreshing the menu when the
> user types.

Could you elaborate on that? Would that work via post-command-hook?

>> And, at least in the tooltip's case, they can't be styled.
>
> What do you mean by "styled"?

Displayed with different background color, for example.

> In any case, if something is missing in tooltip frames to support this
> kind of applications, we had better added that.  IMO, showing
> completion candidates in a tooltip will look much more professionally
> than the current text emulation.  AFAIK, other IDEs do use tooltips in
> these cases.

Of course.

>> Still, this way you can only use 2 colors
>
> Why only 2?

The fringe foreground color and the fringe background color. The fringe 
face may vary between lines, but a bitmap instance ends up using only 
two colors at a time.

>> each line can only contain one bitmap
>
> Fringe real estate is limited, so yes, there are limits to this.

Fringe size is not fixed, the user (or packages) can change it. Even 
with the current default size, I could use being able to display several 
bitmaps at a time: for example, the simple-looking indicator from 
diff-hl and, above it, `?' or `!` from flymake.

> An alternative is to use line-prefix or display margins, and display
> images there.

line-prefix is again something only one package can use at a time.

Could I display some vertical graphic in the margins that smoothly spans 
several lines?

>> Suppose there are multiple modes using the fringe, and they all want to handle clicks. How would they handle that without conflicts?
>
> The click on the fringe is interpreted in the context of the selected
> window's buffer, AFAIR.

And? Suppose there are multiple minor modes in that buffer that might 
like to handle that click?

Re: Layered display API

[Eli Zaretskii]

> Date: Mon, 11 Aug 2014 05:14:24 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> (make-popup :x-coord 340 :y-coord 200 :width ... :height ... :contents 
> "foo\nbar\nbaz" :default-face ...)

Compare this with x-popup-menu: the similarity is striking.  Which is
why I suggested to use menus on TTYs.

> > So text with display properties is one problem.  Any others?
> 
> - `line-prefix', as discussed.
> 
> - Different values of `line-height', `line-spacing', images in the buffer.
> 
> - Changes in some lines' appearance done some other way, like the 
> separator line in `log-edit' buffers.
> 
> - The `intangible' property would probably also cause some problems for 
> our current implementation.
> 
> - Proportional fonts, obviously.
> 
> - Not being able to display the popup over the mode-line and window 
> separators. This would be useful for completion when typing in the 
> minibuffer.
> 
> - The "one big overlay" approach conflicts with other packages that use 
> overlays to put information on the margins or fringes, such as linum and 
> diff-hl. The lines displaying our popup lose the linum and diff-hl 
> indicators.

Given these requirements, I think the only 2 alternatives to implement
them for GUI frames are:

  . tooltip frames, suitably beefed up to provide some features they
    currently don't, like more control of colors and faces

  . some low-level graphics feature that would allow to overlay an
    arbitrary pixmap on the window display (this is far from my area
    of expertise, so I cannot say anything more about this
    possibility)

Nothing else seems possible, because if we rely on the current display
engine, we will be unable to fully control at least the vertical
position of the lines in your popup, and in some cases (e.g.,
line-prefix) also the horizontal position.  The current display engine
is limited to displaying various "display elements" on a canvas, where
each row spans the entire width of a window, and its vertical position
is calculated to leave enough space for the tallest display element of
the row.

> > What I meant is this: if you need to display below the last line of
> > the buffer text, put the overlay at EOB, and include newlines in the
> > overlay string when you need to move to the next screen line.  To
> > align text horizontally you could use spaces or align-to display
> > properties in the string.
> 
> Yes, I might try this, as soon as there's some suggestion how to handle 
> the problem of `line-prefix' in this multi-overlay approach.

Find the longest prefix and align everything so that the left edge
keeps clear of that?

> >>      This is indeed a missing feature.  It should be easy enough to provide
> >>      some special kind of display property that would overlay any other
> >>      displayed content
> >>
> >>
> >> That would leave a question where will it have to be set on. Would that new kind of overlay be able to be displayed far from the position it's set on?
> >
> > No, I meant conceal the text produced by other display properties, and
> > display your overlay string instead.
> 
> It doesn't seem to be solving much: if I want to display something in 
> the middle of, say, large `display' text, there's no specific span of 
> text to set that new property on.

You'd put it on the overlay string.

> > Text-mode menus support navigation with cursor movement keys, like
> > C-p, C-n, up-arrow, and down-arrow.  More accurately, any key bound to
> > next/previous-line will navigate through the menu items as you'd
> > expect.
> 
> We have different commands that move up and down, with specific logic 
> behind them.

Examples?

> Allowing the menu to handle those keys doesn't sound like a good
> idea.

We could generalize the current menu code to allow something like
that.

> >> press another combination of keys and see a doc buffer pop up
> >
> > Help-echo in menus is supported, and shown in the echo area
> > automatically, so you could have all that documentation in the
> > help-echo string.
> 
> It _might_ help with displaying the one-line help we already show in the 
> echo area (although the programmatic interface seems to be incompatible: 
> we only ask the backend for that information when the candidate is 
> selected), but it definitely won't help with popping up the 
> documentation buffer.

You can always exit the menu, pop up the documentation buffer, then
redraw the menu, all this programmatically.

> >> or just continue typing in the buffer and see the popup with completion candidates get updated unobtrusively.
> >
> > This can be achieved programmatically, by refreshing the menu when the
> > user types.
> 
> Could you elaborate on that?

Same as above: exit the menu, do what you need, then redraw it.

> Would that work via post-command-hook?

No.  The current menu code simply ignores any commands it wasn't
programmed to understand and act upon.

> > An alternative is to use line-prefix or display margins, and display
> > images there.
> 
> line-prefix is again something only one package can use at a time.

That is a problem you won't be able to escape.  Emacs modes aren't
supposed to fight each other; if they do, the user is in trouble.

> Could I display some vertical graphic in the margins that smoothly spans 
> several lines?

Emacs can display image slices (see the documentation of the 'display'
property), so this should be possible.  I didn't try it, though.

> >> Suppose there are multiple modes using the fringe, and they all want to handle clicks. How would they handle that without conflicts?
> >
> > The click on the fringe is interpreted in the context of the selected
> > window's buffer, AFAIR.
> 
> And? Suppose there are multiple minor modes in that buffer that might 
> like to handle that click?

Again, fights like that should be resolved "by other means".

Re: Layered display API

[Dmitry Gutov]

On 08/11/2014 07:01 PM, Eli Zaretskii wrote:

> Compare this with x-popup-menu: the similarity is striking.  Which is
> why I suggested to use menus on TTYs.

Yes, it would be nice if we can use them. However, the fact that menus 
handle evens themselves (or try to) makes me think it's not the cleanest 
approach.

> Given these requirements, I think the only 2 alternatives to implement
> them for GUI frames are:
>
>    . tooltip frames, suitably beefed up <...>
>
>    . some low-level graphics feature <...>
>
> Nothing else seems possible, because if we rely on the current display
> engine, we will be unable to fully control at least the vertical
> position of the lines in your popup, and in some cases (e.g.,
> line-prefix) also the horizontal position.

Not even menus? My understanding was they might be able to satisfy most 
of the requirements, aside from working with proportional fonts.

>> Yes, I might try this, as soon as there's some suggestion how to handle
>> the problem of `line-prefix' in this multi-overlay approach.
>
> Find the longest prefix and align everything so that the left edge
> keeps clear of that?

Yes, sounds like a reasonable simplification. This would be a step back 
in terms of functionality, though, but possibly a justified one.

>>> No, I meant conceal the text produced by other display properties, and
>>> display your overlay string instead.
>>
>> It doesn't seem to be solving much: if I want to display something in
>> the middle of, say, large `display' text, there's no specific span of
>> text to set that new property on.
>
> You'd put it on the overlay string.

Let me rephrase the previous message: "...there's no specific span of 
text to put the overlay on". Or that's my understanding.

>>> Text-mode menus support navigation with cursor movement keys, like
>>> C-p, C-n, up-arrow, and down-arrow.  More accurately, any key bound to
>>> next/previous-line will navigate through the menu items as you'd
>>> expect.
>>
>> We have different commands that move up and down, with specific logic
>> behind them.
>
> Examples?

A simple example:

     (define-key keymap (kbd "M-n") 'company-select-next)
     (define-key keymap (kbd "M-p") 'company-select-previous)
     (define-key keymap (kbd "<down>") 'company-select-next-or-abort)
     (define-key keymap (kbd "<up>") 'company-select-previous-or-abort)

The last two abort completion, do some magic and push the event back 
into `unread-command-events'. This happens if <up> is pressed when the 
first candidate is selected, or <down> is pressed when the last one is.

Among other things, `company-select-next' and its counterpart save the 
number of the currently selected completion candidate, and the other 
commands and front-ends use that to display information related to it, 
and for correct visualization.

>> Allowing the menu to handle those keys doesn't sound like a good
>> idea.
>
> We could generalize the current menu code to allow something like
> that.

Sounds promising.

> You can always exit the menu, pop up the documentation buffer, then
> redraw the menu, all this programmatically.

Will the menu allow me to customize the keymap it's using? To be able to 
invoke the `company-show-doc-buffer' command in the first place?

> Same as above: exit the menu, do what you need, then redraw it.
>
>> Would that work via post-command-hook?
>
> No.  The current menu code simply ignores any commands it wasn't
> programmed to understand and act upon.

Ignores, or allows them to go through?

> That is a problem you won't be able to escape.  Emacs modes aren't
> supposed to fight each other; if they do, the user is in trouble.

Some packages's fringe indicators might be incompatible by their 
essence, there's not much we could do there.

Others could co-exist. If the fringe allowed "layered" display of 
bitmaps, for example, flymake could assign its overlays a higher 
priority and happily coexist with diff-hl indicators.

>> Could I display some vertical graphic in the margins that smoothly spans
>> several lines?
>
> Emacs can display image slices (see the documentation of the 'display'
> property), so this should be possible.  I didn't try it, though.

Thanks, I'll look it up sometime.

>> And? Suppose there are multiple minor modes in that buffer that might
>> like to handle that click?
>
> Again, fights like that should be resolved "by other means".

In the buffer contents, they are resolved with buttons. Why not on the 
fringe?

Re: Layered display API

[Stefan Monnier]

>> Compare this with x-popup-menu: the similarity is striking.  Which is
>> why I suggested to use menus on TTYs.
> Yes, it would be nice if we can use them. However, the fact that menus
> handle evens themselves (or try to) makes me think it's not the
> cleanest approach.

From a display point of view, I think the "tty menus" approach is indeed
the cleanest solution when running on a tty.  But they can't be used
as-is for lack of flexibility w.r.t key-bindings and appearance (we
don't really need borders for Company menus, but we do need control
over colors).

In a GUI frame, OTOH, we'd be much better off with a GUI window
(something akin to a tooltip frame).


        Stefan

Re: Layered display API

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Wed, 13 Aug 2014 08:46:59 -0400
> 
> From a display point of view, I think the "tty menus" approach is indeed
> the cleanest solution when running on a tty.  But they can't be used
> as-is for lack of flexibility w.r.t key-bindings and appearance (we
> don't really need borders for Company menus, but we do need control
> over colors).
> 
> In a GUI frame, OTOH, we'd be much better off with a GUI window
> (something akin to a tooltip frame).

I agree.

Re: Layered display API

[Dmitry Gutov]

On 08/13/2014 04:46 PM, Stefan Monnier wrote:

> (we
> don't really need borders for Company menus, but we do need control
> over colors).

Yes, we use a one-column/row margin instead of borders. Works pretty 
well. We'll need to be able to "paint" the non-interactive scrollbar, at 
least, like we do in the current popup.

> In a GUI frame, OTOH, we'd be much better off with a GUI window
> (something akin to a tooltip frame).

When it's ready, yes. Until then, tty menus should work pretty well in 
the graphical mode, too. If they're available, of course.

Re: Layered display API

[Eli Zaretskii]

> Date: Wed, 13 Aug 2014 20:27:27 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, rudalics@gmx.at, emacs-devel@gnu.org
> 
> tty menus should work pretty well in the graphical mode, too. If
> they're available, of course.

TTY menus work only on text-mode frames.  Sorry.

Re: Layered display API

[Stefan Monnier]

>> In a GUI frame, OTOH, we'd be much better off with a GUI window
>> (something akin to a tooltip frame).
> When it's ready, yes.

I don't think it'll get ready on its own, tho ;-)

But you might like to try a non-toolkit build of Emacs and use the
tooltip frames used in that case (e.g. IIRC they understand faces, for
one).
Then we should somehow make those "non-toolkit-tooltip-frames" available
in all builds.


        Stefan

Re: Layered display API

[Eli Zaretskii]

> Date: Wed, 13 Aug 2014 06:42:57 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> On 08/11/2014 07:01 PM, Eli Zaretskii wrote:
> 
> > Compare this with x-popup-menu: the similarity is striking.  Which is
> > why I suggested to use menus on TTYs.
> 
> Yes, it would be nice if we can use them. However, the fact that menus 
> handle evens themselves (or try to) makes me think it's not the cleanest 
> approach.

The menu code can be extended.  More accurately, we could refactor the
menu code to provide the capabilities of overlaying text on window
display for other Lisp features.

> > Given these requirements, I think the only 2 alternatives to implement
> > them for GUI frames are:
> >
> >    . tooltip frames, suitably beefed up <...>
> >
> >    . some low-level graphics feature <...>
> >
> > Nothing else seems possible, because if we rely on the current display
> > engine, we will be unable to fully control at least the vertical
> > position of the lines in your popup, and in some cases (e.g.,
> > line-prefix) also the horizontal position.
> 
> Not even menus? My understanding was they might be able to satisfy most 
> of the requirements, aside from working with proportional fonts.

At least with some toolkits, GUI menus have decorations, which will
look strange if we use them in this capacity.

> >>> No, I meant conceal the text produced by other display properties, and
> >>> display your overlay string instead.
> >>
> >> It doesn't seem to be solving much: if I want to display something in
> >> the middle of, say, large `display' text, there's no specific span of
> >> text to set that new property on.
> >
> > You'd put it on the overlay string.
> 
> Let me rephrase the previous message: "...there's no specific span of 
> text to put the overlay on".

The buffer text that is covered by the "large display property" is
still there, right?  It just isn't displayed.

> Will the menu allow me to customize the keymap it's using?

Of course!  This is Emacs.  See the end of menu-bar.el: the menu
navigation keys are defined as a keymap.

> > Same as above: exit the menu, do what you need, then redraw it.
> >
> >> Would that work via post-command-hook?
> >
> > No.  The current menu code simply ignores any commands it wasn't
> > programmed to understand and act upon.
> 
> Ignores, or allows them to go through?

Ignores.  They are processed and produce no effect.

> >> And? Suppose there are multiple minor modes in that buffer that might
> >> like to handle that click?
> >
> > Again, fights like that should be resolved "by other means".
> 
> In the buffer contents, they are resolved with buttons. Why not on the 
> fringe?

I don't see how buttons can resolve conflicts.  Maybe I'm missing
something.

Re: Layered display API

[Dmitry Gutov]

On 08/13/2014 07:28 PM, Eli Zaretskii wrote:

> The menu code can be extended.  More accurately, we could refactor the
> menu code to provide the capabilities of overlaying text on window
> display for other Lisp features.

Cool. Like Stefan suggested, I'll try playing with a toolkit-less popup 
first, and then you could see if you can provide a similar API with tty 
menus.

I've been under impression that "tty menus" could work in graphical 
mode, too, but now I understand that they're non-portable, like the name 
suggests. That's too bad.

>> Not even menus? My understanding was they might be able to satisfy most
>> of the requirements, aside from working with proportional fonts.
>
> At least with some toolkits, GUI menus have decorations, which will
> look strange if we use them in this capacity.

Yep, I meant "tty menus" there. Not an option.

>>>>> No, I meant conceal the text produced by other display properties, and
>>>>> display your overlay string instead.
>>>>
>>>> It doesn't seem to be solving much: if I want to display something in
>>>> the middle of, say, large `display' text, there's no specific span of
>>>> text to set that new property on.
>>>
>>> You'd put it on the overlay string.
>>
>> Let me rephrase the previous message: "...there's no specific span of
>> text to put the overlay on".
>
> The buffer text that is covered by the "large display property" is
> still there, right?  It just isn't displayed.

Why use the special new property, then? Just put a new overlay over it. 
If it also has `display' and higher priority, it would take over.

>> Will the menu allow me to customize the keymap it's using?
>
> Of course!  This is Emacs.  See the end of menu-bar.el: the menu
> navigation keys are defined as a keymap.

So, you would suggest I dynamically rebind `tty-menu-navigation-map'?

> I don't see how buttons can resolve conflicts.  Maybe I'm missing
> something.

If one piece of code creates one button, and another piece of code 
creates another button, they can put different handlers into the button 
properties, so the results of clicking of these buttons will be 
different, even if they are in the same buffer, on the same line.

Same could be done the fringe, at least in theory.

Re: Layered display API

[Eli Zaretskii]

> Date: Thu, 14 Aug 2014 06:35:11 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> I've been under impression that "tty menus" could work in graphical 
> mode, too, but now I understand that they're non-portable, like the name 
> suggests. That's too bad.

Doing the same on GUI frames would hit all the difficulties that we've
been discussing in this thread, due to proportional and variable-size
fonts, and other display features that don't exist on a TTY.  More
importantly, the TTY menus were developed because there were no menus
on text-mode frames, a problem that didn't exist on GUI frames.

> Why use the special new property, then? Just put a new overlay over it. 
> If it also has `display' and higher priority, it would take over.

Because you want to get priority not only over other overlays, but
also over display properties and maybe other things.

> >> Will the menu allow me to customize the keymap it's using?
> >
> > Of course!  This is Emacs.  See the end of menu-bar.el: the menu
> > navigation keys are defined as a keymap.
> 
> So, you would suggest I dynamically rebind `tty-menu-navigation-map'?

If you need that, yes.

Re: Layered display API

[Dmitry Gutov]

On 08/14/2014 06:53 AM, Eli Zaretskii wrote:

> Doing the same on GUI frames would hit all the difficulties that we've
> been discussing in this thread, due to proportional and variable-size
> fonts, and other display features that don't exist on a TTY.

Guess so. We've been living without non-monospaced fonts support for 
quite a while, though, so that wouldn't be much of a problem, if the 
menus solved at least some other problems.

>> Why use the special new property, then? Just put a new overlay over it.
>> If it also has `display' and higher priority, it would take over.
>
> Because you want to get priority not only over other overlays, but
> also over display properties and maybe other things.

Doesn't any overlay's `display' get priority over text's `display'?

If I want to get priority over "maybe other things", the first problem 
would how to know the list of all those things, and to retrieve the text 
that gets displayed in stead of each of those things. Which would be, 
again, reimplementing the display engine.

Re: Layered display API

[Eli Zaretskii]

> Date: Thu, 14 Aug 2014 17:12:35 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> >> Why use the special new property, then? Just put a new overlay over it.
> >> If it also has `display' and higher priority, it would take over.
> >
> > Because you want to get priority not only over other overlays, but
> > also over display properties and maybe other things.
> 
> Doesn't any overlay's `display' get priority over text's `display'?

I don't remember, but if it does, it's an implementation detail
subject to change without notice.

> If I want to get priority over "maybe other things", the first problem 
> would how to know the list of all those things, and to retrieve the text 
> that gets displayed in stead of each of those things. Which would be, 
> again, reimplementing the display engine.

This property we are discussing (that doesn't yet exist) will be acted
upon by the display engine.  The display engine always knows what
"things" are there at point, and the supporting logic for this
property will cause the display engine to ignore all the other
"things" and display only the overlay that has this property.  At
least that's the theory.

Re: Layered display API

[Dmitry Gutov]

On 08/14/2014 07:20 PM, Eli Zaretskii wrote:

>> Doesn't any overlay's `display' get priority over text's `display'?
>
> I don't remember, but if it does, it's an implementation detail
> subject to change without notice.

...

> This property we are discussing (that doesn't yet exist) will be acted
> upon by the display engine.  The display engine always knows what
> "things" are there at point, and the supporting logic for this
> property will cause the display engine to ignore all the other
> "things" and display only the overlay that has this property.  At
> least that's the theory.

Well, since we don't only need to replace the displayed characters, but 
also modify them, this doesn't do a lot of work for us.

 From what I understand, you're suggesting a property that would act 
like a combination of overlay + display does currently. Why not just 
document that current behavior and then stick to it, rather than 
introduce the new property?

Re: Layered display API

[Eli Zaretskii]

> Date: Fri, 15 Aug 2014 05:20:12 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> > This property we are discussing (that doesn't yet exist) will be acted
> > upon by the display engine.  The display engine always knows what
> > "things" are there at point, and the supporting logic for this
> > property will cause the display engine to ignore all the other
> > "things" and display only the overlay that has this property.  At
> > least that's the theory.
> 
> Well, since we don't only need to replace the displayed characters, but 
> also modify them, this doesn't do a lot of work for us.

Not sure why you would need to modify them.  My understanding is that
you include in the overlay some of the displayed text, and also
include your own text.

What I'm suggesting will allow you not to duplicate the displayed
text, but just add an overlay with your own.

>  From what I understand, you're suggesting a property that would act 
> like a combination of overlay + display does currently. Why not just 
> document that current behavior and then stick to it, rather than 
> introduce the new property?

See above: because what exists doesn't do the job for you well enough.
Copying into your overlay existing text from buffer, other overlays,
and display strings is fragile design with known deficiencies (which
were revealed in this thread).  Having a special property that would
avoid all that is a win, IMO.  For example, you will be able to stop
worrying about line-prefix and images.

Re: Layered display API

[Dmitry Gutov]

On 08/15/2014 10:39 AM, Eli Zaretskii wrote:

>> Well, since we don't only need to replace the displayed characters, but
>> also modify them, this doesn't do a lot of work for us.
>
> Not sure why you would need to modify them.  My understanding is that
> you include in the overlay some of the displayed text, and also
> include your own text.

Yes, we take the displayed text, *modify* its copy to overwrite some 
pieces of it with our text, and put it on our overlay. So one of the 
hard parts, if done perfectly, would be to obtain the displayed text 
correctly.

> What I'm suggesting will allow you not to duplicate the displayed
> text, but just add an overlay with your own.

Sorry, I'm getting strongly mixed signals here: just recently, when I 
enumerated a list of requirements for displaying our popup, you replied:

"""
Given these requirements, I think the only 2 alternatives to implement
them for GUI frames are:

   . tooltip frames, suitably beefed up to provide some features they
     currently don't, like more control of colors and faces

   . some low-level graphics feature that would allow to overlay an
     arbitrary pixmap on the window display (this is far from my area
     of expertise, so I cannot say anything more about this
     possibility)

Nothing else seems possible, because if we rely on the current display
engine, we will be unable to fully control at least the vertical
position of the lines in your popup, and in some cases (e.g.,
line-prefix) also the horizontal position.
"""

So, which part of the job would the new text property perform, and which 
part of it will be left to us to implement?

> See above: because what exists doesn't do the job for you well enough.
> Copying into your overlay existing text from buffer, other overlays,
> and display strings is fragile design with known deficiencies (which
> were revealed in this thread).  Having a special property that would
> avoid all that is a win, IMO.  For example, you will be able to stop
> worrying about line-prefix and images.

Let's imagine this sample case:

   (insert "e\naaaaaa\n")
   (insert (propertize " " 'display "bbbbbb\ncccccc")

(By the way, try this out in *scratch* and do some C-n, C-p. Do you see 
the movement error? Here, the cursor always jumps over the "aaa..." 
line when moving toward the beginning of the buffer.)

Let's say the point is at the end of the first line (after "e"), and 
we'd like to display a popup under it, 4 columns wide and 2 lines tall. 
If the popup is all filled with "x" characters, it should look like this:

e.
axxxxa
bxxxxb
cccccc

If the new property was already implemented, what would the code to do 
this look like?

Re: Layered display API

[Eli Zaretskii]

> Date: Sat, 16 Aug 2014 03:03:33 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> > What I'm suggesting will allow you not to duplicate the displayed
> > text, but just add an overlay with your own.
> 
> Sorry, I'm getting strongly mixed signals here: just recently, when I 
> enumerated a list of requirements for displaying our popup, you replied:
> 
> """
> Given these requirements, I think the only 2 alternatives to implement
> them for GUI frames are:
> 
>    . tooltip frames, suitably beefed up to provide some features they
>      currently don't, like more control of colors and faces
> 
>    . some low-level graphics feature that would allow to overlay an
>      arbitrary pixmap on the window display (this is far from my area
>      of expertise, so I cannot say anything more about this
>      possibility)
> 
> Nothing else seems possible, because if we rely on the current display
> engine, we will be unable to fully control at least the vertical
> position of the lines in your popup, and in some cases (e.g.,
> line-prefix) also the horizontal position.
> """
> 
> So, which part of the job would the new text property perform, and which 
> part of it will be left to us to implement?

None.  The new property is yet another possibility, IMO inferior to
the 2 I suggested above.

> Let's imagine this sample case:
> 
>    (insert "e\naaaaaa\n")
>    (insert (propertize " " 'display "bbbbbb\ncccccc")
> 
> (By the way, try this out in *scratch* and do some C-n, C-p. Do you see 
> the movement error? Here, the cursor always jumps over the "aaa..." 
> line when moving toward the beginning of the buffer.)

Please file a bug report.

> Let's say the point is at the end of the first line (after "e"), and 
> we'd like to display a popup under it, 4 columns wide and 2 lines tall. 
> If the popup is all filled with "x" characters, it should look like this:
> 
> e.
> axxxxa
> bxxxxb
> cccccc
> 
> If the new property was already implemented, what would the code to do 
> this look like?

Something like this:

  (put-text-property POS1 POS1+4 'eliz "xxxx")
  (put-text-property 1 5 STRING 'eliz "xxxx")
  (put-text-property 8 12 STRING 'eliz "xxxx")

where POS1 is the buffer position of the second 'a', and STRING is the
string that is the value of the 'display' property.

Re: Layered display API

[Dmitry Gutov]

On 08/16/2014 11:41 AM, Eli Zaretskii wrote:

> Please file a bug report.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18276

> Something like this:
>
>    (put-text-property POS1 POS1+4 'eliz "xxxx")
>    (put-text-property 1 5 STRING 'eliz "xxxx")
>    (put-text-property 8 12 STRING 'eliz "xxxx")
>
> where POS1 is the buffer position of the second 'a', and STRING is the
> string that is the value of the 'display' property.

Yes, this doesn't sound too good: it will require modifying the buffer 
contents, as opposed to using an overlay, which can be removed at once.

Since we'll have to modify display strings, the code will have to 
account for the display logic, line-prefix, before-string, etc, anyway, 
if only to calculate which part of our "new" text falls on each 
respective display property, or on the "plain" buffer text.

Re: Layered display API

[Bo Lin]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> > What I meant is this: if you need to display below the last line of
>> > the buffer text, put the overlay at EOB, and include newlines in the
>> > overlay string when you need to move to the next screen line.  To
>> > align text horizontally you could use spaces or align-to display
>> > properties in the string.
>> 
>> Yes, I might try this, as soon as there's some suggestion how to handle 
>> the problem of `line-prefix' in this multi-overlay approach.
>
> Find the longest prefix and align everything so that the left edge
> keeps clear of that?

Zero length overlays don't get displayed so this won't work when the
buffer is empty. Not a game breaker of course, but for a completion
tooltip it's still an undesirable defect.

>> >>      This is indeed a missing feature.  It should be easy enough to provide
>> >>      some special kind of display property that would overlay any other
>> >>      displayed content
>> >>
>> >>
>> >> That would leave a question where will it have to be set on.
>> >> Would that new kind of overlay be able to be displayed far
>> >> from the position it's set on?
>> >
>> > No, I meant conceal the text produced by other display properties, and
>> > display your overlay string instead.
>> 
>> It doesn't seem to be solving much: if I want to display something in 
>> the middle of, say, large `display' text, there's no specific span of 
>> text to set that new property on.
>
> You'd put it on the overlay string.

Ideally, for a popup tooltip, it should cover only the small
rectangular area that is the tooltip, while leaving everything else
intact to minimize visual disturbances. This is, AFAICT, currently
impossible to achieve if you have to conceal anything with a
'display property, because: 1) in the simplest case the 'display is
a string, but you don't know the proper display width of each
character; and 2) the 'display can be not-strings.

-Bo

Re: Layered display API

[Eli Zaretskii]

> From: Bo Lin <bo@dreamsphere.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Wed, 13 Aug 2014 22:06:26 -0400
> 
> Hi,
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > What I meant is this: if you need to display below the last line of
> >> > the buffer text, put the overlay at EOB, and include newlines in the
> >> > overlay string when you need to move to the next screen line.  To
> >> > align text horizontally you could use spaces or align-to display
> >> > properties in the string.
> >> 
> >> Yes, I might try this, as soon as there's some suggestion how to handle 
> >> the problem of `line-prefix' in this multi-overlay approach.
> >
> > Find the longest prefix and align everything so that the left edge
> > keeps clear of that?
> 
> Zero length overlays don't get displayed so this won't work when the
> buffer is empty.

When a buffer is empty, there are no line prefixes, right?  Or did I
misunderstand what you eman?

> >> >>      This is indeed a missing feature.  It should be easy enough to provide
> >> >>      some special kind of display property that would overlay any other
> >> >>      displayed content
> >> >>
> >> >>
> >> >> That would leave a question where will it have to be set on.
> >> >> Would that new kind of overlay be able to be displayed far
> >> >> from the position it's set on?
> >> >
> >> > No, I meant conceal the text produced by other display properties, and
> >> > display your overlay string instead.
> >> 
> >> It doesn't seem to be solving much: if I want to display something in 
> >> the middle of, say, large `display' text, there's no specific span of 
> >> text to set that new property on.
> >
> > You'd put it on the overlay string.
> 
> Ideally, for a popup tooltip, it should cover only the small
> rectangular area that is the tooltip, while leaving everything else
> intact to minimize visual disturbances. This is, AFAICT, currently
> impossible to achieve if you have to conceal anything with a
> 'display property, because: 1) in the simplest case the 'display is
> a string, but you don't know the proper display width of each
> character; and 2) the 'display can be not-strings.

I wasn't talking about the currently existing display properties, I
was talking about a new property with the capabilities I described.

Re: Layered display API

[Bo Lin]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> > What I meant is this: if you need to display below the last line of
>> >> > the buffer text, put the overlay at EOB, and include newlines in the
>> >> > overlay string when you need to move to the next screen line.  To
>> >> > align text horizontally you could use spaces or align-to display
>> >> > properties in the string.
>> >> 
>> >> Yes, I might try this, as soon as there's some suggestion how to handle 
>> >> the problem of `line-prefix' in this multi-overlay approach.
>> >
>> > Find the longest prefix and align everything so that the left edge
>> > keeps clear of that?
>> 
>> Zero length overlays don't get displayed so this won't work when the
>> buffer is empty.
>
> When a buffer is empty, there are no line prefixes, right?  Or did I
> misunderstand what you eman?

I thought this was about avoid padding the buffer text with
newlines?

>> >> >>      This is indeed a missing feature.  It should be easy enough to provide
>> >> >>      some special kind of display property that would overlay any other
>> >> >>      displayed content
>> >> >>
>> >> >>
>> >> >> That would leave a question where will it have to be set on.
>> >> >> Would that new kind of overlay be able to be displayed far
>> >> >> from the position it's set on?
>> >> >
>> >> > No, I meant conceal the text produced by other display properties, and
>> >> > display your overlay string instead.
>> >> 
>> >> It doesn't seem to be solving much: if I want to display something in 
>> >> the middle of, say, large `display' text, there's no specific span of 
>> >> text to set that new property on.
>> >
>> > You'd put it on the overlay string.
>> 
>> Ideally, for a popup tooltip, it should cover only the small
>> rectangular area that is the tooltip, while leaving everything else
>> intact to minimize visual disturbances. This is, AFAICT, currently
>> impossible to achieve if you have to conceal anything with a
>> 'display property, because: 1) in the simplest case the 'display is
>> a string, but you don't know the proper display width of each
>> character; and 2) the 'display can be not-strings.
>
> I wasn't talking about the currently existing display properties, I
> was talking about a new property with the capabilities I described.

Oh, I see. Yeah, that would be very nice.

-Bo

Re: Layered display API

[Eli Zaretskii]

> From: Bo Lin <bo@dreamsphere.org>
> Cc: rudalics@gmx.at,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Thu, 14 Aug 2014 12:08:20 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> > What I meant is this: if you need to display below the last line of
> >> >> > the buffer text, put the overlay at EOB, and include newlines in the
> >> >> > overlay string when you need to move to the next screen line.  To
> >> >> > align text horizontally you could use spaces or align-to display
> >> >> > properties in the string.
> >> >> 
> >> >> Yes, I might try this, as soon as there's some suggestion how to handle 
> >> >> the problem of `line-prefix' in this multi-overlay approach.
> >> >
> >> > Find the longest prefix and align everything so that the left edge
> >> > keeps clear of that?
> >> 
> >> Zero length overlays don't get displayed so this won't work when the
> >> buffer is empty.
> >
> > When a buffer is empty, there are no line prefixes, right?  Or did I
> > misunderstand what you eman?
> 
> I thought this was about avoid padding the buffer text with
> newlines?

Sorry, it wasn't clear, as the previous citations talked about both.

So turning to the padding the buffer: it's not about padding with
newlines, it's about including newlines in overlay string.  After the
newline, the overlay string would have the text to be displayed beyond
the EOB.

Re: Layered display API

[Bo Lin]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bo Lin <bo@dreamsphere.org>
>> Cc: rudalics@gmx.at,  emacs-devel@gnu.org,  dgutov@yandex.ru
>> Date: Thu, 14 Aug 2014 12:08:20 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> >> > What I meant is this: if you need to display below the last line of
>> >> >> > the buffer text, put the overlay at EOB, and include newlines in the
>> >> >> > overlay string when you need to move to the next screen line.  To
>> >> >> > align text horizontally you could use spaces or align-to display
>> >> >> > properties in the string.
>> >> >> 
>> >> >> Yes, I might try this, as soon as there's some suggestion how to handle 
>> >> >> the problem of `line-prefix' in this multi-overlay approach.
>> >> >
>> >> > Find the longest prefix and align everything so that the left edge
>> >> > keeps clear of that?
>> >> 
>> >> Zero length overlays don't get displayed so this won't work when the
>> >> buffer is empty.
>> >
>> > When a buffer is empty, there are no line prefixes, right?  Or did I
>> > misunderstand what you eman?
>> 
>> I thought this was about avoid padding the buffer text with
>> newlines?
>
> Sorry, it wasn't clear, as the previous citations talked about both.
>
> So turning to the padding the buffer: it's not about padding with
> newlines, it's about including newlines in overlay string.  After the
> newline, the overlay string would have the text to be displayed beyond
> the EOB.

Ah, I just realized the 'before/after-string properties does get
displayed even on zero length overlays. So yeah, this does work,
sorry for noise.

-Bo

Re: Layered display API

[Stefan Monnier]

>> Basically, we'd like to be able to display a rectangle with propertized 
>> text inside, at an arbitrary position (I would say pixel coordinates, 
>> but that might not work well in terminal), so that it would be displayed 
>> above the buffer contents.
> That you already have, don't you?

I don't think we do.

> Why can't you include the newline in the overlay string instead?

I wonder as well.

> This is indeed a missing feature.  It should be easy enough to provide
> some special kind of display property that would overlay any other
> displayed content,

A similar request was made to overlay non-text content.

> but won't that introduce the kind of arms race we already have with
> overlay priorities?

We have tons of such arms races in the current display system
(e.g. faces, invisibility, ...).  It'd be nice to solve them, but
I don't think this is an argument against providing another display
feature that also suffers from such arms races.

> Btw, why doesn't company use normal tooltips on GUI frames and
> text-mode menus on a TTY?  Wouldn't that be better?

Normal tooltips can be used but have their own problems (I'm pretty sure
one of auto-complete, completion-ui, or other uses that in some cases).
E.g. depending on compile-time choices, they may be provided by the GUI
toolkit, in which case we have very little control about what features
they provide (key-bindings, fonts, colors, ...).

But yes, one possible direction is to spice up our support for "tooltip
frames" such that it can be used for such purposes without losing the
ability to control faces and key-bindings and with control over the
precise layout and the borders that might be drawn around it.


        Stefan

bug#18195: 24.3.92; window-screen-lines is not accurate

[Eli Zaretskii]

> From: Dmitry <dgutov@yandex.ru>
> Date: Tue, 05 Aug 2014 06:00:24 +0400
> 
> If I have line-spacing set, the value the above function returns is
> smaller than the actuall number of screen lines the window can contain.
> 
> For example, when I have the current Emacs frame maximized and
> line-spacing set to 0.2, (window-screen-lines) returns 46.66(6), whereas
> there are 48 fully-visible lines in the given window and one
> partially-visible one.

Fixed in revision 117425 on the emacs-24 branch.