Clarifying graphics protocol behavior with a=p
and placement ID zero
#7043
Replies: 2 comments 1 reply
-
On Mon, Jan 22, 2024 at 04:06:06PM -0800, Mitchell Hashimoto wrote:
Hi Kovid,
The terminal graphics protocol page does not seem to make any explicit statement for the behavior of the display action (`a=p`) with no placement ID set OR `p=0` explicitly. In implementing the spec, I've chosen to match Kitty's actual behavior but it may make sense to clarify this directly in the specification as well.
**(1)** Specifying that `p=0` is functionally equivalent to not specifying a placement ID at all. I believe this is the case.
Yes, the default values for all unspecified keys are documented. The
defaults for both id and placement are 0. See the table at the end.
**(2)** Specifying that `p=0` creates multiple new placements instead of replacing prior `p=0` placements. Or perhaps to put it another way, when `p=0` is specified, a custom internal ID is specified. Without this specification, this sentence in the specification makes it sound like only one placement should exist:
> If you send two placements with the same image id and placement id the second one will replace the first.
Both of the above points describe Kitty's actual behavior today, as far as I can tell.
I believe due to the unspecified behavior here, WezTerm also seems to exhibit bugs around these cases (I'll open an issue there after I get clarification on what the exact behavior should be).
The spec says:
```
If you specify a placement id for an image that does
not have an id (i.e. has id=0), it will be ignored. In particular this means
there can exist multiple images with ``image id=0, placement id=0``.
```
However, multiple images with id=x (where x != 0) and p=0 lead to only a
single image, i.e., there is no internal placement id. I suppose I can
add a sentence clarifying that. Easily checked by doing:
kitten icat --image-id 1 some.png
and repeating multiple times.
…
Thank you.
--
Reply to this email directly or view it on GitHub:
#7043
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
Beta Was this translation helpful? Give feedback.
1 reply
-
Ah, right sorry, you are talking of the case of one transmit and
multiple placements, yes in that case multiple placements *without
placement ids* can be created, note that they *do not* have an internal
placement id, and they cannot be addressed by any future graphics commands.
I have committed a fix to the spec, thanks.
|
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
kovidgoyal
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi Kovid,
The terminal graphics protocol page does not seem to make any explicit statement for the behavior of the display action (
a=p
) with no placement ID set ORp=0
explicitly. In implementing the spec, I've chosen to match Kitty's actual behavior but it may make sense to clarify this directly in the specification as well.(1) Specifying that
p=0
is functionally equivalent to not specifying a placement ID at all. I believe this is the case.(2) Specifying that
p=0
creates multiple new placements instead of replacing priorp=0
placements. Or perhaps to put it another way, whenp=0
is specified, a custom internal ID is specified. Without this specification, this sentence in the specification makes it sound like only one placement should exist:But if I don't specify a placement ID, it appears that Kitty will allow multiple placements. This is also true if I explicitly specify
p=0
.Both of the above points describe Kitty's actual behavior today, as far as I can tell.
I believe due to the unspecified behavior here, WezTerm also seems to exhibit bugs around these cases (I'll open an issue there after I get clarification on what the exact behavior should be).
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions