This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 115098 - Select next element does not work
Summary: Select next element does not work
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords: REGRESSION
Depends on:
Blocks:
 
Reported: 2007-09-09 03:07 UTC by _ gsporar
Modified: 2007-11-05 13:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ gsporar 2007-09-09 03:07:52 UTC 
Running the daily build from 2007-09-06 using JDK6u2 on Ubuntu 7.04
Comment 1 _ gsporar 2007-09-09 03:09:45 UTC 
Accidentally hit Submit without finishing the bug description....  :-)

ALT+SHIFT+Period does not seem to work in Java or Ruby source files.  The first time I press it the current element gets
selected but subsequent presses do not select additional elements in the source file.
Comment 2 Jan Lahoda 2007-09-11 08:02:48 UTC 
I can reproduce (in Java) - when the caret is at the end of an identifier, A-S-. does not extend the selection.

Also, A-S-, does not work at all for me.

Not sure about Ruby - probably belongs to Ruby editor.
Comment 3 Martin Krauskopf 2007-09-11 09:53:38 UTC 
> Also, A-S-, does not work at all for me.

The same for Ruby. Should we file a separate issue for Ruby or it is a bug in some general editing infrastructure?
Comment 4 Jan Pokorsky 2007-09-11 13:08:55 UTC 
Reproducible. In 20070905 it is working. I will investigate what changed.
Comment 5 Jan Pokorsky 2007-09-11 17:38:03 UTC 
It was caused by the fix of issue #114649. The rescheduling of state change events to the tail of events queue results
in broken caret events fired by JTextComponent. dot and mark values of all caret events caused by the running AWT task
are set according to the last caret modification.

Reassigning to editor.
Comment 6 Vitezslav Stejskal 2007-09-12 07:13:19 UTC 
Rescheduling was done to prevent firing events when holding document's lock (in atomicUnlocked). I'll try to fix issue
#114649 in a different way.
Comment 7 Vitezslav Stejskal 2007-09-12 09:53:41 UTC 
I changed the BaseCaret to fire asynchronously only when holding the doc's lock. If no lock is held and the thread is
AWT it fires the change synchronously.

Checking in BaseCaret.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v  <--  BaseCaret.java
new revision: 1.136; previous revision: 1.135
done