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

Post a reply to this message

I'm glad I not the only one who has that problem. It would be very helpful.

Mick


news:3991D974.912623FE@club-internet.fr...
> 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
>

Post a reply to this message

> 
> 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-].

Post a reply to this message

> >
> > 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