in the interest of the heavy/light distinction,
there are quite possibly too many menu choices.
Help-
-default menus-
-beginner
-intermediate
-advanced
-publishing
-programming
it should be easy enough to switch menus in real time.
these wouldn't be much in the way of real differences.
it may be difficult to hide some items.
maybe just give them more transparency,
it shouldn't be necessary for a new user to setup their
own menus out of the box. this would be a simple way in.
is the default now full menus except for no right click
menus? this would be something a new user could easily try
without needing to go through the settings shock.
funny you should mention syntax highlighting in the same
vein as calling SciTE light. I can't imagine a heavier way
to implement syntax highlighting than that used in SciTE.
adding new languages requires a recompile. first you have
to decide if to add to one of the family of languages or
create a new one. all the languages have their own styles
and just getting all the comments the same color out of
the box can be an insurmountable problem for a new user.
shared syntax files mean conflicts can happen.
managing setttings is SciTE, looking at it objectively, is
nearly the same as in Leo! of course, it's a hard problem.
to be fair, SciTE never claims to be more than a demo
for Scintilla, so it's really not fair to pick on SciTE
for not having this or that feature. or even long standing bugs.
it seems like the devs main goal in SciTE is to say no.
much the opposite often happens with Leo.
KWrite, using the kate syntax files and completion is my new favorite
code "light" editor. does many things well. plugins, scriptable. I
have only just used it a few times in the past few
weeks though, from a live backtrack5 KDE dvd, depending
on KDE it will probably not turn out to be a truly light candidate.
we are not taking technology anyway, but the look & feel.
On Oct 10, 5:43 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> Code reuse could be called the holy grail of programming. The
> evidence suggests it will never happen, and for perfectly plausible
> reasons.
>
> Instead, we could hope for *design* reuse.
>
> Still, in the spirit of "lightening everything" it's at least amusing
> to consider the question.
>
> Let's take a concrete example as the base of speculation. Leo does a
> great job (if I do say so myself) at interfacing with
> QSyntaxHighlighter. It's tricky, as described in the Post Script.
>
> Otoh, pygments does a great job of describing, in perhaps the simplest
> way possible, how to tokenize and scan lots of modern-day languages.
>
> So here we have a typical situation: two excellent code bases, each of
> which does something related to the other. Could we merge the best
> parts of each? Yes. All it will take is blood sweat and code :-)
>
> In this case, however, we may get a bit lucky: all pygments pattern
> matchers are regex matchers, so perhaps a single, generic, restarter
> would be needed.
>
> Edward
>
> P.S. The aha behind the line-oriented jEdit colorizer is that we can
> define one or more *restarter* methods for each pattern matcher that
> could possibly match across line boundaries. I say "one or more"
> because we need a separate restarter method for all combinations of
> arguments that can be passed to the jEdit pattern matchers. In effect,
> these restarters are lambda bindings for the generic restarter
> methods.
>
> In actuality, very few restarters are needed. For example, for Python,
> we need restarters for continued strings, and both flavors of
> continued triple-quoted strings. For python, these turn out to be
> three separate lambda bindings for restart_match_span.
>
> When a jEdit pattern matcher partially succeeds, it creates the lambda
> binding for its restarter and calls setRestart to set the ending state
> of the present line to an integer representing the bound restarter.
> setRestart calls computeState to create a *string* representing the
> lambda binding of the restarter. setRestart then calls
> stateNameToStateNumber to convert that string to an integer state
> number that then gets passed to Qt's setCurrentBlockState. The string
> is useful for debugging; Qt only uses the corresponding number.
>
> EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
