Minor GUI bug: misbehavior of the parenthesis matching helper if char. constants with "(" or ")"

[marQIsoft]

Hi,

One of the many features I love in Tinn-R is the visual helper which indicates which opening parenthesis the closing parenthesis at current cursor location corresponds to. It's quite difficult to write in words here, but here is a simple example you can test to see the bug for yourself. If you copy-paste the following line of R code in Tinn-R Editor...:

x = c("I love Tinn-R (and R")

...then if you place the text cursor around the closing parenthesis (at line end), the helper associates it with the opening parenthesis inside the text constant ".....".

    In my Editor, it looks like this then:

  x = c("I love Tinn-R (and R")

Obviously, it's a mistake that can be confusing for more complex codes, as the "(" which effectively acts as the opening parenthesis is not the the emphasized one, but the one just after "c".

Another example with more parentheses in it:

y = c("I'm a bit confused here ((( :(")))))  #too many parentheses here, because I followed the helper's "advice"

y = c("I'm a bit confused here ((( :(")      #corrected code so that it works, though the visual matching of parentheses by the helper is not right

This second example shows how confusing that can be when many text parentheses are present. As a consequence of this "bug", the user is tempted to put 4 ")" too many.

In short, could you improve the behavior of this helper so that it ignores the parentheses (as well as square brackets, and braces: [], {}) that are within character constants, when helping the user to locate the effective parenthesis associations?

Thanks a lot!

Nice day to you.

Marc (alias marQIsoft)

[Jose Claudio Faria]

Hello Marc,

First, sorry for the dealy and thank you for indicating problems in Tinn-R project.

You are correct in all the examples.

I think it will not be simple, but, we will see whether it will be possible to consider such cases.

The new pre-release version have good news and it is stable: http://nbcgib.uesc.br/lec/software/editores/tinn-r/en#h10-download

Pre-release (2016/07/01): Tinn-R_04.02.04.00_setup.exe

Best,

///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica
UESC/DCET/Brasil
joseclaudio.faria at gmail.com
Telefones:
55(73)3680.5545 - UESC
55(73)99966.9100 - VIVO
55(73)99100.7351 - TIM
55(73)98817.6159 - OI

55(73)98129.9942 - CLARO
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\

--
You received this message because you are subscribed to the Google Groups "Tinn-R Editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tinn-r+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Laurencelle]

Hi Jose,

Today, I have some time to check if the many issues we discussed are now resolved in the most recent pre-release version of Tinn-R (.17).

I've checked that problem of parentheses matching for assisting the user when trying to close the parentheses he's opened. I think it's still unresolved.

Consider this other very simple example:

badmatch <- c("hi", "(there)))))")

goodmatch <- c("hi", "(there)")

In the badmatch example, if you place the cursor at the last parenthesis, it won't find its corresponding open parenthesis, because the tool did not ignore the parentheses that were in the character constant (around the word "there"). If you place the cursor at the leftmost parenthesis, it finds one correspondence, but it's not the good one, since it's located in the "text".

In the goodmatch, all works great because parentheses open and close in the excepted order, even in the "text".

As you're very good with regular expressions, I think there should be a way, quite straightforward and efficient, to ignore substrings bounded by some arbitrary symbol such as these famous quotes (" "). Ok, there may be a few complicated special cases when, for example, there are quotation mark chars (\") in the "text"... but in general, I think that a general regular expression would do the job... or maybe that does not work with reg. expressions?

So... I've written you this update for that issue, just to mention it's still there. But you may class it a low-priority issue, as it does not prevent the user from running the codes, it just brings a bit of confusion when dealing with many levels of parentheses, for example when calling functions in function calls...

Thanks.

Marc

To unsubscribe from this group and stop receiving emails from it, send an email to tinn-r+unsubscribe@googlegroups.com.