errael commented on PR #4249:
URL: https://github.com/apache/netbeans/pull/4249#issuecomment-1160667006
> Is it guaranteed that ... happen always in the correct order (1), (2) ?
@sdedic The reload path is
Wathcher thread: detects external change, FileObject.refresh, fires
events
CES does Mutex.EVENT.postReadRequest
(1) EDT: Starts reload in EDT, captures caret positions, task.schedule(0)
(2) RP thread: handles the reload, including **reading the file**,
when finished does
(3) Mutex.EVENT.postReadRequest: restore carets
(4) Mutex.EVENT.postReadRequest: fire `PROP_RELOADED`
The path to the editor module is
Wathcher thread: detects external change, FileObject.refresh, fires
events
editor module does Mutex.EVENT.postReadRequest
(1) EDT: capture the carets
At least 4 thread changes versus 1. It's conceivable that the Watcher thread
would not finish firing events (and that the CES event was fired before the
editor event) before the document reload finishes. In that case the caret would
be set to it's previous save point. If this is a concern, then a caret listener
could save a caretPosition after every move. Is that overkill to prevent a rare
glitch in caret position?
A `PROP_START_RELOAD` event could be fired from the EDT, in (1) above, this
feels cleaner. Should this be included in this PR?
Two things to keep in mind
1. The external file change is truly asyncronous, no guarentees.
2. The file is modified, any setting of positions is a guess.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
