After running into a bit of a wall with certain things in XeTeX I decided to start experimenting a bit with LuaTeX. Unfortunately I ran into a problem I couldn't solve pretty much instantly.

I really need CJK support. According to some quick research, the way to do this in LuaTex is using the luatexja package. However this package throws the following rather annoying warning whenever I use it with a KOMA script document class (which I have so far been using extensively):

LaTeX Warning: Command \selectfont   has changed.
               Check if current package is valid.

The reason it is annoying is that it causes vim's latex-suite to close the file I'm working on and opening lltjfont.sty (which according to its path appears to be a patch for luatexja) for inspection.

The error is thrown on the mere inclusion of the package, regardless of whether or not I actually do something with it. For an MWE:

% luatexja-fontenc also includes fontenc for use in
% conjunction. However the warning is thrown with just
% luatexja as well, so fontenc doesn't seem to be the
% problem
Dummy text

Do you guys know a way how I can resolve the conflict (or at least silence the warning since the document does compile fine)?

Btw, I'm on TexLive2018. My \listfiles output:

scrreprt.cls    2018/03/30 v3.25 KOMA-Script document class (report)
scrkbase.sty    2018/03/30 v3.25 KOMA-Script package (KOMA-Script-dependent basi
cs and keyval usage)
 scrbase.sty    2018/03/30 v3.25 KOMA-Script package (KOMA-Script-independent ba
sics and keyval usage)
  keyval.sty    2014/10/28 v1.15 key=value parser (DPC)
scrlfile.sty    2018/03/30 v3.25 KOMA-Script package (loading files)
tocbasic.sty    2018/03/30 v3.25 KOMA-Script package (handling toc-files)
scrsize11pt.clo    2018/03/30 v3.25 KOMA-Script font size class option (11pt)
typearea.sty    2018/03/30 v3.25 KOMA-Script package (type area)
fontspec.sty    2018/07/30 vv2.6h Font selection for XeLaTeX and LuaLaTeX
  xparse.sty    2018-08-23 L3 Experimental document command parser
   expl3.sty    2018-08-23 L3 programming layer (loader) 
expl3-code.tex    2018-08-23 L3 programming layer 
l3pdfmode.def    2018-08-23 v L3 Experimental driver: PDF mode
fontspec-luatex.sty    2018/07/30 vv2.6h Font selection for XeLaTeX and LuaLaTeX

   tuenc.def    2017/04/05 v2.0i Standard LaTeX file
luatexja-fontspec.sty    2018/07/31 fontspec support of LuaTeX-ja
l3keys2e.sty    2018-08-23 LaTeX2e option processing using LaTeX3 keys
luatexja.sty    2018/08/25 Japanese Typesetting with Lua(La)TeX
luatexja-core.sty    2017/11/12 Core of LuaTeX-ja
luatexbase.sty    2015/10/04 v1.3 luatexbase interface to LuaTeX 
ctablestack.sty    2015/10/01 v1.0 Catcode table stable support
 ltxcmds.sty    2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
pdftexcmds.sty    2018/01/30 v0.27 Utility functions of pdfTeX for LuaTeX (HO)
infwarerr.sty    2016/05/16 v1.4 Providing info/warning/error messages (HO)
ifluatex.sty    2016/05/16 v1.4 Provides the ifluatex switch (HO)
   ifpdf.sty    2017/03/15 v3.2 Provides the ifpdf switch
 xkeyval.sty    2014/12/03 v2.7a package option processing (HA)
 xkeyval.tex    2014/12/03 v2.7a key=value parser (HA)
atbegshi.sty    2016/06/09 v1.18 At begin shipout hook (HO)
etoolbox.sty    2018/08/19 v2.5f e-TeX tools for LaTeX (JAW)
everyhook.sty    2014/11/26 v1.2 (SVN Rev: 12)\ Hooks for low level TeX everyX p
svn-prov.sty    2010/04/24 v3.1862 Package Date/Version from SVN Keywords
ltj-base.sty    2017/05/05
ltj-latex.sty    2018/08/24 LaTeX support of LuaTeX-ja
lltjfont.sty    2018/01/12 Patch to NFSS2 for LuaTeX-ja
   tuenc.def    2017/04/05 v2.0i Standard LaTeX file
everysel.sty    2011/10/28 v1.2 EverySelectfont Package (MS)
lltjdefs.sty    2018/06/15 Default font settings of LuaTeX-ja
lltjcore.sty    2018/06/15 Patch to LaTeX2e Kernel for LuaTeX-ja
filehook.sty    2011/10/12 v0.5d Hooks for input files
filehook-scrlfile.sty    2011/01/03 v0.1 filehook patch for scrlfile package
lltjp-geometry.sty    2018/01/19 Patch to geometry for LuaTeX-ja with vertical w
riting mode
luatexja-compat.sty    2018/03/29 Compatibility with pTeX
luatexja-fontspec-26h.sty    2018/08/02 fontspec support of LuaTeX-ja
  • 1
    Do you have any real font issues? The warning you cite is just that, a warning. Hence, could you test whether there are actually problems? – TeXnician Sep 15 '18 at 11:18
  • 1
    That's only a information not a conflict. everysel tests against the original selectfont definition, but scrartcl has added already patch. If your editor is not able to cope with such warnings, change the editor. – Ulrike Fischer Sep 15 '18 at 11:29
  • Yes, I know it’s just a warning, and I wouldn’t care much if it didn’t force-switch me to that .sty file after compilation. I tried to block the warning or at least stop it from automatically switching files, but without success. vim-latex does let you do that normally but it didn’t want to work – apparently the options for that are applied only when using the normal compilation command, not with a makefile (which I used to try out LuaTeX without having to change my global compilation rule). I’ll have a bit more of a look into it. Thanks everybody! – Abun Sep 16 '18 at 13:32

If you are using vim, you can customise its reactions in case of warnings and errors. See here -- http://vim-latex.sourceforge.net/documentation/latex-suite/compiler-output-customization.html -- for the way to adapt, but however, the whole section about compiling LaTeX seems worth reading: http://vim-latex.sourceforge.net/documentation/latex-suite/latex-compiling.html

The point is: you'll get every time you compile a bunch of warnings, so it really might be worth the time and effort to customise vim.

  • Thank you. I know it’s just a warning and I wouldn’t really care much if it didn’t open that .sty file for inspection after every compilation. I had in fact tried blocking the warning and it didn’t work. It seems that for some reasons the warning filters seem to only be applied when using the default <leader>ll compilation command but not when using a makefile (which I had done in order to test LuaTeX without having to change my global compile rule). I’ll have a bit more of a look into whether or not there is some way around that. Anyways, thanks you very much for the reminder! – Abun Sep 16 '18 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.