#4074 alt modifier key does not work on french keyboard under MacOS

[lauhub]

I use JEdit 5.5 with a french keyboard on a MacOS computer

On older version I could use (e.g.) alt + left arrow to move one word left. This shortcut does not work.

I tried to set the two following attributes in startup.bsh :

Debug.ALT_KEY_PRESSED_DISABLED = false;
Debug.ALTERNATIVE_DISPATCHER = false;

In that case, the alt + left arrow works but the problem is that I can not use the keys like ~, {, }, [, ], | among many others (specifically, non-ASCII characters).

On older versions, I remember I could use the Alt key for shorcuts without any problem I don't remember which one).

[lauhub]

I tried to figured out what happened by examining the code. And I saw that:

/* we don't handle key pressed A+ */
/* they're too troublesome */

Frankly, seeing this opened my eyes: the developer who did that just killed jEdit

How decently a programmer could introduce such a limitation in a text editor ? A software where you need shortcuts

Ho, yes there is the Debug.ALT_KEY_PRESSED_DISABLED option that allows you to re-enable ALT key.

But at the cost of all other keys won't work... the ones that are usefull to write text in your language.

I rarely say negative things in open-source software or forums but seeing that just makes me angry. Seeing that no-one seems to answer to this bug too.

Testing if the keystroke gives a printable character and preventing shortcut if not would have been much clever

Something like:

            if(!isPrintable(keyCode) && Debug.ALT_KEY_PRESSED_DISABLED)
            {
                if((modifiers & InputEvent.ALT_DOWN_MASK) != 0)
                    return null;
            }

May be I am not looking at the right place, but I am seriously worried about jEdit future for now

[Makarius]

On 04/06/2019 02:27, lauhub wrote:

I tried to figured out what happened by examining the code. And I saw that:

/ we don't handle key pressed A+ /
/ they're too troublesome /

Frankly, seeing this opened my eyes: the developer who did that just
killed jEdit

Testing if the keystroke gives a printable character and preventing
shortcut if not would have been much clever

Something like:

        if(!isPrintable(keyCode) && Debug.ALT_KEY_PRESSED_DISABLED)
        {
            if((modifiers & InputEvent.ALT_DOWN_MASK) != 0)
                return null;
        }

May be I am not looking at the right place, but I am seriously worried
about jEdit future for now

How much future do you give e.g. VSCode?

Software projects with a long history have there own rules. The key
handling stems from distant past with quite different Java versions.

I have myself updated some of these things in the transition from Java 6
to Java 7. Even with a French keyboard that I specifically bought for
testing -- at the Apple Store in the souterrain of the Louvre shopping
center.

Now we are approaching a transition of Java 8 to Java 11, which is
probably less drastic: I have not checked yet if it changes the key
handling situation again.

Have you actually tested with current Java 11, or with old Java 8?

Maybe you also want to test this application of jEdit:
http://isabelle.in.tum.de/website-Isabelle2019-RC4

Makarius

[lauhub]

Hi Makarius,

Thank you for your answer and sorry if my words did shock you.

You are asking about VSCode ? I don't know why it comes here. For me, for now, jEdit is not usable. And this is about user needs.

I started using it 15 years ago and it worked well. But since a few years, I had to use alternate text editors (Atom) because jEdit shortcuts got worst and worst. I still keep jEdit for some interesting features I am used to. But today I am forced to use another app for a specific purpose (latex editing): because it lacks all my shortcuts.

May be there are not so much users who are filing a bug when a software does not work: they just leave and try another one. Without any noise.

I am a bit noisy, but I am not leaving so easily ;)

And the bug I am talking about is not the only one about this:

• https://sourceforge.net/p/jedit/bugs/2420/ (opened since 2005)
• https://sourceforge.net/p/jedit/bugs/3993/ (closed but not completely explained)

These two bugs and the current one are the same problem.

My version of Java used by jEdit is 8 (although I have 11 installed): running with Java 11 does not change behaviour described previously.

I understand that you are strongly involved and you gave much of your time and money to make it work.

However, I would like to give you my analysis:

At a glance, what I saw in source code scared me: tons of static, if-else interlocking just to manage that key event part.

Plus a plugin just to manage a specific platform (MacOS).

Plus an option (ALT_KEY_PRESSED_DISABLED) to disable / enable some shortcuts (having to choose between typing a character or accessing a shortcut should not be an option).

So the first thing I thought seeing this was: this part of code needs a complete review and probably a refactoring because putting more and more band-aid will not save if from deadlock.

And I think there is a deadlock here.

A new version of Java would be, in my opinion, a good opportunity to completely refactor the KeyEventWorkaround (yes that is the name of the class) , KeyEventTranslator and all related classes.

And maybe a fresh start would better than losing more and more non-english keyboard users ?

If you need help, I may provide some. If I had more time, I hope I will participate in development.

[Makarius]

On 04/06/2019 21:12, lauhub via jEdit-devel wrote:

I started using it 15 years ago and it worked well. But since a few
years, I had to use alternate text editors (Atom) because jEdit
shortcuts got worst and worst. I still keep jEdit for some interesting
features I am used to. But today I am forced to use another app for a
specific purpose (latex editing): because it lacks all my shortcuts.

My version of Java used by jEdit is 8 (although I have 11 installed):
running with Java 11 does not change behaviour described previously.

At a glance, what I saw in source code /scared/ me: tons of |static|,
|if-else| interlocking just to manage that key event part.

Plus a plugin just to manage a specific platform (MacOS).

Plus an option (|ALT_KEY_PRESSED_DISABLED|) to disable / enable some
shortcuts (having to choose between typing a character or accessing a
shortcut should not be an option).

I know what you mean. The key event handling has accumulated many
strange special cases -- it was worse before I participated a cleanup
for Java 7, together with the abandonment of Java 6.

Note that Java 11 provides an opportunity to discontinue the special
macOS plugin, because the desktop operations are now part of the
standard APIs. Thus full macOS support could be incorporated into main
jEdit. This rearrangement would require to give up Java 8, though: it
has been officially declared dead by Oracle in Jan-2019, but it is to be
expected that many users will continue with it for many more years.

Makarius

[Alan Ezust]

First of all, I'd like to say, it was worse before, with all the weird platform-specific and JDK-specific workarounds that were there before. Thank you Makarius, for helping to clean it up.

On a different note, if we can drop the requirement for JDK8 and clean up more old workaround code, I'm all for it. I have no objection to moving on to Java 11 for jEdit 5.6

[hmijail]

Found this bug while trying to use JEdit on macOS with Australian keyboard... for Isabelle work, of all things :).