Currently, when jEdit is given a large file to open (either during runtime or on startup,
e.g. when the perspective.xml file specifies a large file), it may take a very long
time, during which jEdit is not responsive. jEdit should catch this (like firefox
realizing that a slow script is running) and ask what to do - cancel the loading of
the file, or maybe other things.
The criteria of file size is not good enough. Two files with the same size can take a very different time for loading.
|Submitted||shlomy - 2012-09-19 - 09:51:52z||Assigned||nobody|
|2013-04-05 - 05:34:37z
|why special processing? If it just opened every file in a background task and showed
it in the task monitor, so you could cancel it, and only added the buffer to the buffersets
and allowed the user to see it after it is finished loading, that would be even better,
|2013-04-23 - 15:50:06z
|Tried to use the cancel button in the task monitor, does not work for this kind of
Moving to bugs.
|2013-04-23 - 18:16:39z
the problem is that temporary buffers are loaded on the EDT and so are not cancelable. The code in org.gjt.sp.jedit.io.VFS.load(View, Buffer, String) and org.gjt.sp.jedit.Buffer.load(View, boolean) checks for a temporary buffer and runs them on the EDT. when in startup mode all files are opened temporary and are later on "commited" to full buffers.
When jEdit is already running, all IO tasks are scheduled as background tasks.
The code in VFS.load says that Hypersearch is faster with this special handling:
// this makes HyperSearch much faster
It would be easy to change this to always schedule IO tasks in the background. Somebody should test the impact on Hypersearch...