Re: [scite] exposing the SciTE 'execute tool' functionality to Lua

Neil Hodgson wrote: Do you think it is possible to move the SciTEWin::ExecuteOne() method into a pure C function, and then add it to the scite table within Lua? Let me rephrase this, I know it is possible. Do you think there is enough need? I don't think it is worth the extra comp

[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(...).

Re: [scite] exposing the SciTE 'execute tool' functionality to Lua

Neil Hodgson wrote: The best direction may be to provide a way for Lua to add a command to the command queue. Please consider the following http://www.scintilla.org/aprilw/scite-april-2005-09-24.zip In simple terms, I made AddCommand and Execute virtual methods of the ExtensionAPI class,

[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 n

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 I

Re: [scite] exposing the SciTE 'execute tool' functionality to Lua

Neil Hodgson wrote: Neil Hodgson: This does not appear to have taken threading into account. Which thread is it running on? How is this synchronized with other activities including other queued actions? You may need to lock the queue. I should explain here that for SciTE on Win32,

Re: [scite] exposing the SciTE 'execute tool' functionality to Lua

Neil Hodgson wrote: Neil Hodgson: This does not appear to have taken threading into account. Which thread is it running on? How is this synchronized with other activities including other queued actions? You may need to lock the queue. I think I understand what you mean now. When I press

Re: [scite] exposing the SciTE 'execute tool' functionality to Lua

Neil Hodgson wrote: I switched the order of your replies. Yes, and I'm going to be a bit protective with this feature as it is easy to get threaded code wrong. Hello Neil. I want to emphasize that I'm thinking out loud here, with little to back this up. Instead of having (abbreviated)

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 ste

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 ho

Re: [scite] new 1.66 find-in-files features

Jeff Hillman wrote: I just installed Scite 1.66 (Windows), but the checkboxes in the find-in-file dialog for "Match whole word only" and "Match case" are greyed out. What do I need to do to to be able to use these options? If the 'find.command' setting is blank, SciTE uses an internal grep se

[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 i

[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

Re: [scite] Confirmation that FilePath class does not have a copy constructor

April White wrote: Neil, my development of the job system ABENDS when the code is assigning the command directory in SciTEWin::ProcessExecute() dirNameForExecute = job->directory; I just realized that I moved above assignment from SciTEBase::Execute() to SciteWin::ProcessExec

[scite] stage #1 - job queue encapsulation within a class

FYI The revisions to SciTE for encapsulating the job system with a class is still a work in progress. I have uploaded my initial code to http://www.scintilla.org/aprilw/scite-dev-april-2005-10-23.zip Basically, I've added SciTEJobQueue.cxx/.h, moving Job class into it. I believe the SciTE

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

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

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

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 wor

[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 variabl

[scite] sending message to SciTE

Hello everyone. Within SciTEBase.cxx I have replaced Execute(); with ::SendMessage(reinterpret_cast(wSciTE.GetID()), WM_COMMAND, IDM_JOBS, 0); which I based on the MainHWND() function of SciTEWin.cxx I've added a command case to SciTEWin.cxx and successfully responded to the message abo

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

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 vari

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

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 call

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 h

[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. implem

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 messa

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

[scite] SciTE jobs and parameters

The SciTE documentation states: Alternatively, a command can be made to display the modal Parameters dialog when executed by starting the command with a '*' which is otherwise ignored. If the modeless Parameters dialog is already visible, then the '*' is ignored. With the work I'm doing on j

Re: [scite] command-line parameters for the program you're writing

David Bush wrote: ...Is there some way for the "Go" command to tack on some data for my script to use? Thanks for your time. Hello David. Search the SciTE help for this section: Command parameters and prompting SciTE has 4 properties $(1) .. $(4) which can be used to run commands w

[scite] internal flag 'isBuilt'

Hello everyone. There is a wee bit of snow up here, not enough to lock the town up tight, but enough to make me say "hey, lets play on the computer". I've been refining my job queue code - I still have to work out the kinks in the 'parameterized command' code, and there is an assignment to d

Re: [scite] internal flag 'isBuilt'

Neil Hodgson wrote: ... I want to keep the output of the first job on the screen when the second job runs. ... Maybe have a clears screen flag on each job which is only set on the first if you are adding both a build and go. I was thinking of querying for the 'jobIsBuilding' flag but i

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 f

[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 I included a Changelog.txt file to summarize what I have revised. This version has: - improved & corrected the handling of parameteri

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 boolea

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.

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] Revision #5 of job's

I've uploaded the latest revision of my JobQueue implementation to http://www.scintilla.org/aprilw/scite-april-2005-12-11.zip - rolled back to changes where I merged IsBuilt, IsDirty, UseMonoFont into a bit-field variable - removed the code the passed the job object from the ExecuteOne() metho

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

Re: [scite] Revision #5 of job's

Neil Hodgson wrote: 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 was thinking of reentrance on the UI thread. User

Re: [scite] Revision #5 of job's

April White wrote: ... Maybe I should move the variable 'executing' to the jobQueue class and wrap it in locks. I'll upload everything sometime later, but this is the re-worked SciTEWin::Command() section: ... I've worked over IDM_FINISHEDEXECUTE and IDM_JOBS, it is

[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=Get

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 Ca

Re: [scite] Revision #5 of job's

Neil Hodgson wrote: ps. Instead of downloading the 1.67 source, I can use CVS to get all of the new stuff? Yes, but ... I think you'll end up with a dreadful mess I've kept my cdv source and dev source seperate. I'll use cvs to upgrade cdv and then when ready apply the revisions to

[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,

[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 JobQ

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 prope

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

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 o

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 currentl

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. J

Re: [scite] v1.67 version of my job implementation

Neil Hodgson wrote: timeCommands = props.GetInt("time.commands") != 0; ... DWORD exitcode = static_cast(lParam); You must be using a different compiler than MinGW, or something different. These never complained when I compiled. I've implemented them though. I've also in

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

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

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 s

[scite] assistance with a Lua editor:match() script

Hi everyone. I want to write a Lua script that will do a regex search on the current document, returning all lines that contain the search string, passed through the parameter properties. So far I have: function Internal() local m, txt if props["1"] ~= "" then print( ">Internal:

Re: [scite] assistance with a Lua editor:match() script

April White wrote: I want to write a Lua script that will do a regex search on the current document, returning all lines that contain the search string, passed through the parameter properties. ... for m in editor:match( "^.+" .. props["1"] .. ".+$", SC

Re: [scite] Hello all, I have just 5 quick questions about SciTE on Linux/Gnome.

Robert Roessler wrote: Victor B. Gonzalez wrote: 2) Currently, in writing Python code, indentations are a whole tab. Is it possible to modify these indentations to take up only 4 spaces instead? Is it possible the indents can be made a little tighter? How? There may be some other reason you

[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 b

[scite] can an extender like Lua acces the current buffer?

This may be of primary interest to Neil. I've found that using host->Save() and host->CurrentBuffer() with LuaExtension.cxx fails because these two methods are not part of Extender.h Could they? Should they? I may have to re-think having LuaExtension scite.Execute() to be able to utili

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

[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

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 f

[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?

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 j

Re: [scite] Re: A revision possible based on SciTE documentation

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 PROTECT

Re: [scite] A revision possible based on SciTE documentation

Neil Hodgson wrote: SetDocumentAt is not really something that should be called from the tool thread. 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. I

[scite] Revision #6 to the job system

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.mo

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

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

[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?

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 qu

Re: [scite] Regular expression based generic lexer

Neil Hodgson wrote: Eugene Wong has produced a generic lexer based on regular expressions. I find the approach confusing but others may appreciate it more. You can download from http:/scintilla.sourceforge.net/scite166r.tar.bz2 The language description is contained in .properties files as ke

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 whe

Re: [scite] Lua question

Istvan wrote: I wish to write a lua script which add this text: Last Modified: 2006.02.01 at the top of the edited file when I save it. I wrote something like this for my own use. I can post my solution here, to the Lua-Users site, or by private email to yourself. The only problem it seems

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.

Re: [scite] Lua question

Kein-Hong Man wrote: Bracket with the following (barely tested): editor.UndoCollection = false -- edit stuff here editor.UndoCollection = true It was recommended to me to use: local u = scite.SendEditor( SCI_GETUNDOCOLLECTION ) scite.SendEditor( SCI_SETUNDOCOLLECTION, false ) ..

Re: [scite] Re: Re: Revision #6 to the job system

Bruce Dodson wrote: 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

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 according

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

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), ev

[scite] revision #7 to the tool/command/job system

I've uploaded to http://www.scintilla.org/aprilw/scite-april-2006-02-13.zip the latest release. In summary: *AddJob() has been renamed to AddCommandExt() to more closely mirror AddCommand() *removed DecodeCommandMode() from ../src/Extender.h *corrected implementation between Lua

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. *SciTEBase::ToolsMenu() implements code that consolidates command modes, properties and job flags; my thanks to Bruce Dodson *SciTE::DecodeCommandMode() decodes

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 success

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 ba

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/

Re: [scite] revision #7 to the tool/command/job system

Neil Hodgson wrote: I have corrected the bug and uploaded the correction to the same file as above. The CmdQueue code looks like an abandoned experiment as it doesn't appear to be linked in. I was planning on renaming the Job* system to Command* but reversed this and forgot about the

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-03-02.zip those revisions based on Neil's last email. The CmdQueue code looks like an abandoned experiment as it doesn't appear to be linked in. I was planning on renaming the Job* sy

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

Re: [scite] SciTE 1.68 with z-order buffer switching

Istvan wrote: Regarding F12, it can be changed from SciTEGlobal.properties H&ypertext|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 SciTEGlo

[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-in

[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 followi

[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

[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 correct

Re: [scite] Re: revision #8 to the tool/job/command system

Bruce Dodson wrote: I do think it makes more sense to keep the saveBefore separate from the flags, because saveBefore is not used by the job subsystem; saveBefore is applied "before" the job is placed in queue. With or without that change, here is a further refactoring of the good work you'v

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

Re: [scite] Re: Re: revision #8 to the tool/job/command system

Bruce Dodson wrote: Looking at the savebefore flags, it would be easier to set and evaluate them if these were the flag values: jobSaveBeforePrompt=0, // default jobSaveBeforeYes=768, jobSaveBeforeNo=256, jobSaveBeforeMask=768 Hello Bruce, Interesting idea, though 768 could be

Re: [scite] Default Python properties

Dave Kuhlman wrote: So, I'd like to suggest that the following be added to the python.properties file in the distribution: tabsize.$(file.patterns.py)=4 indent.size.$(file.patterns.py)=4 use.tabs.$(file.patterns.py)=0 comment.block.python=## comment.block.at.line.start.python=1

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

  1   2   >