Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

\footnote に verbatim を許可するか? #18

Closed
aminophen opened this issue Aug 23, 2016 · 14 comments
Closed

\footnote に verbatim を許可するか? #18

aminophen opened this issue Aug 23, 2016 · 14 comments

Comments

@aminophen
Copy link
Member

aminophen commented Aug 23, 2016

#16 の変更と jsclasses のバッティングについての議論です。

既に書いたとおりですが、#16 の変更のうち \@footnotetext に対する【脚注の合印直後の改行を許可、ただしペナルティが設定されている場合はその値を保持】という修正が、jsclasses の【脚注で \verb を使えるようにする修正】とバッティングしています。両立するためには、以下のようなコードをどこか(jsclasses または pLaTeX)に含める必要があります。

\long\def\@footnotetext{%
  \ifydir\def\@tempa{\yoko}\else\def\@tempa{\tate}\fi
  \insert\footins\bgroup\@tempa%
    \reset@font\footnotesize
    \interlinepenalty\interfootnotelinepenalty
    \splittopskip\footnotesep
    \splitmaxdepth \dp\strutbox \floatingpenalty \@MM
    \hsize\columnwidth \@parboxrestore
    \protected@edef\@currentlabel{%
       \csname p@footnote\endcsname\@thefnmark
    }%
    \color@begingroup
      \@makefntext{%
        \rule\z@\footnotesep\ignorespaces}%
      \futurelet\next\pltx@fo@t}
\def\pltx@fo@t{\ifcat\bgroup\noexpand\next \let\next\pltx@f@@t
                            \else \let\next\pltx@f@t\fi \next}
\def\pltx@f@@t{\bgroup\aftergroup\pltx@@foot\let\next}
\def\pltx@f@t#1{#1\pltx@@foot}
\def\pltx@@foot{\@finalstrut\strutbox\color@endgroup\egroup\null
    \ifnum\pltx@foot@penalty=\z@\else
      \penalty\pltx@foot@penalty
      \pltx@foot@penalty\z@
    \fi}

問題は、このコードをどちらに導入するかです。[1]「jsclasses に含める」だと

  • pLaTeX では従来どおり脚注内での verbatim をサポートしないで、合印直後の改行に関する修正だけを入れる
  • jsclasses は従来どおり脚注内での verbatim をサポートしたまま、さらに合印直後の改行に関する修正も入れる

を意味します。一方、[2]「pLaTeX に含める」だと

  • pLaTeX では新たに脚注内での verbatim をサポートし、合印直後の改行に関する修正も入れる
  • jsclasses 側のコードは \@ifl@t@r により新 pLaTeX では無視させる

ことを意味します。どちらがよいでしょうか。

個人的には jsclasses のこれ以上の肥大化を促進する [1] はあまり嬉しくないので、[2] のほうがよいのではないか、と考えています。

@aminophen
Copy link
Member Author

24時間以上発言が無いようなので、私がツイッターでとったアンケート結果(有効票6票、結果は2対4)をもとに決めます。(それでいいのだろうか? と疑問に思いますが、しょうがないでしょう。)

今回は LaTeX との互換性を重視し、「pLaTeX で脚注のなかに \verb を使えるようにする」という対処は行わないとします。pLaTeX のコードには現在の exppl2e.sty のコードが入ります。

逆に、jsclasses 側としては

  • 上に掲げた「合印直後の改行に関する修正」+「\verb サポート」の両方を含むコードを導入する
  • 現状維持

のいずれかをとることになるでしょう。後者の場合は、「せっかく pLaTeX に入れた修正が殺されてしまう」という悲しい結果になるので、おそらく前者をとることになるのでしょう。

異論がありましたら、発言お願いします。

@kuroky49
Copy link
Member

書いていただいた内容だけから判断すると,[1]「jsclasses に含める」(jsclassesのコードは大きくなっても,まともなfeature requestに対する修正はどんどん入れる)を支持します.

@kuroky49
Copy link
Member

kuroky49 commented Aug 24, 2016

で,footnoteの中で \verb が使えるようにすべきか,といわれると,使えたほうがよいが,いままで十分な代替手段が知られていたならば,他のパッケージとの衝突を避けるためにクラスファイルでは何もしない,という選択肢を取ったほうがよい気もします.

現状では,意思決定をするのに十分な人と時間を掛けられていないと思います.

@aminophen
Copy link
Member Author

返信ありがとうございます。

いままで十分な代替手段が知られていたならば

現状では「pLaTeX で jsclasses を使うと自動的に脚注に \verb が使える」ので、代替手段を探そうとした人は少ないでしょう。したがって、これは NO だと思います。

(jsclassesのコードは大きくなっても,まともなfeature requestに対する修正はどんどん入れる)

jsclasses のコードが大きくなるのを私が嫌っているのは、それが「LaTeX カーネルは△△という仕様」「pLaTeX カーネルは○○という仕様」に加え、3つ目の「jsclasses では××という仕様」を維持する必要が生じるからでした。メンテナンスの手間が倍増していますし、衝突の危険性が不必要に増大している気がします。


jsclasses の原著者の方針を前提とするならば、【少なくとも pLaTeX で jsclasses を使う場合には、永久に \verb をサポートする必要がある】が導かれるはずです。

これと、上の「別々の仕様は面倒だ」という観点を両立すると、jsclasses の独自仕様を“独自でない”ものにする、つまり【pLaTeX でも \verb を使えるようにする】になります。すなわちこれが [2]「pLaTeX に含める」の意図です。

逆に、別々の仕様であること自体も「仕様である」と定めるならば、[1]「jsclasses に含める」になります。この場合、「今後もし pLaTeX を変えるときは同時に jsclasses も変えなければならない」と覚えておかないと、致命的な問題が起きる恐れがあります。

@aminophen
Copy link
Member Author

現状では,意思決定をするのに十分な人と時間を掛けられていないと思います.

これを改善したいのですが、私自身は方法を尽くしているつもりですが効果がわかりません。時間が解決してくれるとも思えない(むしろ人が離れていきそう)なのですが…

@okumuralab
Copy link
Member

山下さまほか皆様のご努力に感謝しております。
お力になれていなくて申し訳ない限りです。jsclassesについては,今まで通り\verbが使えれば,それ以上の注文はありません。皆様の手間が最小になるような方法でやっていただければと存じます。

@aminophen
Copy link
Member Author

「今後もし pLaTeX を変えるときは同時に jsclasses も変えなければならない」と覚えておかないと

については、plcore.dtx に「jsclasses では××という仕様のため再定義されます」とでもメモしておけば忘れることはないですね。そうすると、差が生じるのはコードを二通り書く手間だけとなり、不注意で致命的な問題が起きることはないですね。これだと [1]「jsclasses に含める」もそんなにヤバくないのかもしれません。これが無難な策でしょうか。

@kuroky49
Copy link
Member

現状では「pLaTeX で jsclasses を使うと自動的に脚注に \verb が使える」ので、

自然言語を読み間違えていました.@okumuralab さんの言う通りでお願いします.

現状では,意思決定をするのに十分な人と時間を掛けられていないと思います.
これを改善したいのですが、私自身は方法を尽くしているつもりですが効果がわかりません。時間が解決してくれるとも思えない(むしろ人が離れていきそう)なのですが…

期限を切って多数決をしたらみんなが付いてくるわけではない,です.かつ,みんなが付いてくる必要もないでしょう.意思決定をする人が十分な根拠と自信を得られて,前に進めるかどうかが大事だと思います.前に進みにくいときは放っておけばよいと思います.

@kuroky49
Copy link
Member

素朴な質問もしておくと,LaTeX側に,\verbが脚注でも使えるような変更を加えてもらって,p-拡張側ですべきことを減らす,というのは難しいんですか?

@munepi
Copy link
Member

munepi commented Aug 25, 2016

山下さんのご尽力に感謝いたします。
plcore.dtx をガシガシ変えたい気持ちも十分分かりますけれども、「LaTeX との互換性を重視して、「pLaTeX で脚注のなかに \verb を使えるようにする」という対処は行わない」に +1 します。
\footnote 中に verbatim 系をほぼ使わないけれども…、先に LaTeX 側でこれが変わってくれないかなー。)

一方、jsclasses などのクラスファイルで、これを許すクラスファイルを作るのは、その作り手がよいと思えば、自由に機能拡張すればよいですね! 実際に、過去にとある製作の仕事で、本件と同様な \footnote 中に verbatim を許す改変をクラスファイルにしたことがありまして、その際にこの改変をした旨を LaTeX warning で出力するようにしていました。

@aminophen
Copy link
Member Author

aminophen commented Aug 25, 2016

「期限を切って多数決」はツイッターの投票機能のことでしょうけど、あれは投票内容自体を最初からそんなに期待したわけではないです。「どういう方法が告知に有効か」の実験の一つの表れとお考えください。なにかあれにリプライが付く or GitHub に書き込みが入ることを望んでいましたが、それは得られませんでした。

率直な気持ちとしては、私以外にもオープンな場(フォーラム or ツイッター etc)で、この GitHub についてもっと宣伝してくださる方が現れることを望んでいます。その一発の行動には時間がかからないはず。

私自身は、「特に plcore をガシガシ変えたい」という気持ちはないです。メジャーな変更を控えるという LaTeX の方針も理解していますから、それとずれないようにしたいのです。一方で、脚注の \verb については「jsclasses と pLaTeX のコードを両方書くくらいなら、もう一個にまとめればいいじゃん」という気分になってしまったので、他の方はどうだろう、という軽い気持ちで issue にしました。

@aminophen
Copy link
Member Author

aminophen commented Aug 25, 2016

確かに、どうせ変えるなら LaTeX 側に変えてもらうほうがよいというのは一理ありますね。ただ、実は fancyvrb パッケージが「\VerbatimFootnotes を発行すると脚注に \verb を使える」という機能を持っていますし、過去に ML で挙がったこともあるので、今後新たにサポートすることはないのではないかと私は思いました。


「従来どおり pLaTeX 側では \verb をサポートしない」であれば、副作用についての検討は不要になりますから、ひとまず今までに入った修正をマージして一旦リリースを目指そうと思います。今のものなら私が変更点を見渡して理解できる範囲内に収まっていますから、後回しにするより安全です。

今回は pLaTeX と jsclasses の修正が一部連動しますので、日付を決めて同時にリリースするのがわかりやすそうです。そこで、2016/09/03(土)を目標とし、texjporg/platex と texjporg/jsclasses の各 master に最新版を push しました。これで問題がなさそうなら、これを9日後にリリースする、ということでいきましょう。それまでは私もテストを継続します。

詳しい pLaTeX の変更内容は既に列挙したとおりです。

@aminophen
Copy link
Member Author

テストを開始して、ひとつ気になる点が生じました。

フォーマットを作成するときにも「起動時に platex.cfg があれば読み込む」が機能するのですが、これは platex.cfg の目的から外れていると思います。ログを見ると

 $ fmtutil --byfmt platex

fmtutil [INFO]: --- remaking platex with eptex
fmtutil: running `eptex -ini   -jobname=platex -progname=platex *platex.ini' ...
This is e-pTeX, Version 3.14159265-p3.7.1-160201-2.6 (utf8.euc) (TeX Live 2017/dev) (INITEX)
 restricted \write18 enabled.
entering extended mode
(/Users/aminophen/texmf/tex/platex/base/platex.ini
<<< making "platex with Babel" format >>>

(/Users/aminophen/texmf/tex/platex/base/platex.ltx
(/usr/local/texlive/2016dev/texmf-dist/tex/latex/base/latex.ltx

… 中略 …

**************************
*
* making pLaTeX format
*
**************************
(/Users/aminophen/texmf/tex/platex/base/plcore.ltx
(/Users/aminophen/texmf/tex/platex/base/pldefs.ltx
(/Users/aminophen/texmf/tex/platex/base/jy1mc.fd)
(/Users/aminophen/texmf/tex/platex/base/jy1gt.fd)
(/Users/aminophen/texmf/tex/platex/base/jt1mc.fd)
(/Users/aminophen/texmf/tex/platex/base/jt1gt.fd)
Loading kinsoku patterns for japanese.
(/Users/aminophen/texmf/tex/platex/base/kinsoku.tex)))
pLaTeX2e <2016/09/03> (based on LaTeX2e <2016/03/31> patch level 3)
Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
*************************
* Loading platex.cfg.
*************************
(/Users/aminophen/texmf/tex/platex/base/platex.cfg) ) )

Beginning to dump on file platex.fmt
 (preloaded format=platex 2016.8.26)

となっていますから、ダンプ直前に読み込むという挙動のようです。「フォーマット作成ジョブのときは platex.cfg を読まない」としたいので少し考えてみます。

@aminophen
Copy link
Member Author

どうやら platex.ltx のなかの

\input plcore.ltx   %% この行のあとで
\the\everyjob       %% この行が実行されると platex.cfg が読み込まれる

が原因のようなので、この \the\everyjob を外すことにします。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants