[Lvlug] askSam/TWiki Clone (Project?)

[Randy Kramer]

Pat, and anyone else interested,

On Tuesday 30 August 2005 05:42 pm, Pat Regan wrote:
--<good stuff snipped>---

Rather than respond to your posts individually and point-by-point (which I 
might do later, especially if you'd like a response) I want to resummarize 
where I am and the possibilities I see.

Offpoint: Re: Using Darcs:  I understand your thoughts about an offline wiki, 
and am aiming toward a similar goal, but WikiLearn is already approaching 
2000 pages (on line--iirc, 1700 or so last time I checked), and it would not 
surprise me if I had another 2000 (or more) potential pages in my "off-line 
wiki like thing" (using nedit and multiple records in plain text files).

The alternate solutions I see and something about current status (first time 
thru in no particular order, or maybe in order of discovery--might rearrange 
later):

   * I need a name for this approach, but it's the one where I have a 
standalone nedit, standalone html rendering widget (khtml), and create a 
"standalone" TWiki to HTML filter, then let nedit send records to the filter 
which sends them to the html rendering widget for display (using, perhaps, 
stdin/stdout for the link between nedit and the filter, and "iostreams" 
between the filter and the html renderer).  STATUS: I'm sure it's workable, 
but it's rather ugly and "bulky"--if I built the project with this approach, 
one of my ToDo items would be to replace it--so I'm reluctant to head in this 
direction in the first place.

   * Create a "standalone" HTML renderer (using some widget or component, like 
the kde / kparts khtml component), integrate nedit into it (nc) as an 
external editor, built the filter into it (presumably in the same language 
that the HTML component is written it, which for khtml is C++ :-(.  STATUS: 
Would make a nice solution (not one that I'd want to replace immediately, but 
requires a lot of learning.  I am reading stuff on kparts and khtml.

      * Create a solution similar to the previous bullet, but by a shortcut 
approach--find for example, and HTML editor that edits in plain text and has 
a built in HTML renderer for previews, then hack it to suit my purposes. 
STATUS: I've looked at those currently installed on my Mandrake 10 system 
(Bluefish, Mozilla Composer, and Quanta Plus) and none seem like a good 
starting point, for any or several of the following reasons:
         * some are WYSIWYG editors--not very useful as I need the "source 
content" to remain plain text with TWiki markup
         * those that are plain text editors (was that Bluefish) preview by 
calling an external browser which is instantiated when you ask for a preview 
(and each time you ask for a preview), so too slow (to suit me)
         * can't recall if there was something else

      * Create a solution similar to the "previous" bullet, but by a 
(different) shortcut--find an editor or IDE (or maybe something else) that 
incorporates a help viewer that renders HTML), then hack it to suit.  STATUS:  
Just thought of this (again?) recently.  nedit doesn't fit the bill because 
its rendering of help is UGLY (and no idea whether it uses HTML markup) (but 
nedit is still my editor of choice)--I plan to look at kdevelop, and maybe 
all the IDEs and editors on my Mandrake 10 system.

   * Use emacs in one of its wiki modes (file-wiki (if I have the name 
correct) is very similar to what I want to do in that it stores multiple 
records (plain text with wiki markup) in a single file--don't recall (or 
haven't seen) whether it can "publish" to a local or remote wiki).  STATUS:  
A potential solution, but more for me alone (not for my dad, wife, ... for 
example, unless I can teach him emacs, or make emacs look like notepad).  It 
is intriguing though, and I am tempted to keep reading and learning it, 
emacs, and lisp (all for a variety of reasons).  Still, in the end, I think 
it will be a dead end, something I will want to replace/improve, so I should 
try to move on.

   * Others?

Overall status and plan:

I'm letting myself be pulled in too many directions at once--when I start 
reading about kparts / khtml, C++, and get bored/frustrated/fatigued, I 
switch to reading about emacs, lisp, or designing editors.  So, I need to get 
that under control.  (Maybe I just have to bite the bullet (in one sense) and 
spend a month(?) getting my head on straight.)

Another thing I might try to do is sort of create a roadmap or plan or set of 
small milestones for (currently) the second alternative (standalone (k)html 
thingie with integrated nedit and TWiki to HTML filter).  The intent would be 
to map a set of small steps all leading in the right direction but which 
would give me a sense of accomplishment as each is achieved, and would be the 
kind of thing that others could help with (i.e., have a (fairly) clear 
definition.

For example:

   * a first step might be to simply get khtml running as a standalone HTML 
renderer (some of the tutorials I've found accomplish this (iiu/rc) so not a 
big step

   * maybe add stuff to that so that it can read HTML from a file and render 
it (khtml normally expects to get its HTML from a URL or "pushed " to it 
(iiuc) via an iostream (if I have the terminology right).  Note: this might 
be a dead end task as in the end (keep reading) nedit would read from a file, 
"delineate" a record, send the single record to the filter, and the filter 
would send the HTML for rendering--still, doing this would seem to provide 
some sense of accomplishment and develop (or find) the code necessary to read 
from (and save to?) a file

   * incorporate nedit (actually nc) as an external editor--gradually have it 
open and close files, then send selected records out of it for (filtering and 
then) rendering

   * build the (modified) TWiki markup to HTML filter in the khtml thingie

   * integrate, polish, etc.  (eventually I'd want to add a lot more 
funtionality, but at this point I'd have another working version of this 
askSam/TWiki clone (I consider my off line thingie first with folding, then 
with the search by record capability as earlier working versions)

I'm intent on sticking with nedit as the editor component because of the 
folding (on arbitrary markers) and search record macros I've already 
built--if I switch to a different editor I'd have to recreate those.  (This 
even though folding in nedit is not fully satisfactory--it truly folds 
(creates long lines) instead of collapsing (hiding the folded text).)

so, this is where (I think) I am,
Randy Kramer