xterm-mouse-mode gives incorrect posn-object-x-y with display space

xterm-mouse-mode gives incorrect posn-object-x-y with display space

[JD Smith]

The mouse-down events delivered by xterm-mouse-mode do not appear to handle clicks on entities with specified space display widths correctly.  Try this in a graphical window, and again in the terminal, with xterm-mouse-mode enabled:

(defun my/report-mouse (ev)
  (interactive "e")
  (let* ((posn (event-start ev))
	 (rel (posn-object-x-y posn)))
    (message "Got Relative Position %S" rel)))

(insert "\n\n  ----  "
        (propertize " "
                    'extend nil
                    'display '(space :width (48))
                    'keymap '(keymap (down-mouse-1 . my/report-mouse))
                    'font-lock-face 'underline)
        "  ----  ")

Mouse 1 click positions relative to the extended-width space (underlined for visibility) are reported correctly in graphical emacs, in screen pixel units.  With xterm-mouse-mode, however, relative positions are always reported as (0 . 0) for me, no matter where you click.  Is something wrong with my assumption that posn-object-x-y should work similarly in graphical as well as terminal emacs with xterm-mouse-mode (modulo the larger “pixel” size)?

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Stefan Monnier]

Hi JD,

Could you re-send this via `M-x report-emacs-bug`.


        Stefan


JD Smith [2022-11-24 12:22:44] wrote:

> The mouse-down events delivered by xterm-mouse-mode do not appear to handle clicks on entities with specified space display widths correctly.  Try this in a graphical window, and again in the terminal, with xterm-mouse-mode enabled:
>
> (defun my/report-mouse (ev)
>   (interactive "e")
>   (let* ((posn (event-start ev))
> 	 (rel (posn-object-x-y posn)))
>     (message "Got Relative Position %S" rel)))
>
> (insert "\n\n  ----  "
>         (propertize " "
>                     'extend nil
>                     'display '(space :width (48))
>                     'keymap '(keymap (down-mouse-1 . my/report-mouse))
>                     'font-lock-face 'underline)
>         "  ----  ")
>
> Mouse 1 click positions relative to the extended-width space (underlined for visibility) are reported correctly in graphical emacs, in screen pixel units.  With xterm-mouse-mode, however, relative positions are always reported as (0 . 0) for me, no matter where you click.  Is something wrong with my assumption that posn-object-x-y should work similarly in graphical as well as terminal emacs with xterm-mouse-mode (modulo the larger “pixel” size)?

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 24 Nov 2022 12:22:44 -0500
> 
> The mouse-down events delivered by xterm-mouse-mode do not appear to handle clicks on entities with specified space display widths correctly.  Try this in a graphical window, and again in the terminal, with xterm-mouse-mode enabled:
> 
> (defun my/report-mouse (ev)
>   (interactive "e")
>   (let* ((posn (event-start ev))
> 	 (rel (posn-object-x-y posn)))
>     (message "Got Relative Position %S" rel)))
> 
> (insert "\n\n  ----  "
>         (propertize " "
>                     'extend nil
>                     'display '(space :width (48))
>                     'keymap '(keymap (down-mouse-1 . my/report-mouse))
>                     'font-lock-face 'underline)
>         "  ----  ")
> 
> Mouse 1 click positions relative to the extended-width space (underlined for visibility) are reported correctly in graphical emacs, in screen pixel units.  With xterm-mouse-mode, however, relative positions are always reported as (0 . 0) for me, no matter where you click.  Is something wrong with my assumption that posn-object-x-y should work similarly in graphical as well as terminal emacs with xterm-mouse-mode (modulo the larger “pixel” size)?

This has nothing to do with xterm-mouse.  You simply expect something that
is not supported: when posn-object-x-y says OBJECT, it refers to what
posn-object can return, which is either a string or an image.  IOW, objects
that are Lisp objects, which Lisp programs can access and manipulate.  By
contrast, stretch glyphs produced by 'display' "space" specs are not objects
exposed to Lisp, and for them the X/Y offsets of mouse events are
meaningless.  That in case of GUI frames you get pixel offsets from the
beginning of the stretch is a side effect of the implementation of stretch
glyphs on GUI frames; the TTY implementation is different, so you always get
zero.  You will see the same in text terminals equipped with a mouse, like
when Emacs runs with -nw switch on a terminal with GPM mouse on GNU/Linux or
the MS-Windows shell window.

So bottom line, you shouldn't expect DX and DY offsets in click position
data to be meaningful in this case.

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[JD Smith]

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

Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly well on normal width characters in the buffer, providing pixel level information on where *within the character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left corner” would mean other than this for a "string object".  Surely that is not an accident of the implementation!

But it sounds like internal position X/Y offsets for specified spaces in GUI vs. TTY are not reliable, so maybe I should stop using them.

Is there a reliable way to determine where (in pixels [1]) the mouse was clicked relative to a string displayed with specified space, which works equally in the GUI and TTYs?   Keep in mind that the string may not be at a fixed column, but at an arbitrary pixel offset from the window (due to prior specified space, variable width fonts, etc.).  

[1] Obviously in the TTY 1 pixel = 1 char.

> On Nov 24, 2022, at 1:34 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Thu, 24 Nov 2022 12:22:44 -0500
>> 
>> The mouse-down events delivered by xterm-mouse-mode do not appear to handle clicks on entities with specified space display widths correctly.  Try this in a graphical window, and again in the terminal, with xterm-mouse-mode enabled:
>> 
>> (defun my/report-mouse (ev)
>>  (interactive "e")
>>  (let* ((posn (event-start ev))
>> 	 (rel (posn-object-x-y posn)))
>>    (message "Got Relative Position %S" rel)))
>> 
>> (insert "\n\n  ----  "
>>        (propertize " "
>>                    'extend nil
>>                    'display '(space :width (48))
>>                    'keymap '(keymap (down-mouse-1 . my/report-mouse))
>>                    'font-lock-face 'underline)
>>        "  ----  ")
>> 
>> Mouse 1 click positions relative to the extended-width space (underlined for visibility) are reported correctly in graphical emacs, in screen pixel units.  With xterm-mouse-mode, however, relative positions are always reported as (0 . 0) for me, no matter where you click.  Is something wrong with my assumption that posn-object-x-y should work similarly in graphical as well as terminal emacs with xterm-mouse-mode (modulo the larger “pixel” size)?
> 
> This has nothing to do with xterm-mouse.  You simply expect something that
> is not supported: when posn-object-x-y says OBJECT, it refers to what
> posn-object can return, which is either a string or an image.  IOW, objects
> that are Lisp objects, which Lisp programs can access and manipulate.  By
> contrast, stretch glyphs produced by 'display' "space" specs are not objects
> exposed to Lisp, and for them the X/Y offsets of mouse events are
> meaningless.  That in case of GUI frames you get pixel offsets from the
> beginning of the stretch is a side effect of the implementation of stretch
> glyphs on GUI frames; the TTY implementation is different, so you always get
> zero.  You will see the same in text terminals equipped with a mouse, like
> when Emacs runs with -nw switch on a terminal with GPM mouse on GNU/Linux or
> the MS-Windows shell window.
> 
> So bottom line, you shouldn't expect DX and DY offsets in click position
> data to be meaningful in this case.


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

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 24 Nov 2022 16:42:29 -0500
> Cc: emacs-devel@gnu.org
> 
> Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a
> stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the
> GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly
> well on normal width characters in the buffer, providing pixel level information on where *within the
> character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left
> corner” would mean other than this for a "string object".  Surely that is not an accident of the
> implementation!

Yes, but on TTY frames the DX/DY _within_ the character glyph are always
zero, because each character is considered to be exactly one "pixel".  And
if I tell you that stretches of whitespace produced by 'space' display specs
are implemented on TTY as sequences of SPC characters (of course, what
else?), then I think you will understand why the DX/DY values, defined in
the ELisp manual as "the coordinates relative to the top left corner of the
character glyph clicked on", on a TTY are always zero: wherever the click
is, it is always on a glyph of some SPC character from those that represent
the stretch of whitespace.

> But it sounds like internal position X/Y offsets for specified spaces in GUI vs. TTY are not reliable, so maybe
> I should stop using them.

On TTY, you will always get zero DX/DY, so if this is deemed "unreliable",
then yes, you should not use that for your needs, whatever those are.

> Is there a reliable way to determine where (in pixels [1]) the mouse was clicked relative to a string displayed
> with specified space, which works equally in the GUI and TTYs?   Keep in mind that the string may not be at
> a fixed column, but at an arbitrary pixel offset from the window (due to prior specified space, variable width
> fonts, etc.).  

Please tell more about your use case.  I don't think I understand what you
mean by "string displayed with specified space"; AFAIU there were no display
or overlay strings in the recipe you posted, and no description of what you
are trying to do with the 'space' spec that the DX/DY offsets are so
important.

If I have to guess what you want, then my suggestion would be to use
something like this:

  (let* ((event-posn (posn-point (event-start ev)))
         (click-x-y (posn-x-y (event-start ev)))
         (obj-x-y (posn-x-y (posn-at-point event-posn))))
    (cons (- (car click-x-y) (car obj-x-y))
          (- (cdr click-x-y) (cdr obj-x-y))))

IOW, don't trust DX/DY, but calculate the offsets "by hand".

But that's a guess.

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[JD Smith]

> On Nov 25, 2022, at 2:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Thu, 24 Nov 2022 16:42:29 -0500
>> Cc: emacs-devel@gnu.org
>> 
>> Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a
>> stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the
>> GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly
>> well on normal width characters in the buffer, providing pixel level information on where *within the
>> character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left
>> corner” would mean other than this for a "string object".  Surely that is not an accident of the
>> implementation!
> 
> Yes, but on TTY frames the DX/DY _within_ the character glyph are always
> zero, because each character is considered to be exactly one "pixel".  And
> if I tell you that stretches of whitespace produced by 'space' display specs
> are implemented on TTY as sequences of SPC characters (of course, what
> else?), then I think you will understand why the DX/DY values, defined in
> the ELisp manual as "the coordinates relative to the top left corner of the
> character glyph clicked on", on a TTY are always zero: wherever the click
> is, it is always on a glyph of some SPC character from those that represent
> the stretch of whitespace.

Thanks for these details.  This I had indeed understood; with char units, you can’t and won't get any pixel offsets within a single char glyph.  Since for the TTY, Emacs implements a specified space under the hood as a “series of spaces”, the natural thing for consistency with the GUI would be for posn-object-x-y to report click position offsets (in integer character units, naturally) within that stretched space.  It sounds like this may be challenging to implement internally, but it would be the most consistent.  It must be possible, since Emacs 1) knows it drew a specified space as a series of space chars in the TTY, and 2) knows (or could know) where the click occurred within that group of space chars it drew.

To summarize, the fact that in the TTY a stretched space is implemented as a collection of space chars, and on GUI, some other type of pixel-precise graphical element is IMO just an implementation detail.  What if TTY’s of the future allow drawing small graphical elements at pixel precision? How is the user of posn-object-* to know which of the two different and incompatible result flavors they will get?

>> Is there a reliable way to determine where (in pixels [1]) the mouse was clicked relative to a string displayed
>> with specified space, which works equally in the GUI and TTYs?   Keep in mind that the string may not be at
>> a fixed column, but at an arbitrary pixel offset from the window (due to prior specified space, variable width
>> fonts, etc.).  
> 
> Please tell more about your use case.  I don't think I understand what you
> mean by "string displayed with specified space”;

This is how I implement mlscroll, a mode line scroll bar we’ve discussed here before.  The basic design is 3 specified spaces in a row , usually right-aligned in the mode line. Together these 3 (varying width) spaces indicate the number of lines: i) above ii) showing, and iii) after the window.  Just like a “real” scrollbar, the user can interact with it by clicking/dragging/etc.  When clicking on the bar, the precise relative click position determines what lines are scrolled into view (again, just like a real scrollbar).  Surprisingly it looks pretty good on TTY without any special casing, though obviously with char- instead of pixel-granularity.  But this happy consistency breaks down with xterm-mouse-mode, since clicks on the modeline scrollbar are not reportable as positions w.r.t. the clicked element, i.e. since posn-object-x-y always reports 0 on TTY.  

> If I have to guess what you want, then my suggestion would be to use
> something like this:
> 
>  (let* ((event-posn (posn-point (event-start ev)))
>         (click-x-y (posn-x-y (event-start ev)))
>         (obj-x-y (posn-x-y (posn-at-point event-posn))))
>    (cons (- (car click-x-y) (car obj-x-y))
>          (- (cdr click-x-y) (cdr obj-x-y))))
> 
> IOW, don't trust DX/DY, but calculate the offsets "by hand".


Thanks for your good suggestion; this would indeed work as desired in the buffer, since posn-at-point does seem to “know” it’s in a specified space in both GUI and TTY (which makes me think posn-object-x-y should also be able to know this).

Unfortunately posn-point returns nil for posn-area = mode-line, so this does not solve the problem.  Is there any other way you know to determine the starting char position of the _group of spaces_ that TTY Emacs translates a specified space into, in the mode line?  Calculating the char-start of the scrollbar myself will be challenging given dynamic modeline elements and the possibility for the user to place the scrollbar anywhere they want (i.e. not just right-aligned).

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 24 Nov 2022 16:42:29 -0500
> Cc: emacs-devel@gnu.org
> 
> Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a
> stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the
> GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly
> well on normal width characters in the buffer, providing pixel level information on where *within the
> character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left
> corner” would mean other than this for a "string object".  Surely that is not an accident of the
> implementation!

posn-object-x-y for a display/overlay string measure from the nearest glyph
of the string character, not from the beginning of the string.

> > Yes, but on TTY frames the DX/DY _within_ the character glyph are always
> > zero, because each character is considered to be exactly one "pixel".  And
> > if I tell you that stretches of whitespace produced by 'space' display specs
> > are implemented on TTY as sequences of SPC characters (of course, what
> > else?), then I think you will understand why the DX/DY values, defined in
> > the ELisp manual as "the coordinates relative to the top left corner of the
> > character glyph clicked on", on a TTY are always zero: wherever the click
> > is, it is always on a glyph of some SPC character from those that represent
> > the stretch of whitespace.
> 
> Thanks for these details.  This I had indeed understood; with char units, you can’t and won't get any pixel offsets within a single char glyph.  Since for the TTY, Emacs implements a specified space under the hood as a “series of spaces”, the natural thing for consistency with the GUI would be for posn-object-x-y to report click position offsets (in integer character units, naturally) within that stretched space.  It sounds like this may be challenging to implement internally, but it would be the most consistent.  It must be possible, since Emacs 1) knows it drew a specified space as a series of space chars in the TTY, and 2) knows (or could know) where the click occurred within that group of space chars it drew.

The problem is that the "knowledge" about stretch implementation is on a
much lower level than the one on which posn-object-x-y operates.  On the
level of posn-object-x-y there's no stretch, just the position and the
metrics of the glyphs it produced.

> To summarize, the fact that in the TTY a stretched space is implemented as a collection of space chars, and on GUI, some other type of pixel-precise graphical element is IMO just an implementation detail.  What if TTY’s of the future allow drawing small graphical elements at pixel precision? How is the user of posn-object-* to know which of the two different and incompatible result flavors they will get?

If that ever happens, "Someone" will have a lot of work on their hands.

> This is how I implement mlscroll, a mode line scroll bar we’ve discussed here before.  The basic design is 3 specified spaces in a row , usually right-aligned in the mode line. Together these 3 (varying width) spaces indicate the number of lines: i) above ii) showing, and iii) after the window.  Just like a “real” scrollbar, the user can interact with it by clicking/dragging/etc.  When clicking on the bar, the precise relative click position determines what lines are scrolled into view (again, just like a real scrollbar).  Surprisingly it looks pretty good on TTY without any special casing, though obviously with char- instead of pixel-granularity.  But this happy consistency breaks down with xterm-mouse-mode, since clicks on the modeline scrollbar are not reportable as positions w.
 r.t. the clicked element, i.e. since posn-object-x-y always reports 0 on TTY.  

I don't understand what you mean by "surprisingly it looks pretty good on
TTY without any special casing", if mouse clicks on TTY frames give you this
problem.  Are you saying that you only see this with xterm-mouse-mode, but
not with some other mouse which works with Emacs TTY frames?

> >  (let* ((event-posn (posn-point (event-start ev)))
> >         (click-x-y (posn-x-y (event-start ev)))
> >         (obj-x-y (posn-x-y (posn-at-point event-posn))))
> >    (cons (- (car click-x-y) (car obj-x-y))
> >          (- (cdr click-x-y) (cdr obj-x-y))))
> > 
> > IOW, don't trust DX/DY, but calculate the offsets "by hand".
> 
> 
> Thanks for your good suggestion; this would indeed work as desired in the buffer, since posn-at-point does seem to “know” it’s in a specified space in both GUI and TTY (which makes me think posn-object-x-y should also be able to know this).
> 
> Unfortunately posn-point returns nil for posn-area = mode-line, so this does not solve the problem.  Is there any other way you know to determine the starting char position of the _group of spaces_ that TTY Emacs translates a specified space into, in the mode line?  Calculating the char-start of the scrollbar myself will be challenging given dynamic modeline elements and the possibility for the user to place the scrollbar anywhere they want (i.e. not just right-aligned).

Why challenging?  On TTY frames, align-to always aligns to some character
position, and the mouse clicks are reported in terms of character positions
as well.  Why do you even need the fine details of the POSITION part of the
mouse-click events on TTY frames?

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Akib Azmain Turja]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Thu, 24 Nov 2022 16:42:29 -0500
>> Cc: emacs-devel@gnu.org
>> 
>> Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a
>> stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the
>> GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly
>> well on normal width characters in the buffer, providing pixel level information on where *within the
>> character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left
>> corner” would mean other than this for a "string object".  Surely that is not an accident of the
>> implementation!
>
> posn-object-x-y for a display/overlay string measure from the nearest glyph
> of the string character, not from the beginning of the string.
>
>> > Yes, but on TTY frames the DX/DY _within_ the character glyph are always
>> > zero, because each character is considered to be exactly one "pixel".  And
>> > if I tell you that stretches of whitespace produced by 'space' display specs
>> > are implemented on TTY as sequences of SPC characters (of course, what
>> > else?), then I think you will understand why the DX/DY values, defined in
>> > the ELisp manual as "the coordinates relative to the top left corner of the
>> > character glyph clicked on", on a TTY are always zero: wherever the click
>> > is, it is always on a glyph of some SPC character from those that represent
>> > the stretch of whitespace.
>> 
>> Thanks for these details.  This I had indeed understood; with char
>> units, you can’t and won't get any pixel offsets within a single
>> char glyph.  Since for the TTY, Emacs implements a specified space
>> under the hood as a “series of spaces”, the natural thing for
>> consistency with the GUI would be for posn-object-x-y to report
>> click position offsets (in integer character units, naturally)
>> within that stretched space.  It sounds like this may be challenging
>> to implement internally, but it would be the most consistent.  It
>> must be possible, since Emacs 1) knows it drew a specified space as
>> a series of space chars in the TTY, and 2) knows (or could know)
>> where the click occurred within that group of space chars it drew.
>
> The problem is that the "knowledge" about stretch implementation is on a
> much lower level than the one on which posn-object-x-y operates.  On the
> level of posn-object-x-y there's no stretch, just the position and the
> metrics of the glyphs it produced.
>
>> To summarize, the fact that in the TTY a stretched space is
>> implemented as a collection of space chars, and on GUI, some other
>> type of pixel-precise graphical element is IMO just an
>> implementation detail.  What if TTY’s of the future allow drawing
>> small graphical elements at pixel precision? How is the user of
>> posn-object-* to know which of the two different and incompatible
>> result flavors they will get?
>
> If that ever happens, "Someone" will have a lot of work on their hands.
>
>> This is how I implement mlscroll, a mode line scroll bar we’ve
>> discussed here before.  The basic design is 3 specified spaces in a
>> row , usually right-aligned in the mode line. Together these 3
>> (varying width) spaces indicate the number of lines: i) above ii)
>> showing, and iii) after the window.  Just like a “real” scrollbar,
>> the user can interact with it by clicking/dragging/etc.  When
>> clicking on the bar, the precise relative click position determines
>> what lines are scrolled into view (again, just like a real
>> scrollbar).  Surprisingly it looks pretty good on TTY without any
>> special casing, though obviously with char- instead of
>> pixel-granularity.  But this happy consistency breaks down with
>> xterm-mouse-mode, since clicks on the modeline scrollbar are not
>> reportable as positions w.r.t. the clicked element, i.e. since
>> posn-object-x-y always reports 0 on TTY.
>
> I don't understand what you mean by "surprisingly it looks pretty good on
> TTY without any special casing", if mouse clicks on TTY frames give you this
> problem.  Are you saying that you only see this with xterm-mouse-mode, but
> not with some other mouse which works with Emacs TTY frames?
>
>> >  (let* ((event-posn (posn-point (event-start ev)))
>> >         (click-x-y (posn-x-y (event-start ev)))
>> >         (obj-x-y (posn-x-y (posn-at-point event-posn))))
>> >    (cons (- (car click-x-y) (car obj-x-y))
>> >          (- (cdr click-x-y) (cdr obj-x-y))))
>> > 
>> > IOW, don't trust DX/DY, but calculate the offsets "by hand".
>> 
>> 
>> Thanks for your good suggestion; this would indeed work as desired
>> in the buffer, since posn-at-point does seem to “know” it’s in a
>> specified space in both GUI and TTY (which makes me think
>> posn-object-x-y should also be able to know this).
>> 
>> Unfortunately posn-point returns nil for posn-area = mode-line, so
>> this does not solve the problem.  Is there any other way you know to
>> determine the starting char position of the _group of spaces_ that
>> TTY Emacs translates a specified space into, in the mode line?
>> Calculating the char-start of the scrollbar myself will be
>> challenging given dynamic modeline elements and the possibility for
>> the user to place the scrollbar anywhere they want (i.e. not just
>> right-aligned).
>
> Why challenging?  On TTY frames, align-to always aligns to some character
> position, and the mouse clicks are reported in terms of character positions
> as well.  Why do you even need the fine details of the POSITION part of the
> mouse-click events on TTY frames?
>

They (probably a grammatical mistake) are the maintainer of the mlscroll
package, that implement scroll bar in mode line, but using specified
space.  That's why they need the click position *precisely*.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: JD Smith <jdtsmith@gmail.com>,  emacs-devel@gnu.org
> Date: Sun, 27 Nov 2022 00:56:06 +0600
> 
> > Why challenging?  On TTY frames, align-to always aligns to some character
> > position, and the mouse clicks are reported in terms of character positions
> > as well.  Why do you even need the fine details of the POSITION part of the
> > mouse-click events on TTY frames?
> 
> They (probably a grammatical mistake) are the maintainer of the mlscroll
> package, that implement scroll bar in mode line, but using specified
> space.  That's why they need the click position *precisely*.

You are missing my point: on TTY frames "precisely" means at character
position granularity.  There's no resolution below that, so accounting for
the number of glyphs in the stretch of whitespace should not present a
problem.  Unless I'm missing something.

Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[JD Smith]

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



> On Nov 26, 2022, at 7:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 

> posn-object-x-y for a display/overlay string measure from the nearest glyph
> of the string character, not from the beginning of the string.

Right.  My design of three adjacent stretched characters works well (in GUI anyway) by exploiting this. 

> I don't understand what you mean by "surprisingly it looks pretty good on
> TTY without any special casing", if mouse clicks on TTY frames give you this
> problem.  Are you saying that you only see this with xterm-mouse-mode, but
> not with some other mouse which works with Emacs TTY frames?

I only mean it _looks_ good there: the slider moves, and reports the scroll position well, just more granularly, and with no direct mouse interaction possible (or so I thought).  For mouse on TTY I’ve only tried (and only have access to) xterm-mouse-mode; in fact wasn’t even aware of it until a user opened an issue.  

> Why challenging?  On TTY frames, align-to always aligns to some character
> position, and the mouse clicks are reported in terms of character positions
> as well.  

Not impossible, just more complicated, since there are a number of alignment options, only some of which use align-to.  For example you can just replace mode-line-percent-position with the graphical scrollbar, or the user can place the scrollbar at an arbitrary position in the modeline.  And calculating the left boundary in the GUI is complicated by proportional fonts, images, and all sorts of things, so this would require serious special casing for the TTY.  It’s too bad posn-point doesn’t work in the modeline. 

> Why do you even need the fine details of the POSITION part of the
> mouse-click events on TTY frames?

I use the width of the scrollbar as an analog “fractional line position” area.  The precise click scrolls with window to that exact analogous location.  In the TTY “precise” simply means “which character”, but in the GUI it’s “which pixel”.  I don’t know how many people use mouse in a TTY, so I may just prevent it from doing harm but otherwise leave it disabled.  Thanks for the suggestions.


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