On Tuesday 14 April 2009 06:32:13 am Roger Preston wrote:
> I am keen to work for/with a Linux development group, though am not
> sure where to start.
>
> I would describe myself as a competent C++ programmer, though perhaps
> not quite at your levels yet.
Roger,
I'm sure this is not the answer you're looking for, but, what the heck,
I'll try it on for size.
(Irrelevant aside: I am not much of a C or C++ programmer. I used to
do "amateur"/educational programming in a variety of other languages
(Algol, Fortran, Pascal, PL/1, ..., Visual Basic, and some embedded
scripting languages, like that for dBase (3, 3+, and 4), Paradox,
Visual Basic for Word, Excel, Access; nedit, maybe others.)
Anyway, I've been cobbling together a mashup of sorts to be sort of an
askSam replacement on Linux.
The next step I plan in its evolution is to adopt Scite as its new
editor (replacing Kate and nedit, neither of which had all the
functionality I require) (even Scite might not, and might require that
I continue to use nedit for its recordable keyboard macros (which are
easily converted to scripts).
Anyway, Scite can do real folding, which nedit cannot do (there are
some "faux" folding solutions which are not very satisfactory) and Kate
can do unsatisfactorily as there are too many bugs.
From what I understand about Scite's folding, it would be very
satisfactory. (Another limitation of Scite, not particularly relevant
to folding, is that it treats each line as a separate entity, thus
regex searches don't work across line boundaries--I do need this
capability in nedit and Kate for different reasons (in Kate it does
relate to how they do folding, and lack of such capability forces me to
put terminating markup to end every fold, and multiple markups to end
nested folds), but I'm pretty sure that wouldn't be an issue in Scite.
Another thing I didn't mention is that my mashup uses some strange
markup--well, actually it is TWiki markup with some variations. Below
I'll a few items of markup.
To get Scite to fold (and highlight) my markup, it needs a lexer file
that is typically written in C++. (There is apparently an alternate
way to do it by writing a program (not sure they'd call it a lexer) in
their embedded language, Lua (which is apparently something that
originated in Brazil).
There are lexer files written in C++ for a lot of other languages, and
there is a folding file (iirc, written in Lua) for a wiki like language
(sort of the original wiki markup, iirc).
What I'd like to do is to try to interest you in writing a lexer file
for my markup, I think preferably in C++ because I'm assuming it would
run faster. I don't even need a complete one, if you give me a
reasonable start that I could build from (once I learn how to compile
Scite and Scintilla and their lexer files).
I think Scite and Scintilla are good open source projects (I can't
recall the license at the moment, I think they are more BSD / Mit style
licenses rather than GPL, but the primary developer of Scintilla /
Scite (Neil Hodgson) is doing an excellent job, and his aim (successful
so far as I can tell) is to create a cross platform editing widget and
simple editor (he aims on keeping Scite simple, but that's not to say
others won't build on that, in fact, the Scintilla editing widget is
being used by a lot of other projects, including other editors.
His approach to the cross platform approach is writing it in C++ and
then keeping the code compatible so it can be compiled under (at least)
Windows and Linux. (I don't know offhand if he has a version for the
Mac or any other systems at this point.) BTW, in Linux, Scintilla uses
GTK (on Windows it uses, iiuc, native Windows stuff).
So, here's some TWiki markup. Oh, one thing to start--my file format is
a multi-record format, essentially the mbox format, somewhat
simplified, although it is read successfully by the email clients I've
tried it on, including kmail. It uses a three line header as the
record separator, and this might be the toughest thing to deal with due
to Scintilla's lack of regex search across line ends, but I don't
really think it will be--I think finding the first of the three lines
is sufficient to detect a record header, at which point a flag could be
set to help recognize the following two lines. Here is a typical
record separator, first an example, then a "generic" representation:
From "The "Plan"" Thu Mar 26 01:46:21 2009
Date: 03/26/09 01:46 pm
Subject: The "Plan"
(On Kate, I need to terminate a record and use "morF" as the terminating
markup--on Scintilla, this should not be necessary, a record is
terminated by the next record marker or eof.)
More generically:
From "<record title>" <record date in mbox "format">
Date: <in my preferred format>
Subject: <record title>
The duplication of the record title and date are partially historical
and partially for compatibility with many email clients that handle
mbox files--I can't really get away from that at this point in
time--that *might* be a future step in the evolution.
Headings are marked up as follows:
----+ Level 1 Heading (regex like \n-{3}\+ .+\n (or ^-{3}\+.+$))
----++ Level 2 Heading (regex like \n-{3}\+{2} .+\n (or ^-{3}\+{2}.+$))
...
----++++++ Level 6 Heading (or ^-{3}\+{2}.+$)
The primary fold points are at the record level and at the six heading
levels.
The regexes are included primarily for information, as I don't think
they'd be the thing to use in a lexer written in C++ (even though a
regex library should be available--but I could be wrong (about not
using a regex)).
There is inline markup for things like *bold*, _underline_, -hashout_,
and /italic/ text.
There are numbered and bulleted lists, and these can be at multiple
levels (each deeper level indicated by an additional three spaces of
indent). I'd also like to fold at list items, but that can be an
enhancement (and I need to think about the approach I want to
follow--Scintilla (it is Scintilla by the way that does the lexing--my
understanding is that if a lexer is created for Scintilla, Scite and
any other editor or tool using Scintilla can use that lexer for
highlighting and folding with a minimum of effort--maybe just enabling
that as a language choice).
* first level bullet list item
3 first level numbered list item (item number 3)
* 2nd level bullet list item
7 2nd level numbered list item (item number 7)
...
A link is marked up as follows: [[<url>][<label>]], e.g.,
[[http://twiki.org/cgi-bin/view/Wikilearn][WikiLearn]]
Almost all of that markup gets highlighted in various ways as well--the
inline markup is obvious, headings get various degrees of boldness, and
color to mark them, the link and record separators are the most
complicated markup as they get a combination of markup which, at least
for a link, can vary
Hightlighting for a link:
* the square brackets are always shown in a sort of barely visible
gray--you can seem them, but they are not obtrusive
* if a link has both a URL and a label, the URL is shown in a barely
visible yellow, and the label is shown in the typical blue that many
links on web pages are shown
* if a link as a URL but no label, the URL is shown in that typical
blue
Highlighting for a record separator:
* the From is shown in bold black
* the first instance (next to the From) of the record title is shown
in black (may change in the future to something more "obvious")
* everything else, on the remainder of that line and the next two
lines is shown in barely visible yellow.
BTW, the reason for showing some of this stuff in barely visible yellow
or gray is at least partially so that, in editing, I don't accidentally
delete something important (i.e., part of the markup), as I might do if
it were invisible.
Anyway, that gives a reasonable overview of what I'd like to do. If
you're interested in helping, I can point you to links to learn more
about Scintilla and Scite.
I now have to concentrate on my taxes for the next day or so, so I
probably won't respond until Thursday if you have any questions
(although I could probably send you a few links).
If you aren't interested at all, I'll say thank you for inspiring me to
write this email, it gives me (another, perhaps summarized) list of
what I plan to accomplish.
regards,
Randy Kramer
--
I didn't have time to write a short letter, so I created a video
instead.--with apologies to Cicero, et.al.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
