FYI ... http://www.povray.org/download/features/wishlist.php

-- Chris

Post a reply to this message

Keen! :)

Post a reply to this message

"Chris Cason" <new### [at] deletethispovrayorg> wrote:
> FYI ... http://www.povray.org/download/features/wishlist.php

I see that most of the current content of the wishlist is oriented toward
the editor. Perhaps because you are the maintener of this piece of code :-)

I don't know how much you are want to keep the CodeMax component. I
understand you did a lot of work on it to fit it to POV-Ray, and I suppose
it would not be a small task to replace it by another component.

But I also saw in the comments that you may do a major rewrite of the
Windows code...

So, you may want to take a look at the Scintilla <http://www.scintilla.org>
code source editor component.
It is cross-platform (Windows and GTK+), powerful yet still light (with all
lexers, the DLL weights less than 230KB). It has a very liberal licence,
similar to the Python or BSD one.

It mimics most of the Visual Studio features, including most of the keyboard
shortcuts.
It features syntax highlighting, of course, but also error indicators (like
the MS Word spell checking marks), code completion and call tips. It has a
primitive regular expression support, but can be easily replaced by a more
powerful one.

I will soon write a lexer for the POV-Ray syntax, supporting nested
comments. Due to constraints to the lexing method, the nesting level will be
limited. I feel that 3 levels is enough for most needs (commenting out a
zone with comments, and commenting out again this zone) but if you think it
needs more, I can go up to, say, 8 levels.

Multi-File search and replace is out of the scope of the source code editor
component. However, I started to write one (without regex support, but
fast), I can resume work on it if needed (lot of projects, little time :-)

Note: I am not the author of Scintilla, but I regularly contribute to this
project, and the related SciTE text editor.

If time allows, I would like to try and replace CodeMax by Scintilla in the
3.5 code, but I am not sure if this code is here to persist or if it would
be a waste of time to hack it...

Regards.

-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

"Philippe Lhoste" <Phi### [at] GMXnet> wrote in message news:3d50d7e2$1@news.povray.org...
> But I also saw in the comments that you may do a major rewrite of the
> Windows code...

Yes, but it's unlikely that I will replace CodeMax, unless I find something
better. And even if I do, that's years away.

> I will soon write a lexer for the POV-Ray syntax, supporting nested
> comments. Due to constraints to the lexing method, the nesting level will be
> limited. I feel that 3 levels is enough for most needs (commenting out a
> zone with comments, and commenting out again this zone) but if you think it
> needs more, I can go up to, say, 8 levels.

how about letting the user define the level (or at least at compile-time) ?

> If time allows, I would like to try and replace CodeMax by Scintilla in the
> 3.5 code, but I am not sure if this code is here to persist or if it would
> be a waste of time to hack it...

Feel free, you're welcome to try, the current code will be around for quite
some time yet.

regards,

-- Chris

Post a reply to this message

> > I will soon write a lexer for the POV-Ray syntax, supporting nested
> > comments. Due to constraints to the lexing method, the nesting level
will be
> > limited. I feel that 3 levels is enough for most needs (commenting out a
> > zone with comments, and commenting out again this zone) but if you think
it
> > needs more, I can go up to, say, 8 levels.
>
> how about letting the user define the level (or at least at compile-time)
?

Why limit it at all ? All you need is to add 1 each time you reach a /*,
subtract 1 each time you reach a */, and when it's 0, you're no longer in
comments. I can't see why you need a limit...

Post a reply to this message

In povray.general Chris TRIBBECK <chris@--7tharm--.com> wrote:
> Why limit it at all ?

  Why, indeed. I see no reason for limiting it. (After all, there are
other opening-closing pairs of syntax items which are unlimited, such
as parentheses.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3d695553@news.povray.org:

> In povray.general Chris TRIBBECK <chris@--7tharm--.com> wrote:
>> Why limit it at all ?
> 
>   Why, indeed. I see no reason for limiting it. (After all, there are
> other opening-closing pairs of syntax items which are unlimited, such
> as parentheses.)

Because of the current way Scintilla lexers work.

They do an incremental lexing of the document, avoiding to parse the whole 
source on each typed character.
So if you type a char inside a multi-line comment, the lexer will start to 
parse from the current line. It doesn't try to backtrack the beginning of 
the comment up to the beginning of the document.
So it needs to know the current level of nesting at the start of the line, 
so it can correctly decrement this level when meeting */s (and increment 
it of course, with /*s).

In other lexers, it has been worked around by allocating lexer states to 
each level of nesting. By looking at the lexing state of the beginning of 
the line, it knows the nesting level. It is quite ugly, as it eats states 
which is a limited resource. But it is a necessary evil. And in 99% cases, 
outside testing purposes, using a limited number of nesting is enough.

Now, I recently saw there can be information stored per line, that may be 
used for this purpose. I will see.

Note: parenthesis are parsed independently as single operators, we don't 
track the amount of opening and closing, and don't try to change the state 
according to the nesting level, although it can be done, I suppose. 
However, there is a shortcut key allowing to jump from a parenthesis to 
the matching one, and non-matching parenthesis are highlighted when the 
caret go over them. But it is a different beast, independent of lexers.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

Chris Cason wrote:

> FYI ... http://www.povray.org/download/features/wishlist.php
> 
> -- Chris

My wishes....
Support for Subdivision Surfaces (Mesh2)
Support quad or higher poly surfaces (Mesh2).
Both of these would conciderably aid in export from other programs.... (In 
my case wings)

Post a reply to this message

Danni Coy <rgc### [at] midcoastcomau> wrote in message
news:3d8fb3f1@news.povray.org...
> Chris Cason wrote:
>
> > FYI ... http://www.povray.org/download/features/wishlist.php
> >
> > -- Chris
>
> My wishes....
> Support for Subdivision Surfaces (Mesh2)

This has already been done with SDL by John VanSickle.
http://enphilistor.users4.50megs.com/sss.htm
I think that this is better than the "one click" subdivision used by Wings
and other programs because the SDL is tweakable. The limitations of
pre-programmed algorithms are the reason that many prefer to model in
Pov-Ray instead of using gui mouse modelers.

With that in mind, I would like to see more data structures introduced into
Pov SDL to allow more readable and straightforward coding of these types of
algorithms.

> Support quad or higher poly surfaces (Mesh2).
> Both of these would conciderably aid in export from other programs.... (In
> my case wings)

I've only messed with Wings a little bit, but I think I remember that the
program will triangulate any model. Really though, since Pov-Ray does not
directly read output like raw or 3DS files anyway, I think that just adding
triangulation to the converters would be best.

 -Shay

Post a reply to this message