[ESS-bugs] Font lock bugs in R mode

[A.J. Rossini]

Please send to the ess-bugs list to keep the rest of the folks
informed as well -- I'm not our local font-lock expert, and after a
bit of hacking last week, won't have time for a few weeks.

As I said, I agreed about the warnings issue, just not the T/F issue. 
If you can send the examples, we should  look into that (the
warnings), but by "agreement" I also agree that it isn't a simple
problem.   Perhaps some form of manual intervention, i.e. noting that
a prompt is also a valid "end-of-string", would be the right thing.

Also, if you do send the patch I mentioned, then we can put it in, and
you don't have to "fix" every release!

best,
-tony

On 2/13/06, Ari Kornfeld <akorn at perspective.com> wrote:
> Tony,
>
>   Thanks for the reply.  I should have realized that there's an
> "idealism" behind such an obvious problem! Though more of a practical
> minded person myself, I am more than willing to forgive that kind of
> idealism considering how wonderfully ESS works in general (and how easy
> it is for me to fix this particular problem).
>
>   A more serious problem occurs when warning() (in R) truncates the
> function call in its output so that a mismatched paren or mismatched
> quote is printed to the console. In the latter case, font-lock colors
> get turned around -- i.e. everything is colored as if it were a string
> except for strings. In the former case, ESS/Emacs eventually barfs
> complaining of too much nesting. Let me know if you want some sample
> code for these problems. I suppose a general solution (that would
> include the extraneous "in" highlighting) is not to parse program output
> as if it were code...but that doesn't sound simple.
>
>   Speaking of R vs. S-PLUS, my original problem #2 is probably a problem
> in S-PLUS mode as well -- i.e ess-S-mode-font-lock-keywords may have to
> be repositioned inside (defvar inferior-ess-S-font-lock-keywords..)
>
>   Best regards,
> -ari
>
>
> A.J. Rossini wrote:
> > I definitely agree with the bugs you raise for #2 and on, about
> > warning messages.
> >
> > However, with respect to #1, from the R help page for "T":
> >
> >      'TRUE' and 'FALSE' are part of the R language, where 'T' and 'F'
> >      are global variables set to these. All four are 'logical(1)'
> >      vectors.
> >
> > and from a stylistic/good-programming practice, it's the language
> > features that we are trying to highlight.   I believe that T/F have
> > been proposed for deprecation quite a few times, but are kept only for
> > legacy code.  In addition, there are at least 2 people in ESS-core
> > that feel very strongly about the use of T and F.  That being said,
> > we'd probably take patches which accept a flagged version (i.e. for
> > example, conditional on a variable,
> > ess-highlight-silly-T-F-abbreviations, or similarly named).
> >
> > I'm assuming that you are referring to R, and not S or S-PLUS.
> >
> > best,
> > -tony
> >
> > On 2/12/06, Ari Kornfeld <akorn at perspective.com> wrote:
> >
> >> Hi,
> >>
> >>   There appear to a few minor bugs in ess-cust.el (ESS-5.2.12 and prior):
> >>
> >> 1. "T" and "F" should be included in ess-R-constants
> >>
> >> 2. Warning messages are not properly highlighted:
> >> Example Code:
> >>  >  f<-function() warning("Hello")
> >>  > f()
> >> Warning message:
> >>    Hello in: f()
> >>
> >>  Problem:
> >>   "Warning" is black, "message" is red (and "in" is red)
> >>
> >>  Solution (does not solve the "in" problem)
> >>   in  ess-cust.el
> >>   Part 1:
> >> ;; Ari (JAK): "Warning messages?" did not work.  Cut off the "s?"
> >> ;;  and just added both variations
> >> (defvar ess-R-message-prefixes
> >>   '("Error:" "Error in"
> >>     "Warning:" "Warning in" "Warning message"
> >>     "Warning messages"))
> >>
> >>   Part2:
> >> ;; Ari (JAK) moved location of ess-R-mode-font-lock-keywords
> >> ;;  so it doesn't override "Warning message" type of stuff
> >> ;;  in ess-R-message-prefixes
> >> (defvar inferior-ess-R-font-lock-keywords
> >>    (append
> >>    '(("^[a-zA-Z0-9 ]*[>+]" . font-lock-keyword-face)) ; "prompt" must be
> >> first
> >>
> >>    (if (not inferior-ess-font-lock-input) ;; don't font-lock input :
> >>        (list (cons "^[a-zA-Z0-9 ]*[>+]\\(.*$\\)"
> >>            '(1 font-lock-variable-name-face keep t))) )
> >>
> >>    (list
> >>     (cons "^\\*\\*\\*.*\\*\\*\\*\\s *$" 'font-lock-comment-face);
> >> ess-mode msg
> >>     (cons "\\[,?[1-9][0-9]*,?\\]"
> >> 'font-lock-reference-face);Vector/matrix labels
> >>     (cons (concat "^" (regexp-opt ess-R-message-prefixes 'enc-paren))
> >>       'font-lock-reference-face) ; inferior-ess problems or errors
> >>     (cons "#"     'font-lock-comment-face) ; comment
> >>     (cons "^[^#]*#\\(.*$\\)" '(1 font-lock-comment-face keep t)) ; comments
> >>     )
> >>    ess-R-mode-font-lock-keywords
> >>
> >>    )
> >>   "Font-lock patterns used in inferior-R-mode buffers.")
> >>
> >>
> >> Best regards,
> >> -ari
> >>
> >> _______________________________________________
> >> ESS-bugs ESS-bugs at stat.math.ethz.ch
> >> https://stat.ethz.ch/mailman/listinfo/ess-bugs
> >>
> >> _______________________________________________
> >> ESS-core list: https://stat.ethz.ch/mailman/listinfo/ess-core
> >>
> >>
> >
> >
> > --
> > best,
> > -tony
> >
> > blindglobe at gmail.com
> > Muttenz, Switzerland.
> > "Commit early,commit often, and commit in a repository from which we can easily
> > roll-back your mistakes" (AJR, 4Jan05).
> >
> >
> >
>
>


--
best,
-tony

blindglobe at gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).