Filesystem browser slow over network -- need alternate plugin, "SlowOpen"
Submitted by Friday, 11 June, 2004 - 11:10
on
(I'm using jEdit 4.2 pre14 on the Windows platform)
I can see that a lot of thought and work has been put in to improve the Filesystem browser in jEdit 4.2. I like the new interface. In 4.1, I used to often get an error popup when I typed a directory name in the filename field. I don't get run into that problem with 4.2. However...
One thing I liked about the Filesystem browser in 4.1 is that it worked well over slow networks. Because it did not have filename completion, I was able to type ahead in the filename field and open a file without waiting for a DIR I/O operation to complete. This is important since I often work from home accessing my files through a "NET USE" over a VPN. It can take, literally, seconds for jEdit to populate the File System Browser windows of my remote directories. I want to be able to enter "source/abc/def/ghi/Main.java", for instance, or "../tests/TestClass.java" and quickly open a file when I know the exact filename. Even when I'm at work on an enterprise-quality LAN, identifying remote files to open can be overly slow with jEdit 4.2. The jEdit 4.2 File System Browser works well for local files but it can be a stumbling block for remote. I've even gotten to the point where sometimes I open a Command Prompt and type jedit on the command line with the full pathname, rather than go through the File System Browser.
When I save a file, jEdit 4.2 also goes through a cycle with an awkward wait time. When I hit Control-S to save a file, jEdit goes into a mode where it beeps if I try to make new edits to files, it then enters its save, prints a message on the screen (like "1 I/O in progress"), begins to save the file and lets me type. Perhaps jEdit is doing something with its "~" file during the beep period. Over slow networks, the beep period can take several seconds.
Searching for text within a large file on a remote drive can also be slow. It appears that sometimes jEdit goes to disk during a Search->File operation on the current buffer.
So I wish that jEdit would work better on slow networks. I see that there's a plugin called "FastOpen". Perhaps we also need a plug-in called "SlowOpen". And I think improvements could be made in other areas to support remote-file work.
Thanks.
I can see that a lot of thought and work has been put in to improve the Filesystem browser in jEdit 4.2. I like the new interface. In 4.1, I used to often get an error popup when I typed a directory name in the filename field. I don't get run into that problem with 4.2. However...
One thing I liked about the Filesystem browser in 4.1 is that it worked well over slow networks. Because it did not have filename completion, I was able to type ahead in the filename field and open a file without waiting for a DIR I/O operation to complete. This is important since I often work from home accessing my files through a "NET USE" over a VPN. It can take, literally, seconds for jEdit to populate the File System Browser windows of my remote directories. I want to be able to enter "source/abc/def/ghi/Main.java", for instance, or "../tests/TestClass.java" and quickly open a file when I know the exact filename. Even when I'm at work on an enterprise-quality LAN, identifying remote files to open can be overly slow with jEdit 4.2. The jEdit 4.2 File System Browser works well for local files but it can be a stumbling block for remote. I've even gotten to the point where sometimes I open a Command Prompt and type jedit on the command line with the full pathname, rather than go through the File System Browser.
When I save a file, jEdit 4.2 also goes through a cycle with an awkward wait time. When I hit Control-S to save a file, jEdit goes into a mode where it beeps if I try to make new edits to files, it then enters its save, prints a message on the screen (like "1 I/O in progress"), begins to save the file and lets me type. Perhaps jEdit is doing something with its "~" file during the beep period. Over slow networks, the beep period can take several seconds.
Searching for text within a large file on a remote drive can also be slow. It appears that sometimes jEdit goes to disk during a Search->File operation on the current buffer.
So I wish that jEdit would work better on slow networks. I see that there's a plugin called "FastOpen". Perhaps we also need a plug-in called "SlowOpen". And I think improvements could be made in other areas to support remote-file work.
Thanks.