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( )) {
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
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
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
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
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
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
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:
//
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
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
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
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,
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
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,
14 matches
Mail list logo
