SciTE user base

60 views
Skip to first unread message

romor

unread,
Jan 17, 2011, 10:15:42 AM1/17/11
to scite-i...@googlegroups.com
Well I thought on this after couple of my posts in this list and couple of years using SciTE, and the fact that I can't see SciTE in any editor review is surprising to me, but see other editors, many of them Scintilla embedded. Notpad++ as expected almost in every review.

OTOH issues like SciTE folder locks in Windows, and replies that user has to take care of such issues, learn C++, learn sources, and track down "his" problem, effects my comprehension of this editor, making me wonder in how deep delusion I am.
I guess pushing both native Linux/Windows editor has it's drawbacks, but lacking of "some" settings dialogs and relying on Lua just for everything is far from comfortable. For example I can make some Lua automation, but revisiting it after some time is not pleasant, as I'm not stacked in this.

Macro features are none. There was/is advanced and ugly extension - FilerX, which doesn't work on my systems for quite some time, and even when it worked in the past it worked questionably, though the link still exists in SciTE extension page.

Also I think that Windows user can be more attracted if there is some bridge (not external app) in first contact with this editor and its Linux style settings in .properties files.

I hope you get what's on my mind - I think that SciTE user base is more Linux than Windows based, and the reason for that is that whole project and editor workflow is more intuitive to Linux users then Windows

KHMan

unread,
Jan 17, 2011, 10:49:50 AM1/17/11
to scite-i...@googlegroups.com
On 1/17/2011 11:15 PM, romor wrote:
>[snip]

> I hope you get what's on my mind - I think that SciTE user base is more Linux than Windows based, and the reason for that is that whole project and editor workflow is more intuitive to Linux users then Windows

Not really, it's more of an editor for programmers -- users are
supposed to know what they are doing, hand-holding is minimal.
Also, it's a demo for Scintilla -- a baseline implementation.
Yeah, some features are awkward, and I'm sure they can be improved
if there are contributors.

If it did all the dialog boxes, it will duplicate a lot of those
Scintilla-based editors. Why compete with the whole gaggle of
those editors? SciTE has a separate niche. Of course, sometimes
non-programmers complain, but hey, it was not written for them...

I always have half a dozen instances open on WinXP, spread among
virtual windows with VirtuaWin. Lean and mean, perfect for my
needs. When I want more, I click the icon and it starts instantly,
and that why as a user I'm still here.

Do you really want to portray SciTE as a mainstream editor for
mainstream users? Tell all Mac users that it's great for them? No,
it's a bad match for some types of users. They'll be expecting
something like Notepad++. There is already a Notepad++, no need to
push for everything to look and work like a mainstream editor for
mainstream users.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

romor

unread,
Jan 17, 2011, 12:02:54 PM1/17/11
to KHMan
> Not really, it's more of an editor for programmers -- users are
> supposed to know what they are doing, hand-holding is minimal.
> Also, it's a demo for Scintilla -- a baseline implementation.
> Yeah, some features are awkward, and I'm sure they can be improved
> if there are contributors.

I don't think programmer can escape IDE, so I'd say scripters instead.
Some contributors can be attracted as they are attracted to this very editor

> If it did all the dialog boxes, it will duplicate a lot of those
> Scintilla-based editors. Why compete with the whole gaggle of
> those editors? SciTE has a separate niche. Of course, sometimes
> non-programmers complain, but hey, it was not written for them...

I didn't mean all that dialogs, but something more friendly conforming to SciTE "simple philosophy". It can be one window dialog setting for beginners interfacing SciTEGlobal.properties, macros, keyboard shortcuts settings, easy menu customization, easy custom lexer template, taking adventage of ever expanding Windows features...

Everything looks so fragile now as it is to me, but then I'm not a programmer, nor familiar with SciTE internals and don't think that SciTE isn't for me, instead I feel it's build with "Linux philosophy" if you excuse me

KHMan

unread,
Jan 17, 2011, 1:08:14 PM1/17/11
to scite-i...@googlegroups.com
On 1/18/2011 1:02 AM, romor wrote:
>> Not really, it's more of an editor for programmers -- users are
>> supposed to know what they are doing, hand-holding is minimal.
>> Also, it's a demo for Scintilla -- a baseline implementation.
>> Yeah, some features are awkward, and I'm sure they can be improved
>> if there are contributors.
>
> I don't think programmer can escape IDE, so I'd say scripters instead.
> Some contributors can be attracted as they are attracted to this very editor

If you want an SciTE "with extras", do check out SciTE-ru. If
that's not good enough for you, then in practice it is up to users
to implement what they want. Nobody will jump up and implement
what you wish for -- there is too little manpower around.

>> If it did all the dialog boxes, it will duplicate a lot of those
>> Scintilla-based editors. Why compete with the whole gaggle of
>> those editors? SciTE has a separate niche. Of course, sometimes
>> non-programmers complain, but hey, it was not written for them...
>
> I didn't mean all that dialogs, but something more friendly conforming to SciTE "simple philosophy". It can be one window dialog setting for beginners interfacing SciTEGlobal.properties, macros, keyboard shortcuts settings, easy menu customization, easy custom lexer template, taking adventage of ever expanding Windows features...

That's a lot of functionality. It'll be like 2,000 lines of code
for Win32 and 2,000 lines of code for GTK+, which has to be
written and then maintained forever. Both versions also need to be
kept in reasonable lockstep. If you can get someone to do all of
that for you, then lucky you :-)

All of it is already in Notepad++. No need to reinvent the wheel.

> Everything looks so fragile now as it is to me, but then I'm not a programmer, nor familiar with SciTE internals and don't think that SciTE isn't for me, instead I feel it's build with "Linux philosophy" if you excuse me

Stop the "Linux philosophy" nonsense. I repeat: it's an editor for
programmers. You set up your custom properties once and then tweak
rarely. For experienced users, it never gets in the way.

romor

unread,
Jan 17, 2011, 1:42:29 PM1/17/11
to KHMan
> If you want an SciTE "with extras", do check out SciTE-ru. If
> that's not good enough for you, then in practice it is up to users
> to implement what they want. Nobody will jump up and implement
> what you wish for -- there is too little manpower around.

I'm not asking for myself or for extras, I hope I started general discussion about SciTE user base. I don't need SciTE.ru or Notepad++ as I'm used to SciTE

> That's a lot of functionality. It'll be like 2,000 lines of code
> for Win32 and 2,000 lines of code for GTK+, which has to be
> written and then maintained forever. Both versions also need to be
> kept in reasonable lockstep. If you can get someone to do all of
> that for you, then lucky you :-)

As I said if you attract more people to your software, it's contributors will enlarge

I put what first popped on my mind without alluding that that is what SciTE needs, but just as example. Preferences dialog for never-changing global properties couldn't be that hard to make. Macros will be welcomed by anyone I guess

> All of it is already in Notepad++. No need to reinvent the wheel.

There is difference between providing minimal settings interface or feature or UI enhancement and editors with rich settings interface or extensions. You are mentioning Notepad++, but that easily can be just any other editor. So replying with get Notepad++ when someone ask for feature can be seen as neglecting the request

KHMan

unread,
Jan 17, 2011, 2:00:23 PM1/17/11
to scite-i...@googlegroups.com
On 1/18/2011 2:42 AM, romor wrote:
>> If you want an SciTE "with extras", do check out SciTE-ru. If
>> that's not good enough for you, then in practice it is up to users
>> to implement what they want. Nobody will jump up and implement
>> what you wish for -- there is too little manpower around.
>
> I'm not asking for myself or for extras, I hope I started general discussion about SciTE user base. I don't need SciTE.ru or Notepad++ as I'm used to SciTE

Fair enough, and I have pointed out the issues of manpower.
Usually, the ratio of users to contributors is very high, so don't
put your hopes too high.

> [snip]

Having said that, I will stay out of the rest of this thread --
you don't want me going on about negative things. :-)

Have fun,

romor

unread,
Jan 17, 2011, 2:07:56 PM1/17/11
to KHMan
> Usually, the ratio of users to contributors is very high, so don't
> put your hopes too high.

I didn't thought of that. It seems like SciTE specific to me :) Do you know maybe contributors ratio based on platform?

KHMan

unread,
Jan 17, 2011, 2:41:49 PM1/17/11
to scite-i...@googlegroups.com

Most small open source projects are pretty resource-constrained. I
think making Scintilla better is the main focus. So some other
things tend to be lower priority. SciTE does not have a corporate
presence like say PHP or Ruby on Rails, hence, the way things are
done are different. Also, doing dialog boxes properly will require
Win32 code and GTK+ code and that's going to thin out contributors
even more.

Of course, it's not wrong to be discussing features, but it's good
to be cognizant of the limitations of projects such as SciTE in
catering to users.

Perhaps I can try to explain further why many of us think property
files are fine: See, there can be per-user and per-directory
overrides for property files -- it's an excellent abstraction for
managing different styling needs for different projects (you just
copy or change one file). So for programmers, it fits our needs
perfectly (and we are used to editing textual configuration files)
and consequently, there is little urge to spend hours adding
thousands more lines of code to get dialog boxes for that. So,
each point of view does have merit, except each view is fine for
different demographics.

romor

unread,
Jan 17, 2011, 3:13:37 PM1/17/11
to KHMan
Thanks for your replies

I'd contribute with my spare time to SciTE if I had C skills, but I know my limits, and choose Python as my main helper, then some other scripting languages in occasions.
Property files are fine, but I guess what I was thinking about was some centralized easily accessible dialog that can magically take care of main property file and lua scripts and tied-up SciTE :)
I'm not pushing this over, as I got your reply, but trying to distill my thought

Cheers

Neil Hodgson

unread,
Jan 17, 2011, 6:05:53 PM1/17/11
to scite-i...@googlegroups.com
KHMan:

> Perhaps I can try to explain further why many of us think property files are
> fine: See, there can be per-user and per-directory overrides for property
> files -- it's an excellent abstraction for managing different styling needs

> for different projects ...

Properties files can also customize settings for different sets of
file patterns so that, for example, .aspx files can be treated as
mostly the same as .html but with specific differences when needed.
These techniques for controlling behaviour are difficult to achieve
with a GUI. A set of dialogs that treated all these settings as simple
globals would be limiting.

SciTE has limited goals: I want it to be very useful for that group
of users for which it is suited. It is not going to chase after market
share to the detriment of that usefulness.

It would be easier to work on SciTE if it was mostly written in Lua
or Python but rewriting it would be much effort that I'm not
interested in performing.

Neil

Philippe Lhoste

unread,
Jan 18, 2011, 9:05:41 AM1/18/11
to scite-i...@googlegroups.com
On 17/01/2011 18:02, romor wrote:
> I don't think programmer can escape IDE, so I'd say scripters instead.
> Some contributors can be attracted as they are attracted to this very editor

Yes and no. At work, we have a large Java application to maintain, so we use Eclipse.
But I still fire SciTE for a quick fix, or if I need column editing, etc.
And for the casual Java coding I do at home (mostly with Processing), where most of the
debugging is done with println(), SciTE is still perfect for me.
The fact I can use it to edit also AutoHotkey, Lua, PHP, XML, HTML, CSS, JavaScript,
Scala, VB, POV-Ray, Nimrod, properties, makefile, batch files, and some more
(occasionally) like Python, Perl, shell, etc., all this without having to install a
plugin, and without waiting several minutes for the startup to complete, are quite
compelling reasons for continuing to use SciTE.

Now, of course, I often recommend it... with a disclaimer that setting it up isn't for the
faint of heart! ;-) But it isn't that hard, really.

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

Andy Sy

unread,
Jan 19, 2011, 11:20:07 PM1/19/11
to scite-i...@googlegroups.com
romor wrote:

> Also I think that Windows user can be more attracted if there is
> some bridge (not external app) in first contact with this editor
> and its Linux style settings in .properties files.
>
> I hope you get what's on my mind - I think that SciTE user base is
> more Linux than Windows based, and the reason for that is that whole project
> and editor workflow is more intuitive to Linux users then Windows

We use SciTE under Windows to develop PHP and Python web apps. It's
perfect for this. SciTE is awesome in that it syntax highlights
PHP, Javascript and HTML separately even if on the same file.

Plus how can you beat its folding?

You don't really need an IDE. Just have reference
files invokable via shortcut keys, and jump back and forth between
browser and SciTE screens.

Using X-mouse style focus on follow makes such a setup far more
convenient than any IDE for my tastes.

Rather than scripting SciTE directly, for certain customized
uses, I just use the command.input.*, command.replace.selection.*
functionality to pipe a selection out to python and then have
python process that and replace it with something else.

Quite easy and nothing new to learn!


================================
http://www.webmechs.com/webpress
The Webmechs Webpress blog

Reply all
Reply to author
Forward
0 new messages