(204/211) 4074 - alt modifier key does not work on french keyboard under MacOS

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

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

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.

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

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