> >
> > Is there a way in the window editor to highlight matching <>{}() : When
> > your cursor is close to one opening brace {, the editor make the
> > matching closing brace blink or highlight or whatever. ( as found in
> > many editors in Windows or Unix)
> >
> > When using a texture or a function with countless (){}, it is easy to be
> > lost when POV tells you that they do not match.
> >
> > Cheers
> >
> > Fabien
>
> You can use Search/Match Brace (or Ctrl-] as shortcut). This is not as
> good as highlighting, for it moves cursor to matching brace, but it
> helps sometimes.

>
> Only problem here is that this shortcut does not work with national
> keyboard, as for getting ] character AltGr has to be pressed and instead
> of matching I get ] when pressing Ctrl-AltGr-].

Yes, I noticed that too.

Fabien

Post a reply to this message

If you use proper indentation it shouldn't be hard to see matching brackets.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I recall that Borland C++ used to momentarily bold the matching braces as
you typed allowing you to see the blocks of code you were editing. That
would be a nice feature for the Windows or Mac editor. ( do any of the other
platforms have integrated editors?)
I usually use good indentation practices, but sometimes I like to put one
short but complex expression on a single line and then the order of the
braces and parentheses can be confusing.
One other thing bothers me about the editor in Windows. Tabs don't seen co
come out as tabs. If you tab once, you have to backspace several times to
get back to where you were.
HH

Post a reply to this message

Well, I do use indentation a lot, but when you get material { texture { ... down
to a color_map mixed with other normal_map, there's bound to be an error.

Fabien



>   If you use proper indentation it shouldn't be hard to see matching brackets.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Halbert wrote:

> I recall that Borland C++ used to momentarily bold the matching braces as
> you typed allowing you to see the blocks of code you were editing.

Exel also does this when you are editing a formula.

> That would be a nice feature for the Windows or Mac editor. ( do any of the
> other
> platforms have integrated editors?)

I think Mark was contemplating a Linux one

> I usually use good indentation practices, but sometimes I like to put one
> short but complex expression on a single line and then the order of the
> braces and parentheses can be confusing.

very true, me to

> One other thing bothers me about the editor in Windows. Tabs don't seen co
> come out as tabs. If you tab once, you have to backspace several times to
> get back to where you were.

This is because you have set the option to convert tabs to spaces when typing.
Click on an editor tab, choose "Editor/Codemax properties" from the menu, click
on the "Language/Tabs" tab & uncheck the "Convert tabs to spaces while typing"
checkbox.



> Is there a way in the window editor to highlight matching <>{}() : When
> your cursor is close to one opening brace {, the editor make the
> matching closing brace blink or highlight or whatever. ( as found in
> many editors in Windows or Unix)

You would have to ask the POV-Team to make this change to their (donated) custom
version of the Codemax dll & include this in WinPOV 3.5 - I am under the
impression that the codemax's original author donated the src with this control
- is this true ?? If not you could suggest this to the author.

Also - Some WinPOV 3.5 feature requests.
- is there any chance that when the "Keep single instance" option is on and the
user opens a new instance of WinPOV with /EDIT on its command line that the file
will be opened in the already running instance. In 3.1g the running instance is
just brought to the foreground.
- when the "Keep single instance" option is on could new instances with /RENDER
or +i on their command line put these files in the render queue of the currently
running instance. In 3.1g /RENDER does the same as /EDIT & +i causes the
specified file to be rendered if the running instance is not already rendering

--
Bye
Pabs

Post a reply to this message

: Well, I do use indentation a lot, but when you get material { texture { ... down
: to a color_map mixed with other normal_map, there's bound to be an error.

  Again: A proper indentation should help.

material
{
    texture
    {
        pigment
        {
            onion color_map
            {
                [0 rgb 0]
                [1 rgbf 1]
            }
            turbulence .5
        }
        finish
        {
            specular .5 roughness .05
        }
    }

    interior
    {
        ior 1.5
    }
}

  At least I can distinguish quite well matching parentheses there.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Well throw in a few directives like #if #switch #while and the rest, along
with more of the possible keywords, and you might start losing sight of
those neatly ordered braces  :-)

Bob

Post a reply to this message

Bob Hughes <per### [at] aolcom?subject=pov-news:> wrote:
: Well throw in a few directives like #if #switch #while and the rest, along
: with more of the possible keywords, and you might start losing sight of
: those neatly ordered braces  :-)

  Those can be indented as well.
  Right, there are no braces with #-commands, but still I haven't had any
problem with them

union
{
    #declare IndX = 0;
    #while(IndX < 100)
        #declare IndY = 0;
        #while(IndY < 100)

            sphere { <IndX, IndY, 0>, .1 }

            #declare IndY = IndY+.1;
        #end
        #declare IndX = IndX+.1;
    #end

    pigment { rgb x }
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I try to keep scripts as clean and tidy as yours, but what I meant is that it would be
a nice add-on for the coming version of POV. ( win or other)
But I just don't have a clue if it will require a lot of work or not.





> : Well, I do use indentation a lot, but when you get material { texture { ... down
> : to a color_map mixed with other normal_map, there's bound to be an error.
>
>   Again: A proper indentation should help.
>
> material
> {
>     texture
>     {
>         pigment
>         {
>             onion color_map
>             {
>                 [0 rgb 0]
>                 [1 rgbf 1]
>             }
>             turbulence .5
>         }
>         finish
>         {
>             specular .5 roughness .05
>         }
>     }
>
>     interior
>     {
>         ior 1.5
>     }
> }
>
>   At least I can distinguish quite well matching parentheses there.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thanks for the tip regarding the tabs. Amazing how much the "little things"
make a difference.
HH

Post a reply to this message