(170/211) 3933 - Splitting shortcuts does not work correctly on Mac OS X

I don't see anything suspicious in this combination. Key event problems, especially on Mac OS, have happened in the past -- usually it is either Apple or Oracle responsible for it. Such things can be tested with the KeyEventDemo application on https://docs.oracle.com/javase/tutorial/uiswing/events/keylistener.html

Today I've got a big update of El Capitan 10.11.1 from Apple. Maybe that makes the difference.

Right now I have noticed that the problem is more common – more shortcuts behave like this…

I am sure that there is nothing wrong with the OS or JDK – I am developing Java applications using the jEdit and my apps, using standard keyboard listeners, keystrokes, shortcuts, etc., behave just normally (in fact I have noticed one strange situation on the Windows system – right the opposite of this situation).

And also the problem did not just appeared with current release of jEdit. I was not honest, sorry… I have noticed this problem in previous releases of jEdit, I do not remember the version, it was long time ago, but then I installed unbundled daily release of jEdit and the problem disappeared, so I was happy enough… Now I decided to install current major release to “get rid” of the daily release temporary solution, but with this new major release the problem reappeared, so I decided to report it… I have no idea where it could be hidden… Baybe it is due bundling… I really have no idea…

All the Best!
Roman

:-))

I am myself not responsible for official jEdit bundling, but I have spent a lot of time on bundling Isabelle/jEdit on all platform families: Linux, Windows, Mac OS X, including many problems with keyboard varieties on these platforms. The Isabelle/jEdit bundling eliminates most "variables", the user has no choice of JDK.

Can you try http://www4.in.tum.de/~wenzelm/test/Isabelle_23-Oct-2015 and say if there is a difference? I've made that just yesterday based on the jedit-5.3.0 release -- the formal changeset is here: http://isabelle.in.tum.de/repos/isabelle/rev/d40f906bb13f

Hi,

I’ve found a free “window” in my timetable and tested the Isabelle. I was expecting a different result, but the behavior of the Isabelle was identical.

I am wondering what could stand behind this small but not very “nice” issue…
So I was curious and due this my curiosity I’ve installed the newest daily build of jEdit (from Oct 23 2015) and the application distributed this way behaves normally.

Please, can you recommend me some steps to help identify the roots of this issue? (I am wondering why other Mac users do not experience this issue. Or there are so few of them? Maybe they are just not using these shortcuts… Who knows?)

Roman

I don't think there is a significant difference in the sources of current repository version of jEdit (e.g. SVN 24115 from 2015-10-22) to the 5.3.0 release.

I see two possibilities:

1. Different packaging of official releases versus snapshots.
2. Different application startup.

From a distance, I would rather guess at 2.

Since I am more familiar with Isabelle/jEdit bundling than the official one, the test is again from that. What happens when you run the following from the Terminal on Mac OS X El Capitan 11.11?

.../Isabelle_23-Oct-2015/Isabelle/bin/isabelle jedit


Alternatively, you can try this with any java and jedit.jar you find:

java -version
java -jar .../jedit.jar


Of course, you need to interpolate the `...` directory correctly, depending where things are.


Moreover, to see how key strokes are actually interpreted by jEdit, you may go to Utilities / Global Options / Shortcuts and then remap e.g. the action "About jEdit ...". In the little dialog box "Specify shortcut" the input field shows interpreted key events in jEdit notation.

Another question: What is your keyboard layout?

Hi, I ran all the commands.

-----

After execution the `…/bin/isabelle jedit` the behavior was the same. I tried to remap the shortcut for “Split Horizontally” and following happened:

* After I pressed for example `Command+W`, everything was okay.
* After I pressed for example `Command+2`, the `Command+2` appeared in the dialog input box, but jEdit beeped once to signalize that some extra keystroke has been rejected.
* After pressing `Command+2` again the situation (almost) repeated: extra one `Command+2` has been shown – like I would try to define combined keyboard shortcut – but the duplicate (within single iteration) has been rejected (with the beeping) again.

-----

~~~~
java -version
~~~~

showed:

~~~~
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
~~~~

-----

~~~~
java -jar jedit.jar
~~~~

from Isabelle’s `Contents/Java` showed:

~~~~
System keymap folder do not exist, your installation is broken.Install keymaps in /Users/romanhorvath/Desktop/Isabelle_23-Oct-2015.app/Contents/Java/keymaps
~~~~

(It might be a clue… or might not…)

-----

My keyboard layout (it might mean something) is Slovak QWERTY (unimportant notice: more common in my country is QWERTZ, but I dislike the Slovak Y and Z swap :-) ).

I've made some more experiments myself, and it turns out that the key reason is the Slovak QWERTY keymap. I can confirm the problem with this keymap and the following combinations:

jdk-7u80 and jedit-5.2.0
jdk-8u66 and jedit-5.3.0

There is nonetheless a slight difference how C-2 is treated in the underlying Java versions. This can be seen by KeyEventDemo. This is for jdk-8u66:

KEY PRESSED:
key code = 50 (2)
modifiers = 4
extended modifiers = 256 (⌘)
action key? NO
key location: standard
KEY RELEASED:
key code = 50 (2)
modifiers = 4
extended modifiers = 256 (⌘)
action key? NO
key location: standard

For jdk-7u80, KEY PRESSED is the same, but KEY RELEASED is missing.

In both situations, the jEdit key event handling produces some degree of non-sense. This needs further investigation.

Meta question: Do you remember a combination of Java and jEdit versions where this worked properly?

After some more investigations here is a new summary of the situation:

* The problem occurs both on Mac OS X Mavericks and El Capitan (presumably also on Yosemite).
* Native Apple Look-and-feel needs to be enabled.
* It does not depend on the MacOSX plugin status: it may be either on or off.

Technically, the reason appears to be an odd conflict of menu accelerator keys vs. regular keyboard shortcuts managed by jEdit: when you type C-2 the "View" menu flashes briefly, indicating that one of its item have been selected, namely View / Splitting / Split Horizontally.

These observations also open the following workarounds:

* Use Utilities / Global Options / Shortcuts to delete the primary shortcut for this action and instead define it as alternative shortcut. Thus it is not installed as menu accelerator, and cannot get into conflict.
* Or: Avoid Apple look-and-feel, use Metal or Nimbus instead.
* Or: Keep Apple look-and-feel, but don't use the real Apple screen manu bar. E.g. like this:

java -Dapple.laf.useScreenMenuBar=false

The .app bundle contains that in Contents/Info.plist near the bottom, with the opposite value as default.


Meta-Note: I am quite familiar with the key event handling, because I've spent a long time upgrading all that for Java 7 on Mac OS X, which was the big move from Apple Java to Oracle Java. I am *not* familiar with the menu handling, I merely figured out that by watching closely what happens.

That's basically it. We need some jEdit admistrator to figure out what to do in the official version.

I see. It seems that the problem is going to be solved. Just find somebody who can help. Do you know somebody or can you contact the team?

To the older question: I do not remember the previous working version number. It was long time ago (I am not sure how much)… My solution was to use unbundled version, I updated it from daily build releases storage until the 5.3.0 went out.

Concerning unbundled versions that worked: I guess it was just due to different look-and-feel defaults, e.g. apple.laf.useScreenMenuBar.

This looks like a bug in the native Apple Look and Feel. I found it always troublesome so when I am on the mac, I am still using Metal L&F and as a result, the behavior is much closer to what i am accustomed to on other platforms. I suppose for the future, we must remember to ask reporters of MacOS bugs which Look and Feel they are using.

I agree that ultimately Oracle is responsible. In the past few years (of Java 7 on Mac OS X) the situation has actually improved slightly. E.g. a similar menu key shortcut conflict concerning C-ENTER has now disappeard, see http://isabelle.in.tum.de/repos/isabelle/rev/9c6346319eee

Maybe there is an easy way to produce a minimal example and submit them to the Java issue tracker?

I tried to create a mini-application that has text area (`JTextArea`) with keyboard shortcuts defined through input map mechanism and menu items with the same “shortcuts” definition that means with the same menu accelerators…

It was an attempt to simulate the situation. It was a blind shot because I do not know the details of jEdit’s code…

In my app, both ways of shortcuts definition work separately (when the `JTextArea` has focus). That means that keyboard commands may be defined by the keystrokes of `JTextArea`’s map or through menu accelerators. It is not necessary to use both ways to put the keyboard commands to work.

I have enabled Mac Look and Feel with `apple.laf.useScreenMenuBar` set to `true`. I was hoping that the double effect of shortcuts will come out, but my effort was just “waste of effort”… Mini-application works perfectly. The keyboard strokes override the menu items accelerators. There is no conflict.

I hoped that there is a hidden bug in JDK/JRE that will come out only when the Mac L&F with specific settings (…`ScreenMenuBar`) is enabled, but nothing came out…

Maybe the keyboard shortcuts should not be defined within the text area’s map; maybe they should be defined somewhere on the higher level or by using completely different mechanism… I don’t know… I was just curious; it was just blind shot… (I just found out where the problem doesn’t lie… :-) )

Can you attach the source of that mini application, or put it somewhere on a public repository?

I am attaching it – the zip contains two files…

TestDoubleKeystrokesOnMac.zip (4.5Kio)

Related ticket: https://sourceforge.net/p/jedit/bugs/3905/

If you (any of you) think the Mac keyboard shortcuts should be changed, please submit a patch to the keymaps/Mac_OS_X_Keys.props file.