Ikumi Keita writes:
>> Arash Esbati writes:
>> While we're at it: I think I found some unnecessary parentheses in the
>> option management of geometry.el and graphicx.el which I removed[1].
>> Please feel free to revert the patch if I'm missing something.
>
> Oh, sorry for overlooking this!
Hi Arash,
> Arash Esbati writes:
> While we're at it: I think I found some unnecessary parentheses in the
> option management of geometry.el and graphicx.el which I removed[1].
> Please feel free to revert the patch if I'm missing something.
Oh, sorry for overlooking this! Thank you very
Ikumi Keita writes:
>> Arash Esbati writes:
>
> That's the point I'd like to know. I think that the code would usually
> suffice, too. I wonder why `LaTeX-provided-class-options' has a
> structure which allows more than one class. Under what situation can it
> have more than one entry?
> Ikumi Keita writes:
> My current proposal are attached below. Does anyone find difficulties
> with these? If none, I'll commit them in the next week.
Done.
Bye,
Ikumi Keita
___
auctex mailing list
auctex@gnu.org
Hi Mosè and all,
> Mosè Giordano writes:
> Most LaTeX classes are based on other classes (e.g., standard ones),
> you may want to keep track of the options provided to the class
> directly used and to the base one.
Thanks for explanation, perhaps you are talking about the case the user
Hi Keita,
On Tue, Nov 20, 2018 at 8:08 AM Ikumi Keita wrote:
> I wonder why `LaTeX-provided-class-options' has a
> structure which allows more than one class. Under what situation can it
> have more than one entry?
Most LaTeX classes are based on other classes (e.g., standard ones),
you may
Hi Arash,
> Arash Esbati writes:
> One thing occured to me: You use the following code (which was there
> before):
> (apply #'TeX-run-style-hooks
>(apply #'append
> (mapcar #'cdr LaTeX-provided-class-options)))
> Assuming that
Ikumi Keita writes:
>> Arash Esbati writes:
>> using `TeX-update-style-hook' would have been also my suggestion -- I
>> think it is the straightforward approach.
>
> Hmm, then should we go the way of the revised patch #1? It saves the
> value of `TeX-active-styles' by let-binding.
Hi
Hi Arash,
> Arash Esbati writes:
> using `TeX-update-style-hook' would have been also my suggestion -- I
> think it is the straightforward approach.
Hmm, then should we go the way of the revised patch #1? It saves the
value of `TeX-active-styles' by let-binding.
>> Thus I propose another
Ikumi Keita writes:
> It isn't a good idea to adhere to `TeX-run-style-hooks' after all
> because it taints `TeX-active-styles'. I abandoned it and took another
> straightforward approach in the attached patch #1, which is for the
> current git master.
Hi Keita,
using `TeX-update-style-hook'
> Ikumi Keita writes:
> How about the attached patch? It introduces a new entry :classopt in
> style hook dialect and assigns all hooks associated with class option
> into that new dialect. It let-binds `TeX-style-hook-dialect' to
> :classopt when it runs these hooks, so the package style
Hi Mosè, thanks for valuable indication!
> Mosè Giordano writes:
> I'm not sure this is correct. Inserting a package name as class
> option doesn't actually load the package. I think I removed that
> feature exactly because it could have wrongly loaded packages that
> weren't meant to be
Hi Keita,
On Tue, Oct 30, 2018 at 3:39 PM Ikumi Keita wrote:
> I.e., the class options are no longer treated as styles in the sense of
> AUCTeX.
>
> I added some codes to recover the functionality of these lines, so they
> just began to work again in the codes in the latest git repository.
I'm
Le 10/11/2018 à 22:15, jfbu a écrit :
Hi Keita,
Le 30/10/2018 à 15:38, Ikumi Keita a écrit :
Hi Jean and all,
jfbu writes:
afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It
Hi Keita,
Le 30/10/2018 à 15:38, Ikumi Keita a écrit :
Hi Jean and all,
jfbu writes:
afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It would be nice to get this done
Hi Jean and all,
> jfbu writes:
> afaict in case of say \documentclass[dvipdfmx]{article}
> the AUCTeX parsing does not set TeX-PDF-from-DVI variable
> to "Dvipdfmx". This has to be done by user.
> It would be nice to get this done automatically in case
> of document class option dvipdfm or
Hi,
afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It would be nice to get this done automatically in case
of document class option dvipdfm or dvipdfmx.
Similarly dvips global option
17 matches
Mail list logo
