Accumulating properties
Neil Hodgson
languages are gathered together as a list. open.filter defines the
filters available in the open dialog, source.files defines the normal
set of file types, and menu.language defines the Language menu.
The user can change these values in their user.properties file but
that often means duplicating the settings in user.properties which
means they won't respond to updated global properties when a new
version is installed. Since variables are late evaluated, you can't
add a new language by writing in the user.properties
menu.language=$(menu.language)Nu language|nu||
A related issue is that adding a language involves both adding a
new .properties file and editing its properties into the global
properties file.
There are several approaches that could be used to help here:
1) An append operator '+=' could be defined to append text to
variables. This would allow the ada.properties file to include
source.files+=*.ads;*.adb;
2) Add 'simply expanded variables' that are evaluated early instead of
late. This is similar to make where SciTE's current variables are
'recursively expanded variables' and we can copy make's syntax with a
colon before the assignment:
source.files:=$(source.files)*.ads;*.adb;
This is more verbose but allows changing the order so values can be
added at the beginning as well as at the end.
Both these approaches are a bit fragile: each file has to do the right
thing or the chain will break.
3) Have a wildcard property syntax like:
source.files=$(*source.files.*)
where each language's .properties files adds definitions like:
source.files.ada=*.ads;*.adb;
To allow overriding in user.properties, this would be evaluated by
searching all property sets for variables that start with
'source.files.', removing duplicates, and then evaluating each
variable name.
There may be issues here with the order and whether a delimiter
should be added between settings.
To complement these features, there could be more control over
which .properties files are imported with inclusion or exclusion lists
definable:
import.properties=ada python shell
or
import.properties=$(properties.in.global.directory)
import.exclude=cpp batch
As there are ordering issues between the .properties files and
changing import.properties may add or remove files which contain
variables that are used in import.properties, it may be necessary to
loop on loading properties until the set of files imported is stable
with an upper bound on the number of loops.
Neil
Lorenzo Donati
[...]
Sorry to be slightly OT, but these are somewhat related and may suggest
a way to overhaul the properties system to accomplish what you meant.
Many times I wished for a "master" configuration file in the SciTE
directory, such as SciTE.ini or whatever, in which you could specify
exactly which standard properties files will be loaded and in which
order, with options to suppress standard location searching (it would be
useful for "portable" installations - I don't like to call scite through
a cmd shell script just to set SciTE_HOME to point to my pendrive).
Maybe also some GUI options that cannot be set later in the game (a
custom extra menu?)
This file wouldn't be in the "default" config file chain. It would have
a completely different purpose - it would be a sort of
"meta-configuration" file. It's the same approach of the eclipse IDE -
it has an eclipse.ini file where the deployer - as opposed to the user -
can set a bunch of options which cannot be set in another way, since
they influence the way other configuration files are loaded.
On a related note, I always wondered why SciTE properties files aren't
Lua files. I suppose it is a legacy from a time when SciTE didn't embed Lua.
Probably Lua is fast enough to compete on par with the current
properties file loader.
I know that plain Lua files as configuration files may be intimidating
for a newbie, but this could be ameliorated with a DSL. In such a way, a
"normal" config file would be written only with the DSL facility (just
guessing the syntax, for comprehension's sake - no deep thinking behind
- there may be better solutions):
Props "command.shortcut.1.*.py" = "Ctrl+1"
or
P "command.shortcut.1.*.py" = "Ctrl+1"
(here P or Props or whatever is a function that does the right
table/metatable tricks to make the syntax work)
whereas more expert Lua scripters may access the full power of Lua:
local function complex_text_processing()
local original_text = props['CurrentSelection']
-- do stuff
return processed_text
end
Props "command.1.*.py" = complex_text_processing
Of course a well-defined loading sequence should be specified for
"default" config files.
> Neil
>
Cheers.
-- Lorenzo
Lorenzo Donati
pressing the send button the morning after :-(
On 22/08/2011 12.04, Lorenzo Donati wrote:
[...]
>
>
> Props "command.shortcut.1.*.py" = "Ctrl+1"
A couple of brackets is missing:
Props[ "command.shortcut.1.*.py" ] = "Ctrl+1"
>
> or
>
> P "command.shortcut.1.*.py" = "Ctrl+1"
idem:
P[ "command.shortcut.1.*.py" ] = "Ctrl+1"
>
> (here P or Props or whatever is a function that does the right
> table/metatable tricks to make the syntax work)
>
This syntax works in plain Lua, no tricks needed.
The errors are due to a tentative proposal badly edited afterwards.
[...]
sorry for the noise.
-- Lorenzo
Mario Mey
time I open SciTE, I want that code minimized... Could I?
Neil Hodgson
> Many times I wished for a "master" configuration file in the SciTE
> directory, such as SciTE.ini or whatever, in which you could specify exactly
> which standard properties files will be loaded and in which order
I think this would cause even more problems with users confused by
the effects of different load orders producing unexpected behaviour.
> On a related note, I always wondered why SciTE properties files aren't Lua
> files. I suppose it is a legacy from a time when SciTE didn't embed Lua.
Using Lua would add noise to the files and make it too easy to fail
because of a syntax error.
Neil
Philippe Lhoste
> I minimize some code (the minus at the left of the code) and the next
> time I open SciTE, I want that code minimized... Could I?
No.
It would need a companion file for each file or directory, and would
probably fail if you edit the file (add/remove lines) with another
editor (supposing the fold information is using the line number to tell
where the fold points are).
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Mario Mey
helpfull for me. And now, when I am having more complex... and more
code, I would find what I want easier.
Could it be a feature in future...?
Possibles solutions:
1.- It could be saved in default session file.
2.- It could create a commented code... and, when editing, it can be
hidden. For example (comment at the end of line 235 is created
automatically):
234 - print('foo')
235 - def func(x): # Min #
236 - print('1')
237 - print('2')
238 - print('3')
239 - return x
240 - func(4)
And, in edit mode, we should see like this:
234 - print('foo')
235 + def func(x):
-----
240 - func(4)
El 23/08/11 04:29, Philippe Lhoste escribi�:
Philippe Lhoste
> When I used ActionScript, in Flash, the reducing visible code was REALLY
> helpfull for me.
I haven't used the Flash IDE. I don't know if other folding IDEs like
Eclipse remember the foldings, although it can be easier for them, as
they already has a database about the project.
I find myself rarely folding code anyway, more using Ctrl+E to jump to
the other end of a method (although it won't work for Python-like code...).
> And now, when I am having more complex... and more
> code, I would find what I want easier.
A possible way is to have everything folded on opening, thus you open
only the parts interesting you.
I found back the property: fold.on.open
> Could it be a feature in future...?
>
> Possibles solutions:
>
> 1.- It could be saved in default session file.
> 2.- It could create a commented code... and, when editing, it can be
> hidden. For example (comment at the end of line 235 is created
> automatically):
>
> 234 - print('foo')
> 235 - def func(x): # Min #
I am a bit reluctant of having a display feature changing the code
itself. Can be a nightmare for source code control systems...
Searching the above property, I actually found out there is a way to ask
to save folding state in the session files! I totally forgot about this
(never used it). Search session.folds in the SciTE doc.
steve donovan
> I find myself rarely folding code anyway, more using Ctrl+E to jump to the
> other end of a method (although it won't work for Python-like code...).
It would be useful if Ctrl-E would use folding information, rather
than tracking curly braces. It would be useful for Lua as well.
> Searching the above property, I actually found out there is a way to ask to
> save folding state in the session files! I totally forgot about this (never
> used it). Search session.folds in the SciTE doc.
The capabilities of SciTE always amaze me ....
steve d.
Mario Mey
I want to launch SciTE from an icon. To save session on quit, I have to
start it as admin. I can use "gksu SciTE", but I have to enter the pass
all the times.
Isn't there any way to automatically save the default session to...
/home/user/SciTE, for example? So, we don't need to launch it as admin.
El 23/08/11 08:51, Philippe Lhoste escribi�:
Philippe Lhoste
> Thank you, Philippe! The option was there. And now... I have a doubt...
> I want to launch SciTE from an icon. To save session on quit, I have to
> start it as admin. I can use "gksu SciTE", but I have to enter the pass
> all the times.
>
> Isn't there any way to automatically save the default session to...
> /home/user/SciTE, for example? So, we don't need to launch it as admin.
Still from the manual:
"For GTK+, the file is called ".SciTE.session" and is located in the
directory given by the SciTE_HOME environment variable and if that is
not set, the value of the HOME environment variable and if that is not
set, the top level directory."
Lorenzo Donati
On 23/08/2011 0.28, Neil Hodgson wrote:
> Lorenzo Donati:
>
>> Many times I wished for a "master" configuration file in the SciTE
>> directory, such as SciTE.ini or whatever, in which you could specify exactly
>> which standard properties files will be loaded and in which order
>
> I think this would cause even more problems with users confused by
> the effects of different load orders producing unexpected behaviour.
As I mentioned, maybe not too clearly, it should be a very specialized
and advanced "hook" for people knowing what they are doing (deployers,
sysadmins, power users). It should come with BIG caveats and warning
sign in the manual. I almost feel it shouldn't even be dynamically
re-loaded if modified or appear in the Option menu.
And after all SciTE is an editor for programmers. I think that even from
the most novice it should be expected not to mess with things he/she
doesn't understand fully, if proper warning has been issued, otherwise
he/she shouldn't complain.
Moreover, there are issues that cannot be solved cleanly otherwise. To
be concrete, consider this example (I've been bitten by it a couple of
times). I usually carry SciTE on a removable HD and use it under
different systems/machines. Sometimes it happens that SciTE is already
installed on those machines, and SciTE_HOME is not what I'd like it to
be. It is really annoying using a shell script to reset SciTE_HOME and
then start SciTE (not to speak of the ugly black box flashing on Windows!).
I suppose that an option in a properties file cannot do, because I
assume the env var is processed too early. That's where such a
meta-configuration file would help (with an option to disable/override
SciTE_HOME processing).
I don't think in that meta file should go tons of options (*this* would
make it really messy indeed), but only some carefully selected options
that cannot be put in normal properties file.
>
>> On a related note, I always wondered why SciTE properties files aren't Lua
>> files. I suppose it is a legacy from a time when SciTE didn't embed Lua.
>
> Using Lua would add noise to the files and make it too easy to fail
> because of a syntax error.
I see. Fair point.
>
> Neil
>
-- Lorenzo
Neil Hodgson
> As I mentioned, maybe not too clearly, it should be a very specialized and
> advanced "hook" for people knowing what they are doing (deployers,
> sysadmins, power users).
These people should be able to write a short C (or Windows
Scripting) launcher program that starts SciTE as they want.
> Moreover, there are issues that cannot be solved cleanly otherwise. To be
> concrete, consider this example (I've been bitten by it a couple of times).
> I usually carry SciTE on a removable HD and use it under different
> systems/machines. Sometimes it happens that SciTE is already installed on
> those machines, and SciTE_HOME is not what I'd like it to be. It is really
> annoying using a shell script to reset SciTE_HOME and then start SciTE (not
> to speak of the ugly black box flashing on Windows!).
The next stage is that someone will be unhappy with the location of
the master configuration file and ask for a command line option to
move it somewhere else. There's no end to this slope.
Neil
Mario Mey
SciTE_HOME environment. I looked around web, but I don't understand how
to do it.
Could you explain it to me? There is no hurry...
El 24/08/11 04:37, Philippe Lhoste escribi�:
Philippe Lhoste
> Thanks Philippe, I think it's possible, but I don't know how to edit the SciTE_HOME
> environment. I looked around web, but I don't understand how to do it.
That's funny, when I deal with people using Unix systems, I tend to see them as knowing
them deeply, perhaps because these systems are more technical than a Windows system...
It is not a criticism, it takes guts to choose such system over the mainstream (if that's
a personal choice instead of having it forced in the workplace), and one has to learn it,
of course.
I fear I am not the most qualified to answer, as my main computing environment is Windows
(at home and at work), although I manipulated a number of Unix systems in my career. If
somebody has more precise information, don't hesitate to share it!
IIRC, you set permanent environment variables in a file like .rc in your home directory,
but the name will depend on the shell you use (shell, csh, bash, etc.). No idea of the
standard in Ubuntu.
Lorenzo Donati
> On 25/08/2011 15:32, Mario Mey wrote:
>> Thanks Philippe, I think it's possible, but I don't know how to edit
>> the SciTE_HOME
>> environment. I looked around web, but I don't understand how to do it.
>
> That's funny, when I deal with people using Unix systems, I tend to see
> them as knowing them deeply, perhaps because these systems are more
> technical than a Windows system...
> It is not a criticism, it takes guts to choose such system over the
> mainstream (if that's a personal choice instead of having it forced in
> the workplace), and one has to learn it, of course.
>
> I fear I am not the most qualified to answer, as my main computing
> environment is Windows (at home and at work), although I manipulated a
> number of Unix systems in my career. If somebody has more precise
> information, don't hesitate to share it!
>
> IIRC, you set permanent environment variables in a file like .rc in your
> home directory, but the name will depend on the shell you use (shell,
> csh, bash, etc.). No idea of the standard in Ubuntu.
>
I'm also an almost all-Windows user, but I seem to remember on *NIX
systems there's also a cmd line incantation to start a program with some
env var set in specific way. Something like:
env SciTE_HOME=/my/favourite/path SciTE
the man pages for the env command could be useful.
</too-limited-nix-knowledge>
-- Lorenzo
Mario Mey
channel is not the correct one. I only want to say this...
I am using Ubuntu for about 1.5 years. I always have used the computer
and I think I know a bit more about computers than the common people.
Only a bit more. When I start using OSS, I did it by filosophy... and at
the beggining, I thought it was going to be difficult. Now, with distros
like Ubuntu, Fedora, etc, using Linux is really easy... and thanks God
(God=programmers), now, anyone can use Linux, any "common person". It is
not more difficult than Windows.
But, if you want to "meter mano" (argentinism), to go deeper inside...
yes, maybe it's a bit difficult. The same in Windows. And maybe... in
Windows, you can't do it (like changing the backgrownd image in my
girlfriend Windows 7 Starter)
WE MUST NOT FEARING CHANGE. Open Source Software is the way to use the
technology as our, not only use the software.
Sorry, I had to say it!
Anyone can help me to change the SciTE_HOME enviroment?
El 25/08/11 11:35, Philippe Lhoste escribi�:
KHMan
> [snip]
> Anyone can help me to change the SciTE_HOME enviroment?
One-liner (tested on Cygwin):
export SciTE_HOME=/my/favourite/path && SciTE
Or set it in .bashrc:
export SciTE_HOME=/my/favourite/path
I'm not sure if it is set when you click icons to start apps. If
not, try the system-wide rc file which is in /etc/bash.bashrc or
something similar.
HTH,
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Mario Mey
SUGGESTION: when folding code, it would be good if the folded lines was
from the first, to the last, EXCLUDING THE SUBSEQUENT EMPTY LINES.
Sometimes, I use these empty lines for a better visual separation
between functions, for example.
Is there any reason to fold the empty lines?
El 25/08/11 13:20, KHMan escribi�:
Mario Mey
fold.compact=0
El 25/08/11 19:00, Mario Mey escribi�:
Neil Hodgson
function syntax. This would allow adding more features over time. One
use would be the wildcard feature mentioned. Another would be to
provide quoting so that strings could be delivered more safely to
tools. This came up with a find.command bug report
http://sourceforge.net/tracker/?func=detail&atid=102439&aid=3395633&group_id=2439
Automatic quoting is likely to cause problems and would not be
compatible with current use. Adding extra properties to indicate
quoting would be clumsy.
Since make has been a source of syntax for properties files, its
function syntax could be used within properties files. Functions in
make look like variables that start with "<function> " so SciTE's
makefile uses the 'shell' function like this:
UNAME:=$(shell uname -s)
Functions could be differentiated from variables by the presence of
a space. This would be incompatible with using spaces inside variable
names but I don't think anyone is doing this.
The two functions that appear useful for now are 'wildcard' and
'quote'. Example uses would be
search.command=grep XXX $(quote FileDir)
source.files=$(wildcard source.files.)
Neil
steve donovan
> The two functions that appear useful for now are 'wildcard' and
> 'quote'. Example uses would be
> search.command=grep XXX $(quote FileDir)
> source.files=$(wildcard source.files.)
This seems like a powerful solution. I remember converging on this
when I did Sciboo, which was a Scintilla editor using that other great
language from Brazil, Boo.
steve d.
Lorenzo Donati
> Another approach to extending properties would be to introduce
> function syntax. This would allow adding more features over time. One
> use would be the wildcard feature mentioned. Another would be to
> provide quoting so that strings could be delivered more safely to
> tools. This came up with a find.command bug report
> http://sourceforge.net/tracker/?func=detail&atid=102439&aid=3395633&group_id=2439
>
> Automatic quoting is likely to cause problems and would not be
> compatible with current use. Adding extra properties to indicate
> quoting would be clumsy.
>
> Since make has been a source of syntax for properties files, its
> function syntax could be used within properties files. Functions in
> make look like variables that start with "<function> " so SciTE's
> makefile uses the 'shell' function like this:
>
> UNAME:=$(shell uname -s)
>
> Functions could be differentiated from variables by the presence of
> a space. This would be incompatible with using spaces inside variable
> names but I don't think anyone is doing this.
>
> The two functions that appear useful for now are 'wildcard' and
> 'quote'. Example uses would be
> search.command=grep XXX $(quote FileDir)
> source.files=$(wildcard source.files.)
>
I would prefer something a bit different. Once the function mechanism
spreads and more functions are added, I foresee complex function chains
to be written, mixed with variables. This will end up with lots of
parentheses and nesting.
I'm not too fond of makefile syntax (BTW, I find := way too similar to
=, it's easy not to see the difference), but if there is no choice, at
least using a different type of brackets would help reading the files.
For example:
search.command=grep XXX $[quote $(FileDir)]
And IMO variables have to be explicitly expanded. I assume that FileDir
is not a literal in your example. If this is so, with automatic var
expansion, you couldn't write this:
search.command=grep XXX $[quote $(FileDir)/subdir]
but you should create a "temp" variable before and then pass it to the
quote function. This means more clutter in the properties files.
The $[func] approach could also avoid depending on a space for
differencing and could also allow 0-arity functions, if need arise.
A simple use for those functions could be as comments markers (of course
whether this is feasible depends on when functions are evaluated):
$[begin-comment]
whatever here inside will be skipped
$[end-comment]
BTW: do you plan adding also user defined functions? They would be
useful to simplify boring configuration tasks, but I'm not so sure of
the implications.
> Neil
>
-- Lorenzo
Neil Hodgson
> search.command=grep XXX $[quote $(FileDir)]
While that could work for FileDir its not going to look so good
with wildcard which takes a name prefix:
source.files=$[wildcard $(source.files.)]
is going to look like a there is a variable called source.files.
and it will be expanded before calling wildcard.
> And IMO variables have to be explicitly expanded. I assume that FileDir is
> not a literal in your example. If this is so, with automatic var expansion,
> you couldn't write this:
>
> search.command=grep XXX $[quote $(FileDir)/subdir]
but you can write
search.command=grep XXX $(quote FileDir)/subdir
> The $[func] approach could also avoid depending on a space for differencing
> and could also allow 0-arity functions, if need arise.
If arity 0 is ever needed then S(func ) is fine.
> A simple use for those functions could be as comments markers (of course
> whether this is feasible depends on when functions are evaluated):
>
> $[begin-comment]
I just use the block comment command.
> BTW: do you plan adding also user defined functions?
No.
Neil
Neil Hodgson
I'm still not sure about including this.
The first function is 'escape' and escapes characters like '$', '
', and '*' that are significant to the Unix shell so that unusual file
names or search strings can be passed to external tools. There could
be something similar for Windows although it more common for commands
to be run directly instead of through a shell and so there is less
need for quoting. On Unix, there could also be different styles of
escape for use within quotes as this could be more readable. An
example tool setting:
search.command=grep XXX $(escape FileDir)
The 'star' command finds all variables that start with a prefix and
joins them together. For example, the filter menu in the file open
dialog could be constructed like this:
open.filter=\
All Source|$(source.files)|\
$(all.files)\
$(star filter.)
A problem with doing this is that the filter list gets much longer
with rarely wanted values. This feature would be improved by some way
of eliminating variables of no interest.
The variables are ordered alphabetically by name so the order can
be manipulated by naming variables. With '1' coming before 'a', Perl
could be pushed to be the first specific filter with
filter.perl=
filter.1perl=Perl (pl pm)|$(file.patterns.perl)|
Neil
Neil Hodgson
properties files imported.
The "imports.include" property defines the names of the properties
files that may be imported. Say you are only interested in using
fortran and lisp, then in user properties, you could set
imports.include=fortran lisp
There is also an "imports.exclude" property that is examined only
if "imports.include" is empty or missing. This property stops the
named files from being imported. This is not as useful to users as
"imports.include" but is used to reduce the number of properties files
imported by SciTE in a default installation from over 70 to less than
30 and also to disable properties files that clash with others.
The import command was extended to allow "import *" which imports
all .properties files in the same directory as the file containing the
command, taking into account "imports.include" and "imports.exclude".
The default installation global properties then uses "import *" along
with "imports.exclude" to import the standard set of properties. This
allows new .properties files to be added to an installation by simply
copying them into the directory containing global properties.
The "imports.include" and "imports.exclude" properties will only
work correctly when located in global properties, user properties, or
a properties file imported by either of these.
Since the "imports.include" property will often be set in the user
properties which is loaded after global properties, both its value and
the value of "imports.exclude" are checked after loading user
properties. If they have changed then global properties and user
properties are loaded again. This could lead to a cycle, for example
if lisp.properties set imports.exclude=lisp and so the number of
iterations is capped, currently at 2.
I am more certain of these additions than of the "star" and
"escape" functions although they are related: "star" is particularly
useful to provide UI lists when the set of imported files matches the
user's working set of languages.
Not currently in Hg. Available from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable
Neil
Jérôme LAFORGE
It seems that ShellEscape have to also escape * (wildcard) character.
Because on modern file system, the pathname can contain * (wildcard)
like classic character.
Unfortunately, I can't test the source code "$[escape .... ]" because
the File Path Set::FilePathSet has been removed.
So, the tarball source doesn't compile.
Jérôme LAFORGE
Jérôme LAFORGE
../src/FilePath.cxx: In member function ‘void
FilePath::List(FilePathSet&, FilePathSet&)’:
../src/FilePath.cxx:423: error: ‘class std::vector<FilePath,
std::allocator<FilePath> >’ has no member named ‘Append’
../src/FilePath.cxx:425: error: ‘class std::vector<FilePath,
std::allocator<FilePath> >’ has no member named ‘Append’
make: *** [FilePath.o] Erreur 1
Neil Hodgson
> I just read this topic. If if I'm not mistaken on this subject.
> It seems that ShellEscape have to also escape * (wildcard) character.
> Because on modern file system, the pathname can contain * (wildcard)
> like classic character.
That is one of the problems with escaping and particularly
automatic escaping - sometimes you want the shell to do some
expansion. For example, in your original example on the tracker you
were interested in shell-significant characters in find.directory or
find.files:
find.command=grep -R -i --exclude=*.svn* --line-number "$(find.what)"
$(find.directory)$(find.files))
Now, say we have backed up earlier versions of some cxx files by
adding a final quote (.cxx') and then want to search these files so
enter "*.cxx'" in the Find in Files dialog. To ensure the quote makes
it to grep we $(escape find.files). If escape quotes '*' as well then
grep complains because there is no file called literally "*.cxx'":
neil@neil-VirtualBox:~/merc/scite/gtk$ grep gdkkey \*.cxx\'
grep: *.cxx': No such file or directory
whereas
neil@neil-VirtualBox:~/merc/scite/gtk$ grep gdkkey *.cxx\'
SciTEGTK.cxx':#include <gdk/gdkkeysyms.h>
Widget.cxx':#include <gdk/gdkkeysyms.h>
I don't really want to have many variants of escape to match each
particular scenario. While there could be an extra argument to show
what to quote, this could also have problems with .properties
significant characters:
find.command=grep "$(find.what)" $(escape *|'" find.files))
> Unfortunately, I can't test the source code "$[escape .... ]" because
> the File Path Set::FilePathSet has been removed.
FilePathSet had been a custom class but it was replaced with a
typedef using the standard library vector class.
typedef std::vector<FilePath> FilePathSet;
> Sorry, I forgot to put the error from gcc :
> ../src/FilePath.cxx: In member function ‘void
> FilePath::List(FilePathSet&, FilePathSet&)’:
> ../src/FilePath.cxx:423: error: ‘class std::vector<FilePath,
> std::allocator<FilePath> >’ has no member named ‘Append’
> ../src/FilePath.cxx:425: error: ‘class std::vector<FilePath,
> std::allocator<FilePath> >’ has no member named ‘Append’
> make: *** [FilePath.o] Erreur 1
OK, fixed to use push_back instead of Append. Uploaded new copy.
Neil
Jérôme LAFORGE
In case of escape without extra argument, maybe you can never escape
wildcard, and specified into documentation that it is the SciTE user
that's in charge of to escape manually the wildcard into find dialog
for example. In this case, ShellEscape has to ignore the \ just before
the *.
Thx for the fix of Linux compilation.
Neil Hodgson
> I am more certain of these additions than of the "star" and
> "escape" functions although they are related ...
The imports.include, imports.exclude and import * features are now
committed to hg. The star and escape functions have not yet been
committed as the escape function may change to allow control over
which characters are escaped.
Neil
John Yeung
across a problem, which might be related to my own configuration or
stupidity, but might be worse.
I'm testing this on WinXP SP3, SciTE version downloaded as
http://www.scintilla.org/wscite.zip
about two hours ago. The modification dates are all 2011-09-11 12:16.
My problem is that none of the language-specific properties files in
the SciTE program directory are imported. If I put language
properties files in the same directory as my user properties, they are
successfully imported.
Is there any further information I can provide to help figure out how
to import the program-directory properties?
John
Neil Hodgson
> My problem is that none of the language-specific properties files in
> the SciTE program directory are imported. If I put language
> properties files in the same directory as my user properties, they are
> successfully imported.
Have you changed imports.include or imports.exclude? Setting these
in user properties will affect global properties.
Look in SciTEGlobal.properties and ensure it ends with "import *"
and there is an imports.exclude before that to hide some of the
.properties. While that file is in the editor run "dir *.properties"
in the output pane to check that all the files are there.
Neil
John Yeung
>> files in the SciTE program directory are imported. If I put
>> language properties files in the same directory as my user
>> properties, they are successfully imported.
>
> Have you changed imports.include or imports.exclude?
> Setting these in user properties will affect global properties.
No, I haven't. I didn't touch SciTEGlobal.properties from the latest
download, which ends with imports.exclude and import *, and I tried
various things with SciTEUser.properties, including removing any
import statements there and even renaming the file entirely so there
is no user properties file loaded at all. In all cases, the full
complement of language-specific properties files are in the SciTE
program directory, same place where SciTEGlobal.properties lives, and
none of them are imported.
> Look in SciTEGlobal.properties and ensure it ends with "import *"
> and there is an imports.exclude before that to hide some of the
> .properties. While that file is in the editor run "dir *.properties"
> in the output pane to check that all the files are there.
Yep, all there.
John
Neil Hodgson
> No, I haven't. I didn't touch SciTEGlobal.properties from the latest
> download, which ends with imports.exclude and import *, and I tried
> various things with SciTEUser.properties, including removing any
> import statements there and even renaming the file entirely so there
> is no user properties file loaded at all. In all cases, the full
> complement of language-specific properties files are in the SciTE
> program directory, same place where SciTEGlobal.properties lives, and
> none of them are imported.
OK, there are a few steps to "import *". First is to enumerate the
directory and then this is filtered to just .properties and generic
properties (*SciTE*, abbrev, Embedded) removed. Its possible that a
different disk type (such as FAT or NFS) or permissions could be
affecting some of this. Disks that force upper case extensions should
work (on Windows) as I tested with some .PROPERTIES files.
Check that directory enumeration and some file filtering works by
running Find in Files in the global properties directory with Files
set to "*.properties" with something present in many properties l;ike
"filter.".
Neil
John Yeung
> Check that directory enumeration and some file filtering works by
> running Find in Files in the global properties directory with Files
> set to "*.properties" with something present in many properties l;ike
> "filter.".
Yep, Find in Files appears to work fine.
Question: If "import *" means "load properties from THIS directory",
then what's supposed to happen when the global and user properties
both contain "import *" and there are some properties files in each
directory?
John
Neil Hodgson
> Question: If "import *" means "load properties from THIS directory",
> then what's supposed to happen when the global and user properties
> both contain "import *" and there are some properties files in each
> directory?
First, "import *" in the global directory will import all the
.properties files in that directory and place them in the global
property set. Then, "import *" in the user directory will import all
the .properties files in that directory and place them in the user
property set where they will override the global properties. If a
single file is in both directories then it will be read twice, applied
to each property set, and the one in user properties will be the
source of values since it is earlier in the property search path.
Neil
John Yeung
> [How imports should work]
Thanks, that's what I thought, and what makes sense to me.
But for now it's not working that way on either of the machines I've
tried it on. If no one else is having this problem, then I suppose I
could either get used to keeping properties files in my user directory
or stick with an old version of SciTE. (I'm very good at the latter.)
John
Philippe Lhoste
On 12/09/2011 17:59, John Yeung wrote:
> I'm testing this on WinXP SP3, SciTE version downloaded as
>
> http://www.scintilla.org/wscite.zip
>
> about two hours ago. The modification dates are all 2011-09-11 12:16.
Same config here, except dates are 2011-09-13 01:39
French WinXP.
> My problem is that none of the language-specific properties files in
> the SciTE program directory are imported. If I put language
> properties files in the same directory as my user properties, they are
> successfully imported.
I just unzipped the wscite directory on my disk and ran SciTE. It picked the *.properties
from my user dir (defined with SciTE_HOME).
Then I dropped to command line, set SciTE_HOME= (ie. cancel the env. var.) and ran
SciTE.exe from there. I dropped various file (HTML, .bat, .diff, .sh, etc.) and it shown
the highlight from this release (my highlights are slightly different).
So, for me, both default and personal settings work out of the box.
> Is there any further information I can provide to help figure out how
> to import the program-directory properties?
If there is some process to do to reproduce your problem, just say.
Neil Hodgson
> But for now it's not working that way on either of the machines I've
> tried it on. If no one else is having this problem, then I suppose I
> could either get used to keeping properties files in my user directory
> or stick with an old version of SciTE. (I'm very good at the latter.)
Well, its a worry since if it has happened within a small set of
testers, then it is likely to recur.
I wonder if there is a SciTE_HOME setting or something unusual with
the application location or USERPROFILE such as a roaming user
profile.
Neil
John Yeung
> I wonder if there is a SciTE_HOME setting or something unusual with
> the application location or USERPROFILE such as a roaming user
> profile.
Well, when I do 'set SciTE_HOME' at the command prompt, I get
'Environment variable SciTE_HOME not defined'. My USERPROFILE here is
'C:\Documents and Settings\jyeung'. (I don't know what a roaming user
profile is.)
I'm running 2.29 in 'C:\Program Files\SciTE'. (I just downloaded the
latest wscite.zip and dumped all its contents there.)
I've tried setting SciTE_HOME to the program directory in a command
shell and then invoking SciTE from that shell, and it still doesn't do
the imports. I can see 'SciTE_HOME=C:\Program Files\SciTE' when I do
'set' in SciTE's output pane.
With or without SciTE_HOME, I can't do program-directory imports.
John
John Yeung
> With or without SciTE_HOME, I can't do program-directory imports.
Hm. Actually, now SciTE_HOME works. It started working when I
created a SciTEUser.properties in the SciTE_HOME (i.e. program)
directory. Ever since then, even after removing SciTEUser.properties,
the global imports work.
I know it sounds crazy, but I am positive SciTE_HOME wasn't working
before. I really did grab the SciTE_HOME value from SciTE's output
pane before, while the Options menu was empty below "Open Lua Startup
Script".
Anyway, it would seem there is a way to jolt SciTE into working with
SciTE_HOME, but I'm still not having any luck when SciTE_HOME isn't
set.
John
Neil Hodgson
> Well, when I do 'set SciTE_HOME' at the command prompt, I get
> 'Environment variable SciTE_HOME not defined'. My USERPROFILE here is
> 'C:\Documents and Settings\jyeung'. (I don't know what a roaming user
> profile is.)
A roaming user profile is where your account is held on a server
and copied down to the PC when you log in and copied back up at log
out allowing you to use different machines. It works through various
pieces of trickery like directory redirection.
> I'm running 2.29 in 'C:\Program Files\SciTE'. (I just downloaded the
> latest wscite.zip and dumped all its contents there.)
OK, the problem is the directory name is "SciTE" and there was a
check for generic properties files which contain "SciTE" but the full
path was checked instead of just the file name. Fix committed and
available from
John Yeung
I feel kinda dumb for not mentioning that earlier. The latest version works.
Out of curiosity, I tried to find what the differences were between
the 2011-09-11, 2011-09-13, and 2011-09-14 versions, and I can't find
any other than SciTE.exe and SciLexer.dll. I tried looking at the
contents of the respective scite.zip files, but I didn't see any
changes. Where in the source was the fix?
John
Neil Hodgson
> Out of curiosity, I tried to find what the differences were between
> the 2011-09-11, 2011-09-13, and 2011-09-14 versions, and I can't find
> any other than SciTE.exe and SciLexer.dll. I tried looking at the
> contents of the respective scite.zip files, but I didn't see any
> changes. Where in the source was the fix?
http://scintilla.hg.sourceforge.net/hgweb/scintilla/scite/rev/15a4cad5b085
Neil
John Yeung
>> scite.zip files, but I didn't see any
>> changes. Where in the source was the fix?
>
> http://scintilla.hg.sourceforge.net/hgweb/scintilla/scite/rev/15a4cad5b085
Ah. That (and I suspect other minor changes) didn't make it into
scite.zip. I suppose Mercurial is the best (only?) way to get the
latest updates. (Not that I need them. I just expected the source to
match the executable.)
John
Neil Hodgson
> Ah. That (and I suspect other minor changes) didn't make it into
> scite.zip. I suppose Mercurial is the best (only?) way to get the
> latest updates. (Not that I need them. I just expected the source to
> match the executable.)
Sorry, I had pointed the build script at a temporary repository and
hadn't moved it back. The downloads should be OK now.
Neil
John Yeung
not taking effect automatically. If I resave my user properties
within SciTE, the user import settings take effect right away; but
then the next time I close and reopen SciTE, the user import settings
are once again ignored.
John
Neil Hodgson
OK, it was failing to reevaluate when there were settings for both
imports.exclude and imports.include.
http://scintilla.hg.sourceforge.net/hgweb/scintilla/scite/rev/d4cf02c675bf
New downloads
John Yeung
> OK, it was failing to reevaluate when there were settings for both
> imports.exclude and imports.include.
Looks fixed. So far, so good....
John