Re: [scite] Three proposed patches to SciTE
steve donovan:
for (int param = 0; param maxParam; param++) {
SString paramText(param + 1);
SString paramTextVal = props.Get(paramText.c_str());
if (paramTextVal.length() 0) {
if (paramTextVal.contains( )) {
SString val;
val += \;
val += paramTextVal;
val += \;
paramTextVal = val;
}
parameters += paramTextVal;
parameters += ;
}
}
Needs documentation.
BTW, the existing line in lua.properties is problematic:
command.go.*.lua=Lua-5.0.exe $(FileNameExt)
The .exe shouldn't be needed on Windows either.
The Lua people are now just calling their executable 'lua', now that
the 5.0-5.1 transistion is over.
Someone that uses command line Lua on Windows should say whether this works
command.go.*.lua=lua $(FileNameExt)
Neil
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
steve donovan:
if (props.GetInt(find.files.using.extension)) {
SString ext = *.;
ext += filePath.Extension().AsInternal();
memFiles.Insert(ext);
}
Since its fairly rare for a language to have a single extension
(C/C++ programmers will often have both .c/.h or similar) I was
expecting a second layer to this. If someone writes up a documentation
patch as well the above can go in.
Neil
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
The IDM_* constants are now exposed to Lua like all the SCI_* constants. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 8/1/07, Neil Hodgson [EMAIL PROTECTED] wrote: The modularity wasn't that great either as it made other features depend on the Lua subsystem. It also exposes a lot more symbols to features like user.shortcuts that may not be sensible although it would allow user.shortcuts=Alt+Home|SCI_RIGHTEND| Ah, I see: one can't then do a Lua-free build; that's a bugger. But one does get the bonus feature ;) Any other way to skin the cat? One could keep the IDM_ table part of the core and make IFaceTable depend on it? steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
steve donovan: Ah, I see: one can't then do a Lua-free build; that's a bugger. I suppose IFaceTable doesn't have to be considered part of Lua support - I can't see any calls to real Lua in IFaceTable.cxx or .h but am unsure whether there are indirect links. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 8/1/07, Neil Hodgson [EMAIL PROTECTED] wrote: I suppose IFaceTable doesn't have to be considered part of Lua support - I can't see any calls to real Lua in IFaceTable.cxx or .h but am unsure whether there are indirect links. OK, then how about refactoring the IDM_ lookup out as a static SciTEBase function, and making IFaceTable use that if it can't match one of the Scintilla constants. If weird inappropriate constants are a problem then we can enforce that in IFaceTable. steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 7/31/07, Neil Hodgson [EMAIL PROTECTED] wrote:
How are you going to arbitrate between the current extension's
choice and the history? I commonly make a series of searches with one
mask.
I've thought about that. One method would be to (a) always make unique
insertions into the history and (b) ensure that the current extension
pattern is the first in the history list. Uniqueness is necessary,
otherwise we get lots of bogus copies. I'll see if I can come up with
a reasonably elegant way to implement this. (This behaviour would only
happen if some property, say find.files.using.extension, was non-zero)
Don't really see the advantage over using quotes where needed when
specifying commands.
I'll post a solution; it isn't too complicated.
Apropos MenuCommand changes:
This has been looked at before. If you have a good way of doing it
I'll probably include it.
The patch involves changing the signature of ExtensionAPI::DoMenuCommand;
in Extender.h around line 30, we then have
virtual void DoMenuCommand(const char *cmd)=0;
in SciTEBase.h around 901 we have:
void DoMenuCommand(const char* cmd);
and the corresponding method definition in SciTEBase.cpp, at the end
of the file, actually does the interesting bit:
void SciTEBase::DoMenuCommand(const char* cmd) {
int cmdID;
if (cmd cmd[0]) {
if (isdigit(cmd[0])) {
cmdID = atoi(cmd);
} else {
cmdID = GetMenuCommandAsInt(cmd);
}
MenuCommand(cmdID, 0);
}
}
In LuaExtension.cxx, around 277, there is a new implementation of
cf_scite_menu_commmand():
static int cf_scite_menu_command(lua_State *L) {
const char* cmdID = lua_tostring(L,1);
if (cmdID) {
host-DoMenuCommand(cmdID);
}
return 0;
}
(Here we're relying on lua_tostring() that tries to convert any value
into a string)
As an added bonus, in SciTEBase::PerformOne() (around 4588) we use
DoMenuCommand to implement the 'menucommand' extension verb:
} else if (isprefix(action, menucommand:)) {
DoMenuCommand(arg);
}...
steve d.
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 7/31/07, Neil Hodgson [EMAIL PROTECTED] wrote:
Don't really see the advantage over using quotes where needed when
specifying commands.
Fair enough, but the patch isn't very complicated:
In SciTEBase::SelectionIntoProperties() (ScTEBase.cxx, 1213)
insert this code:
// collecting parameters into a collective 'Parameters' property
SString parameters;
for (int param = 0; param maxParam; param++) {
SString paramText(param + 1);
SString paramTextVal = props.Get(paramText.c_str());
if (paramTextVal.length() 0) {
if (paramTextVal.contains( )) {
SString val;
val += \;
val += paramTextVal;
val += \;
paramTextVal = val;
}
parameters += paramTextVal;
parameters += ;
}
}
props.Set(Parameters,parameters.c_str());
A more elegant way to quote the string using SString, anybody?
Now all I have to do to get my program to use these parameters is to
modify the command.go properties - for instance:
command.go.*.lua=lua $(FileNameExt) $(Parameters)
BTW, the existing line in lua.properties is problematic:
command.go.*.lua=Lua-5.0.exe $(FileNameExt)
because this only works for Windows; need something like:
if PLAT_GTK
command.go.*.lua=lua $(FileNameExt)
if PLAT_WIN
command.go.*.lua=Lua-5.0.exe $(FileNameExt)
Or just leave out the .exe?
The Lua people are now just calling their executable 'lua', now that
the 5.0-5.1 transistion is over.
Anyway, just to show that it can be done and it isn't complicated.
Tastes may differ, of course.
steve d.
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
steve donovan: The patch involves changing the signature of ExtensionAPI::DoMenuCommand; in Extender.h around line 30, we then have virtual void DoMenuCommand(const char *cmd)=0; The idea of a published extension interface is to give extension writers a solid basis to work. Changing method signatures will make existing extensions fail. I'd like people to think about this when proposing additions to the extension interface: once its published in a release we're stuck with it. in SciTEBase.h around 901 we have: void DoMenuCommand(const char* cmd); I didn't want to do it this way since its less useful than having the constants be available to Lua similar to the way that other constants (such as SCI_SETZOOM) are made available. Doing this in the same way as SCI_SETZOOM would add around 3K for strings (in IFaceTable.cxx) that are already in the executable so I'd prefer a way that avoids double storage of those strings. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 7/31/07, Neil Hodgson [EMAIL PROTECTED] wrote:
steve donovan:
The patch involves changing the signature of ExtensionAPI::DoMenuCommand;
in Extender.h around line 30, we then have
virtual void DoMenuCommand(const char *cmd)=0;
The idea of a published extension interface is to give extension
writers a solid basis to work. Changing method signatures will make
existing extensions fail. I'd like people to think about this when
proposing additions to the extension interface: once its published in
a release we're stuck with it.
We already have another solution for this task in SciTE Ru-Board edition:
http://scite.ruteam.ru/engine/upfiles/mozers/SciTE-Ru_Kernel.html
(change name is [MenuCommandString])
that didn't change extension interface, only expand it:
add line to Extender.h
virtual int GetMenuCommandAsInt(const char *commandName)=0;
add line to SciTEBase.h
virtual int GetMenuCommandAsInt(const char *commandName) { return
GetMenuCommandAsInt(SString(commandName)); }
and change function in LuaExtension.cxx to:
static int cf_scite_menu_command(lua_State *L) {
if (lua_isnumber(L, 1)) {
host-DoMenuCommand((int)lua_tonumber(L, 1));
} else {
const char *s = luaL_checkstring(L, 1);
if (s) {
int cmdID = host-GetMenuCommandAsInt(s);
if (cmdID) {
host-DoMenuCommand(cmdID);
} else {
raise_error(L, MenuCommand ID not found.);
}
}
}
return 0;
}
Maybe, it's more useful solution.
--
With best regards,
Vladislav V. Vorob'ev
___
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
On 7/31/07, Neil Hodgson [EMAIL PROTECTED] wrote: I didn't want to do it this way since its less useful than having the constants be available to Lua similar to the way that other constants (such as SCI_SETZOOM) are made available. Doing this in the same way as SCI_SETZOOM would add around 3K for strings (in IFaceTable.cxx) that are already in the executable so I'd prefer a way that avoids double storage of those strings. So the IDM_ constants could be put into IFaceTable, and would then be automatically available. Then GetMenuCommandAsInt() could call IFaceTable::FindConstant(name). I know this is a little awkward, because then the script-generated tables in IFaceTable come from two sources, but it would avoid the double storage issue and provides a unified mechanism to look up significant constants. steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
steve donovan: So the IDM_ constants could be put into IFaceTable, and would then be automatically available. Then GetMenuCommandAsInt() could call IFaceTable::FindConstant(name). I know this is a little awkward, because then the script-generated tables in IFaceTable come from two sources, but it would avoid the double storage issue and provides a unified mechanism to look up significant constants. The modularity wasn't that great either as it made other features depend on the Lua subsystem. It also exposes a lot more symbols to features like user.shortcuts that may not be sensible although it would allow user.shortcuts=Alt+Home|SCI_RIGHTEND| Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] Three proposed patches to SciTE
Hi all, I'm just canvassing opinion on three changes which could be useful 1) Currently, Find-in-files is initialized with the property 'find.files, but it would be cool if there was an option for it to use the _current extension_ to build up a mask. If I am working in Python, then it should know that I am probably wanting to search Python files, etc. 2) View|Parameters sets $(1)..$(4). It would be convenient if there was a new constructed property $(Parameters) which is built out of these properties, quoted if necessary to make a valid command line. It would then be quite safe to update all the command.go properties to use $(Parameters) out of the box. 3) On the scripting side, scite.MenuCommand() takes an integer id which has to be looked up in SciTE.h by a human. Now SciTE already maintains a map of 'IDM_...' constants, so it is possible to redefine Extender::MenuCommand() to take a string argument and use this table if necessary, so that one can use symbolic 'IDM_..' names. This only takes an extra 15 lines and doesn't otherwise affect the interfaces. I have solutions for these (I wouldn't suggest them if I didn't ;)) but I wanted to know what people thought of them before I start posting patches. steve d. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Three proposed patches to SciTE
steve donovan: 1) Currently, Find-in-files is initialized with the property 'find.files, but it would be cool if there was an option for it to use the _current extension_ to build up a mask. If I am working in Python, then it should know that I am probably wanting to search Python files, etc. How are you going to arbitrate between the current extension's choice and the history? I commonly make a series of searches with one mask. 2) View|Parameters sets $(1)..$(4). It would be convenient if there was a new constructed property $(Parameters) which is built out of these properties, quoted if necessary to make a valid command line. It would then be quite safe to update all the command.go properties to use $(Parameters) out of the box. Don't really see the advantage over using quotes where needed when specifying commands. 3) On the scripting side, scite.MenuCommand() takes an integer id which has to be looked up in SciTE.h by a human. Now SciTE already maintains a map of 'IDM_...' constants, so it is possible to redefine Extender::MenuCommand() to take a string argument and use this table if necessary, so that one can use symbolic 'IDM_..' names. This only takes an extra 15 lines and doesn't otherwise affect the interfaces. This has been looked at before. If you have a good way of doing it I'll probably include it. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
