Re: [scite] for your consideration, a patch to OpenSelected()
Neil Hodgson wrote: Are you open to conditional compilation? ... ... You could write a patching script. I can learn how to make and use diff patch I guess. The code for finding if the path is a directory should use FilePath::IsDirectory which is portable. I forgot, thank you. I'll upload a new version with this change and include the documentation change as well. I'll probably start a new message thread at that point. April -- The phrase working mother is redundant. -- Jane Sellman ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] for your consideration, a patch to OpenSelected()
Neil Hodgson wrote: April White: I've found it useful to be able to easily open the folder that the filename is in, without having to ... Is this seen by others as a commonly needed operation? Everyone works differently and this doesn't seem to me to be something that I'd use. Its not easily discoverable either although possibly some documentation would help. I forgot about the documentation. I have altered the SciTEDoc.html file section Open Selected Filename with: On Windows only, if the selected file name is actually a directory, the Open dialog will appear. I am unsure whether to change SciTE.rc: MENUITEM Open Selected Filename\tCtrl+Shift+O,IDM_OPENSELECTED to MENUITEM Open Selected Filename or Folder\tCtrl+Shift+O, IDM_OPENSELECTED (This change would be carried forward into CommandValues.html by scite/scripts/commandsdoc.py) BTW I noticed that scite/scripts/commandsdoc.py has this line: !--Generated by scite/scripts/scommandsdoc.py -- notice the 's' preceding commandsdoc.py April -- Quitters never win, and winners never quit, and if you never win and never quit, you're just obsessive/compulsive -- Roxanne Longstreet (Rachel Caine) ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] for your consideration, a patch to OpenSelected()
Neil Hodgson wrote: April White: a suggested patch to the OpenSelected() method so that if the selected text is a directory, the 'open dialog' appears. Why would someone want this? I've found it useful to be able to easily open the folder that the filename is in, without having to copy and paste the folder name to the clipboard and then paste it into the open dialog box, or to open the selected file using ctrl+o and then having the open dialog using the current folder. Either is two steps and too cumbersome. This suggested revision is to attain the same functionality in one step. April -- They say the older you get, to wiser you get... You must be very, very wise Nermal Garfield ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] for your consideration, a patch to OpenSelected()
April White wrote: I have uploaded to http://www.scintilla.org/aprilw/scite-v174dev-openselected-april-2007-08-04.zip a suggested patch to the OpenSelected() method so that if the selected text is a directory, the 'open dialog' appears. I have not attempted to implement this in my GTK machine. Neil, this is the change I mentioned in my JobQueue email that was outside of the scope of changing the job system. April There has been no message on this thread. Does this mean that my suggested patch is rejected? April -- A truly happy person is one who can enjoy the scenery on a detour. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] for your consideration, a patch to OpenSelected()
I have uploaded to http://www.scintilla.org/aprilw/scite-v174dev-openselected-april-2007-08-04.zip a suggested patch to the OpenSelected() method so that if the selected text is a directory, the 'open dialog' appears. I have not attempted to implement this in my GTK machine. Neil, this is the change I mentioned in my JobQueue email that was outside of the scope of changing the job system. April -- Babies are a good way to start people. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] For your consideration, my SciTE Job Queue implementation
Neil Hodgson wrote: The cancelFlag is used in both the UI thread and the execution thread so should be protected. That is why InterlockedExchange is used in the current code. The same effect should be possible by using the JobQueue mutex in an int SetCancelFlag(int value) method. The IDM_FINISHEDEXECUTE and IDM_JOBS cases are too complex to contain within SciTEWin::Command so should be moved out into methods. Thank you for the suggestions. I will implement them over the next week or so. and upload a new version. Including multiple changes in a patch makes it much harder to review. I've uploaded a separate patch but my next release will obviously contain it still as the two changes have common files. I hope this is acceptable. April -- Babies are a good way to start people. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: [lua] removing empty lines
I have not been following this thread, but would not a search and replace work? Search for \r\n\r\n Replace with \r\n (and I guess if it is a Linux file, that would \n\n and \n respectfully) with the 'Transform backslash expressions' checked Run the script until no changes are made. April -- Good judgment comes from experience. Experience comes from bad judgment. -- Jim Horning ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] For your consideration, my SciTE Job Queue implementation
Neil Hodgson wrote: The cancelFlag is used in both the UI thread and the execution thread so should be protected. That is why InterlockedExchange is used in the current code. The same effect should be possible by using the JobQueue mutex in an int SetCancelFlag(int value) method. Can anyone confirm whether InterlockedExchange() exists in GTK? April -- Good judgment comes from experience. Experience comes from bad judgment. -- Jim Horning ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: For your consideration, my SciTE Job Queue implementation
mitchell wrote: April White wrote: I have uploaded to: http://www.scintilla.org/aprilw/scite-v174dev-april-2007-07-29.zip http://www.scintilla.org/aprilw/scite-dev-april-2006-05-02.zip the source code for my implementation a replacement for the SciTE command system, for both Win32 and GTK. Is there a description on what exactly this is and does? I'm curious :) It is a rewrite of the tool/command/job system. I wanted to be able to call external programs from within a Lua script, but I found the os.execute() to be too limited. I had first talked about this maybe a year ago and Neil gave me some suggestions. So allow for the Lua system to add command's but not clash with the multi-threaded command system I had to redesign it. I got it working in Win32 but received no help on implementing it in GTK, so that had to wait until I got my Mandriva box running. Which I did, and I've got the code working in GTK now as well. The 'command.go.needs' system could even be extended so that instead of a simple two-step process it could be three or more. I know you could write a batch/shell script to do that, but some people are rigid in their wants and needs. Or instead of re-writing the 'command.needs...' system you could create a Lua script: scite.Execute(step 1...) scite.Execute(step 2...) scite.Execute(step 3...) Oh, I forgot to include the change to the SciTELua.html file (I think that is the one). I'll have to locate an old copy and upload it. Is this enough enough information? April -- The true measure of a man is how he treats someone who can do him absolutely no good. -- Samuel Johnson (1709-1784) ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] me, Linux, and SciTE/Scintilla
April White wrote: I think I am going to rethink my approach to the job system under Linux, to minimize the changes. Back to the drawing board. Success! I have to remove all of my debug code, document my changes, and remember how to connect to the site where I've stored previous versions in the past, but it works on my Mandriva box. Okay, only the 'Go' command, but it works. I'll try the change I made to the SciTE/Lua interface, where I added scite.Execute() Happiness is! April -- You can't teach a new mouse old clicks. Steve Quinn Maxims for the Internet Age ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] For your consideration, my SciTE Job Queue implementation
I have uploaded to: http://www.scintilla.org/aprilw/scite-v174dev-april-2007-07-29.zip http://www.scintilla.org/aprilw/scite-dev-april-2006-05-02.zip the source code for my implementation a replacement for the SciTE command system, for both Win32 and GTK. I've included Changelog-AprilW.txt in which I've tried to list all of the changes I made. There are one or three changes outside of the command system I did which I hope will also be accepted. April -- You can't teach a new mouse old clicks. Steve Quinn Maxims for the Internet Age ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] testing, testing, 1, 2, 3...
I posted something six hours ago and it has not shown up. April -- You can't teach a new mouse old clicks. Steve Quinn Maxims for the Internet Age ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] me, Linux, and SciTE/Scintilla
April White wrote: ... And the GTK source compiles, but no job runs - ... I think I know why it is not running the commands in Linux. In the win32 changes, when a command is added the program broadcasts a message IDM_JOBS, which in turn starts the execution of jobs. I did not implement such a thing in the gtk code. Is there an equivalent to win32 SendMessage()? April -- I'm drowning in boredom, and you're handing me anchors? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] me, Linux, and SciTE/Scintilla
Neil Hodgson wrote: There are various memory debuggers. I've found Valgrind useful on Linux. Thank you for reminding me. I've seen it discussed on other lists, and I also saw it in the list of packages. I just have to remember to try it. There is no close equivalent to SendMessage. Thank you Neil. I think I am going to rethink my approach to the job system under Linux, to minimize the changes. Back to the drawing board. April -- I'm drowning in boredom, and you're handing me anchors? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: me, Linux, and SciTE/Scintilla
mitchell wrote: I would recompile Scintilla and SciTE with the DEBUG=1 option, then run 'gdb SciTE', press 'r' and enter to run SciTE, and if it still segfaults, gdb will let you know and you can enter the 'back' command to show a backtrace of what happened. Thanks Mitchell. I did compile with DEBUG=1, and followed the steps above, but I did not get a segfault while executing a tool - nothing did happen - but I did get a double free or corruption when I exited SciTE. The results of 'back' were vague and useless, showing a few unidentified addresses and some with system names such as 'libc.so.6' So now I have to double check my changes very carefully and if that is fruitless come up with a way to debug my changes. I've heard of Insight, a gdb GUI; I wonder if it exists for Linux / Mandriva. April ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Scite v1.74, Lua, and loadlib
April White wrote: My startup script has: SciTEExtension.lua:620: attempt to call global 'loadlib' (a nil value) Spoke to soon, it is now package.loadlib so I go that working, but I think I implemented a small revision that I'll have to track down April -- Decisions ruled by fear aren't usually good ones 'The Death of Chaos', L.E. Modesitt, Jr. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] save after
Bambero wrote: I made a simple shell script which uploads (to ftp server) curently open file. I'm using: command.name.3.*=FTP put command.3.*=put $(FilePath) command.subsystem.3.*=0 command.mode.3.*=savebefore:1 but it will be nice to do this command after each save. How familiar are you with the Lua interface? The Lua/SciTE interface has an event OnSave() which is merely a Lua script function that is automatically called after a file has been saved. I have not dabbled with the Lua / SciTE interface for quite a long time, I may be rusty here. You would have something like: function OnSave() os.execute(put \ .. props.FilePath .. \); return false; end os.execute() does a simple shell swap to run the program given as the parameter to it. props.FilePath is a Lua means to retrieve a SciTE property. If the property have spaces or periods in its name use props[ its.name.here ] The \ embeds a quote inside the string April -- Illiterate? Write for help ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Open separate instance via command line in spite of global check.if.already.open
Alexander Kriegisch wrote: I like the global option to use a shared instance whenever opening files in SciTE. In special cases (e.g. SVN check-in), though, I need a separate instance because SVN waits for the instance to be closed inorder to proceed with the check-in. The whole thing needs to be synchronous, which is understandable. I could not find a command line argument to achieve this. Alexander, I just learned this myself and you will be amazed how simple it is. I thought of this from something Neil told me along time ago about opening a file for readonly. Any property can be set or cleared on the command line by prefixing it with a dash. Now in my case the 'check.if.already.open' is off, but if I open a file and then use: scite -check.if.already.open=1 (another file) or scite -check.if.already.open (another file) the second file is loaded into the first instance of SciTE. The second example works because it turns the property on by default The same should work for you, but you would use scite -check.if.already.open=0 (another file) April -- It is by caffeine alone I set my mind in motion. It is by the Beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: os.execute is not cutting it
Benjamin Fisher wrote: It would be still be cleaner to be able to call SciTEWin::ExecuteOne and SciTEWin::ShellExec, without having to use an external program, since this is the exact functionality I am after. The development I did on the command/job system would probably work here but I have not had the inclination to get my linux PC working so I could do the necessary gtk changes. Of course that was also several versions ago, I'd have to almost restart with the latest release anyway. Is there any programmer on a linux PC that would volunteer to implement the necessary changes in gtk? I believe it is mostly some stub methods. April -- As I let go of my feelings of guilt, I am in touch with my inner sociopath. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Get text from output window ? (LUA)
mozers wrote: How can I get a text from output window? Check what your setting for clear.before.execute is. If it is not zero, then the output is being cleared between every tool invocation. April -- The E-mail of the species is more deadly than the mail. Steve Quinn Maxims for the Internet Age ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] a VB module to interface to Scintilla, and a lua script to make it
Some time ago I downloaded a VB example of an interface to Scintilla. I recently realized that this example was missing many of the constants and such from Scintilla.iface. Not having Python on my PC, updating the HFacer.py script was fruitless, so I wrote an equivalent one in Lua. This script and the resulting SciLexer.bas file are uploaded to: http://www.scintilla.org/aprilw/HFacer.lua http://www.scintilla.org/aprilw/SciLexer.bas The script also rebuilds Scintilla.h and SciLexer.h, though it does not overwrite the original file if there is a change. The new file has copy- prefaced to the file name. Obviously you need the Lua executable to run this script. April -- Tomorrow is a mystery, yesterday was history, and today is a gift, because it is the present! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Build command for Makefiles
Chris Sutcliffe wrote: Is it possible to have 'Build' enabled for a Makefile (with no extension)? My Makefile has the syntax all highlighted, but the 'Build' command is disabled (i.e. the menu item is greyed out). I encountered this. I put these lines within my user properties file: command.build.makefile=make command.build.Makefile=make April -- Never say to a cop... I can't reach my license unless you hold my beer. (OK in Texas) ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] AutoCShow problems
Neil Hodgson wrote: Mitchell Foral: The problem is in the OnUserListSelection event. I'm trying to call AutoCShow() from it with an instance methods list, but I get autocompletion of whatever it was the user selected ... My preferred solution is to have a generic deferred task mechanism in the scripting subsystem so you can say something like performLater(fn) which will call fn some time shortly after handling all the processing for the current UI event. I have not had the opportunity to port my job changes to my Linux/GTK PC, so I wonder if there is a possibility that the scite.Execute() implementation could do what Mitchell is looking for. I designed scite.Execute() to call external tools, but if the command mode is set to Lua, then maybe the command text can be passed back into Lua. Neil, do you suspect this may work? April --- Press any key... no, no, no, NOT THAT ONE! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Calltip
mozers wrote: I write so: WScript.StdIn[press dot] - calltips no :( ... How to force SciTE that he has determined a dot on the left? Look into the help file for calltip./lexer/.word.characters to see if it will work. For example: calltip.python.word.characters=._$(chars.alpha) I am not sure what the lexer name is for vbs files,. maybe vb. April -- ... File not found. Should I fake it? (Y/N) ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] adapting a 1.66 lexer to 1.67
April White wrote: I am attempting to adapt the regex lexer by Eugene Wong (LexUser) to my 1.67 version. I found it - the constant KEYWORDSET_MAX was increased in Eugene's version from 8 to 23 April -- Boldly going nowhere ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Sub : Command Line
Philippe Lhoste wrote: Very nice, useful as I have a number of small routines which I don't want to put in the tool menu. Here is my take on ordering the list: A little improvement: ... I almost forgot that in Lua, you can put functions in lists, and call them! Philippe, thank you for the excellant improvement. I've sent a copy to my work account, I'll implement it tomorrow! April -- I have studied many philosophers and many cats. The wisdom of cats is infinitely superior. Hippolyte Taine ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Sub : Command Line
Doyle Whisenant wrote: ... I have used the user defined list feature to write custom tool menus, for example all of the CVS tools (for work). Is this what you want to do? I'd be interested in this. Any example code? Doyle, I have a better version at the office, but this should work. If I missed something, let me know and I'll post any omissions This version requires that the tool name match the function name, which limits the name. The version I have at work builds a table of display names/function names which gives a better display (tbl[Check out] = co.bat) but the display order is not in the order added - does anyone have any suggestions on how to keep a table in the order the items were added? user.properties: command.mode.lua=subsystem:lua,quiet:yes,savebefore:no command.name.25.*=Other Tools command.25.*=OtherTools() command.shortcut.25.*=Ctrl+Alt+T command.mode.25.*=$(command.mode.lua) lua startup script: -- at the top, outside of any function: local udl_ListTools = 15; function OnUserListSelection(t,str) if t == udl_ListTools then assert(loadstring(str .. ()))(); return true else return false end end function OtherTools() local s = Backup .. udl_Separator .. HexEdit editor:GrabFocus() editor:UserListShow( udl_ListTools, s ) end function Backup() ... end function HexEdit() ... end -- Some days you are the dog and some days you are the hydrant! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Sub : Command Line
(This may be a re-post) Doyle Whisenant wrote: ... I have used the user defined list feature to write custom tool menus, for example all of the CVS tools (for work). Is this what you want to do? I'd be interested in this. Any example code? Doyle, I have a better version at the office, but this should work. If I missed something, let me know and I'll post any omissions This version requires that the tool name match the function name, which limits the name. The version I have at work builds a table of display names/function names which gives a better display (tbl[Check out] = co.bat) but the display order is not in the order added - does anyone have any suggestions on how to keep a table in the order the items were added? user.properties: command.mode.lua=subsystem:lua,quiet:yes,savebefore:no command.name.25.*=Other Tools command.25.*=OtherTools() command.shortcut.25.*=Ctrl+Alt+T command.mode.25.*=$(command.mode.lua) lua startup script: -- at the top, outside of any function: local udl_ListTools = 15; function OnUserListSelection(t,str) if t == udl_ListTools then assert(loadstring(str .. ()))(); return true else return false end end function OtherTools() local s = Backup .. udl_Separator .. HexEdit editor:GrabFocus() editor:UserListShow( udl_ListTools, s ) end function Backup() ... end function HexEdit() ... end -- Some days you are the dog and some days you are the hydrant! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Re: Re: Command.Save.Before question
Bruce Dodson wrote: For me, the fact that the auto keyword already exists for some other property isn't enough reason to push it through. In the absence of any additional user stories, I would defer to Neil. Hi Bruce. Neil pretty much said the same thing, though Jos does support it. My suggestion keeps the same implementation for existing command modes, though there is not numeric equivalent - save.before:2 is not the same as replace.selection:2 April -- Don't piss me off! I'm running out of places to hide the bodies. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Command.Save.Before question
Neil Hodgson wrote: Current behaviour is all a bit accidental and just based on how the code was factored. The lower level file writing shouldn't refuse just because the file hasn't changed. There could be additional flags but the argument for the extra complexity isn't that strong as you can always provide extra ways to retrieve the pristine examples. I've not tested it yet, but I did implement a savebefore:auto command mode, changing it to yes ot no depending on whether the buffer is dirty. Would you prefer that this not be so implemented? April -- If you try to fail, and succeed, which have you done? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Command.Save.Before question
Jos vanderZande wrote: Is there any reason why the Command.Save.Before=1 always saves the file in stead of using the same behaviour used by Command.Go ? (Only save the file when it is changed) Jos, I think it has always been this way, but that does not mean it cannot be changed. Though it is arguable whether save before and save before if changed are comparable. If (and this is a big *if*) a script uses Command.Save.Before=1 and the command tool itself then compares two file timestamps, with the above change you are proposing, expected side effects would not occur. Let me use this example: - you are editing a file with extension .xyz - a command executes a CLI/console tool that converts an .xyz file into .zyx which in turn is passed onto some viewer - but the viewer is opened only if the conversion occurs, - but the conversion only occurs if the .xyz file is newer than then .zyx file I know that this is a long and windy example, but with your revision, the viewer would never be displayed. This is a trivial example, probably better off implemented with command.go. Are there any counter-arguments, ideas, etc? April -- I will strive to live each day as if it were my 50th birthday. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] scite and XML documents
At work I've been assigned to a project which requires extensive editing of existing xml and xsl documents. Another unrelated project involves the creation of new xml documents against existing xsd document. SciTE edits these files, and with a Lua script I can re-indent a document to my needs in moments. However SciTE does not validate the xml documents, and using 'go' to display the document within Windows explorer is useless because it likewise does not validate the document. Is there a command-line tool that validates xml documents against either an internal or external schema that SciTE recognizes the output and so can use the F4 key? April -- Oh, that sound of male ego. You travel halfway across the galaxy and it's still the same song. Eve McHuron, 'Mudd's Women', stardate 1330.1 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: scite and XML documents
Bruce Dodson wrote: There's a tool called HTML Tidy that has some support for XML; see http://tidy.sf.net/. In my setup I have the following command defined: I've not used Tidy is some time. Does it validate against dtd's or schema's? I used it some time ago, I always though it was ensuring the file was valid html/xml, without using the schema April -- Bills travel through the mail at twice the speed of cheques. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Command.Save.Before question
Jos vanderZande wrote: ... or Run it with the Latest Beta version using Alt+F5. ... so you see what happens when they press Alt+F5. They get prompted to save the script to another file. Second reason is that i created a LUA script that will create x number of backups when Save is performed. I don't want to create a backup when the script isn't changed and ALT+F5 is performed. So maybe it could be changed that we add another value for Save.Before that will only saves the file when changed or change the behaviour to be the same as used by F5? Jos, you do have a point. The new code Bruce Dodson donated already has a skeleton base to detect the keyword auto, so it should not be hard for me to extend this and related code to implement what Jos has asked for. If someone wants to implement this within the cdv version, go ahead, else it will have to wait until I've done the necessary gtk revisions to the job system that are required for my new implementation. April -- I honor my personality flaws for without them I would have no personality at all. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] revision #8 to the tool/job/command system
Neil Hodgson wrote: April White: In addition to the small bugs patched since the last major release, it was pointed out that the command mode parsing was not reversing flags when duplicates were encountered. This has been corrected. OK, that looks better. Main thing needed for integration is GTK+ compatibility which doesn't need to be thread-safe. I'll implement some of the suggestions Bruce Dodson made and then I'll port transfer the code to my linux machine. I still cannot get the two PCs to have any sort of shared folder or allowable FTP'ing, so it'll be by 'sneaker-net'. April -- I am willing to make the mistakes if someone else is willing to learn from them. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] revision #8 to the tool/job/command system
I've uploaded to http://www.scintilla.org/aprilw/scite-april-2006-04-01.zip the latest release. In addition to the small bugs patched since the last major release, it was pointed out that the command mode parsing was not reversing flags when duplicates were encountered. This has been corrected. April -- I am grateful that I am not as judgmental as all those , self-righteous people around me. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] fix for bug 859526
I wrote this bug report, I decided to take a stab at solving it. Please find at http://www.scintilla.org/aprilw/scite-april-bug-859526-2006-03-26.zip my submission. Basically it revises the code that detects and handles the line continuator, breaking the loop if there is a blank line following the line that ends with the slash April -- A balanced diet is a cookie in each hand. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Re: reagrding SourceForge feature request for Scintilla 1244324
April White wrote: Neil, with your recent changes, is this FR complete? Sorry to bother you again, but I believe bug 1011217 can also be closed April -- A balanced diet is a cookie in each hand. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] reagrding SourceForge feature request for Scintilla 1244324
Neil, with your recent changes, is this FR complete? April -- Only a lack of imagination saves me from immobilizing myself with imaginary fears. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] SciTE 1.68 with z-order buffer switching
Istvan wrote: Regarding F12, it can be changed from SciTEGlobal.properties Hypertext|html|F12|\ I recommend copying the menu property from SciTEGlobal to your user file so you don't lose changes when you upgrade next. I've only found the at import statements cannot be moved out of SciTEGlobal. April -- Those who know _how_ will always have a job; those who know _why_ will always be their boss! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] revision #7 to the tool/command/job system
I've uploaded to http://www.scintilla.org/aprilw/scite-april-2006-03-12.zip . I removed the bulky array of command mode settings and equivalent properties. This also removed the typedef usage. A bug within the 'replace selection' code was corrected. Neil Hodgson wrote: The job system code doesn't currently compile for GTK+ so someone will have to be found to port it although its mostly just a matter of editorial changes (executing changes to something like JobQueue.IsExecuting(), etc) as the mutex can be implemented as null sine ScinTE on GTK+ is single threaded. I have installed Mandriva 2006 on my other PC. When there is a degree of acceptance to this implementation I can work on GTK, though with my inexperience with Mandriva/Linux/GTK in general any volunteers or suggestions are welcome, April -- I don't feel old. I don't feel anything until noon. Then it's time for my nap. - Bob Hope ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Mono C# on Win32?
Cupcake Kid wrote: Hi, I recently installed Mono for Win32 and I added its bin directory to PATH so I can access its compiler without using the Mono command prompt. However, the problem is, when I try and build something using SciTE, I get the following message (this problem only affects C#, C/C++, Java compilers work fine): mcs test.cs -pkg:dotnet The system cannot find the file specified. This is the command line I added to cpp.properties: if PLAT_WIN command.build.*.cs=mcs $(FileNameExt) -pkg:dotnet command.go.*.cs=$(FileName) command.go.subsystem.*.cs=1 I removed the csc command since that only applies to the M$ C# compiler. I'm pretty sure I updated the PATH properly since I can compile on a regular console using the same command line. The mcs program is actually a batch file, first try changing mcs to mcs.bat I'm dabbling with mono at home, I usually compile from the command line because mcs GPFs. Maybe I have to try replacing the batch file with the exe that it references. April -- Why do people with closed minds always open their mouths? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] revision #7 to the tool/command/job system
April White wrote: I've uploaded to http://www.scintilla.org/aprilw/scite-april-2006-02-13.zip the latest release. I have corrected the bug and uploaded the correction to the same file as above. April -- Before they invented drawing boards, what did they go back to? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Lua and InputBox
Wojciech Warczakowski wrote: is it possible to use something like InputBox in Lua? I'm using SciTE on WindowsXP. First, I believe InputBox() is not part of the windows 32 API. Second, I believe you would have to compile such a function into a DLL and load it within a Lua script. I've successfully inplemented a GetOpenFile() method. April -- I have never understood the female capacity to avoid a direct answer to any question. Spock, 'This Side of Paradise', stardate 3417.3 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] SciTE and ClearCase
Ghassan Hammouri wrote: I am unable to open any file that is in a ClearCase directory. Even if the file is a newly-created file (i.e. view-private) with read-write permissions for everyone, SciTE will refuse to open it. If I copy that same file to my home directory (not under ClearCase), everything works fine. This problem seems to occur only with SciTE; gedit, nedit, and vi work fine. Has anyone else encountered problems with SciTE and text files in a ClearCase directory? I use ClearCase (unknown version) at work and I've never had problems. In fact I now use a tool menu batch file to check out and in documents. Sometimes a drive letter is desolved into the UNC mapping and some of the batch files complain. I've manipulated VB .frm, .sql, .bat, .txt, and probably countless others. When you say SciTE will refuse to open it does it raise an error? Oh, Windows or Linux? I'd guess Windows, unless there is a ClearCase for Linux. More input... :-) April -- Just for today, I will not sit in my living room all day in my underwear in the Hollywood Cafe. Instead, I will move my computer into the bedroom. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
RE: [scite] Re: Re: Re: Revision #6 to the job system
From: Bruce Dodson [EMAIL PROTECTED] If there is a function to decode the command mode string (that doesn't add to the job queue), it needs more parameters. In particular, the save-before value should not be stuffed into the flags. Save-before is not a queued action: the save occurs in the main thread, before the command is added to the queue, and the flag isn't needed later. So, it is cleaner to keep it separate from the flags. The save-before-prompt flag is excluded from extenders, to avoid threading problems. I think I added all of these flags to more easily pass values between the new method and the caller. Look inside LuaExtension at the ..._execute method, it to saves the buffer. I have not seen any messages from Neil as to this code, but that does not mean it is wanted. More discussion is needed I think. I had one more observation about that function (DecodeCommandMode): The parameters are pointers, not references. Was that an arbitrary choice, or were there technical / design reasons for it? I don't mind if they are pointers; but if they are pointers, perhaps the function should check for null and ignore the corresponding command.mode flags if the pointer is null. The params are pointers because the original method was to be used by extenders. An oversight, they can be byref. I will amend next weekend. April ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Re: Revision #6 to the job system
Bruce Dodson wrote: Okay, in that case it would be a common method that is called by both AddJob and ToolsMenu, rather than having ToolsMenu call AddJob directly. (Mainly for the sake of clenliness.) I have removed DecodeCommandMode() from Extender.h, and altered LuaExtension.cxx accordingly. There is some name confusion though. SciTE is a sample application, not a library. With that in mind, would it be okay to reconcile some of these names? Right now we have AddCommand, AddJob, and Execute (plus whatever we call the worker method that gets invoked from both ToolsMenu and AddJob). It gets difficult to keep track. I was attempting to rename the JobQueue stuff to CommandQueue when I ran into a self-made bug with command = SString(command.command); The multiple uses of 'command' confused the compiler. I know I can use this-command = SString(command.command); but I wanted to hold off until we get some consensus on the use of the names. - the menu is called 'Tools' - the properties are 'command' - the internal enum values for subsystem and flags are job...; this must be where I got JobQueue from I have uploaded to http://www.scintilla.org/aprilw/scite-april-2006-02-05.zip my revisions to date. I will be away on business for the week, in the mean time please discuss amongst yourselves whether the JobQueue system should be renamed to CommandQueue. As well, the suggestion offered by Bruce whereby the ToolMenu() method builds one large command mode string to be passed into DecodeCommandMode(), are there any objections to it? I have looked at it and see some merit to it, though I would probably define and loop through an array of command properties and equivalent mode strings, to consolidate this new implementation. Right now there are a half dozen repeated blocks of code that could be reduced. BTW Bruce, I am not quite sure which Execute you are referring to. Since Lua already has an Execute() method I thought it would be more natural for script writers to use scite.Execute(). Within SciTE itself I removed SciTEWin::Execute(). ttfn April -- A man's got to do what a man's got to do. A woman must do what he can't. Rhonda Hansome ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Revision #6 to the job system
Bruce Dodson wrote:
Congratulations, you're the lucky winner of ... a code
review!
Hello Bruce. I feel so... special :-)
1) As Neil pointed out, the correct model for setting up the
function is like Open, not like SendEditor.
I've altered this in my source. Thank you Neil and Bruce.
2) If it is necessary to add new methods to the
ExtensionAPI, I would try to keep them at a high level so
that other extensions (e.g. Director) can also use them
without having to copy boilerplate code from LuaExtension.
To that end, you might consider removing DecodeCommandMode
from ExtensionAPI, and changing AddJob to do that work.
AddJob could have this signature:
virtual bool AddJob(const char *jobCommand, const char
*jobDirectory, const char *jobMode, const char
*jobInput=0)=0;
The implementation of AddJob would decode the mode string to
get the subsystem, save-before option, and flags. Pass a
non-NULL for jobInput (even an empty string) and that means
jobHasInput gets added to the flags after the mode string is
decoded. (Also, since the raw flags are not passed in to
AddJob, there is no need to mask out the flags that are
disallowed from extensions.)
I'm not sure I am following you on this.
AddJob() is a low-level interface between an extension and the tool
system. I wanted to allow the user the choice of using scite.Execute()
with either numeric identifiers for subsystem and flags or a command
mode string, much like existing tools can be configured.
To change the implementation as you suggest would restrict them to only
the mode method.
if (!host-AddJob(cmd, dir, mode, input)) {
lua_pushfstring(L, failed to add %s to the SciTE command
queue, cmd);
raise_error(L);
}
return 0;
}
I like this. Thank you.
3) It was good to factor out code that is used by both the
new job subsystem and the tools menu. Much better than copy
/ paste. But in the process, you had to invent some new
workarounds, to shoehorn all the command properties into
flags so they could be passed around more easily; and to
continue supporting the old-style command properties
(command.quiet, command.save.before, etc).
I think the solution is to factor out even more of the code.
What if the old-style command properties are handled just by
appending them to the command.mode? What if ToolsMenu just
reads the properties, and delegates to another method to
interpret them and submit the command to the queue? (It
could delegate to AddJob, or to a method that is called from
both ToolsMenu and AddJob.)
This is an interesting proposal. Let me think on it for a bit; I'll be
away next week on business though so be patient.
Well, I had to give it a try. A sample implementation (that
does not depend on the new job system) is uploaded here:
http://users.hfx.eastlink.ca/~gisdev/SciTE_ToolsMenu_sample.zip
I've grabbed a copy. t'nks
I am not clear on what AddJob does exactly, what the return
value means, why some job subsystems are disallowed, etc.,
so I didn't try to integrate that in my sample code.
Neil did not want an extension to interface to a SciTE method such as
AddCommand(); AddJob() only has simple C parameter types
As it is meant to be used by an extension, AddJob() excludes certain
subsystems and flags that could cause thread contentions.
4) Since I peeked at AddJob, I suppose I should mention that
SaveIfUnsure prompts the user with a modal dialog. If
AddJob is called from a thread other than the main UI
thread, the dialog would probably appear non-modal. Might
be worth testing. (You won't be able to test it from Lua,
because Lua code always executes in the main thread.)
Rest assured that Neil has been all over me about the code being thread
safe. I left the call to SaveIfUnsure() in but I believe by excluding
the 'savebefore:prompt' command mode, this method will never be called.
Thank you Bruce for your review and insights. I'll be keeping your
email marked as 'unread' so I will re-read it when I return from the States.
April
--
As I learn to trust the universe, I no longer need to carry a gun.
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Lua question
Doyle Whisenant wrote: Is there an event that I can use to run a lua script when SciTE is closing similar to OnOpen? Is it possible to do this? If so, how? I need to access all open buffers when SciTE closes. Anyone know of a reliable way to do this? Do you want when a buffer closes or when SciTE is exiting? For the former: OnBeforeSave( filename ) For the latter, I believe you are out of luck. April -- One does not thank logic. Sarek, 'Journey to Babel', stardate 3842.4 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Revision #6 to the job system
Chris wrote: I don't understand exactly what this change to the job system does (nor do I understand what the job system is in the first place). what exactly is a job in this context? Sorry for being an idiot :) It is a different term for a tool. Currently at most two tools can be in the queue to run. I wanted to add a method to the Lua script interface that would allow tools to be run from Lua but interact with SciTE the way items from the tool menu do. Neil will only accept an implementation that was thread safe. I have been developing such an implementation by changing the fixed array of tools into a link list April -- Today I will gladly share my experience and advice, for there are no sweeter words than I told you so! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Revision #6 to the job system
April White wrote: I have uploaded to http://www.scintilla.org/aprilw/scite-april-2006-01-26.zip my latest changes to the job system. Something seems to be broken, please ignore this upload for now. April -- As I let go of my feelings of guilt, I am in touch with my inner sociopath. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Revision #6 to the job system
April White wrote: I have uploaded to http://www.scintilla.org/aprilw/scite-april-2006-01-26.zip my latest changes to the job system. The Changelog.txt file contains more information. A brief list is: - an interface between Lua and the job system has been added as scite.execute() - Lua jobs can use 'command.mode' settings, though there are some exclusions - to facilitate the decoding of 'command.mode' strings, an extender method has been added - the code that replaces the current selection with the results of the job has been moved out of the tool thread I fixed the bug I introduced into new code. I've uploaded the corrected copy to the above .zip file April -- My intuition nearly makes up for my lack of self-judgment. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] The previous message about 'hot links' in a Scintilla/SciTE screen
I have looked through the archives for December and January for an earlier message where the writer said that they had implemented a 'hot link' within a scintilla or scite screen. Does anyone remember this, enough to remind when what the message subject was so I can go back to the archives? April -- My intuition nearly makes up for my lack of self-judgment. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: A revision possible based on SciTE documentation
Hi Bruce. Bruce Dodson wrote: I wonder if a simpler solution for command.replace.selection might be to cancel the job (or at least skip the replace-selection part) if the user changes to another buffer before it completes. Unless I am wrong, one strong advantage of moving the selection replacement code from within SciTE::ExecuteOne() to the IDM_FINISHEDEXECUTE handler is that it moves an buffer update from within the tool thread back into the UI thread. At least I think the IDM_FINISHEDEXECUTE handler is in the UI thread. April April White [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Neil Hodgson wrote: April White: ... revise the code that handles the command.replace.selection... code to locate the original buffer and select it. ... ... so just make it always switch back. ... It works but the output pane has the contents redraw repositioned (the output is longer than the screen, the scroll bar jumps from top to bottom) several times, at least once in a different font/color. When it is finished being jittery, the job output is replaced in the buffer I expect it to and the buffer I had selected was made active again, and the output pane has the results I expected. This code is within SciTEWin::ExecuteOne(). Maybe I should store the job output to a variable within the job object and have the IDM_FINISHEDEXECUTE handler do the replacement. Can you see anything wrong with the above code, and what are your thoughts on the latter idea. -- If you are too open minded, your brains will fall out. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] A revision possible based on SciTE documentation
Hello Neil.
I guess as I write this it is not 'good morning' but 'good evening'.
Neil Hodgson wrote:
April White:
... revise the code that handles the
command.replace.selection... code to locate the original buffer and
select it. ...
... so just make it always switch back.
Neil, I have alter the code that handles the replacement of the
selection when a job completes with this code:
if (doRepSel) {
int currentBuffer = buffers.Current();
FilePath jobBufferPath = jobQueue.CurrentJobBufferPath();
if (jobBufferPath.IsSet()
!CurrentBuffer()-SameNameAs(jobBufferPath)) {
for (int i = 0; (i buffers.length); i++) {
if (buffers.buffers[i].SameNameAs(jobBufferPath)) {
SetDocumentAt(i);
Platform::SendScintilla(wEditor.GetID(),SCI_REPLACESEL,0,(sptr_t)(repSelBuf.c_str()));
SetDocumentAt(currentBuffer);
break;
}
}
} else {
Platform::SendScintilla(wEditor.GetID(),SCI_REPLACESEL,0,(sptr_t)(repSelBuf.c_str()));
}
}
It works but the output pane has the contents redraw repositioned (the
output is longer than the screen, the scroll bar jumps from top to
bottom) several times, at least once in a different font/color. When it
is finished being jittery, the job output is replaced in the buffer I
expect it to and the buffer I had selected was made active again, and
the output pane has the results I expected.
This code is within SciTEWin::ExecuteOne(). Maybe I should store the
job output to a variable within the job object and have the
IDM_FINISHEDEXECUTE handler do the replacement.
Can you see anything wrong with the above code, and what are your
thoughts on the latter idea.
April
--
Top-of-the-line military hardware,
and I'd give anything for a can of Raid.
Major West, 'Lost in Space'
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] an implemention of a lua-users.org wiki scite script
I noticed that the http://lua-users.org/wiki/SciteScripts entry for SciteListAllOccurances was empty. I have posted my implementation to http://lua-users.org/wiki/SciteListAllOccurances ttfn April -- Why should I waste my time reliving the past when I can spend it worrying about the future? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] a wonky behaviour of user list
I had the output pane open, and I hit a hot key that activated a user list from a Lua script, but the cursor stayed in the output pane and I have to click/double click the list to activate the on list select method. Clicking on the list changed which item was active but did not set focus to it. Could either: - the hot keys be disabled when the output pane is active, - displaying a user list to move focus to the list, or - clicking on the list to move focus to it. April -- Before I criticize a man, I walk a mile in his shoes. That way, if he gets angry, he's a mile away and barefoot. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] A revision possible based on SciTE documentation
Neil Hodgson wrote: April White: ... revise the code that handles the command.replace.selection... code to locate the original buffer and select it. ...so just make it always switch back. I'll add it to my 'todo' list. ... or translate the selection from Canadian. :-) eh April -- Before I criticize a man, I walk a mile in his shoes. That way, if he gets angry, he's a mile away and barefoot. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] can an extender like Lua acces the current buffer?
Neil Hodgson wrote: Something like host-Perform(saveas: + host-Property(FilePath)) or host-menucommand:(IDM_SAVE) and host-CurrentBuffer() I don't know of an easy way to get the buffer number but the file name is available. I'd prefer extending the set of text commands or properties rather than the set of methods of ExtensionAPI. I realized a few hours after I posted this that the desired functionality could be placed within SciTEBase::AddJob() instead of LuaExtension scite.Execute() If the extension passes in the 'filter' flag or 'save' flag then those operations would be done within AddJob() which would be capable to do so. April -- I can please only one person per day. Today is not your day. Tomorrow isn't looking good either. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] A revision possible based on SciTE documentation
The docs regarding the command.replace.selection... property states: However, please bear in mind that command.replace.selection will send the output to whatever window is active /when the command completes/. The revisions I have been working on for the new job system is now storing the buffer name into the job object, so the 'building' flag can be set. It should not be hard to revise the code that handles the command.replace.selection... code to locate the original buffer and select it. Maybe extend the command.replace.selection... property with a new value so that existing functionality remains and the newer functionality is selectable by the user. April -- With my last breath I spit at thee... 'The Wrath of Khan' ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
Robert Roessler wrote: ... which means some of these bugs can still slip through, only to be found by those users with the shiny new dual-core they got over the holidays. ;) Sounds like someone just vounteered... :-) April -- The government's view of the economy can be summed up in a few short phrases: If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it. -- Ronald Reagan ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
Neil Hodgson wrote: April White: Can you think of any better test than trying to bang on the keyboard? You could try automating this with http://www.hiddensoft.com/autoit3/ Having a program like autoit bang on the keyboard does not seem much better, though it can do it faster but I don't really think that'll prove anything. April -- Eagles may soar, but weasels don't get sucked into jet engines. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
April White wrote: I've also started to implement the interface between Lua and the new job system. It may be rushing things, but it'll be in my next upload. Neil, I've being doing some empirical tests of the Lua/scite interface for jobs. I have a batch file that I've set to run from within a Lua script which takes a few seconds to run, so I start it and then play with SciTE. The editor accepts standard editing keys, but tools are disabled - I guess the code that disables the menus works. Can you think of any better test than trying to bang on the keyboard? April -- How much deeper would the ocean be without sponges? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
April White wrote: I've uploaded to http://www.scintilla.org/aprilw/scite-april-2005-12-29.zip my implementation of the new job system for v1.67 There had been a problem with the 'clear.before.execute' code, it was not properly clearing the output pane before the first job of a GO. It is fixed; I decided to upload todays revisions under the same name as above. Happy New Year. April -- Change is inevitable, except from vending machines. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
Neil Hodgson wrote: It is fixed; I decided to upload todays revisions under the same name as above. OK. There are some threading worries. jobQueue.CurrentJob() returns a pointer to a single job object which could potentially be deleted while the pointer is being used even though currently this may be safe. Since nothing is written into this pointer, you could make the pointers const and also hand out a copy to ensure it can be used without worrying about deletion. I think I'll revise things again :-) I'll remove 'CurrentJob()' and add 'CurrentJobFlags()' and 'CurrentJobBufferPath()' The two would be initialized within the CanExecute() code, returning copies of the respective values. I'll play with it while I'm waiting for New Years to arrive... JobQueue::CurrentJobDirectory has a small vulnerability since it doesn't lock and copying a FilePath involves allocations. I was about to say you were worrying to much, because the internal variable is only assigned within GetNextJob(), but I recalled that it is initialized within JobQueue::Clear(), so I agree that the variable should be locked. Additionally, since GetNextJob() is only called from within CanExecute(), I've made it a private method. April Happy New Years! -- Get a new car for your spouse. It'll be a great trade! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] v1.67 version of my job implementation
April White wrote: I think I'll revise things again :-) I'll remove 'CurrentJob()' and add 'CurrentJobFlags()' and 'CurrentJobBufferPath()' The two would be initialized within the CanExecute() code, returning copies of the respective values. JobQueue::CurrentJobDirectory has a small vulnerability since it doesn't lock and copying a FilePath involves allocations. I was about to say you were worrying to much, because the internal variable is only assigned within GetNextJob(), but I recalled that it is initialized within JobQueue::Clear(), so I agree that the variable should be locked. Additionally, since GetNextJob() is only called from within CanExecute(), I've made it a private method I've revised the code as above and uploaded it as http://www.scintilla.org/aprilw/scite-april-2005-12-31.zip ttfn April -- Get a new car for your spouse. It'll be a great trade! ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Color of matching parenthesis
Jos vanderZande wrote:
Check the SciTEGlobal.properties for:
# Brace highlight
style.*.34=fore:#00,bold
Okay, color me silly, but I've put:
style.*.34=fore:#FF,bold,back:#FF
style.*.35=fore:#FF,bold,back:#FF
style.*.37=fore:#FF,back:#FF
into my user properties file and the indention line is colored
differently, but the () [] {} are not changed
braces.check=1
braces.sloppy=1
are set in my global properties, and I tried clearing
braces.cpp.style=
but to no avail.
I know I've seen braces highlighted but I cannot remember in what file type.
I feel so silly, but what is wrong?
April
--
Depression is merely anger without enthusiasm.
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Color of matching parenthesis
Jos vanderZande wrote: The Brace normally takes the color that you set for Operator. when I set color.operator=fore:#FF then brackets became blue But when you put you cursor just behind a Brace this an the closing Brace will assume the color specified with style.*.34. That is the problem though - the open and close braces do not change color when the cursor is beside them. I have just determined that there is something within my user properties file that is causing the conflict - when I renamed it, the braces are colored correctly. And the culprit is... my Lua startup file. I wanted a simple means where I could initialize some values, so I used: function OnUpdateUI() udl_Initialize() return 0; end but the problem is that, thinking like a C programmer, the return 0 and return false where the same thing. They are not, because as soon as I changed the return 0 to return false, the braces are colored correctly. Maybe we could add an extender callback OnStartup. April -- Support bacteria. They're the only culture some people have. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] v1.67 version of my job implementation
I've uploaded to http://www.scintilla.org/aprilw/scite-april-2005-12-29.zip my implementation of the new job system for v1.67 This revision includes those thoughts I wrote in my last email: - rewrite if (!executing !jobQueue.IsEmpty()) as if (jobQueue.CanExecute()) - add the method JobQueue::CanExecute() which examines an internal flag IsExecuting; if it is not set, sets it and pops a job from the queue; these are the first two lines of SciTEBase::Execute() - replace any query of executing with jobQueue.IsExecuting() I've also included in the zip file a new makefile that is meant to be placed in the folder above scite scintilla. It is designed to detect whether it is windows or gtk and then calls the makefile for the appropriate subfolder. I've also included a revised makefile for scintilla\win32 and scite\win32. Aside from the new files needed for the job implementation, I've always had problems with 'make clean' not working properly. I've found an implementation that succeeds, hopefully it is acceptable. I hope everyone has a Happy New Year! 2006 here I come :-) April -- Remember, half the people you know are below average. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Can command line parameters set some options
I've put together a batch file that is automating some repetitive commands. Part of the process is to edit two files, but I'd like to have one file with the 'read-only' option turned on. I know adding a new command line prefix -openreadonly would be very simple, but before I pound the keys, is there a more elegant solution that would allow for future expansion? April -- I just got lost in thought. It wasn't familiar territory. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Revision #5 of job's
Neil Hodgson wrote: April White: I've been going over in my head the 'executing' variable. Not really the same as it sets executing even if it bails out because the queue is empty. I found that out the hard way. Moving executing inside jobQueue and adding a CanExecute method with appropriate locking may be a better approach although you could just reverse the tests. With the locking I've added to the jobQueue, adding CanExecute() would probably be best. Maybe a redesign of jobQueue.IsEmpty() as well. This is off the top of my head: - rewrite if (!executing !jobQueue.IsEmpty()) as if (jobQueue.CanExecute()) - add the method CanExecute() which examines an internal flag IsExecuting; if it is not set, sets it and pops a job from the queue, thereby setting the flag and preparing for the actual execution - these are the first two lines of SciTEBase::Execute() - replace any query of executing with jobQueue.IsExecuting() This sounds good on paper, I'll try it later today. Thank you Neil. April ps. Instead of downloading the 1.67 source, I can use CVS to get all of the new stuff? -- In politics, if you want anything said, ask a man. If you want anything done, ask a woman. -- Margaret Thatcher ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Is this a bug?
FYI.
I have not upgraded to v1.67 yet.
This line gets rendered in the yellow color of a compiler directive:
#define bump() if ( GetTickCount()last+1000 ) {
last=GetTickCount(); putchar('.'); }
However this line:
#define bump() if ( GetTickCount()last+1000 ) { /* Sleep(0); */
last=GetTickCount(); putchar('.'); }
gets rendered in the proper color until it hits the comment at which
points it renders in the comment green color.
The bug is that when the comment rendering completes it renders the
remaining text in the default color, black, not the directive colour.
April
--
Behind every successful man is a surprised woman.
-- Maryon Pearson
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Revision #5 of job's
Neil Hodgson wrote: Exposing a pointer to the current job outside locking is somewhat dangerous. It looks like it is currently safe but it would be easy for changes to the code to break thread safety. I just checked in some changes that improve thread safety in the current code because of small additions made over time without thought about possible thread issues. For CurrentJob(), I'd avoid the possibility of breakage where easy. For example, there could be a safe accessor to getting the current job directory that used locking and made a copy of the directory string for SciTEBase::Execute. I do not fully agree with you Neil. SciTEWin invokes SciTEBase::Execute() only where there is a job ready to run. I would think that if a second thread was going to start a job, the first one running would block it I've moved the executing = true; assignment to the top of the method, though, and I've implemented jobQueue.CurrentJobDirectory() Moving any use of job to before the point where IDM_JOBS joins in makes it safer. I've repositioned the code, introducing a long int variable to preserve the job exit state. Since this is complex processing, the section could reasonably be moved into a separate method. I'll re-examine this later. The above revisions seem to work. Thank you Neil. April -- Laugh and the world laughs with you. Cry and you cry with your girlfriends. -- Laurie Kuslansky ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Getting Configuration Directory
sn0n wrote: which prints the path the file im editing is in, i want to print the dir Scite and its conf files are in... Please let me know how Is $(SciteDefaultHome) what you are looking for? April -- I'm not an expert... I just play one from time to time. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] 4th stage of reprogramming job system
Neil Hodgson wrote: I've noticed that I am not deleteing the job object within ProcessExecute(). I would like to: - add a variable exitstate to the job class - return the job as a void * instead of the exitstate This way the IDM_FINISHEDEXECUTE code can get the exit state and build flags. Wouldn't it be better if the IDM_FINISHEDEXECUTE was able to remove the finished job object safely and query it for the file path and status? Hi Neil. The SciTEWin::ProcessExecute() method currently pops a job off the queue, and I've modified IDM_FINISHEDEXECUTE to receive the job as a parameter via lparam. I have not altered anything to store the buffer name so far, but the new code is working. Oh, I am also planning on on having IDM_FINISHEDEXECUTE delete the job object. I think that is what you are suggesting. BTW, which is a 'better' means of assigning the buffer name to the job object: 1. adding a parameter to AddCommand(), or 2. utilizing CurrentBuffer() within AddCommand() - this absolutely depends on the buffer being unchanged between the time the AddCommand() is called and the job object is created April -- Good judgment comes from experience. Experience comes from bad judgment. -- Jim Horning ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] 4th stage of reprogramming job system
Neil Hodgson wrote: - the buffer flags isDirty and useMonoFont has been encapsulated within a buffer variable and controlled by enum flags Grouping all these into a bit set makes it too easy to incorrectly set multiple states. ... Code that uses bitsets is also longer with extra boolean operators. I've reversed my changes. The biggest problem ... is that ProcessExecute ... is now modifying the current buffer I've been considering this for a bit. You are quite correct but I think that storing the name of the buffer within a job is not sufficient. The job that contains the flag that must be queried in order to assign isBuilt would not exist by the time the IDM_FINISHEDEXECUTE code runs. I've noticed that I am not deleteing the job object within ProcessExecute(). I would like to: - add a variable exitstate to the job class - return the job as a void * instead of the exitstate This way the IDM_FINISHEDEXECUTE code can get the exit state and build flags. I know I will not see your reply for some time, so I'll make a backup and try this anyway. April -- So, when are you going to celebrate National Procrastination Day? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #3
Neil Hodgson wrote: ... Maybe AddCommand could return whether it added a command or not. Implemented. I've managed to remove the isBuilding variable by implementing a job flag enum jobIsBuilding ... I think this needs to be displayed before putting the command into the queue Thank you for finding this. I've moved the code that displays the param dialog from the ::Execute() method to the ::AddCommand() method. I've altered my user properties so that GO on a .c file is: command.go.*.c=*$(FileName) $(1) $(2) $(3) $(4) command.go.needs.*.c=gcc $(FileNameExt) -o $(FileName) In such a case, the go.needs job is added to the queue first but does not display the param dialog, and the job is not started. When the .go. job is added, the param dialog is displayed, and then runs both commands in sequence. If the .go.needs job fails, the param dialog is still displayed but the .go. job does not run April -- Many of life's failures are people who did not realize how close they were to success when they gave up. Thomas A. Edison ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] 4th stage of reprogramming job system
I have uploaded my fourth revision to http://www.scintilla.org/aprilw/scite-april-2005-11-27.zip http://www.scintilla.org/aprilw/scite-dev-april-2005-11-10.zip I included a Changelog.txt file to summarize what I have revised. This version has: - improved corrected the handling of parameterized commands - corrected the handling of multiple commands - the previous release was wrongly executing all commands in the queue in a loop - made the internal global flag isBuilt a buffer flag; if two files are open that use the go.needs setting, each maintains its own built status - the buffer flags isDirty and useMonoFont has been encapsulated within a buffer variable and controlled by enum flags TODO: - I have learn more about the internal variables 'dirNameAtExecute' and 'dirNameForExecute', removing the one assignment with the execute thread code I've added a 'Peek' method to the job queue class so that private methods can see what is in the queue. Maybe I'll make this a public class so that SciTEBase::Execute(), which is outside of the execute thread, can assign dirNameForExecute and dirNameAtExecute in a safer manner. April -- Many of life's failures are people who did not realize how close they were to success when they gave up. Thomas A. Edison ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #3
Neil Hodgson wrote: I've been thinking of a new approach to the 'send job message' to the window. My initial test worked by having the AddCommand method send the job message. This eliminates the need for individual calls to AddCommand to send the message. One problem with this is that code that calls AddCommand often checks immediately if the queue is empty. The only time I can see that code checks if the queue is non-empty is to assign TRUE to isBuilding. I'll change AddCommand() to return true/false indicating that something was added, eliminating the need to examine if the queue is empty. The parameterised command seems really confused now: I'll try your example later this week. I knew that as soon as I altered how jobs worked, the parameterized command was be flaky. To make the code easier to understand, the key functions should have comments that say which threads they can be running on. I'm all for such a revision, but I'm a little unsure what 'key functions' to mean. Are you referring to the functions of the jobQueue class? Is it safe to issue a message within the message handler? SendMessage may be reentered but it is often an indication of overly complex code, and there is a potential for trouble if the message is unexpectedly crossing threads. I want the IDM_FINISHEDEXECUTE code to activate the next job in the queue. I can either send the appropriate message, or reposition the IDM_FINISHEDEXECUTE code to fall into the IBM_JOBS code. April -- Error: Keyboard not attached. Press F1 to continue. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #3
April White wrote: The revisions to SciTE for encapsulating the job system with a class is ready for final review. I have uploaded my third revision to http://www.scintilla.org/aprilw/scite-dev-april-2005-11-10.zip I've been thinking of a new approach to the 'send job message' to the window. My initial test worked by having the AddCommand method send the job message. This eliminates the need for individual calls to AddCommand to send the message. As part of my revisions, I positioned the IDM_FINISHEDEXECUTE code to fall through the IDM_JOBS message and then into the default code. I would like to move it back to its original position and issue a ::SendMessage for IDM_JOBS. Is it safe to issue a message within the message handler? If I an satisfied with the performance, I'll delete the above .zip and upload a new one. April -- We've crossed the thin line between genius and insanity. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] stage #3
The revisions to SciTE for encapsulating the job system with a class is ready for final review. I have uploaded my third revision to http://www.scintilla.org/aprilw/scite-dev-april-2005-11-10.zip I included a Changelog.txt file to summarize what I did. >From my last email, I wrote: 2. implement a means whereby a direct call to Execute() is unnecessary I chose to replace Execute() calls with the sending of a message to the window. This works, though if there is a suggestion that would eliminate these, please post your comments. Maybe the timer like Neil suggested... TODO: 1. revise the extension system so that a script may add jobs to the queue April -- All men are animals, some just make better pets. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] sending message to SciTE
Neil Hodgson wrote: I am thinking about changing how the jobs are executed. I'm thinking of removing the code that sends a message to the window and merely check if the queue is not empty. By checking when it was last checked, and only doing the check every fraction of second, it should not have a drag on resources. The IDM_FINISHEDEXECUTE processing is fairly heavy so you don't want to execute it multiple times and there shouldn't be too much of a delay before the UI is reenabled. My initial attempts were an utter failure but I'll try to come at it again from another angle and retry. April -- Boldly going nowhere ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] sending message to SciTE
Neil Hodgson wrote: The implementation of Jobs::JobList::HasParameterisedCommand and Jobs::HasParameterisedCommand need const to match the header. Fixed. I must have uploaded before trying to compile. commandMax and commandCurrent should disappear Already done. The commandMax variable only appears within a commented block of code. When I do not need that anymore, it'll be removed. and some of the other fields (cancelFlag?) should be inside JobQueue. TODO: cancelFlag, jobUsesOutputPane Some processing has been moved from SciTEBase::Execute in the UI thread to SciTEWin::ProcessExecute in the tool thread which has increased the chances of a thread clash. TODO: I need to go back over what I did and rethink it. calls to props.GetInt (win95.death.delay and output.scroll) have crawled into the tool thread which is unsafe as the property set could be reloaded by the UI while the tool is running inside the props.GetInt call. Everything the tool thread needs should be put in the Job or JobQueue object and protected with the lock. TODO: add read-only methods for these two properties to JobQueue class, add a method that initializes them, and re-initialize them after all properties are reloaded The queue class should be called JobQueue rather than Jobs and be housed in JobQueue.h and JobQueue.cxx Done the header should not be included in SciTEBase.h but rather in every .cxx file that needs to see this. Done. Mutex.h should not be included twice in WinMutex.cxx. Done. oops. I hope the icky debug stuff is going to disappear. When I don't need it any more. I've disabled the DEBUG define so the code it excluded. Copyright? doesn't deserve a ?. Since you gave me the example I wrote the code from, I do not feel right in listing copyright for me. Can I/may I assign it or give it to you? The JobQueue Lock and Unlock should be private so that callers can't confuse the lock state. Done. I initially left them public so that the soon-to-be written code that would allow a Lua script to add multiple commands could lock the queue, add the commands, and then unlock the queue. I've been rethinking this position and it may not be an issue. The queue is only locked at it is modified, so while a command is actually running, other commands can be added, which will run when the current job is completed. The destructor should lock just in case the other thread is still active when the queue is being torn down. Done. Thank you catching this! When I have more stuff done on the TODO list above I'll re-post my code. I am thinking about changing how the jobs are executed. I'm thinking of removing the code that sends a message to the window and merely check if the queue is not empty. By checking when it was last checked, and only doing the check every fraction of second, it should not have a drag on resources. April -- Why don't ease, lease, and please sound alike? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] sending message to SciTE
(This may be a duplicate posting) Neil Hodgson wrote: The implementation of Jobs::JobList::HasParameterisedCommand and Jobs::HasParameterisedCommand need const to match the header. Fixed. I must have uploaded before trying to compile. commandMax and commandCurrent should disappear Already done. The commandMax variable only appears within a commented block of code. When I do not need that anymore, it'll be removed. and some of the other fields (cancelFlag?) should be inside JobQueue. TODO: cancelFlag, jobUsesOutputPane, isBuilding, timeCommands Some processing has been moved from SciTEBase::Execute in the UI thread to SciTEWin::ProcessExecute in the tool thread which has increased the chances of a thread clash. TODO: I need to go back over what I did and rethink it. calls to props.GetInt (win95.death.delay and output.scroll) have crawled into the tool thread which is unsafe as the property set could be reloaded by the UI while the tool is running inside the props.GetInt call. Everything the tool thread needs should be put in the Job or JobQueue object and protected with the lock. TODO: add read-only methods for these two properties to JobQueue class, add a method that initializes them, and re-initialize them after all properties are reloaded The queue class should be called JobQueue rather than Jobs and be housed in JobQueue.h and JobQueue.cxx Done the header should not be included in SciTEBase.h but rather in every .cxx file that needs to see this. Done. Mutex.h should not be included twice in WinMutex.cxx. Done. oops. I hope the icky debug stuff is going to disappear. When I don't need it any more. I've disabled the DEBUG define so the code it excluded. Copyright? doesn't deserve a ?. Since you gave me the example I wrote the code from, I do not feel right in listing copyright for me. Can I/may I assign it or give it to you? The JobQueue Lock and Unlock should be private so that callers can't confuse the lock state. Done. I initially left them public so that the soon-to-be written code that would allow a Lua script to add multiple commands could lock the queue, add the commands, and then unlock the queue. I've been rethinking this position and it may not be an issue. The queue is only locked at it is modified, so while a command is actually running, other commands can be added, which will run when the current job is completed. The destructor should lock just in case the other thread is still active when the queue is being torn down. Done. Thank you catching this! When I have more stuff done on the TODO list above I'll re-post my code. I am thinking about changing how the jobs are executed. I'm thinking of removing the code that sends a message to the window and merely check if the queue is not empty. By checking when it was last checked, and only doing the check every fraction of second, it should not have a drag on resources. April -- Why don't ease, lease, and please sound alike? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] sending message to SciTE
Neil Hodgson wrote: ... calls to props.GetInt (win95.death.delay and output.scroll) Neil, I need your help with the design of this new implementation. I want to add a method to the JobQueue class which loads all of the necessary properties into instance variables. This method would be called within ReadProperties(). However the JobQueue instance does not know anything about the props instance variable of SciTE itself. I know I can add get/set methods to JobQueue for each variable I want to embed within JobQueue and call them within ReadProperties(), but I'd hope to find a means where the JobQueue.ReadProperties() method itself can do all of the work. This would allow new properties to be read used without revising the SciTE.ReadProperties() method. I'd like to be able to pass the props instance variable from SciTE.ReadProperties() into JobQueue.ReadProperties(), but at this point the props class definition is within SciTEBase. Could I move it out to its own file, allowing JobQueue to include the .h file and utilize the class? April -- Why don't ease, lease, and please sound alike? ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] sending message to SciTE
April White wrote: I've added a command case to SciTEWin.cxx and successfully responded to the message above. I removed SciTEWin::Execute(), placing that code within the command case, and it executes the commands in the queue. I tested Makefile and a simple .c file hoo hoo, it works :-) April -- If you give me more than one job to do, don't tell me which is a priority. I am a psychic. Rules of Work ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] stage #2 - job queue encapsulation within a class
The revisions to SciTE for encapsulating the job system with a class is still a work in progress. I have uploaded my second revision to http://www.scintilla.org/aprilw/scite-dev-april-2005-10-27.zip From my last email, I wrote: TODO: 1. lock all accesses to the various class methods and variables - I'll probably make some variables private/protected, such as 'next' 'prev', and introduce Get..() .and Set...() methods 2. implement a means whereby a direct call to Execute() is unnecessary 3. revise the extension system so that a script may add jobs to the queue Using the example provided graciously by Neil, I've added the Mutex and WinMutex classes. It compiles and runs, at least. I've also hidden some of the methods and added others - next/prev are gone, lock/unlock are new. So #2 is the next goal. Neil said in an earlier email: When the thread exits, it should post a message to SciTE (like it does now) as that is a good time to enable UI and look in the queue for new jobs. Alternatively, this could be a periodic clock tick check. Hmm, both are good suggestions, though the message idea keeps the code within the message handling system, although, upon reading the docs on windows SetTimer, it to could/would be kept within the message handler. April -- I got rid of my husband. The cat was allergic. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #1 - job queue encapsulation within a class
Neil Hodgson wrote: It looks a bit like this untested code: ... CRITICAL_SECTION cs; ... Neil, you've introduced something new to me. I was going to pursue the class using the windows mutex functions, but you've introduced the CRITICAL_SECTION concept. Can you give me your two cents worth as to which is a better path to follow. I've only just googled for the term, checked out a few hits. April -- You will always be lucky if you know how to make friends with strange cats. Colonial American proverb ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #1 - job queue encapsulation within a class
Neil Hodgson wrote: The UI thread monitors this and when there is a command here and no tool thread running, it moves a command into the main command queue and starts the tool thread. ... When the thread exits, it should post a message to SciTE (like it does now) as that is a good time to enable UI and look in the queue for new jobs. Alternatively, this could be a periodic clock tick check. The normal way to allow the code that knows about mutexes to choose for you is to define a function or static method that hands out implementation objects that satisfy an interface. Scintilla does this with Surface and SurfaceImpl. It looks a bit like this untested code:... Thank you Neil. That gives my something to go on. I did not understand how a class coming from src\ would utilize the functionality defined within a class IN Win32\. More play time ahead :-) April -- Dogs believe they are human. Cats believe they are God. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #1 - job queue encapsulation within a class
Neil Hodgson wrote: Oh, at this time, the SciTEJobQueue.h file contains some debugging define's and stuff, but they are only active when DEBUG is defined, but I also left in a line that define'd it. These are quite compiler-specific. Yep. I forgot to disable them. I do not know how to debug windows code using MinGW, so I intersperse the code with these entries. Took some patience, but I realized that the Pop() method was casting the DoubleLinkList pointer to the wrong type. It is to JobList, I was was incorrectly using Job. 2. implement a means whereby a direct call to Execute() is unnecessary I don't understand what you are planning here? This is based on something you wrote some time back, in the exposing the SciTE 'execute tool' functionality to Lua'. I quote you as: The UI thread monitors this and when there is a command here and no tool thread running, it moves a command into the main command queue and starts the tool thread. #1. My lessons on semaphores mutexes was about eight years ago. I know that Windows has mutexes, but what about Linux? scintilla/gtk/PlatGTK.cxx uses the GMutex type provided by glib. This code could be used but since SciTE on GTK+ is single threaded it is simpler to provide a null implementation. Can it be as simple as a tiny class that uses #if PLAT_WIN to identity the windows mutexes? Otherwise it'd have to be a base class inherited by both Windows and GTK, but then I have no idea how the Jobs class would use the inherited class. I've been playing with this design this evening. Nothing fails, but I do not know it if is really working either. April -- The cat has too much spirit to have no heart. Ernest Menaul ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] stage #1 - job queue encapsulation within a class
April White wrote: I have uploaded my initial code to http://www.scintilla.org/aprilw/scite-dev-april-2005-10-23.zip There may be an extraneous 'Trace()' call that will echo the command string to the output pane. -- I have studied many philosophers and many cats. The wisdom of cats is infinitely superior. Hippolyte Taine ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Confirmation that FilePath class does not have a copy constructor
Neil, my development of the job system ABENDS when the code is assigning the command directory in SciTEWin::ProcessExecute() dirNameForExecute = job-directory; I know that it is failing on this line because I've written to a log file before and after this line, the second log entry is not written. I just want to confirm that the FilePath class does not have copy constructor nor assignment operator. April -- There is no snooze button on a cat who wants breakfast. Unknown ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] startup script reports an error
My Lua extension script has a function that centers the cursor in the middle of the screen, using code suggested by Neil. This works fine when called from the tool menu. FYI I called this 'CenterCursor' Additionally I have a function that hooks OnOpen, to locate a key word. When this word is found, the position the cursor was at when the file was saved is retrieved and repositioned. This too works fine. However, recently I added a call to 'CenterCursor' after the cursor has been position by the OnOpen hook. This is not working. This error is reported: ...\SciTEExtension.lua:510: bad argument #1 to `VisibleFromDocLine' (number expected, got string) The function is: function CenterCursor() local line = props.SelectionStartLine; local topLineWanted = editor:VisibleFromDocLine(line) - editor.LinesOnScreen / 2; -- line 510 editor:LineScroll(0, topLineWanted - editor.FirstVisibleLine) end FYI, if you like the script, you may find this revision useful for a second one called TopCursor(). Change the second line to: local topLineWanted = editor:VisibleFromDocLine(line) - 2; April -- A fool must now and then be right by chance. Cowper ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] exposing the SciTE 'execute tool' functionality to Lua
Doyle Whisenant wrote: Does this mean that one can have multiple tools executing one after another with only one command? If not, is this possible? No promises, I've only just cracked open the code... Ultimately I feel the command system will be able to handle multiple tools, but no via a hot key direct call. An executing tool blocks the tool menu currently and I feel should remain so. However, I want to allow a Lua tool script to add multiple commands, which should accomplish what you want. There is a lot to learn and more to do. I have to allow multiple threads to add to the queue, which necessitates locking the queue, etc, etc. Mutexes, semaphores, and handles oh my. :-) April -- I can't remember if I'm the good twin or the evil one. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] exposing the SciTE 'execute tool' functionality to Lua
Neil Hodgson wrote: Add a class that encompasses: - the storage of Job jobQueue[commandMax] array and - the functionality of SciTEBase::ClearJobQueue(), SciTEBase::AddCommand() Yes, encapsulating the job queue into a new JobQueue class would be very helpful. Okay, that'll be step #1 - replace the jobQueue array with a parent class and link-list. The JobQueue class will need to perform locking ... Step #2 :-) Lets see what some advantages are: - existing job methods could use the new parent class - the queue array is safe, only the parent class can add or remove entries - the number of jobs, currently limited to two, would be unbounded - you could argue that this is also a disadvantage I think it is mostly an advantage. However, I'm less sure that exposing this to the user is always good. Sometimes when an external tool is taking some time, I press F5 again in case I missed the first time. Should this add a second run to the queue or should only a single user action be running at once? Off the cuff, I'd say that UI events should not be able to add multiple commands, but of course that is easier said than done. If the same executing value is used, then tool commmand could still be blocked, and only an extender or internal events such as command.go.needs would be able to add multiple commands. - Lua and other extenders could interface to the job system from the UI thread but the job would be executed from the tool thread - each code piece that adds a command would not have to conditionally execute it There is some additional processing that needs to be checked if AddCommand directly calls Execute. I think you mis-read my message. Currently most/all calls of AddCommand() are followed by if (commandCurrent 0) before calling Execute. If the UI thread monitors the queue and calls Execute when necessary, then the call to Execute after every AddCommand would be unnecessary. April -- Allow me to introduce my selves. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] SciBall.ico
Peter Wu wrote: I edit the icon from Microsoft visual studio. there is only one icon to edit. maybe it is 32x32 bitmap If I use microsoft paint from accesseries, the icon is different from what I see under Microsoft visual studio. maybe it is 16x16 bitmap. I opened the .ico using Micrsofts ImagEdit program and it showed three 'unknown device' images and a 32x32 image. April -- I will strive to live each day as if it were my 50th birthday. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Suggestions for locating a problem with compile/build/go tools
I have in my user properties command.build.makefile=make command.build.Makefile=make command.build.*.mak=make -f $(FileNameExt) When I edit a makefile, the compile/build/go tools are grayed out. When I edit makefile.mak, the 'build' tool is enabled. Could this be a problem with the new filepath class? Has it been fixed in v1.66? April -- Without freedom of choice there is no creativity. James T. Kirk, 'The Return of the Archons', stardate 3157.4 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] I revised my notes for http://lua-users.org/wiki/SciteLuaDll
I've alter my notes on the above wiki page, explaining about passing a parameter to the libinit() method, so that the name of the table can be set by the user. Would this also be the site/place where I could post samples of C functions that can call scite methods such as scite.SendEditor(...). My attempts to access the properties table did not work. It left the stack in a inconsistent state. If someone would be interested in looking at it, email me off line. April -- Without followers, evil cannot spread. Spock, 'And The Children Shall Lead', stardate 5029.5 ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] problems compiling scite on mingw
patrick müller (aka elias) wrote: ... but scite don't compile and i've no clue where the problem is. (btw. i'm a c noob ;)) Here is the output: ... mingw32-make: *** No rule to make target `WindowAccessor.o', needed by `SciTEBase.o'. Stop. Hello Patrick, Please double check that Scintilla was properly made. The above message when SciTE is compiling indicates that the WindowAccessor.o was not made while Scintilla compiled . When Scintilla compiles, the .o files are placed into scintilla\win32, look there Go back to Scintilla\Win32 and run make clean all which should delete all .o files and then recompile everything. I'll be online for a while, let me know soonest - off the list if you want - what happens April -- Eat well, stay fit, die any way. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] lua script changes to a buffer - to get them outside of an undo
I have script that locates within the current buffer a line like: last at: and replaced the part with the current line position, so that when the file is loaded, the cursor is repositioned. The script works fine, but I would like the changes made to the buffer to be excluded from the 'undo' stack. Is this possible? April -- When women are depressed they either eat or go shopping. Men invade another country. -- Elayne Boosler ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
