From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] some tex-related packages Date: Mon, 20 May 2024 09:18:11 +0000 Message-ID: <87cypgn8oc.fsf@posteo.net> References: <87msol9emj.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37489"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Arash Esbati To: Paul Nelson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 20 11:18:59 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s8zAZ-0009Sp-3C for ged-emacs-devel@m.gmane-mx.org; Mon, 20 May 2024 11:18:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s8z9w-00083M-Eb; Mon, 20 May 2024 05:18:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8z9s-00082n-Vk for emacs-devel@gnu.org; Mon, 20 May 2024 05:18:18 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8z9q-0002FW-9o for emacs-devel@gnu.org; Mon, 20 May 2024 05:18:16 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 49A7D24002B for ; Mon, 20 May 2024 11:18:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1716196692; bh=SkJrKx9BULQP0PIwjElAZ8WmoRY4w0PG2oS4i6ynbhk=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=DHbcppC4/9qpRY+TgpeVUsZr4QXlpicMSyHPKxT5Ffuvc/wON9U1tS40w7orxDI6w YA+BIgfpGzNujXEb8f+vJ6KDeajW2W6NEzqNJO2LFIPoiO9UZ7E4OEmKN7RmF3JO52 Q4Xwq+KxOBtOdP8dKff1SH9SF7F1Vu1UCD17JHbaTXT/08ZkFwmyXhj6p2byNeGUp5 +A7rKRrgAnRPKf0OuayapG8KPUAedUnXrTqALZ/ENh3dmVDI/m4n1iwryFcMXMVE8m 4sW9l19HP0C+75L2aTfpxLK2b4HZ+7uW8dhbuJRljYHIZQcyPOTW17C6lzXseqLqgq gyBWwQyHcFGhQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VjX6W6L6Gz6trs; Mon, 20 May 2024 11:18:11 +0200 (CEST) In-Reply-To: (Paul Nelson's message of "Mon, 20 May 2024 11:01:57 +0200") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319402 Archived-At: Paul Nelson writes: > Hi Philip (CC: Arash, in case you have further thoughts), > > >> Perhaps it should be renamed to something like "latex-numbering"? >> > > Thanks for this suggestion, agreed. > >> >> > tex-continuous provides a minor mode in which a tex document is compiled >> > continuously using latexmk, the error log is parsed using AUCTeX, and >> > errors are reported via flymake. >> >> That sounds interesting. Here again, tex- implies one thing but latexmk >> another. > > > How about "latexmk-continuous"? (The names latex-flymake and > auctex-latexmk are both taken, and those packages do different things. The > new feature is that the compilation takes place continuously rather than on > demand, with the errors reported in the buffer.) Sounds good and descriptive! > >> Is the dependency on latexmk hard, or could you re-use AUCTeX's facilities? >> > > AUCTeX provides TeX-command-run-all, which does something similar to > latexmk (and also runs "View" at the end, displaying the PDF, which I > suppose could be disabled somehow). I considered swapping latexmk for > TeX-command-run-all + after-save-hook, but this seemed troublesome for a > few reasons. One was that the timer for preview-auto (my other package, > mentioned below) doesn't fire when AUCTeX's processes are active, so if we > use AUCTeX to regularly recompile the document, then there will be > stretches of time in which the previews don't update. The use of a > separate (latexmk) process adds something like a secondary compilation > thread, keeping the primary thread free for preview-auto. > > I don't view the dependency on latexmk as serious, since I believe it is > included nowadays in all tex distributions (and I have colleagues who have > been using my package on each of the major OS's, so it seems portable in > practice). My package does re-use AUCTeX's error parsing facilities, which > in some sense provide the heavy lifting, and also respects some AUCTeX > configuration variables, such as TeX-output-dir. I'd be happy to update > the package to use more of AUCTeX's facilities if someone spotted a way to > do so without the issues that I encountered. As it is an external package, I don't think the dependency on the external package is an issue either (especially if the name makes it explicit to prevent an unpleasant surprise). >> >> > preview-auto provides a minor mode in which AUCTeX previews generate >> > automatically in the visible part of the buffer. >> >> This makes me think, have you communicated any of these features to the >> AUCTeX developers? Perhaps it would make more sense to upstream these >> as patches instead of having too many little packages? >> >> > They've been communicated, and the first two have been discussed: > > https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00043.html > https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00066.html > https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00086.html > > They rely on recent AUCTeX patches: > > https://lists.gnu.org/archive/html/bug-auctex/2024-04/threads.html > > The question of upstreaming one of them was raised: > > https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00173.html > > I'd be happy with whatever makes the most sense, but figured submitting to > ELPA would make them readily available without introducing additional > burden on the AUCTeX maintainers. I'll let the AUCTeX maintainers decide. That being said, I am sure they'd always appreciate a helping hand in general. > On the topic of "too many little packages", I'll confess that I have a few > more in the queue, e.g.: > > https://github.com/ultronozm/tex-parens.el > https://github.com/ultronozm/tex-item.el > https://github.com/ultronozm/preview-auto.el > > (plus a few more, listed at https://github.com/ultronozm/emacsd, that I'd > like to think about more before "formally" publishing) > > I've been trying to split the functionality accumulated in my config into > the smallest coherent packages that I can, but would welcome feedback or > other suggestions, especially if there are trade-offs with having too many > little packages. It might just be my view, but having too many little packages makes it difficult for newcomers to get an overview and understand what they want or need. Having code under the maintainance of a group of people usually makes it more future-proof, both by reducing the bus-factor but also by having more time to fine polish the code. > Thanks, best, > > Paul -- Philip Kaludercic on peregrine