[scite] Add shourcuts for built-in menu items
Hi, all This same message was sent to the list several days ago but it seems to have disappeared without warning. So I send it once again. I am testing some new lexer codes with SciTE. In doing this I often need to use the menuitem "toggle all folds". It would be nice to be able to add a user defined shortcut for built-in menu items like"toggle all folds". Is it possible to do that? instanton ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Weird selection
Hi, I just found that SciTE make weird selection of a text when I try to select a word leaded by a - character under Fedora Core 6 and SciTE 1.74 To reproduce, create a new emtpy file then paste this string into the new document: -testing Place the cursor at the end of the "testing" word, then make a selection back with the keybord hold down SHIFT + CTRL and then press LEFT_ARROW_KEY once. The selection will contain not just the testing word but the - sign too and the cursor appear between the - sign and the testing word: -|testing It doesn't happen with SciTE 1.73, just tested it. Thanks Istvan ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Add shourcuts for built-in menu items?
Hi, all This same message was sent to the list several days ago but it seems to have disappeared without warning. So I send it once again. I am testing some new lexer codes with SciTE. In doing this I often need to use the menuitem "toggle all folds". It would be nice to be able to add a user defined shortcut for built-in menu items like"toggle all folds". Is it possible to do that? [EMAIL PROTECTED] 2007-06-29 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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 > straightforward; there's a GDK macro for getting that from the > main widget: > > #include > > Window w = GDK_WINDOW_XWINDOW(widget); That's not what I meant by a Unix-equivalent to $(WindowID). I meant an equivalent for the use of the Director interface, not from the perspective of the OS or of the windowing system. WindowID is useful to start a Director from a particular SciTE instance, as exemplified in the documentation by this: command.name.0.*=Project Editor command.0.*="C:\os\scite\bin\filerx.exe" "$(FileDir)" "$(WindowID)" command.subsystem.0.*=2 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 $(PipeName) As for the ability to front SciTE, I'm almost done with the implementation of a "focus:" message. As Neil mentionned in a previous email, we should be careful about this. Activating (the word X uses for that, i.e. giving a window the focus and raising it above the others) can be really annoying for a user, for example if a window is suddenly activated while we were doing something else. To avoid that, we have to use timestamps. When we ask a window to be fronted, we give the X server timestamp of the user action that caused the actions leading to the activation. The window manager will then decide whether to front the window or not, depending whether the user activated another window since that action. If it doesn't activate the window, it might give an indication that the window asked to be fronted (e.g. in Gnome, using Metacity, the button will flash in the task bar) [1]. So I've decided that the Director command would be "focus:time", time being an X server time stamp. Note that it isn't the usual timestamp defined as "the number of seconds since epoch". It is: "A timestamp is a time value, expressed in milliseconds. It typically is the time since the last server reset." (From the X Window System Protocol specification [2]) Where to get that from? Remember we need to get the timestamp of the last user action, so we don't force the window to be fronted. In a GTK+ application, you can get the timestamp of an event with gdk_event_get_time(). For example in a project manager, I might select several files and click a button "Open". The program would them send several "open:" command to SciTE and at the end a "focus:" message with the timestamp of the button click. If I haven't done anything since, SciTE will be fronted by the window manager. For the single instance code, I'm going to use something else, since there is no button anybody clicked on. When you start a program by opening a file in Nautilus (in Gnome, but it's the same in KDE as far as I know) or by lauching it from the menu, a .desktop file [3] is used. If this file specifies StartupNotification=true, then an environment variable called DESKTOP_STARTUP_ID is set which contains a _TIME string followed by the timestamp we need [4]. Unfortunately, this variable is unset by gtk_init(), which means I need to store it before it is called. Therefore I have the following problem: how should I pass this to CheckForRunningInstance() which is inside a class that is instanciated later? Would it be okay if I just added an argument to SciTEGTK::Run()? That's it about the focus: message for now. I should have some space on a web server soon, so I'll not have to worry about file size and wait because the mailing list thinks they're might be a virus in my emails, and will post some code. Doesn't anyone have some comments about my remarks in DirectorExtension.cxx? Steve, you only commented on one of them. Nicolas ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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-notification-spec/startup-notification-latest.txt especially "Communicating from a launcher process to a launchee process" ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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 $(PipeName) As Neil mentionned in a previous email, we should be careful about this. Activating (the word X uses for that, i.e. giving a window the focus and raising it above the others) can be really annoying for a user, for example if a window is suddenly activated while we were doing something else. 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. Doesn't anyone have some comments about my remarks in DirectorExtension.cxx? Steve, you only commented on one of them. //TODO: is it really good to exit like this? Well, up to now that's the way we've always been exiting ;) But seriously, the director has lanched SciTE and we are in an unrecoverable position; why not just quit? // If we keep the exit call, we shouldn't call it with 0... Absolutely. The director should be able to check this and go Oh No! // TODO: should we really use ipc.scite.name even if not started by director? Good question. To be consistently backward-compatible, one shd bail out. But I thought that assymmetrical extensions (those that just want to drive SciTE and not listen) are quite legitimate. // TODO: store the file name in a property? Absolutely! The x11.windowid is actually something else altogether. ScitePM needs it for its own bring-SciTE-to-front. But then that will be handled properly... steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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-spec/latest/ [4] http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt especially "Communicating from a launcher process to a launchee process" There is a danger of overengineering. This is a slipperly slope which will end up with us using something like DBus...! steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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 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 suddenly risen above what you're reading. Of course, in our case it's not very likely, and if the director takes too long, just fix the director! But if we don't use timestamps, then SciTE will never be activated, even if it's legitimate (it's the way it's working now). Besides, I didn't mention it in my previous email, but director processes won't have to provide an X server timestamp, if they can't obtain one or don't care. You'll be able to send a "focus:" message without a timestamp. >> //TODO: is it really good to exit like this? >Well, up to now that's the way we've always been exiting ;) But >seriously, the director has lanched SciTE and we are in an >unrecoverable position; why not just quit? Okay. >> // If we keep the exit call, we shouldn't call it with 0... >Absolutely. The director should be able to check this and go Oh No! -> exit(3); >>// TODO: should we really use ipc.scite.name even if not started by director? > >Good question. To be consistently backward-compatible, one shd bail >out. But I thought that assymmetrical extensions (those that just want >to drive SciTE and not listen) are quite legitimate. Okay, leave it that way. >>// TODO: store the file name in a property? >Absolutely! Okay, will look into making a $(PipeName) property. >The x11.windowid is actually something else altogether. ScitePM needs >it for its own bring-SciTE-to-front. But then that will be handled >properly... Yup, send a "focus:" message :) I will send an email when I'll be able to upload the files. Nicolas ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Re: Weird selection
Hi, Place the cursor at the end of the "testing" word, then make a selection back with the keybord hold down SHIFT + CTRL and then press LEFT_ARROW_KEY once. The selection will contain not just the testing word but the - sign too and the cursor appear between the - sign and the testing word: -|testing This probably happens because '-' is not considered a word character in whichever properties file last specifies the word.characters property. -Mitchell; It doesn't happen with SciTE 1.73, just tested it. Thanks Istvan ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Re: Add shourcuts for built-in menu items?
Hi, I am testing some new lexer codes with SciTE. In doing this I often need to use the menuitem "toggle all folds". It would be nice to be able to add a user defined shortcut for built-in menu items like"toggle all folds". Is it possible to do that? The user.shortcuts property. Look in SciTE.h for the command number for 'toggle all folds'. -Mitchell; [EMAIL PROTECTED] 2007-06-29 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Add shourcuts for built-in menu items?
That works, thanks. Didn't know wrer to get ther command number -) [EMAIL PROTECTED] 2007-07-04 - Original Message - From: mitchell To: scite-interest Sent: 2007-07-03, 23:27:39 Subject: [scite] Re: Add shourcuts for built-in menu items? Hi, > I am testing some new lexer codes with SciTE. In doing this I often need > to use the menuitem "toggle all folds". It would be nice to be able to > add a user defined shortcut for built-in menu items like"toggle all > folds". Is it possible to do that? The user.shortcuts property. Look in SciTE.h for the command number for 'toggle all folds'. -Mitchell; > > [EMAIL PROTECTED] > 2007-06-29 > > > > > ___ > Scite-interest mailing list > Scite-interest@lyra.org > http://mailman.lyra.org/mailman/listinfo/scite-interest ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] selection.back in Sc1.exe
For Sc1.exe built with the latest CVS and MinGW it appears that selection.back is not working. Whatever value is asigned to selection.back the background of selected text in Sc1 is always the same very light blue, and it seems that this background is not fully transparent, because setting selection.fore=#FF makes the text selected invisible. What might be the cause then? instanton 2007-07-03 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Weird selection
Istvan: The selection will contain not just the testing word but the - sign too and the cursor appear between the - sign and the testing word: -|testing Only selects "testing" for me. Perhaps your settings are not the defaults. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] selection.back in Sc1.exe
instanton: For Sc1.exe built with the latest CVS and MinGW it appears that selection. back is not working. Whatever value is asigned to selection.back the background of selected text in Sc1 is always the same very light blue, Works for me with MinGW with default being a grey background. Setting selection.back=#FF in user properties makes that pink. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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-user machines. Its also a 'standard' which could lead to easier integration with other tools but DCOP and Orbit were also standards. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: Re: Re: Re: Re: [scite] Single instance and Director Extension in SciTEGTK
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 suddenly risen above what you're reading. On Windows the 'rule' is that the application currently with focus can donate it to another application. That means that sending a "focus:" message to the SciTE that should have focus wouldn't work on Windows since the OS will refuse to heed the call. Instead the SciTE with focus must call SetForegroundWindow on the SciTE that it is asking to open the file. >The x11.windowid is actually something else altogether. ScitePM needs >it for its own bring-SciTE-to-front. But then that will be handled >properly... Yup, send a "focus:" message :) Sending a "focus:" message is better than exposing implementation details like window IDs if possible. SciTE derivatives could have multiple top level windows. Its likely that SciTE for GTK+ only runs on X now (sometimes on top of another system like OS X) but its not the only possibility. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: Re: [scite] selection.back in Sc1.exe
Neil, Yes it works on another machine. Probably it was connected with the way my screen is working. But then I have another question: why should the same setting give rise to different display effect for SciTE.exe and Sc1.exe? I attacg two small screenshots to illustrate the difference. [EMAIL PROTECTED] 2007-07-04 - Original Message - From: Neil Hodgson To: Discussion of the SciTE editor Sent: 2007-07-04, 07:43:29 Subject: Re: [scite] selection.back in Sc1.exe instanton: > For Sc1.exe built with the latest CVS and MinGW it appears that selection. > back is not working. Whatever value is asigned to selection.back the > background of selected text in Sc1 is always the same very light blue, Works for me with MinGW with default being a grey background. Setting selection.back=#FF in user properties makes that pink. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest <><>___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Weird selection
Neil Hodgson wrote: Istvan: The selection will contain not just the testing word but the - sign too and the cursor appear between the - sign and the testing word: -|testing Only selects "testing" for me. Perhaps your settings are not the defaults. You're right, thank you. Istvan ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
