Re: [AUCTeX] How to configure TeX special characters?

[David Kastrup]

Marcin Borkowski <address@hidden> writes:

> On 2017-05-01, at 15:46, David Kastrup <address@hidden> wrote:
>
>> Marcin Borkowski <address@hidden> writes:
>>
>>> Hi all,
>>>
>>> a friend of mine has this problem: he does not want $, & and % to have
>>> special meaning to (La)TeX, so he changes their catcodes to make them
>>> un-special; to retain the possibility of inputting math, typesetting
>>> tables and commenting out things, he assigns the respective catcodes to
>>> some Unicode\setminus ASCII characters.
>>>
>>> Putting aside the question whether it's a good idea (personally I don't
>>> like it very much, but I can see the rationale), how do I convince
>>> AUCTeX to take that into consideration when font-locking?  I tried to
>>> monkey-patch AUCTeX sources (for instance, I tried changing
>>> "\\$\\$\\([^$]+\\)\\$\\$" in font-latex-make-user-keywords into
>>> something like "〖\\([^$]+\\)〗", then even restarting Emacs
>>> altogether), but to no avail.
>>
>> That would be a serious upstream battle.  Language-specific editing
>> support relies on assumptions.  That is one reason that LaTeX has
>> several editors catering to it pretty well while plain TeX (which does
>> not really provide much in the line of document structuring) doesn't.
>>
>> I don't think that AUCTeX caters all that well for more serious breaches
>> of convention.
>
> Thanks for your prompt reply!
>
> I am not sure about my personal stand on it.  On the one hand, it's
> always saddening to find a piece in Emacs (or the "Emacs ecosystem")
> which is not easily configurable.  OTOH, as I mentioned in the OP,
> I agree that my friend's idea goes quite against established LaTeX
> conventions.  OYAH, AFAIK ConTeXt already treats dollars etc. as normal
> characters, so it's quite possible that AUCTeX will have to cater for
> that particular thing anyway.

I am pretty sure I remember that comment character is configurable in
some parts of AUCTeX, but I am also pretty sure that it's unlikely to be
implemented consistently and reliably because it's just too uncommon.

-- 
David Kastrup