On Thu, Jul 26, 2001 at 03:00:49AM -0400, John Gellene wrote:
> I tried this. If you try to launch a second file before the server data
> file is written (I have had delays of up to twelve seconds on my
> installation) you will launch a second instance of jEdit. The second
> instance loads somewhat faster because files are in the system cache. What
> often happens then is that the second instance persists because it doesn't
> see the server data file. When you close one of the instances, you delete
> the server file, and the edit server become unusable - no more launching.
> By making file loading go through the launcher I can queue multiple requests
> without losing the edit server. Right now if the second request comes too
> quickly it will be dropped, but it will usually be processed even if jEdit
> has not fully loaded. Either way the edit server remains intact.
This approach has a few disadvantages, though. For example, if the
'restore files' setting is enabled, the last set of files will always be
loaded, no matter what was sent to jEditLauncher. I agree that some
people will prefer this behavior; but jEdit already has a toggle setting
to accomodate that. jEditLauncher basically 'forces' this setting to be
on. I consider this a bug that should be fixed before 3.2final.
Can't you have jedit.exe set a flag before it starts jEdit, and clear that
flag after it detects that the server file has been written (it should
also be cleared if jEdit exits prematurely). If another jedit.exe is started
and the flag is set, it should wait until the flag is cleared.
You should probably use COM or something for this flag so that if jedit.exe
itself crashes, it won't linger forever.
> I think that lengthening the timeout is simpler and eliminates the more
> common race conditions. You would have add command line parameters that
> take their own arguments, and the launcher would increase in size to
> accomodate the new variations. At 52KB I think it's too large already; in
> the next round I'm going to separate the context menu handler from the
> launcher component. This will also make installation easier, because the
> memory-resident context menu handler will not necessarily have to be
> replaced during an upgrade or reinstallation.
I have added a new -run= command line parameter to jEdit 3.2pre7 to replace
If passed to the initial instance, the specified script file will be run
right after any startup scripts. This is before the initial view is created.
If passed to a client instance, it sends a BeanShell.runScript(...) to the
In both cases, the view, buffer, textArea and editPane variables are not
set. You can use the following code snippet to obtain a view instance:
// Runnable interface
// get most recently created view
view = jEdit.getLastView();
// do something useful
// run the specified Runnable after startup is complete, or
// immediately if already started
So here is what I suggest you do:
- File names passed to jedit.exe, server not running - pass the file names
as command-line arguments to jEdit.
- File names passed to jedit.exe, server running - connect as before,
sending a script down the socket that calls EditServer.handleClient()
- Script passed to jedit.exe, server not running - start jEdit with the
-run= command-line switch.
- Script passed to jedit.exe, server running - send a BeanShell.runScript()
command down the socket.
- JDiff request, server not running - write a script to a temporary file,
using the above wrapper, then start jEdit with the -run= switch.
You can pass the two file names as ordinary command line arguments, so
that no other files will be restored. By the time the script is run, the
files will be loaded (because of the runInAWTThread() call).
- JDiff request, server running - just send a script directly down the
socket, no need to bother with a temporary file.
I know this is a lot of work, but if you don't count the JDiff stuff, it
is basically what the pure-Java edit server client in jEdit does. And
you could even remove the feature for running BeanShell scripts from the
context menu; I think most people wouldn't need it.
Implementing just the two file name cases above shouldn't be very much
work at all.
> One change to jEdit that would be helpful for those using the launcher is a
> way to reset the edit server without exiting jEdit. If it were reset
> automatically, the new authorization key should provide suffcient security
> protection, but even if there were a sound objection to an automatic reset,
> it should be possible to restart it with a user action, perhaps in response
> to an automatic prompt.
I will add a command to reset the server in 4.0.