Steve D. Perkins wrote:

I recently discovered Scintilla in the search for a nice C/C++-based text widget, and have found myself going from using SciTE as a build test to using it as a complete replacement for UltraEdit in all my editing needs. This truly is the best open-source text editor in the market, and I love the design philosophy of making it feature-rich while not allowing the core project to "evolve" (or "sprawl") into a bloated full-blown IDE.

It is good that you like the non-bloatedness, because... (see below)

There is only one shortcoming with SciTE that I don't understand. With most text editors, or applications in general for that matter, changes to your settings persist from one execution to the next. If you turn on line-numbering, or switch to monospaced font, the editor will start out in that state the next time you use it. With SciTE, I have been playing around with the "SciTE.properties" file... but it's a little clunky, and there are some setting options that I haven't yet figured out how to control through properties. It seems like it wouldn't be a big deal to have SciTE save its current state to the properties file upon shutdown, or upon a setting being changed, or upon some manual "Save my settings" menu option, etc. Has such functionality already been discussed in the past and rejected on some grounds? If not, I would like to suggest it as a feature request. If so, I would really like to hear the reasoning and urge its reconsideration.

As you have already surmised, this comes up every once in a while... :) The author has remained firm on the "not turning into an IDE" topic, which includes things like GUI option manipulation and saving.

Practical issues include the multi-platform nature of Scintilla/SciTE - creating and maintaining all of the requisite dialogs is difficult enough for *one* platform, but having the problem be essentially open-ended makes it downright ugly. :)

In reality, things aren't too bad: a useful model is to make "global" changes only in your "user" properties file (editing the official "global" properties file makes it harder to apply updates), and use the "local" (per-directory) properties files as makefile adjuncts - or even makefile replacements for simple projects. Note that the properties file "precedence" rules work out the way you want here.

Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest

Reply via email to