Latex3: Pesan kelas diklaim sebagai pesan "Paket"

Ya, tetapi Anda harus mengatakannya secara eksplisit dengan menambahkan jenis file Anda ke \g_msg_module_type_prop :

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

dan secara opsional namanya menjadi \g_msg_module_name_prop :

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

maka Anda mendapatkan peringatan seperti:

Class My Nice Class Warning: Bar

Mungkin l3msg dapat mengisi otomatis tipe jika \ProvidesExpl<Thing> digunakan...

MWE:

\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}

Mungkin l3msg dapat mengisi otomatis tipe jika \ProvidesExpl<Thing> digunakan...

Akan menyenangkan! :senyum:

Tidak ada hubungan khusus antara \ProvidesExpl... dan awalan modul yang digunakan untuk kode: Saya pikir itu hanya sesuatu yang harus dilakukan secara manual.

Itu sebelum masalah 'benar-benar kelas tidak boleh menggunakan sintaks expl3 ' - itu adalah ide yang tidak cukup berhasil. (Kelas masih membutuhkan lebih banyak pekerjaan, tetapi seharusnya tidak melakukan pemrograman, yang termasuk dalam paket.)

Tidak ada hubungan khusus antara \ProvidesExpl... dan awalan modul yang digunakan untuk kode: Saya pikir itu hanya sesuatu yang harus dilakukan secara manual.

Saya tidak mengerti mengapa.

Itu sebelum masalah 'benar-benar kelas tidak boleh menggunakan sintaks expl3 ' - itu adalah ide yang tidak cukup berhasil. (Kelas masih membutuhkan lebih banyak pekerjaan, tetapi seharusnya tidak melakukan pemrograman, yang termasuk dalam paket.)

Saya tidak mengerti apa ide yang tidak cukup berhasil.

Tidak ada hubungan khusus antara \ProvidesExpl... dan awalan modul yang digunakan untuk kode: Saya pikir itu hanya sesuatu yang harus dilakukan secara manual.

Saya tidak mengerti mengapa.

Dalam \ProvidesExplClass nama kelas tidak harus sama dengan awalan yang digunakan oleh kode. Atau kode tersebut dapat digunakan oleh paket dan kelas (saya melakukannya dalam istilah LaTeX2e dalam achemso ), sehingga tautannya tidak akan terlihat.

Itu sebelum masalah 'benar-benar kelas tidak boleh menggunakan sintaks expl3 ' - itu adalah ide yang tidak cukup berhasil. (Kelas masih membutuhkan lebih banyak pekerjaan, tetapi seharusnya tidak melakukan pemrograman, yang termasuk dalam paket.)

Saya tidak mengerti apa ide yang tidak cukup berhasil.

Kelas seharusnya tentang pemformatan/gaya/dll, bukan fungsionalitas. Yang terakhir harus ditambahkan oleh paket, yang idealnya tidak tergantung pada kelas yang digunakan. Situasi saat ini tidak ideal, dan pada awal set \ProvidesExpl... disediakan untuk hanya mencerminkan \Provides... dari kernel LaTeX2e. Tetapi dengan melihat ke belakang itu pendekatan yang salah: _packages_ harus menggunakan kode expl3 , _classes_ harus menggunakan antarmuka tingkat dokumen atau desain yang _mungkin_ diimplementasikan dalam expl3 .

Kelas seharusnya tentang pemformatan/gaya/dll, bukan fungsionalitas.

Kelas yang sedang saya kerjakan harus menyisipkan grafik pada halaman pertama dokumen... jika grafik ini ditemukan dan sebaliknya harus menampilkan peringatan (selain peringatan di file log). Apakah itu desain atau fungsionalitas?

Saya telah memperbaiki masalah yang ada dengan memindahkan dokumentasi \g_msg_module_name_prop dan \g_msg_module_type_prop sebelumnya di dokumentasi l3msg .

@dbitouze Saat Anda mengajukan pertanyaan bagus tentang desain vs kode, saya rasa masalah ini bukan tempat yang tepat. Mungkin masuk akal untuk memposting pertanyaan di stackexchange dan meminta salah satu anggota tim menjawab di sana? Atau pertanyaan di milis LaTeX-L. Aku tidak tahu.

Selesai .

Saya telah memperbaiki masalah yang ada dengan memindahkan dokumentasi \g_msg_module_name_prop dan \g_msg_module_type_prop sebelumnya di dokumentasi l3msg .

AFAICS, MCE di OP masih menulis:

Paket myclass Peringatan: Bar

bahkan dengan pdflatex-dev . Berikut adalah output di terminal (ditambah daftar file):

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 sudahkah Anda melamar?

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

"Diperbaiki" dalam pesan Bruno adalah memindahkan dokumentasi lebih awal untuk memperjelas bahwa baris seperti itu perlu ditambahkan bukan berarti baris seperti itu tidak lagi diperlukan.

@dbitouze sudahkah Anda melamar?

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

Hum, tidak, maaf atas kesalahpahamannya.

"Diperbaiki" dalam pesan Bruno adalah memindahkan dokumentasi lebih awal untuk memperjelas bahwa baris seperti itu perlu ditambahkan bukan berarti baris seperti itu tidak lagi diperlukan.

Sayang sekali: Saya pikir (dan berharap) perbaikannya tidak memerlukan lagi tindakan apa pun dari penulis kelas: senyum: Apakah sudah direncanakan?

Seperti yang dijelaskan @josephwright, tidak ada koneksi yang dapat dideteksi secara otomatis antara awalan yang digunakan dan nama kelas atau paket. Ini tidak benar-benar berbeda dari metode 2e lama yang secara eksplisit mengatakan \ClassWarning dan kemudian memberikan nama, hanya sekarang Anda harus mendefinisikan koneksi hanya sekali dan di masa lalu Anda harus melakukan ini pada setiap panggilan dengan menggunakan a \Class... perintah dan memberikan nama kelas untuk itu.

Jadi menggunakan "kelas saya" hanyalah sebuah string yang diteruskan ke sistem pesan dan sementara kita manusia mungkin berpikir melihat "kelas" dalam namanya berarti itu adalah kelas, sistem pesan tidak dapat membuat pengurangan itu (dan mungkin saja salah). Inilah sebabnya mengapa tindakan dari penulis kelas diperlukan dan diperlukan di masa lalu di mana Anda menulis \ClassWarning{<classname>} . Fakta bahwa nama kelas diketahui \ProvidesExplClass tidak berarti bahwa string yang digunakan dalam msg menggunakan nama itu. Misalnya sebagian besar nama paket saya panjang tetapi awalan yang saya gunakan cukup pendek. Jadi, Anda harus memberi tahu sistem pesan bahwa string tertentu adalah kelas.

Kami masuk akal bisa melacak ketika \ProvidesExplClass dipanggil dan
\g_msg_module_type_prop belum dimodifikasi antara awal dan akhir
file (mungkin hanya memperingatkan jika \msg_new:nnnn telah dipanggil).

Kedengarannya tidak terlalu jelek, dan itu bisa menghindari kesalahan mudah ini.

kita bisa, tetapi itu adalah biaya runtime untuk setiap dokumen sementara kesalahannya adalah kesalahan kelas yang memanifestasikan dirinya dengan keluaran yang salah (tetapi tidak berbahaya) dan mudah diperbaiki sekali dan untuk semua. Jadi saya tidak terlalu mendukung memperlambat pemrosesan dengan pemeriksaan runtime. Jika sama sekali harus masuk ke opsi centang. Saya tahu biaya runtime ini semuanya kecil dengan sendirinya tetapi secara berlebihan mereka bertambah.