[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] context match regexp, fontlock, verbatim

From: Carlos
Subject: [AUCTeX-devel] context match regexp, fontlock, verbatim
Date: Fri, 30 Oct 2015 02:07:00 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

context match regexp


Mosé, Tassilo, Ivan, Arash, Uwe, Marcin, David, Angeli, Artemio, and to
you, yes, to you, just like Quijote said hehe, whose name I can't
remember (de cuyo nombre no puedo acordarme), to the list in general (my
apologies if I'm forgetting someone):

highlighting is pure convenience and not the norm or the standard. A
year from now someone who knows someone who knows someone decides to
append arguments to an \input sequence and there you have it. whatever
i'll think or say next, will be pointless. the only reason that the
above sequence, is the standard for now, lest the same reason that lies
behind guillemot. It's so widespread that it would break havoc to change it.

texnically speaking, you are aware of it, 'brackets' are 'braces' in
context's grouping argumentative parlance, and tex does not understand
one space from another, but boxes. think inside and become an
expert.. think too much and one might forget the mode in which one is
located. so the next sentences that follow are just a reminder. 

 in context, the name of a font is not the filename of the font. and the spaces 
do not matter either, (this is still in effect, although is hard to say if 
it'll stay like that though). so both, liberationmono, and liberation mono, are 
the same. and i believe the same applies in latex. but it would be wrong to say 
that one can't specify e.g., liberation mono (with whitespace) because it's not 
the filename.

Make sure texmfcnf.lua finds its way or you would have problems with filenames 
and such. type businesses are like sausages. but lua is not turing, so beware 
of the finished sausage. Asegúrate que ese fichero se encuentre, asegúrate de 

so the above regexp would work with a space after the equal sign. the problem 
with the last sentence is that one would not want to apply syntax highlighting 
to say, the file that follows the \input. of course that a defined sequence 
such as \input ought to have it, but not the filename. so it's unlikely to have 
both '\input' and its 'filename' highlighted. 

same goes for say tables' delimiters. (whether these are defined now as \NC \NR 
\LR ). and also xtables, with their own sequences. 

it's not texnically sound to say for example:

\startcolumns[ n = 3 ]

although you could,

but it is sound, to say [n=3]

or for example

\usemodule[Liberation Mono]
\usemodule[Minion Pro]

the problem with the last example matching regexp is that it would highlight the
character after the delimiter equal sign too. 

if someone can come up wih a better idea than the following 

(defvar context-font-mode
  (font-lock-add-keywords 'context-mode '("\\\\[\\\\[a-z0-9=A-Z]*]*")))

(set (make-local-variable 'font-lock-defaults)
     '(context-font-mode nil t))

will be appreciated. 

it's not texnically sound either to call a table natural, but since it
has an organic association in today's fast environment, it's the new fad
in context. one can't help but try to construct a natural table rather
than just a table. with the latter the interpersonal relationship to
have a table is out the door, and the remote thought of making a table too. :)

in another note, if you load another theme in laTeX, with a light
background under the verbatim environment, and then switch to a dark
background theme, font lock for the former, takes over for the duration
of said environment. Is this the standard? for example, if you were to
switch from oneof the default themes such as leuven to deeper-blue, and
one would have the leuven default fontification in the verbatim
environment. Was this a feature request? I'm sincerely asking because of
preferences. what one might find indispensable, someone else might
not... it was tested in two old hardware (i don't like gadgetry nor
computers)  with the current git version of emacs. I'm not going to
bother you by sending a screenshot of the problem, because of the
uselessness of a screenshot to diagnose what the problem is.

Also, is '\input{filename}' and its fontification the standard? in
context there is no need to specify las llaves, so one can get away with
\input filenamehere.
unless the literature is wrong, and the authors also got it wrong, why
can't I say '\input "filename" without breaking fontification of the
backlash? so in order to have fontlock, one is forced to have braces
with the aforementioned example? 

Have a good one guys. Bye bye.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]