GNU bug report logs -
#71866
30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Previous Next
Full log
Message #134 received at 71866 <at> debbugs.gnu.org (full text, mbox):
On 24/07/2024 22:22, Dmitry Gutov wrote:
> On 24/07/2024 19:29, Eli Zaretskii wrote:
>>> Date: Wed, 24 Jul 2024 17:34:18 +0300
>>> Cc: alan <at> idiocy.org, 71866 <at> debbugs.gnu.org
>>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>>
>>>> Then I don't understand what you mean by "many/most characters become
>>>> blank under cursor". It seems to contradict what you say now: that
>>>> "only one char is blanked".
>>>
>>> In the recipe I managed to produce starting with 'emacs -Q', only 's' is
>>> such a character (see the original description). When point is over 'a'
>>> or 'd', no bug.
>>>
>>> In actual practice, many/all characters exhibit the problem, I just
>>> haven't managed to create a simple repro for this.
>>
>> Curiouser and curiouser. And when you say that 's' is a character
>> that is blanked, does it mean that if you have several such
>> characters, then moving the cursor to any of them will show the
>> problem?
>
> Yes: with buffer contents 'asdasdasdasd' (or any small variations of
> that), only the 's' chars exhibit the problem with the repro script.
>
> With my custom init, all of the chars exhibit the problem.
>
>> I don't understand even in principle how a display problem could be
>> specific to some characters, unless it's something related very
>> strongly to the font that is being used. So what happens in a session
>> in which 's' is a problematic character if you put a face property on
>> 's' that forces Emacs to use a different font?
>
> I tried something different: enabled variable-pitch-mode.
>
> * With the small repro script in the first message, the problem is gone.
>
> * With my custom init, the problem remains for all chars. *shrug*
OTOH, for example
(put-text-property (point) (1+ (point) 'font-lock-face '(:family "Arial"))
doesn't have that effect (when point is at one of the 's'-es) - the
bug's still there.
A couple of more experiments:
- Buffer text 'asdasdasdasdsssssssss' - the problem occurs only on at
the first 3 's'-es.
- Buffer text 'asdasdasdasdaaaaaaaaa' - the problem occurs at positions
2, 5, 8, 11 and [14..] - that is, the first 3 's'-es, and then for all
'a'-s at the end except the first one (that comes after the last 'd').
This bug report was last modified 1 year and 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.