Neil Hodgson wrote:
Is there a complete version of this patch?
Hi everybody,
I'm back from my holiday. As Steve mentionned, there is still
the issue of 'dead pipes', pipes left by after a crash of SciTE.
I had noticed a problem with those, I couldn't restart SciTE after
having killed it,
steve donovan:
I think we're confident enough for this to be updated. I'll have a
look at the needed changes.
Is there a complete version of this patch?
Neil
___
Scite-interest mailing list
Scite-interest@lyra.org
I think we're confident enough for this to be updated. I'll have a
look at the needed changes.
The only concern Nicolas and I had was the problem of 'dead pipes'
that happens when an instance of SciTE goes down in flames. I have
some dead pipe cleaning code but I don't know whether it should go
Does this need updated documentation on
http://scintilla.sourceforge.net/SciTEDirector.html ?
Neil
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
On 7/19/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
A) Is there a particular reason you resurrected the /tmp/SciTE.register
file? I'm not sure I like this way of calling register:.
I also prefer the correspondent method, since I am starting to dislike
explicitly named temporary files. I
Hi Nicolas,
I've made the changes as suggested; we only use the new explicit
register syntax, and puts out sensible error messages on stderr.
There was an interesting bug, which I discovered when playing with a
Python extension script: we were putting out '\0\n' at the end of
notifications,
Steve Donovan wrote:
I picked up what I thought was the latest, and it still had the old
case, so I let it be.
The latest before yours was this one:
http://nico.esoxprojects.net/scite/director-2007-07-05.zip
It doesn't work with the latest revisions, as it doesn't acknowledge
the changes with
Hi Steve,
I just sent a message to the mailing list, hadn't seen your
latest email yet.
The OnBeforeSave() is in, but doesn't work ;) My test Python script
was always receiving 'saving:..' after the damn file was actually
saved. A similar internal Lua script worked; my guess is that file
Hi Neil and Nicolas,
I've made some changes and added some comments (this is also now in
CR+LF SciTE standard and works with new snapshot)
http://mysite.mweb.co.za/residents/sdonovan/DirectorExtension.zip
'ipc.scite.name' will now always have the valid listening pipe name,
whether set
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
On 7/8/07, Neil Hodgson [EMAIL PROTECTED] wrote:
PipeName is just giving ipc.scite.name a default value so could go
into ipc.scite.name
That makes sense.
I don't see any use for current.pid.
I put it in because it's useful for a script to know which SciTE
instance it belongs to. For
There seems to be some unnecessary entities. Looking at the set of
properties mentioned in the DirectorExtension, [ipc.director.name,
current.pid, ipc.scite.name, PipeName] it appears that
PipeName is just giving ipc.scite.name a default value so could go
into ipc.scite.name (is there a
Chachereau Nicolas:
Basically the only change since the last version sent to the
mailing list is that you can now call register: with a
correspondant field as well, that is, sending
:filepath:register:, where filepath is a file you created
and to which SciTE will write the name of the pipe you
Neil Hodgson wrote:
Doesn't that remove the need for /tmp/SciTE.register?
Well, yes I guess so. If everybody's okay with that, we can remove it.
On Windows, ActivateWindow(const char *timestamp) is less obviously
useful (and the argument isn't) so I'm not sure whether this should go
in
steve donovan:
use SciTE as a single instance even without the director. If you want,
we could break backward compatibility and require SciTE to be compiled
without NO_FILER to be able to use check.if.already.open.
Can we imagine a situation where people can't or won't put in the
director
On 7/5/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
Neil Hodgson wrote:
Doesn't that remove the need for /tmp/SciTE.register?
Well, yes I guess so. If everybody's okay with that, we can remove it.
I'll vote for that; I was never happy with having yet another _named_
temp file which was
On 7/5/07, Neil Hodgson [EMAIL PROTECTED] wrote:
People with weird almost-Posix environments (things like QNX or
OpenVMS) may not be able to get all the wanted calls. Those concerned
with security may not want an open command channel that goes through
/tmp files.
I tend to forget these
I've put up an updated version of all three files.
Director Extension:
http://nico.esoxprojects.net/scite/director-2007-07-05.zip
This now requires a correspondent field for the register: command.
Otherwise it won't do anything. No SciTE.register anymore.
Single instance:
Hi everybody!
I think we're almost done with the changes. I uploaded some
files. I tried to break up the changes in steps, so that they
can be looked and committed separately.
First, the revised DirectorExtension.
http://nico.esoxprojects.net/scite/director.zip
Basically the only change
Sorry, I forgot the urls. Here they are:
[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2510465
[2] http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf (p.165)
[3] http://standards.freedesktop.org/desktop-entry-spec/latest/
[4]
On 7/3/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
This starts filerx and tells it which instance it is supposed to
talk to. The X window ID isn't useful for this purpose, what a
director started from SciTE would need is the name of the pipe
SciTE is listening to. We could simply call this
On 7/3/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
Sorry, I forgot the urls. Here they are:
[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2510465
[2] http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf (p.165)
[3]
Steve Donovan wrote:
Yeah, but how real a problem is this? The typical situation is that
you are working with the Director program, and it wants to bring up
SciTE to show us a file (like scitePM). Having an extension running in
the background which brings up SciTE is just bad-mannners.
That's not
steve donovan:
There is a danger of overengineering. This is a slipperly slope which
will end up with us using something like DBus...!
I had a another look at DBus. It probably is too complex although
since there is a per-user instance there will be less opportunity for
interference on
Chachereau Nicolas:
That's not really the use case. Suppose the director, for some reason,
takes a while before asking SciTE to be activated. You might then
have switched to another application, e.g. might be reading something
in your web browser. It would then be an annoyance if SciTE was
Steve Donovan wrote:
That's what I think - named pipes are so easy, you don't need a higher
degree or special equipment ;) Although controlling a remote instance
of SciTE might be entertaining, it wouldn't be high on most people's
list of piorities. But, it's true, pipes are global. I was
BTW, scitepm actually drives SciTE pretty smartly. It makes up its
own unique pipes, and passes the ipc properties in the environment to
its own SciTE instance. So there is no problem with multiple scitepm
instances. The new interface extensions can coexist quite happily.
I'm the author of
Roy Wood wrote:
I'm the author of scitepm, so thanks for the nice words. :-)
I'm very happy to modify scitepm to work with whatever IPC strategy
you guys want to set up in scite. The code in scitepm is very clean,
and implementing the required changes would be a snap. Just let me
know what the
That's the next thing on my todo list, and I already have some pointers.
Basically we need to call gtk_window_present() but there is some stuff
with timestamps - to ensure the window gets fronted unless it's
annoying for the user - that I've got to research. What would the
message be called? I'd
Here's a patch making the single instance handling use the
director interface. The patch assumes that the patch about exit
functions has already been applied.
The new behaviour is the following:
It tries to find a pipe in the current temporary directory (ie
usually /tmp) to communicate with an
On 6/29/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
I don't really like the assumption that a process can only
communicate with SciTE if it started it. I think a process
should be able to become a director even after SciTE started.
According to the documentation, it is possible on Windows,
On 6/30/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
The more I think of it, the more I'm convinced breaking backward
compatibility and going for sockets would be worth it. But I'm not
the only one to decide here :)
Here's my first stab at a new revamped Director interface for GTK:
On 6/30/07, Neil Hodgson [EMAIL PROTECTED] wrote:
Fronting windows with insufficient reason became such a problem on
Windows that recent versions of Windows try to stop applications
fronting themselves except in particular cases. SciTE should not be
fronted by default for most of these
Steve Donovan wrote:
Here's my first stab at a new revamped Director interface for GTK:
[snip]
I'll take a serious look at that. As I wrote in an email that
mysteriously disappeared, I'm not sure I like having potentially so
many pipes open. That's what I was referring to when saying that I
would
Chachereau Nicolas:
I think we should decide in which way SciTE reacts when it is
sent a message. I think SciTE should be raised above the other
windows in some cases, like:
find:, goto:, insert:, loadsession:, macrocommand:,
macrolist:, menucommand:, open:, output:, replaceall:
35 matches
Mail list logo
