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, b
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
http://mailman.lyra.org/mai
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
i
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
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
>buf
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 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, beca
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
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 wh
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 externall
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 ther
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 we
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 inte
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 wa
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
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 y
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 sin
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
sudde
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 multi
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
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] http://standards.freedesktop.org/desktop-entry-sp
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
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]
http://standards.freedesktop.org/startup-no
Steve Donovan wrote (in a private response to my previous email):
> That looks good, Nicolas! You ask in the source:
> // We would have a Unix-equivalent to $(WindowID)
> ScitePM would already like us to create a property x11.windowid
> so it can bring SciTE to the front if necessary. That seems
>
On 7/2/07, Chachereau Nicolas <[EMAIL PROTECTED]> wrote:
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.
Cool - that modernizes old code.
sprintf(requestPipeName,"/%s/SciTE.%d.in", g
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
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 p
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 wha
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 sci
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 th
On 6/30/07, Chachereau Nicolas <[EMAIL PROTECTED]> wrote:
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 tend to using local sockets. However
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
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 comma
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:
http:/
Neil Hodgson 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 commands as they damage use case
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,
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:
Fronting
38 matches
Mail list logo