Re: Keeping up; was Another Emacs incompatibility

[Nick Dokos]

Francis Belliveau <f.belliveau@comcast.net> writes:

> Seems to me that was the first thing that I tried.  
> Unfortunately, the OS is in charge at that point and it is looking for a GUI 
> feature triggered by C-g rather than passing it inside.
> Once the GUI level of the OS, usually Linux via ssh in my case, things
> seem to get stuck in some mode where only a mouse-click will fix the
> problem. Actually that means at least two layers of OS in are in the
> mix. I end up trying innocuous things like minimize, clicking inside
> the region, etc.  I eventually wake things up.  Maybe C-g after
> clicking inside the region will work.
>

Have you tried hitting ESC while the cursor is in the menu? That seems
to work "often" IME.

> The next time this happens I will try and not the entire sequence I
> used to eventually untangle myself.  It happens seldom enough now that
> I am working mostly remotely, since I encounter fewer machines that do
> not have my customizations installed.
>
>
>> On Aug 23, 2020, at 17:27, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> 
>> Francis Belliveau <f.belliveau@comcast.net> writes:
>> 
>>> Now let me ask a question that I have trouble with for a long time. My
>>> customizations turn off the menus and tool-bars because they take up
>>> valuable screen-space and I hate leaving the keyboard to use them.
>>> However, I often end up on a machine where my custom stuff does not
>>> exist and accidentally change the focus within emacs to a menu while
>>> moving focus between windows. How do I get emacs to focus back on the
>>> buffer so that I can go back to typing?I generally fight my way out of
>>> the problem, but I have yet to find a magic combination that I can
>>> remember to use next time
>> 
>> If the menu is Emacs' menu, C-g should do the trick.
>
>
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler