[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updating xparse.el
Re: Updating xparse.el
Fri, 11 Sep 2020 15:27:49 +0200
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Arash Esbati <firstname.lastname@example.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:
> 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
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:
> 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.