I use either command-tab task switching on OSX (the equivalent of Alt-
tab on other systems) or alt-tab (with 'witch', a better task switcher). Both
of them exhibit the same behaviour :
When jedit regains focus this way, the arrow keys just don't work. you
have to type something else (space, letter, whatever), then the arrow keys
work again.
Needless to say, this is quite annoying in daily use ;)
| Submitted | dmorel - 2006-04-25 - 18:58:38z | Assigned | nobody |
|---|---|---|---|
| Priority | 5 | Category | keyboard / shortcuts |
| Status | Open | Group | normal bug |
| Resolution | None | Visibility | No |
| 2006-04-25 - 19:02:40z dmorel |
Logged In: YES user_id=1509906 Same behaviour with jedit 4.2 final and 4.3pre3, on sun jDK 1.4 and 5 |
|---|---|
| 2006-05-26 - 12:39:43z smsm1 |
Logged In: YES user_id=1079067 I get this issue too. jEdit gets focus but text areas don't get full focus. Can sometimes happen when you dismiss a dialog. Using Apple JDK 1.5 & 1.4.2. (Sun does not provide one for Mac OS X). |
| 2008-03-06 - 19:58:08z psb6 |
Logged In: YES user_id=2029469 Originator: NO I see the same problem many times per day, although I cannot find a way to reliably produce the failure. Many things besides the arrow keys do not work while in this state, including keyboard shortcuts for Copy and Save. For example, Apple-S types an "s" in the document, rather than doing Save. The (silent) failure of Copy is particularly annoying, since I then paste into some other app with whatever random thing was alread in the copy buffer. The failure state ends when you type into a document. I"m using jEdit version 4.2pre12, Java 1.5.0_13, under Leopard. The problem has existed for a long time however, e.g. under Tiger too. |
| 2008-03-10 - 22:22:24z kpouer |
Logged In: YES user_id=285591 Originator: NO did you try with or without the simplified keyboard handling ? |
| 2008-03-10 - 22:31:07z ezust |
Logged In: YES user_id=935841 Originator: NO I see this in linux also. JDK 1.5/1.6, |
| 2008-03-11 - 15:04:51z psb6 |
Logged In: YES user_id=2029469 Originator: NO kpouer said: > did you try with or without the simplified keyboard handling ? I'm sorry, I don't understand the question above. Regards, Patrick |
| 2008-03-11 - 15:16:50z kpouer |
Logged In: YES user_id=285591 Originator: NO This is an experimental keyboard handling, you can activate or deactivate it in the global options of jEdit |
| 2008-03-11 - 15:59:29z psb6 |
Logged In: YES user_id=2029469 Originator: NO I have "simplified keyboard handling" disabled (not checked). Cheers, Patrick |
| 2008-03-11 - 16:13:33z ezust |
Logged In: YES user_id=935841 Originator: NO I also have it disabled. Also ,I suspect this is related to which particular combo of plugins I have docked at the time. I think a more interesting question would be: has this ever happened with jedit in a "new plain view" without any dockables? If not, (and I suspect this is the case, although I almost NEVER use jedit without dockables, so it's hard to be sure) then the next question to ask is, which Plugin is grabbing focus? The answer is, just about any of them :-( |
| 2008-03-11 - 16:47:27z psb6 |
Logged In: YES user_id=2029469 Originator: NO I have not explored "docked" windows at all, so I'm pretty sure I do not have any "docked" plugins. The plugins I have showing in Plugin Manager are: Editor Scheme Jakarta Commons Latest Version Check Mac OS Plugin QuickNotepad Regards, Patrick |
| 2008-03-11 - 17:19:37z psb6 |
Logged In: YES user_id=2029469 Originator: NO I'd like to broaden the description of the "hung" text area state somewhat. The ignored keystrokes include back-space, delete, home, end, page-up, and page-down (in addition to the arrow keys, and all keyboard shortcuts previously mentioned). Also, if I have two buffers in a "split view", I can move the focus (blinking cursor) between them via the menu item View:Splitting:Go To Next Text Area without clearing the failed state. The only thing that clears it is a normal letter/number key stroke. Regards, Patrick |
| 2008-04-01 - 12:00:18z alan_carriou |
Logged In: YES user_id=802617 Originator: NO As far as I am concerned, it might be related to bugs 1242430, 1527334, 1609548, 1650718, 1721208 and 1747202... All those items are related to keyboard keys randomly not functionning properly. Matthieu tried a fix between 4.3pre12 and 4.3pre13 (revision r11222) that I have used for a few weeks, and I have not been able to reproduce the bug anymore (it used to happen quite often). As I had not found a reliable way of reproducing the bug (some combinations of alt+tab triggered the bug, but not always), I wanted to use the new release a bit before saying "It's ok", but I must admit the bug seems to be gone once and for all. For me, it is a big THANK YOU to Matthieu for getting rid of that most particularly annoying bug. For all who have met those keyboard bugs, have you tried the latest relase ? |
| 2008-04-11 - 14:44:59z psb6 |
Logged In: YES user_id=2029469 Originator: NO Alas, I've tried 4.3pre13 for about a week on Java 1.5.0_13 under OS-X version 10.5.2 and have seen no improvement to this keyboard problem. I'm glad it's working for you though. :) Patrick |
| 2008-09-27 - 21:48:00z marco-caminati |
My symptoms are a bit different than original bug description, but I posted here since
causes seem similar. *****Description***** If JEdit gets called by xdvi to do dvi reverse search through latex source specials, it loses keyboard focus, i.e. JEdit window is focused but normal text typing (i.e. MOST keystrokes) doesn't work (except for Return key which creates a new line, or Ctr+Home which gets to buffer start, and maybe a few other odd combinations) and cursor does not show on current line (which is marked in color as usual, anyway) until you do one of the following: -click on the text area -Press TAB -Press Ctrl-TAB (which in KDE is by default not available) *****Workaround***** Call jedit with the command line parameter -run=/usr/local/share/bug.bsh, where bug.bsh looks like this: void doSomethingUseful() { void run() { // view = jEdit.getLastView(); //prova=jEdit.newFile(view); //jEdit._closeBuffer(view,prova); view.splitVertically(); view.unsplitCurrent(); } if(jEdit.getLastView() == null) VFSManager.runInAWTThread(this); else run(); } doSomethingUseful(); (written taking inspiration from jedit builtin help faq) *****Considerations.***** Maybe this has to do with the way xdvi calls its editor, as stated on xdvi manpage (http://linux.die.net/man/1/xdvi): "The argument of this option isn't executed as a shell command, but via exec() to prevent evil tricks with the contents of source specials." Maybe this is a general java fault, as the following links could let suppose: http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/360927e294780b28 http://forums.sun.com/thread.jspa?threadID=5163401&tstart=0 I remember that on JWM window manager things were still worse, the misbehaviour showing even when window-switching via Alt+Tab. I have not the chance of test it right now. This is obviously an annoying bug. *****Test software versions.***** Operating System: Linux slax 2.6.24.5 Jedit 4.3 pre 15 java version "1.6.0_05" Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) xdvi 22.84.9 (motif) fluxbox 1.0.0 KDE 3.5.9 |