A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00214.html below:

Re: [PATCH] On the nasty "ghost key" problem on NS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Po Lu Subject: Re: [PATCH] On the nasty "ghost key" problem on NS Date: Fri, 04 Nov 2022 17:29:02 +0800 User-agent: Gnus/5.13 (Gnus v5.13) 
Kai Ma <justksqsf@gmail.com> writes:

> Yes and no. Emacs still responds to new key events, but a previous
> call is stuck and does not return. Presumably in another thread. To be
> more clear: changing that code to be
>
>   static int enter_cnt, leave_cnt;
>   enter_cnt++;
>   [referenced piece of code]
>   leave_cnt++;
>   /* (Or just count the return/leave counts of (ns-in-echo-area).) */
>
> leave_cnt can be less than enter_cnt. I’ve confirmed re-entrance to
> [firstRectForCharacterRange] leads to the problem.

I'm going to guess what actually happened is that ns-in-echo-area
signalled.

What happens if you replace ns-in-echo-area with:

  safe_call (0, Qns_in_echo_area)

?

> Pardon my ignorance, is there any reason to special-case the echo
> area? Simply let win = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe))
> and the problem is gone.

I don't know.  I'd rather leave as much code untouched as possible.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4