[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64927: 30.0.50; kill-ring with no X
From: |
Eli Zaretskii |
Subject: |
bug#64927: 30.0.50; kill-ring with no X |
Date: |
Thu, 03 Aug 2023 21:26:47 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: m43cap@yandex.com, 64927@debbugs.gnu.org, larsi@gnus.org
> Date: Thu, 03 Aug 2023 12:30:36 -0400
>
> I think this problem was noticed when the new feature was introduced and
> we fixed the generation of the kill-ring menu, but apparently nobody
> fixed the problem in the second part of the code which generates the
> kill-ring (I remember I mentioned at the time that we should try and
> consolidate those two code paths).
Looks like that, yes.
> > Do you see any reasonably practical way to get that back?
>
> The best we can do is to use `key-valid-p` as a best-effort test to
> decide whether we're in the presence of the new or the old format, but
> it will inevitably suffer from false positives/negatives.
Not sure I understand: if key-valid-p returns nil, what do you suggest
to do with "keys" such as those produced in the scenario of this bug
report?
- bug#64927: 30.0.50; kill-ring with no X, Eli Zaretskii, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X, Stefan Monnier, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X, Eli Zaretskii, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X, Eli Zaretskii, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X, Stefan Monnier, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X,
Eli Zaretskii <=
- bug#64927: 30.0.50; kill-ring with no X, Stefan Monnier, 2023/08/03
- bug#64927: 30.0.50; kill-ring with no X, Colin Baxter, 2023/08/04
- bug#64927: 30.0.50; kill-ring with no X, Eli Zaretskii, 2023/08/04
bug#64927: 30.0.50; kill-ring with no X, Colin Baxter, 2023/08/03