Re: Updating xparse.el

[Florent Rougon]

Hi Arash,

Arash Esbati <arash@gnu.org> wrote:

> I'm not sure about the name.  In this setup, every unknown macro \foo
> gets fontified with `font-latex-sedate-face' like in your example here:
>
>     https://imgur.com/a/7ADVb5e
>
> I find your suggestion somewhat misleading.

Sorry, you are right. My little problem with the name you chose is that
when `font-latex-fontify-replacement-text' is set to nil, the
replacement text of \NewDocumentCommand and friends *still* gets
fontified (and in the nicest way according to my taste), thus I like the
behavior but find the name a bit unintuitive. However, the alternate
name I proposed is indeed not good, because when the variable is
non-nil, the replacement text of \NewDocumentCommand and friends is not
fontified in a single color as I believed: it is just fontified in a
different way that I find hard to read. To be clear for other readers,
here are two screenshots: <https://imgur.com/a/IyY8Ox9>.

- The first is with stock AUCTeX (I did 'emacs -q' followed by
  (add-to-list 'load-path "~/the/path"), (require 'tex-site) and
  M-x LaTeX-mode in the appropriate buffer). There is a lot of
  font-lock-function-name-face, which I find uncomfortable for the eyes.

- The second screenshot is with my custom config. Arash's patch
  implements this for \NewDocumentCommand and friends from xparse when
  the variable `font-latex-fontify-replacement-text' is set to nil.
  Ideally, I think this should be extended to other commands such as
  \newcommand, \DeclareRobustCommand, \NewEnviron from the environ
  package, etc. (cf. my previous mail where I listed those which I treat
  this way).

So, well, I don't really have a better suggestion for the name,
actually. Or maybe `font-latex-fontify-replacement-text-as-argument', if
people like it.

>> - My custom config does similar changes to a few basic LaTeX2e commands:
>>
>>     \newenvironment
>>     \renewenvironment
>>
>>     (...)
>>
>>     \mbox
>>     \sbox
>>
>>   (...)
>
> I'm easy with adding them to the new setup.  My plan is to allow the
> variable to be set as a file-local variables (as you may have seen in
> the patch).  This should give users better control between normal
> documents and package writing.

As long as the “desired behavior” (according to my taste, i.e.
second screenshot above) is easy to achieve, this is fine with me.
Thanks!

Regards

-- 
Florent