Steve Donovan wrote: > 'ipc.scite.name' will now always have the valid listening pipe name, > whether set externally or generated internally - so 'PipeName' is > redundant. 'current.pid' is actually useless as well as redundant; an > internal extension can now look at 'ipc.scite.name' and find what they > want from that.
Seems logical to me. Sorry that I didn't answer the previous emails, I've been busy with other things. > If we run out of available listening slots, then the request fails > and the result is '*', which seems an unlikely valid filename ;) The result from sending a register: message, that is. Was a bit unclear in your email. A few comments: A) Is there a particular reason you resurrected the /tmp/SciTE.register file? I'm not sure I like this way of calling "register:". When writing my little script, I had following problems with it: What happens if the file already exists before calling "register:"? Should I remove it? But then I might prevent another program using the director interface from reading the filename of the pipe it needs. If I don't remove it (and even if I do) I might end up having several file names in SciTE.register, without knowing which one is mine. I think we should enforce the use of the correspondent field for the "register:" message. In case we keep it, we must add some error checking to the fopen/fwrite calls. B) You ask in a comment in the code how we might indicate a problem if we can't open the pipe passed to us in the correspondent field. I don't see a way to indicate the problem to the director, but we might indicate it to the user (e.g. using perror()), which would allow the bug to be detected and reported. C) I would remove the comment about current.pid, because it isn't helpful for somebody reading the code and not knowing about our changes, since it refers to something that doesn't exist anymore in the code. Instead of saying what current.pid was intended for and why it's useless, say what ipc.scite.name is useful for. D) We added a "closed:filepath" message sent by SciTE. Any other candidates? You suggested something before saving, IIRC. I think that's it. Nicolas _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest