From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Nelson Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] some tex-related packages Date: Mon, 20 May 2024 11:01:57 +0200 Message-ID: References: <87msol9emj.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b9888a0618def4cf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37386"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Arash Esbati To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 20 12:54:11 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 1s90eg-0009X9-Al for ged-emacs-devel@m.gmane-mx.org; Mon, 20 May 2024 12:54:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s90dt-00019p-Dg; Mon, 20 May 2024 06:53:21 -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 1s8yuJ-000136-Ui for emacs-devel@gnu.org; Mon, 20 May 2024 05:02:16 -0400 Original-Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s8yuH-00070j-Ng; Mon, 20 May 2024 05:02:11 -0400 Original-Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-7e21b6e98bdso121899739f.0; Mon, 20 May 2024 02:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716195728; x=1716800528; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K/qm/npoUAsXObIojNVvvSnTKRN0YMvVekdu44j/MJQ=; b=VnO4TtGyG7dGmbLcXNkPJdy2pz27ZvpIcixRBRQO6e9rXtR2Q8bT5sy7DVIawbrg8c clUkkICu1fMhAaC3HlhVEKjVZYU1bZ/0MIRr7PUKkYlmBbBoOKMPu3Tl7PQDMpe2QGTO sl+jcTUT8CRVmDd7eGma/GvBVQOJZMVxj3kj4V5Ca8FaaYIexedes48dDNCuGNQEYuf1 IoY+nRpBAmyYIjNDvNopFcIYpvaZ9TE/eypAft7NY1csICtq/VsWFv+7fl+mz+3nDTWK 33y7BCfrwejYjJDdPCZFKvs73QbER+4jof8tZk/3ai9Fq4Uet1cSXdY0M0x5rIfB2sDd S6Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716195728; x=1716800528; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K/qm/npoUAsXObIojNVvvSnTKRN0YMvVekdu44j/MJQ=; b=jKm7pETa42oJTWcb7B8duzT24l7rGBII0myGy3WZSebr92ykhaG/Z38dHHdotqCBCm kthamPUPPPObj4QCUyeeLp+LdrnxjPC1Z4qAAH7kG+eowpix97AL5GjG5mH2BDCXshq8 2BCWFpIhf8RSUwRXT9ac3UJsFycpHlAJvyW5MgeENPt9h5j3ZOfzIJNOFO2TM2Z8SulI pJsBV1FZXRx7ah5gJnwaIIcYM/BiXIueNCHw3Ze84C0yhFApQDlmmaBjynx+3NjPLlXL De0N0jUoCyJ4DajirOxXVRz/pMzyFHMGoJv3FaAK7k2lOKsdhJsAprtV8syvt76OBVZa TLnw== X-Forwarded-Encrypted: i=1; AJvYcCWmuRZQZeAYf0zYobFk/XCovw8TD9d+XwVv8iKw7iQCIAb9YDABf4dJ9apnZG258HewDyoxESuaHq9+bYux X-Gm-Message-State: AOJu0YxPh1dmHmLuUdLvr8xevH6X4HvlTHgziCLSH1h0QkKz7+pKdKok aH1jgjXT+pIJBJOcTk0jtjeVFyESOmHX+NZa+MvwjMFy7SgU6nMqaRLMUpzY4JzhzxlcYg9+MLs bdt8pKkARSmEyxtsaad6oT/IbVGA= X-Google-Smtp-Source: AGHT+IE6hkVRNbooEJBKj/ztMFt0v4xRx+/OKJYfml6Rf3jfVXVmM45raOo1GyCFpg+zsEa/4bRT0AekT/NRRnndzH4= X-Received: by 2002:a5e:c806:0:b0:7de:dcb6:2889 with SMTP id ca18e2360f4ac-7e1b51b669fmr3235290139f.7.1716195727868; Mon, 20 May 2024 02:02:07 -0700 (PDT) In-Reply-To: <87msol9emj.fsf@posteo.net> Received-SPF: pass client-ip=2607:f8b0:4864:20::d29; envelope-from=ultrono@gmail.com; helo=mail-io1-xd29.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 20 May 2024 06:53:20 -0400 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:319403 Archived-At: --000000000000b9888a0618def4cf Content-Type: text/plain; charset="UTF-8" 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.) > 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. > > > 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. 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. Thanks, best, Paul --000000000000b9888a0618def4cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Philip (CC: Arash, in c= ase you have further thoughts),
=C2=A0
=C2=A0 Perhaps it should be renamed to somethi= ng like "latex-numbering"?

Th= anks for this suggestion, agreed.
=C2=A0

> tex-continuous provides a minor mode in which a tex document is compil= ed
> continuously using latexmk, the error log is parsed using AUCTeX, and<= br> > errors are reported via flymake.

That sounds interesting.=C2=A0 Here again, tex- implies one thing but latex= mk
another.=C2=A0

How about "latexmk-con= tinuous"?=C2=A0 (The names latex-flymake and auctex-latexmk are both t= aken, and those packages do different things.=C2=A0 The new feature is that= the compilation takes place continuously rather than on demand, with the e= rrors reported in the buffer.)
=C2=A0
Is the dependency on latexmk hard, or coul= d you re-use AUCTeX's facilities?

A= UCTeX provides TeX-command-run-all, which does something similar to latexmk= (and also runs "View" at the end, displaying the PDF, which I su= ppose could be=C2=A0disabled somehow).=C2=A0 I considered swapping latexmk = for TeX-command-run-all + after-save-hook, but this seemed troublesome for = a few reasons.=C2=A0 One was that the timer for preview-auto (my other pack= age, mentioned below) doesn't fire when AUCTeX's processes are acti= ve, so if we use AUCTeX to regularly recompile the document, then there wil= l be stretches of time in which the previews don't update.=C2=A0 The us= e of a separate (latexmk) process adds something like a secondary compilati= on thread, keeping the primary thread free for preview-auto.

I don't view the dependency on latexmk as serious, sin= ce I believe it is included nowadays in all tex distributions (and I have c= olleagues who have been=C2=A0using my package on each of the major OS's= , so it seems portable in practice).=C2=A0 My package does re-use AUCTeX= 9;s error parsing facilities, which in some sense provide the heavy lifting= , and also respects some AUCTeX configuration variables, such as TeX-output= -dir.=C2=A0 I'd be happy to update the package to use more of AUCTeX= 9;s facilities=C2=A0if someone spotted a way to do so without the issues th= at=C2=A0I encountered.

=C2=A0

> 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?=C2=A0 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 b= een discussed:

<= a href=3D"https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00066.= html" target=3D"_blank">https://lists.gnu.org/archive/html/auctex-devel/202= 4-04/msg00066.html

=
They rely on recent AUCTeX patches:

https://lists.gnu.org/archive/<= /span>h= tml/bug-auctex/2024-04/threads.html

The= question of upstreaming one of them was raised:

<= a href=3D"https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00173.= html" target=3D"_blank">https://lists.gnu.org/archive/html/auctex-devel/202= 4-04/msg00173.html

I'd be happy w= ith whatever makes the most sense, but figured submitting to ELPA would mak= e them readily available without introducing additional burden on the AUCTe= X maintainers.

On the topic of "too many = little packages", I'll confess that I have a few more in the queue= , e.g.:


= (plus a few more, listed at=C2=A0https://github.com/ultronozm/emacsd, that I'= ;d like to think about more before "formally" publishing)

I've been trying to split the functionality accumulat= ed in my config into the smallest coherent packages that I can, but would w= elcome feedback or other suggestions, especially if there are trade-offs wi= th having too many little packages.

Thanks, best,<= /div>

Paul

--000000000000b9888a0618def4cf--