[ESS-bugs] ess-mode 12.09 [rev. 5167 (2012-09-24)]; highlighting logical variables
Stefano Conti
s.conti at gmx.co.uk
Tue Oct 2 10:55:25 CEST 2012
Good morning Vitalie,
Following up on yesterday night's e-mails, I can confirm that font locking seems to be _partially_ operational on the GNU Emacs 22.1.1 + ESS 12.09 installed on my machine at work: see attached screenshot.
Moreover, answers to your questions are individually addressed in the attached .txt files.
Thank you for your continued help, all the best,
--
Stefano
> ----- Original Message -----
> From: Vitalie Spinu
> Sent: 10/01/12 05:30 PM
> To: Stefano Conti
> Subject: Re: [ESS-bugs] ess-mode 12.09 [rev. 5167 (2012-09-24)]; highlighting logical variables
>
> >> "Stefano Conti" <s.conti at gmx.co.uk>
> >> on Mon, 01 Oct 2012 17:34:04 +0200 wrote:
>
> SC> Sorry, your 2nd question slipped through the craks. Meanwhile I've been playing
> SC> a little myself with the ESS --> Font-Lock sub-menu: switching neither
> SC> "ess-fl-keyword:constants" nor "ess-R-fl-keyword:F&T" switches appears have any
> SC> influence.
>
> This should not be. Does switching of other keywords has any effect
> on the highlighting in your buffer? Are you sure you are loading the
> correct ESS and not some old version of it?
>
> So let's try to figure out what is going on. Please paste here the
> values of the following variables from your ESS buffer (C-h v):
>
> font-lock-keywords
> font-lock-defaults
> ess-font-lock-keywords
> ess-font-lock-defaults
>
> SC> From your comment I also see that you don't seem to have the same
> SC> issue...
>
> Yes, you are the first to have a font-lock problems in 12.09.
>
> Vitalie
>
> >> ----- Original Message -----
> >> From: Vitalie Spinu
> >> Sent: 10/01/12 04:17 PM
> >> To: Stefano Conti
> >> Subject: Re: [ESS-bugs] ess-mode 12.09 [rev. 5167 (2012-09-24)]; highlighting logical variables
> >>
> >> >> "Stefano Conti" <s.conti at gmx.co.uk>
> >> >> on Mon, 01 Oct 2012 17:03:33 +0200 wrote:
> >>
> >> > There are text properties here:
> >> > fontified t
> >> > == END ==
> >>
> >> This is not good. How about my other question? Can you set/unset
> >> ess-fl-keyword:constants from ESS/Font-Lock sub-menu and see if it makes
> >> any difference? How about other keywords, does setting/insetting them
> >> lead to change in fortification?
> >>
> >> It's very strange that you have problems with TRUE/FALSE but no any
> >> other keywords.
> >>
> >> Vitalie
> >>
> >>
> >> > The only font setting command I have in my .emacs file is
> >>
> >> > (setq font-lock-maximum-decoration t)
> >>
> >> > which shouldn't interfere with the font locking issue I've notice; that is unless I'm mistaken.
> >>
> >> > Hope the above helps; thank you again, cheers,
> >>
> >> > --
> >> > Stefano
> >>
> >> >> ----- Original Message -----
> >> >> From: Vitalie Spinu
> >> >> Sent: 10/01/12 03:51 PM
> >> >> To: Stefano Conti
> >> >> Subject: Re: [ESS-bugs] ess-mode 12.09 [rev. 5167 (2012-09-24)]; highlighting logical variables
> >> >>
> >> >> >> "Stefano Conti" <s.conti at gmx.co.uk>
> >> >> >> on Mon, 01 Oct 2012 16:25:34 +0200 wrote:
> >> >>
> >> >> [...]
> >> >>
> >> >> SC> I have just realised that the latest ESS also offers a flaky
> >> >> SC> handling of syntax highlighting.
> >> >>
> >> >> What do you mean by "flaky"? Is there any other problem except
> >> >> TRUE/FALSE which you have reported?
> >> >>
> >> >> SC> Specifically, logical statements (TRUE / FALSE) seem to no longer
> >> >> SC> be highlighted in green (at least on both my work and home
> >> >> SC> systems) font.
> >> >>
> >> >> It is not highlighted in green, but is it highlighted at all? Place the
> >> >> point on TRUE and do "C-u C-x =". Do you see:
> >> >>
> >> >> There are text properties here:
> >> >> face font-lock-type-face
> >> >> fontified t
> >> >> ?
> >> >>
> >> >> If not look in ESS/Font-Lock menu and see if constants are selected.
> >> >>
> >> >> Also check your .emacs if you interfere with font-lock yourself. If so,
> >> >> remove that. ESS font-lock internals have been changed.
> >> >>
> >> >> Vitalie
-------------- next part --------------
ess-font-lock-defaults is a variable defined in `ess-custom.el'.
Its value is shown below.
Documentation:
Internal. Holds dialect sepcific font-lock defaults in the
current buffer. Old system. From ESS[12.09] switched to new
system described in `ess-font-lock-keywords'.
Value:
(("\\<\\(attach\\|detach\\|library\\|\\(?:requir\\|sourc\\)e\\)\\>" . font-lock-constant-face)
("\\(\\(?2:\\s\"\\).+\\2\\|\\sw+\\)\\s-*\\(<-\\)[ \n]*function" 1 font-lock-function-name-face t)
("\\<\\(break\\|else\\|f\\(?:or\\|unction\\)\\|i[fn]\\|message\\|next\\|re\\(?:peat\\|turn\\)\\|s\\(?:top\\|witch\\)\\|w\\(?:arning\\|hile\\)\\)\\>" . font-lock-keyword-face)
("->\\|<\\(?:<?-\\)" . font-lock-constant-face)
("\\<\\(FALSE\\|Inf\\|N\\(?:A\\(?:_\\(?:\\(?:c\\(?:haracter\\|omplex\\)\\|integer\\|real\\)_\\)\\)?\\|ULL\\|aN\\)\\|TRUE\\)\\>" . font-lock-type-face))
Local in buffer Work/HPA/R/PW/Clamydia/code_clam.r; global value is nil
Automatically becomes buffer-local when set in any fashion.
-------------- next part --------------
ess-font-lock-keywords is a variable defined in `ess-custom.el'.
Its value is
ess-R-font-lock-keywords
Local in buffer Work/HPA/R/PW/Clamydia/code_clam.r; global value is nil
Automatically becomes buffer-local when set in any fashion.
Documentation:
Internal. Holds a name of the dialect sepcific font-lock
keywords in the current buffer. See `ess-R-font-lock-keywords'
for an example.
-------------- next part --------------
font-lock-defaults is a variable defined in `font-core.el'.
Its value is shown below.
Documentation:
Defaults for Font Lock mode specified by the major mode.
Defaults should be of the form:
(KEYWORDS [KEYWORDS-ONLY [CASE-FOLD [SYNTAX-ALIST [SYNTAX-BEGIN ...]]]])
KEYWORDS may be a symbol (a variable or function whose value is the keywords to
use for fontification) or a list of symbols. If KEYWORDS-ONLY is non-nil,
syntactic fontification (strings and comments) is not performed.
If CASE-FOLD is non-nil, the case of the keywords is ignored when fontifying.
If SYNTAX-ALIST is non-nil, it should be a list of cons pairs of the form
(CHAR-OR-STRING . STRING) used to set the local Font Lock syntax table, for
keyword and syntactic fontification (see `modify-syntax-entry').
If SYNTAX-BEGIN is non-nil, it should be a function with no args used to move
backwards outside any enclosing syntactic block, for syntactic fontification.
Typical values are `beginning-of-line' (i.e., the start of the line is known to
be outside a syntactic block), or `beginning-of-defun' for programming modes or
`backward-paragraph' for textual modes (i.e., the mode-dependent function is
known to move outside a syntactic block). If nil, the beginning of the buffer
is used as a position outside of a syntactic block, in the worst case.
These item elements are used by Font Lock mode to set the variables
`font-lock-keywords', `font-lock-keywords-only',
`font-lock-keywords-case-fold-search', `font-lock-syntax-table' and
`font-lock-beginning-of-syntax-function', respectively.
Further item elements are alists of the form (VARIABLE . VALUE) and are in no
particular order. Each VARIABLE is made buffer-local before set to VALUE.
Currently, appropriate variables include `font-lock-mark-block-function'.
If this is non-nil, it should be a function with no args used to mark any
enclosing block of text, for fontification via M-o M-o.
Typical values are `mark-defun' for programming modes or `mark-paragraph' for
textual modes (i.e., the mode-dependent function is known to put point and mark
around a text block relevant to that mode).
Other variables include that for syntactic keyword fontification,
`font-lock-syntactic-keywords' and those for buffer-specialized fontification
functions, `font-lock-fontify-buffer-function',
`font-lock-unfontify-buffer-function', `font-lock-fontify-region-function',
`font-lock-unfontify-region-function', and `font-lock-inhibit-thing-lock'.
Value:
((("\\<\\(attach\\|detach\\|library\\|\\(?:requir\\|sourc\\)e\\)\\>" . font-lock-constant-face)
("\\(\\(?2:\\s\"\\).+\\2\\|\\sw+\\)\\s-*\\(<-\\)[ \n]*function" 1 font-lock-function-name-face t)
("\\<\\(break\\|else\\|f\\(?:or\\|unction\\)\\|i[fn]\\|message\\|next\\|re\\(?:peat\\|turn\\)\\|s\\(?:top\\|witch\\)\\|w\\(?:arning\\|hile\\)\\)\\>" . font-lock-keyword-face)
("->\\|<\\(?:<?-\\)" . font-lock-constant-face)
("\\<\\(FALSE\\|Inf\\|N\\(?:A\\(?:_\\(?:\\(?:c\\(?:haracter\\|omplex\\)\\|integer\\|real\\)_\\)\\)?\\|ULL\\|aN\\)\\|TRUE\\)\\>" . font-lock-type-face))
nil nil
((46 . "w")
(95 . "w")))
Local in buffer Work/HPA/R/PW/Clamydia/code_clam.r; global value is nil
Automatically becomes buffer-local when set in any fashion.
-------------- next part --------------
font-lock-keywords is a variable defined in `font-lock.el'.
Its value is shown below.
Documentation:
A list of the keywords to highlight.
There are two kinds of values: user-level, and compiled.
A user-level keywords list is what a major mode or the user would
set up. Normally the list would come from `font-lock-defaults'.
through selection of a fontification level and evaluation of any
contained expressions. You can also alter it by calling
`font-lock-add-keywords' or `font-lock-remove-keywords' with MODE = nil.
Each element in a user-level keywords list should have one of these forms:
MATCHER
(MATCHER . SUBEXP)
(MATCHER . FACENAME)
(MATCHER . HIGHLIGHT)
(MATCHER HIGHLIGHT ...)
(eval . FORM)
where MATCHER can be either the regexp to search for, or the function name to
call to make the search (called with one argument, the limit of the search;
it should return non-nil, move point, and set `match-data' appropriately iff
it succeeds; like `re-search-forward' would).
MATCHER regexps can be generated via the function `regexp-opt'.
FORM is an expression, whose value should be a keyword element, evaluated when
the keyword is (first) used in a buffer. This feature can be used to provide a
keyword that can only be generated when Font Lock mode is actually turned on.
HIGHLIGHT should be either MATCH-HIGHLIGHT or MATCH-ANCHORED.
For highlighting single items, for example each instance of the word "foo",
typically only MATCH-HIGHLIGHT is required.
However, if an item or (typically) items are to be highlighted following the
instance of another item (the anchor), for example each instance of the
word "bar" following the word "anchor" then MATCH-ANCHORED may be required.
MATCH-HIGHLIGHT should be of the form:
(SUBEXP FACENAME [OVERRIDE [LAXMATCH]])
SUBEXP is the number of the subexpression of MATCHER to be highlighted.
FACENAME is an expression whose value is the face name to use.
Instead of a face, FACENAME can evaluate to a property list
of the form (face FACE PROP1 VAL1 PROP2 VAL2 ...)
in which case all the listed text-properties will be set rather than
just FACE. In such a case, you will most likely want to put those
properties in `font-lock-extra-managed-props' or to override
`font-lock-unfontify-region-function'.
OVERRIDE and LAXMATCH are flags. If OVERRIDE is t, existing fontification can
be overwritten. If `keep', only parts not already fontified are highlighted.
If `prepend' or `append', existing fontification is merged with the new, in
which the new or existing fontification, respectively, takes precedence.
If LAXMATCH is non-nil, that means don't signal an error if there is
no match for SUBEXP in MATCHER.
For example, an element of the form highlights (if not already highlighted):
"\\<foo\\>" discrete occurrences of "foo" in the value of the
variable `font-lock-keyword-face'.
("fu\\(bar\\)" . 1) substring "bar" within all occurrences of "fubar" in
the value of `font-lock-keyword-face'.
("fubar" . fubar-face) Occurrences of "fubar" in the value of `fubar-face'.
("foo\\|bar" 0 foo-bar-face t)
occurrences of either "foo" or "bar" in the value
of `foo-bar-face', even if already highlighted.
(fubar-match 1 fubar-face)
the first subexpression within all occurrences of
whatever the function `fubar-match' finds and matches
in the value of `fubar-face'.
MATCH-ANCHORED should be of the form:
(MATCHER PRE-MATCH-FORM POST-MATCH-FORM MATCH-HIGHLIGHT ...)
where MATCHER is a regexp to search for or the function name to call to make
the search, as for MATCH-HIGHLIGHT above, but with one exception; see below.
PRE-MATCH-FORM and POST-MATCH-FORM are evaluated before the first, and after
the last, instance MATCH-ANCHORED's MATCHER is used. Therefore they can be
used to initialize before, and cleanup after, MATCHER is used. Typically,
PRE-MATCH-FORM is used to move to some position relative to the original
MATCHER, before starting with MATCH-ANCHORED's MATCHER. POST-MATCH-FORM might
be used to move back, before resuming with MATCH-ANCHORED's parent's MATCHER.
For example, an element of the form highlights (if not already highlighted):
("\\<anchor\\>" (0 anchor-face) ("\\<item\\>" nil nil (0 item-face)))
discrete occurrences of "anchor" in the value of `anchor-face', and subsequent
discrete occurrences of "item" (on the same line) in the value of `item-face'.
(Here PRE-MATCH-FORM and POST-MATCH-FORM are nil. Therefore "item" is
initially searched for starting from the end of the match of "anchor", and
searching for subsequent instances of "anchor" resumes from where searching
for "item" concluded.)
The above-mentioned exception is as follows. The limit of the MATCHER search
defaults to the end of the line after PRE-MATCH-FORM is evaluated.
However, if PRE-MATCH-FORM returns a position greater than the position after
PRE-MATCH-FORM is evaluated, that position is used as the limit of the search.
It is generally a bad idea to return a position greater than the end of the
line, i.e., cause the MATCHER search to span lines.
These regular expressions can match text which spans lines, although
it is better to avoid it if possible since updating them while editing
text is slower, and it is not guaranteed to be always correct when using
support modes like jit-lock or lazy-lock.
This variable is set by major modes via the variable `font-lock-defaults'.
Be careful when composing regexps for this list; a poorly written pattern can
dramatically slow things down!
A compiled keywords list starts with t. It is produced internal
by `font-lock-compile-keywords' from a user-level keywords list.
Its second element is the user-level keywords list that was
compiled. The remaining elements have the same form as
user-level keywords, but normally their values have been
optimized.
Value:
(t
(("^##' *\\([@\\]\\(S3method\\|TODO\\|a\\(?:liases\\|uthor\\)\\|concept\\|docType\\|ex\\(?:amples\\|port\\(?:Class\\|Method\\|Pattern\\)\\)\\|format\\|i\\(?:mport\\(?:\\(?:\\(?:Classe\\|Method\\)s\\)?From\\)?\\|nclude\\)\\|keywords\\|method\\|n\\(?:\\(?:am\\|ot\\)e\\)\\|param\\|r\\(?:dname\\|e\\(?:ferences\\|turn\\)\\)\\|s\\(?:eealso\\|lot\\|ource\\)\\|title\\|us\\(?:age\\|eDynLib\\)\\)\\)\\>"
(1 'font-lock-keyword-face prepend))
("^##' *\\([@\\]\\(\\(?:importFro\\|para\\)m\\)\\)\\>\\(?:[ ]+\\(\\sw+\\)\\)?"
(1 'font-lock-keyword-face prepend)
(3 'font-lock-variable-name-face prepend))
("[@\\]\\(export\\|nord\\)\\>"
(0 'font-lock-variable-name-face prepend))
("^##'"
(0 'bold prepend))
("\\<\\(attach\\|detach\\|library\\|\\(?:requir\\|sourc\\)e\\)\\>" . font-lock-constant-face)
("\\(\\(?2:\\s\"\\).+\\2\\|\\sw+\\)\\s-*\\(<-\\)[ \n]*function" 1 font-lock-function-name-face t)
("\\<\\(break\\|else\\|f\\(?:or\\|unction\\)\\|i[fn]\\|message\\|next\\|re\\(?:peat\\|turn\\)\\|s\\(?:top\\|witch\\)\\|w\\(?:arning\\|hile\\)\\)\\>" . font-lock-keyword-face)
("->\\|<\\(?:<?-\\)" . font-lock-constant-face)
("\\<\\(FALSE\\|Inf\\|N\\(?:A\\(?:_\\(?:\\(?:c\\(?:haracter\\|omplex\\)\\|integer\\|real\\)_\\)\\)?\\|ULL\\|aN\\)\\|TRUE\\)\\>" . font-lock-type-face))
("^##' *\\([@\\]\\(S3method\\|TODO\\|a\\(?:liases\\|uthor\\)\\|concept\\|docType\\|ex\\(?:amples\\|port\\(?:Class\\|Method\\|Pattern\\)\\)\\|format\\|i\\(?:mport\\(?:\\(?:\\(?:Classe\\|Method\\)s\\)?From\\)?\\|nclude\\)\\|keywords\\|method\\|n\\(?:\\(?:am\\|ot\\)e\\)\\|param\\|r\\(?:dname\\|e\\(?:ferences\\|turn\\)\\)\\|s\\(?:eealso\\|lot\\|ource\\)\\|title\\|us\\(?:age\\|eDynLib\\)\\)\\)\\>"
(1 'font-lock-keyword-face prepend))
("^##' *\\([@\\]\\(\\(?:importFro\\|para\\)m\\)\\)\\>\\(?:[ ]+\\(\\sw+\\)\\)?"
(1 'font-lock-keyword-face prepend)
(3 'font-lock-variable-name-face prepend))
("[@\\]\\(export\\|nord\\)\\>"
(0 'font-lock-variable-name-face prepend))
("^##'"
(0 'bold prepend))
("\\<\\(attach\\|detach\\|library\\|\\(?:requir\\|sourc\\)e\\)\\>"
(0 font-lock-constant-face))
("\\(\\(?2:\\s\"\\).+\\2\\|\\sw+\\)\\s-*\\(<-\\)[ \n]*function"
(1 font-lock-function-name-face t))
("\\<\\(break\\|else\\|f\\(?:or\\|unction\\)\\|i[fn]\\|message\\|next\\|re\\(?:peat\\|turn\\)\\|s\\(?:top\\|witch\\)\\|w\\(?:arning\\|hile\\)\\)\\>"
(0 font-lock-keyword-face))
("->\\|<\\(?:<?-\\)"
(0 font-lock-constant-face))
("\\<\\(FALSE\\|Inf\\|N\\(?:A\\(?:_\\(?:\\(?:c\\(?:haracter\\|omplex\\)\\|integer\\|real\\)_\\)\\)?\\|ULL\\|aN\\)\\|TRUE\\)\\>"
(0 font-lock-type-face)))
Local in buffer Work/HPA/R/PW/Clamydia/code_clam.r; global value is nil
More information about the ESS-bugs
mailing list