Latex3: कक्षा संदेश "पैकेज" संदेश होने का दावा करते हैं

यह है, लेकिन आपको अपनी फ़ाइल के प्रकार को \g_msg_module_type_prop जोड़कर स्पष्ट रूप से बताना होगा:

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

और वैकल्पिक रूप से इसका नाम \g_msg_module_name_prop :

\prop_gput:Nnn \g_msg_module_name_prop { myclass } { My~Nice~Class }

तो आपको एक चेतावनी मिलती है जैसे:

Class My Nice Class Warning: Bar

हो सकता है कि l3msg यदि \ProvidesExpl<Thing> का उपयोग किया गया हो तो इस प्रकार को स्वतः भर सकता है...

मेगावाट:

\begin{filecontents*}[overwrite]{myclass.cls}
\ProvidesExplClass
  {myclass}
  {2021/04/26}
  {0.1}
  {
    My Nice Class
  }
\NeedsTeXFormat{LaTeX2e}
\LoadClass { article }
%
\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }
\prop_gput:Nnn \g_msg_module_name_prop { myclass } { My~Nice~Class }
\msg_new:nnn {myclass} {Foo} {Bar}
\msg_warning:nn {myclass} {Foo}
\end{filecontents*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{myclass}
\begin{document}
\end{document}

हो सकता है कि l3msg यदि \ProvidesExpl<Thing> का उपयोग किया गया हो तो इस प्रकार को स्वतः भर सकता है...

अच्छा होगा! :मुस्कुराओ:

\ProvidesExpl... और कोड के लिए प्रयुक्त मॉड्यूल उपसर्ग के बीच कोई विशेष संबंध नहीं है: मुझे लगता है कि यह केवल कुछ ऐसा है जिसे मैन्युअल रूप से करना है।

इससे पहले कि पूरी 'वास्तव में कक्षाओं को expl3 वाक्यविन्यास का उपयोग नहीं करना चाहिए' - यह एक ऐसा विचार था जो काफी काम नहीं करता था। (कक्षाओं को अभी भी बहुत अधिक काम करने की ज़रूरत है, लेकिन प्रोग्रामिंग नहीं करनी चाहिए, जो पैकेज में है।)

\ProvidesExpl... और कोड के लिए प्रयुक्त मॉड्यूल उपसर्ग के बीच कोई विशेष संबंध नहीं है: मुझे लगता है कि यह केवल कुछ ऐसा है जिसे मैन्युअल रूप से करना है।

मैं नहीं देखता क्यों।

इससे पहले कि पूरी 'वास्तव में कक्षाओं को expl3 वाक्यविन्यास का उपयोग नहीं करना चाहिए' - यह एक ऐसा विचार था जो काफी काम नहीं करता था। (कक्षाओं को अभी भी बहुत अधिक काम करने की ज़रूरत है, लेकिन प्रोग्रामिंग नहीं करनी चाहिए, जो पैकेज में है।)

मुझे समझ में नहीं आता कि ऐसा क्या विचार है जो काफी काम नहीं करता है।

\ProvidesExpl... और कोड के लिए प्रयुक्त मॉड्यूल उपसर्ग के बीच कोई विशेष संबंध नहीं है: मुझे लगता है कि यह केवल कुछ ऐसा है जिसे मैन्युअल रूप से करना है।

मैं नहीं देखता क्यों।

\ProvidesExplClass में वर्ग का नाम कोड द्वारा उपयोग किए गए उपसर्ग से मेल नहीं खाता है। या कोड का उपयोग पैकेज और वर्ग दोनों द्वारा किया जा सकता है (मैं इसे LaTeX2e शब्दों में achemso में करता हूं), इसलिए लिंक स्पष्ट नहीं होगा।

इससे पहले कि पूरी 'वास्तव में कक्षाओं को expl3 वाक्यविन्यास का उपयोग नहीं करना चाहिए' - यह एक ऐसा विचार था जो काफी काम नहीं करता था। (कक्षाओं को अभी भी बहुत अधिक काम करने की ज़रूरत है, लेकिन प्रोग्रामिंग नहीं करनी चाहिए, जो पैकेज में है।)

मुझे समझ में नहीं आता कि ऐसा क्या विचार है जो काफी काम नहीं करता है।

कक्षाएं वास्तव में स्वरूपण/शैली/आदि के बारे में होनी चाहिए, कार्यक्षमता नहीं। उत्तरार्द्ध को संकुल द्वारा जोड़ा जाना चाहिए, जो आदर्श रूप से उन वर्गों से स्वतंत्र होगा जिनका वे उपयोग करते हैं। वर्तमान स्थिति आदर्श नहीं है, और शुरुआत में \ProvidesExpl... सेट को LaTeX2e कर्नेल से केवल \Provides... को मिरर करने के लिए प्रदान किया गया था। लेकिन अंत में यह गलत दृष्टिकोण है: _packages_ को expl3 कोड का उपयोग करना चाहिए, _classes_ को दस्तावेज़- या डिज़ाइन-स्तरीय इंटरफ़ेस का उपयोग करना चाहिए जिसे _might_ expl3 में लागू किया जाना चाहिए।

कक्षाएं वास्तव में स्वरूपण/शैली/आदि के बारे में होनी चाहिए, कार्यक्षमता नहीं।

जिस वर्ग पर मैं वर्तमान में काम कर रहा हूं उसे दस्तावेज़ के पहले पृष्ठ पर एक ग्राफिक सम्मिलित करना चाहिए ... यदि यह ग्राफिक पाया जाता है और अन्यथा एक चेतावनी प्रदर्शित करनी चाहिए (लॉग फ़ाइल में चेतावनी के अतिरिक्त)। क्या यह डिजाइन या कार्यक्षमता है?

मैं के प्रलेखन ले जाकर हाथ में इस मुद्दे को ठीक करने के बाद \g_msg_module_name_prop और \g_msg_module_type_prop में पहले l3msg प्रलेखन।

@dbitouze जबकि आप डिज़ाइन बनाम कोड पर एक अच्छा प्रश्न पूछ रहे हैं, मुझे नहीं लगता कि यह समस्या सही जगह है। शायद स्टैकएक्सचेंज पर एक प्रश्न पोस्ट करना और टीम के सदस्यों में से एक का जवाब देना समझ में आता है? या लाटेक्स-एल मेलिंग सूची पर एक प्रश्न। मैं वास्तव में नहीं जानता।

हो गया ।

मैं के प्रलेखन ले जाकर हाथ में इस मुद्दे को ठीक करने के बाद \g_msg_module_name_prop और \g_msg_module_type_prop में पहले l3msg प्रलेखन।

AFAICS, ओपी में MCE अभी भी लिखता है:

पैकेज myclass चेतावनी: बार

pdflatex-dev । यहाँ टर्मिनल में आउटपुट है (प्लस फ़ाइल सूची):

This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021) (preloaded format=pdflatex-dev)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2021-12-01> pre-release-0 (develop 2021-6-6 branch)
L3 programming layer <2021-06-01>

LaTeX Warning: Writing or overwriting file `./myclass.cls'.


(./myclass.cls
Document Class: myclass 2021/04/26 v0.1  My Nice Class 
(/usr/local/texlive/2021/texmf-dist/tex/latex-dev/base/article.cls
Document Class: article 2021/02/12 v1.4n Standard LaTeX document class
(/usr/local/texlive/2021/texmf-dist/tex/latex-dev/base/size10.clo))

Package myclass Warning: Bar

) (/usr/local/texlive/2021/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
 (./test.aux) (./test.aux)

 *File List*
 myclass.cls    2021/04/26 v0.1  My Nice Class 
 article.cls    2021/02/12 v1.4n Standard LaTeX document class
  size10.clo    2021/02/12 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def    2021-05-07 L3 backend support: PDF output (pdfTeX)
 ***********

 )
No pages of output.
Transcript written on test.log.

@dbitouze क्या आपने आवेदन किया है

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

ब्रूनो के संदेश में "फिक्स्ड" यह स्पष्ट करने के लिए दस्तावेज़ीकरण को पहले स्थानांतरित करना था कि इस तरह की लाइन को जोड़ने की आवश्यकता नहीं है कि इस तरह की अब आवश्यकता नहीं है।

@dbitouze क्या आपने आवेदन किया है

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

हम, नहीं, गलतफहमी के लिए खेद है।

ब्रूनो के संदेश में "फिक्स्ड" यह स्पष्ट करने के लिए दस्तावेज़ीकरण को पहले स्थानांतरित करना था कि इस तरह की लाइन को जोड़ने की आवश्यकता नहीं है कि इस तरह की अब आवश्यकता नहीं है।

बहुत बुरा: मैंने सोचा (और आशा व्यक्त की) फिक्स को अब वर्ग लेखक से किसी भी कार्रवाई की आवश्यकता नहीं है: मुस्कान: क्या यह योजनाबद्ध है?

जैसा कि @josephwright ने समझाया कि उपयोग किए गए उपसर्ग और वर्ग या पैकेज नाम के बीच कोई स्वचालित रूप से पता लगाने योग्य कनेक्शन नहीं है। यह स्पष्ट रूप से \ClassWarning कहने और फिर नाम देने की पुरानी 2e पद्धति से वास्तव में अलग नहीं है, केवल अब आपको केवल एक बार कनेक्शन को परिभाषित करना होगा और अतीत में आपको प्रत्येक कॉल पर एक का उपयोग करके ऐसा करना होगा। \Class... कमांड और उसे क्लास का नाम देना।

तो "माईक्लास" का उपयोग केवल संदेश प्रणाली को पारित एक स्ट्रिंग है और जब हम इंसान सोच सकते हैं कि नाम में "कक्षा" देखने का मतलब है कि यह एक वर्ग है तो संदेश प्रणाली उस कटौती को नहीं कर सकती है (और यह वैसे भी गलत हो सकता है)। यही कारण है कि वर्ग लेखक से कार्रवाई की आवश्यकता है और अतीत में इसकी आवश्यकता थी जहां आपने \ClassWarning{<classname>} लिखा था। तथ्य यह है कि वर्ग का नाम \ProvidesExplClass लिए जाना जाता है, इसका मतलब यह नहीं है कि संदेश में प्रयुक्त स्ट्रिंग उस नाम का उपयोग कर रही है। उदाहरण के लिए मेरे अधिकांश पैकेज नाम लंबे हैं लेकिन मेरे द्वारा उपयोग किए जाने वाले उपसर्ग काफी कम हैं। तो आपको संदेश प्रणाली को बताना होगा कि एक विशेष स्ट्रिंग एक वर्ग है।

जब \ProvidesExplClass को कॉल किया जाता है और
\g_msg_module_type_prop को प्रारंभ और अंत के बीच संशोधित नहीं किया गया है
फ़ाइल (शायद केवल तभी चेतावनी दें जब \msg_new:nnnn को कॉल किया गया हो)।

यह बहुत बदसूरत नहीं लगता, और यह इस आसान गलती से बच सकता है।

हम कर सकते थे, लेकिन यह प्रत्येक दस्तावेज़ के लिए एक रनटाइम लागत है जबकि त्रुटि एक वर्ग त्रुटि है जो स्वयं को गलत (लेकिन हानिरहित) आउटपुट के साथ प्रकट करती है और इसे एक बार और सभी के लिए आसानी से ठीक कर दिया जाता है। तो मैं वास्तव में रनटाइम चेक के साथ प्रसंस्करण धीमा करने के पक्ष में नहीं हूं। अगर बिल्कुल भी चेक विकल्प में जाना चाहिए। मुझे पता है कि इस रनटाइम लागत सभी अपने आप में छोटी हैं लेकिन कुल मिलाकर वे जोड़ते हैं।