Is there a way to get relative position to a single cell with mouse events?

[ldemailly]

To get square pixels TUI apps often use

	TopHalfPixel    = '▀'
	BottomHalfPixel = '▄'

But mouse tracking "\033[?1003h" only gives terminal grid coordinates

I'm aware of "\x1b[?1016h" which is in pixels but then you need to map pixels to the grid and it's also quite verbose and less supported

So I was wondering if we can use bit 7 and maybe 8 of Cb though... not sure of the actual encoding/if it makes sense

[mitchellh]

If the existing protocols do this, then I'm happy to support. If they do not, we're discussing a brand new terminal behavior and we should move to discussions. cc @rockorager

[rockorager]

This would definitely be a new protocol. I don't think it's worth adding another protocol for this though, since the TUI can get enough info to calculate it from the pixel reports. This protocol would just push that calculation onto the emulator. And the likelihood of a "proximity" based protocol becoming more adopted than the existing pixel protocol is very unlikely.

[mitchellh]

Yeah that was my feeling as well. I think the best solution to this would be:

1. Use in-band size reports
2. Use mouse mode with pixels

This provides all the numbers to do trivial math to figure out offset within a cell. Since in-band size reports happen in-band, you can be confident in the order they're providing with respect to mouse reports for consistency with the terminal grid.

Since this issue was proposing totally new terminal behavior anyways, using something like in-band reports which is still only supported by a few terminals (Ghostty included) is still strictly better. 😄

[ldemailly]

I was proposing to keeping but extending the x10 , terminal grid coordinates one, using the same codes as there seems to be bits available

This protocol would just push that calculation onto the emulator.

The point actually is that's already what the emulator does: it gets the host mouse and find which grid terminal coordinates match (including whichever real coordinate it is without lag as it knows its own size)

That calculation is unnecessary complex for most apps

But if we do do a new protocol, I do think it should be in TermX,TermY,%X,%Y ie relative to the terminal grid
(yet again I'm asking for just 1 or 2 bits in the existing CSI M

[mitchellh]

I believe introducing subtle incompatibilities in existing standards (even if they're part of "unused" portions) is more dangerous than ripping the bandaid and introducing a new separate sequence.

But if we do do a new protocol, I do think it should be in TermX,TermY,%X,%Y ie relative to the terminal grid
(yet again I'm asking for just 1 or 2 bits in the existing CSI M

This is more intriguing as a proposal. I don't want to modify the format of existing reports at all. They're longstanding defacto standards and even using unused bits or introducing portions that in theory shouldn't be parsed is an issue due to Hyrum's Law. Introducing a new mode would be better.

[ldemailly]

not sure I use the right terminology so to clarify maybe

if I have 80x24 terminal, assuming 1,1 (or maybe 0,0 in a new proto) in the top left corner

and my mouse is over the 2nd line and 3rd character (even if that one is double width) but on 3/4 of the way toward the bottom right corner of that character, I would get (before encoding)

2,3,75,75

or to save some space maybe smaller resolution like just 2 bits 0 (00) ==top left quadrant of that character, 1 (01), top right; 2 (10) bottom left, 3 (11) bottom right

2,3,3

just examples/illustration (I suppose it'd be encoded with usual range offsets for ansi stuff and stay on 3 characters)