[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Help With Getting Source Code (bunzip2,
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-09-20 22:21:49
Message-ID: 200509201521.49743.sequitur () easystreet ! com
[Download RAW message or body]

On Tuesday 20 September 2005 11:46 am, Randy Kramer wrote:
> On Tuesday 20 September 2005 01:50 pm, Andras Mantia wrote:
> > On Tuesday 20 September 2005 19:20, Randy Kramer wrote:
> > >    * I want to edit a plain text file with TWiki markup, filter that
> > > to HTML, and then (internally) preview that as rendered HTML.
> > >
> > > So, without knowing C or C++ (but having made some attempt to learn
> > > them at least twice), I'd like to dig into Quanta's source code and
> > > see if I can make any progress toward my goal.
>
> Thanks for the reply!
>
> > Is there a tool to render twiki markup to HTML?
>
> Yes, the obvious one being TWiki (a wiki) itself.
>
> > Can a webserver do it?
>
> Yes, in the form of TWiki (which is written in Perl).

The most logical solution we've found for preprocessing is the project preview 
and in almost all cases it's not too difficult to set up a local test server 
so there is not the time delay of internet requests. This solution does nt 
require maintenance or development, just installing packages.
>
> > If yes, you can use the same approach as we do with PHP preview: use a
> > preview prefix and view the files through a web server.
>
> That, iiuc, would be your external preview.  Based on my experience so far,
> that would not be nearly fast enough to suit my needs / desires.

Locally it should or your site would be a dog. ;-)
>
> One of the problems is it seems (unless I'm missing something or version
> 3.2.0 is that far behind the leading edge), each time an update (a new
> piece of HTML) is sent to a browser for the external preview, a new
> instance of the browser is initiated, thus I have to wait for the startup
> of the browser.
>
> There are some other factors that I haven't raised so far, some of which
> might be relevant to your suggestion:
>
>    * I want (in most cases) the rendering to be driven by the text
> editor--I want to issue a command in the text editor to have a new piece of
> TWiki markup rendered, I don't want to go to the browser and pull (request)
> a new piece.

Not only will instant update be available in Quanta 4 but we should also have 
XSLT visual development on the fly. So this would be a matter of working out 
an interface if you wanted something custom.
>
>    * I don't think this is directly relevant, but another thing I didn't
> mention is that the TWiki marked up text file contains multiple records
> (separated by a(n arbitrary, i.e., changable) record separator, currently
> "\n---++ ").  Almost always, I will send only one record of TWiki text for
> rendering at a time.  Further, I don't want to send that text to a file
> (either disk based or RAM based) as an intermediate step--either one will
> slow things down unacceptably.

If there are particulars here we're not seeing it's also possible to manage 
the entire editor content with scripts and for instance parse and/or take a 
parsed element from the current cursor position and send it to a temp file to 
load into a preprocessing template, similar to sending a database record. As 
Andras said, look at kdcop. Quanta has extensive abilities here for managing 
customizations without ever having to write a line of C++. That was our 
design goal.
>
> Describing my speed goal (with my tongue deeply in cheek), if I have one of
> these files with say 2000 records and 2 MB (characters), in nedit (the
> editor I currently use for the purpose) I can scroll through all 2000
> records in about a second.  (How fast can you move the elevator bar on an
> application like nedit ;-)  I'd like to get as close as possible to that
> kind of speed in the next generation of my project.

I'm not sure comparative speed, but you might want to develop a DTEP for it, 
which is XML based tag description with regexp to define tag areas. This will 
also give you auto complete.
>
> (I'm somewhat stuck on nedit at the moment as I've built some functionality
> into it using its macro capability.  Not sure I can do the same with
> kate/kwrite--I'll probably be looking, at least in the first Quanta based
> iteration, on using nedit instead of kate/kwrite.  Don't know how difficult
> that might be.)

Quanta has the following facilities.
1) User defined Actions which can use any installed scripting language that 
runs in the shell and can be activated by keystroke or toolbar button. These 
Actions can also manage any conceivable input/output/debug scenario with the 
current file in the editor.
2) Project Event Actions which apply to project, file, transfer and revision 
actions enabling scripts you have in the script manager to function. These 
can also pass parameters.
3) The entire interface is scriptable with DCOP providing access to key 
project information an actions as well as everything happening in the editor 
and interface. If it's on a menu or toolbar or is an interaction between 
parts it's there.

In addition to this there are code abbreviations, extensive template support 
and document packages that enable you to manage auto completion and 
structural validation. I suspect you will have a hard time finding anything 
other than emacs that is close.

Eric
>
> Anyway:
>
>    * thanks for the opportunity to expound a little bit more about the
> project ;-)
>
>    * why do you ask--is the internal preview feature going away?
>
> regards,
> Randy Kramer
>
>
>
> _______________________________________________
> quanta-devel mailing list
> quanta-devel@kde.org
> https://mail.kde.org/mailman/listinfo/quanta-devel
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel

[prev in list] [next in list] [prev in thread] [next in thread]