Re: [PATCH] fix delete-property handling
-- Resending the email as I didn't include the mailing list at first. Apologies. Hi, Ikumi, Thank you for the review! > Thanks for your proposals. I'm now reading through the proposed codes. > They basically look good to me. I think that AUCTeX can accept them and > it requires copyright assignment. I assume that you haven't signed FSF > copyright assignment form before, so please follow this instruction if > you want to have your proposal incorporated into AUCTeX: > https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future I have signed my copyright assignment (for GNU Emacs and AUCTeX) and emailed to mailto:ass...@gnu.org. They haven't responded yet though. >(This isn't a suggestion, just an impression.) >> + (put symbol 'delete-selection >> + (lambda () >> + (unless (funcall electricp) >> + (get #'self-insert-command 'delete-selection) > >Good simple solution. I wasn't aware that `delete-selection' property >can return a function because of the commentary of delsel.el: >;; FUNCTION >;; For commands which need to dynamically determine this behavior. >;; FUNCTION should take no argument and return one of the above >;; values, or nil. In the latter case, FUNCTION should itself >;; do with the active region whatever is appropriate." >I took that "one of the above values" doesn't include FUCTTION itself. >However, `delete-selection-helper' is actually written to operate >recursively, which I didn't realize. >(That was the reason I wrote the current `delete-selection' property of >`LaTeX-insert-left-brace' to discriminate the cases between '(yank >supersede kill t nil) and a function.) Yes, I think the commentary at the top of delsel.el failed to express the intention. The docstring for delete-selection-helper says «FUNCTION should take no argument and return a value acceptable as TYPE, or nil.», which clarifies that recursive operation is allowed. I've implemented the rest of the corrections/suggestions and am attaching that as a new patch for patch-0001. I will need to rebase my patch-0002 on top, which I'll do after the review of that one. Best, Artem
master d9f8ff12: Support mcite compat macros provided by biblatex
branch: master
commit d9f8ff12b12ee1d2d2ac9f39ebb470ac3d4f6fe8
Author: Arash Esbati
Commit: Arash Esbati
Support mcite compat macros provided by biblatex
* style/biblatex.el (LaTeX-arg-biblatex-mcite): New function.
("biblatex"): Use it and support mcite compat macros.
Re-indent code. (bug#31132)
---
style/biblatex.el | 202 +-
1 file changed, 155 insertions(+), 47 deletions(-)
diff --git a/style/biblatex.el b/style/biblatex.el
index 31180226..ae630321 100644
--- a/style/biblatex.el
+++ b/style/biblatex.el
@@ -237,20 +237,56 @@ for citation keys."
(TeX-argument-insert (mapconcat #'identity items ",") optional))
(setq noinsert t
+;; Support for mcite-like Citation Commands, see § 3.9.10 of Biblatex
+;; reference manual.
+(defun LaTeX-arg-biblatex-mcite (optional)
+ "Query and insert the mandatory argument of \\mcite compat macros."
+ (let ((set-name (TeX-read-string
+ (TeX-argument-prompt optional nil "Set")))
+(read-cite (lambda (opt)
+ (if (and (fboundp 'reftex-citation)
+ (fboundp 'reftex-plug-flag)
+ (reftex-plug-flag 3))
+ (reftex-citation t)
+ (TeX-completing-read-multiple
+(TeX-argument-prompt opt nil "Key(s)")
+(LaTeX-bibitem-list)
+cite-keys arg)
+(cond ((and (not (string-empty-p set-name))
+(y-or-n-p "Add citation keys to the set name?"))
+ ;; We want \mcite{set-name,*key1,*key2,*key3}
+ (setq cite-keys (funcall read-cite optional))
+ (when cite-keys
+ (setq cite-keys (mapcar (lambda (x) (concat "*" x))
+ cite-keys)))
+ (setq arg (concat set-name
+ (when cite-keys
+ (concat "," (mapconcat #'identity
+ cite-keys
+ ","))
+ ;; We want \mcite{key1}. FIXME: Are multiple keys
+ ;; allowed?
+ ((string-empty-p set-name)
+ (setq arg (mapconcat #'identity
+(funcall read-cite optional)
+",")))
+ (t (setq arg "")))
+(TeX-argument-insert arg optional)))
+
(defun LaTeX-arg-biblatex-natbib-notes (optional)
"Prompt for two note arguments of a natbib compat citation command."
(when TeX-arg-cite-note-p
- (let ((pre (TeX-read-string
- (TeX-argument-prompt optional nil "Prenote")))
-(post (TeX-read-string
- (TeX-argument-prompt optional nil "Postnote"
-(TeX-argument-insert pre optional)
-(TeX-argument-insert post optional)
-;; pre is given, post is empty: Make sure that we insert an
-;; extra pair of `[]', otherwise pre becomes post
-(when (and pre (not (string= pre ""))
- (string= post ""))
- (insert LaTeX-optop LaTeX-optcl)
+(let ((pre (TeX-read-string
+(TeX-argument-prompt optional nil "Prenote")))
+ (post (TeX-read-string
+ (TeX-argument-prompt optional nil "Postnote"
+ (TeX-argument-insert pre optional)
+ (TeX-argument-insert post optional)
+ ;; pre is given, post is empty: Make sure that we insert an
+ ;; extra pair of `[]', otherwise pre becomes post
+ (when (and pre (not (string= pre ""))
+ (string= post ""))
+(insert LaTeX-optop LaTeX-optcl)
(TeX-add-style-hook
"biblatex"
@@ -334,32 +370,45 @@ for citation keys."
(TeX-arg-completing-read-multiple (LaTeX-bibitem-list) "Keys"))
;;; Citation Commands
'("cite" (TeX-arg-conditional TeX-arg-cite-note-p
- (["Prenote"] ["Postnote"]) ()) TeX-arg-cite)
+ (["Prenote"] ["Postnote"]) ())
+ TeX-arg-cite)
'("Cite" (TeX-arg-conditional TeX-arg-cite-note-p
- (["Prenote"] ["Postnote"]) ()) TeX-arg-cite)
+ (["Prenote"] ["Postnote"]) ())
+ TeX-arg-cite)
'("parencite" (TeX-arg-conditional TeX-arg-cite-note-p
- (["Prenote"] ["Postnote"]) ())
TeX-arg-cite)
+ (["Prenote"] ["Postnote"]) ())
+ TeX-arg-cite)
'("Parencite" (TeX-arg-conditional TeX-arg-cite-note-p
- (["Prenote"] ["Postnote"]) ())
TeX-arg-cite)
+ (["Prenote"] ["Postnote"]) ())
+ TeX-arg-cite)
'("footcite" (TeX-arg-conditional TeX-arg-cite-note-p
- (["Prenote"] ["Postnote"]) ())
TeX-arg-cite)
+
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn [2024-04-09 14:09:53] wrote:
> Hi all,
>
> some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
> AUCTeX ELPA release and asked why there were changes to files which
> shouldn't be committed because they are generated from other files,
> e.g., info files.
>
> The reason is that at the time where we added AUCTeX to ELPA (and
> created the externals/elpa branch for that purpose), the ELPA machinery
> wasn't able to perform our normal build procedure. But Stefan Monnier
> chimed in and suggested that nowadays, those issues are most probably
> resolved or can be resolved in some less drastic way than a separate
> branch. For example, building info manuals from multiple texi files
> residing in subdirectories are no problem anymore (one can specify `:doc
> ("doc/auctex.texi" "doc/preview-latex.texi")` in the ELPA package
> recipe) and we could have a separate elpa target in our Makefile and
> specify that as `:make "elpa"` in package recipe.
>
> I think it would be great if we could make it so that everyone of us
> could trigger a new ELPA release directly from the master branch by just
> incrementing the Version header which currently resides in auctex.el on
> the externals/elpa branch but which is generated from auctex.el.in on
> the master branch so not suitable for a Version header. But no problem,
> the elpa recipe could specify some different `:main-file`.
>
> So basically, I see these challenges:
>
> - We set the AUCTeX/preview version and date in the texi files from
> AUCTEXVERSION, AUCTEXDATE, PREVIEWVERSION, and PREVIEWDATE which are
> guessed by autoconf from the ChangeLog.1 and ChangeLog-preview files
> which arranges that the *VERSION is just the same as the *DATE if
> the top entry in the ChangeLogs is not a release entry in which case
> the version is extracted there.
>
> These ChangeLogs aren't usually edited. Currently, the tarball
> release process prepends the changes since the last tarball release,
> and then the "release manager" (Mosè) adds an entry like
>
> --8<---cut here---start->8---
> 2024-01-17 Mosè Giordano
>
> * Version 13.3 released.
> --8<---cut here---end--->8---
>
> on top. So how should that work for ELPA releases?
For GNU ELPA releases,the "main" place where you keep version numbers
should be your "main file", ideally `auctex.el`.
So your make target will want to extract the version from there instead
of from the ChangeLog. But that should be easy. The "right" way would
be to fire an Emacs process and use `package-buffer-info` or just
`lm-header` to fetch the info. But I'd use a `sed` one-liner.
That won't give you a date, tho. You could try and use Git to find
a corresponding date, but personally, I'd just use the current date instead.
> - There's also a completely different alternative: make the
> externals/elpa the new "main" branch and drop master and tarball
> releases altogether. Is there still a justification for having
> them? I mean, we dropped XEmacs support anyway and it should be
> easy enough for distros to just use the ELPA tarballs as basis for
> their distro packages.
That's what I'd do if I were you, indeed.
But note that this will still require tweaking the GNUmakefile to fetch the
Version from the new place and a few things like that and changing the
recipe to add something like `:make "elpa"`.
> - Mostly to Stefan: How can we test that safely? I guess we'll find
> some more issues. I don't want to edit the AUCTeX recipe in
> elpa-packages and then deploy broken packages to users.
You can also try and reproduce the build locally as follows:
git clone --single-branch https://git.sv.gnu.org/git/emacs/elpa
cd elpa
make # Setup the infrastructure
make packages/auctex # Create a worktree of the package
make auctex.tar # Build the tarballs into `auctex.tar`
Note that the tarball is built from *the commit* rather than from the
current set of files (i.e. we start with `git stash` and we `git clean`
as well, IIRC, so be forewarned that it can throw away uncommitted data).
Once that's working, we can install it in `elpa.git` but without
changing the `Version:` header so it doesn't trigger a release: it will
still trigger building a new tarball in GNU-devel ELPA so we can confirm
that it all works according to plans. And once we're satisfied with
http://elpa.gnu.org/devel/auctex.html, all that remains is to bump up
the `Version:`.
Stefan
Making AUCTeX ELPA releases from the master branch
Hi all,
some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
AUCTeX ELPA release and asked why there were changes to files which
shouldn't be committed because they are generated from other files,
e.g., info files.
The reason is that at the time where we added AUCTeX to ELPA (and
created the externals/elpa branch for that purpose), the ELPA machinery
wasn't able to perform our normal build procedure. But Stefan Monnier
chimed in and suggested that nowadays, those issues are most probably
resolved or can be resolved in some less drastic way than a separate
branch. For example, building info manuals from multiple texi files
residing in subdirectories are no problem anymore (one can specify `:doc
("doc/auctex.texi" "doc/preview-latex.texi")` in the ELPA package
recipe) and we could have a separate elpa target in our Makefile and
specify that as `:make "elpa"` in package recipe.
I think it would be great if we could make it so that everyone of us
could trigger a new ELPA release directly from the master branch by just
incrementing the Version header which currently resides in auctex.el on
the externals/elpa branch but which is generated from auctex.el.in on
the master branch so not suitable for a Version header. But no problem,
the elpa recipe could specify some different `:main-file`.
So basically, I see these challenges:
- We set the AUCTeX/preview version and date in the texi files from
AUCTEXVERSION, AUCTEXDATE, PREVIEWVERSION, and PREVIEWDATE which are
guessed by autoconf from the ChangeLog.1 and ChangeLog-preview files
which arranges that the *VERSION is just the same as the *DATE if
the top entry in the ChangeLogs is not a release entry in which case
the version is extracted there.
These ChangeLogs aren't usually edited. Currently, the tarball
release process prepends the changes since the last tarball release,
and then the "release manager" (Mosè) adds an entry like
--8<---cut here---start->8---
2024-01-17 Mosè Giordano
* Version 13.3 released.
--8<---cut here---end--->8---
on top. So how should that work for ELPA releases?
- There's also a completely different alternative: make the
externals/elpa the new "main" branch and drop master and tarball
releases altogether. Is there still a justification for having
them? I mean, we dropped XEmacs support anyway and it should be
easy enough for distros to just use the ELPA tarballs as basis for
their distro packages.
- Mostly to Stefan: How can we test that safely? I guess we'll find
some more issues. I don't want to edit the AUCTeX recipe in
elpa-packages and then deploy broken packages to users.
Bye,
Tassilo
master 49c9feb1: Allow preprocessing of previews
branch: master commit 49c9feb133e38a34d4eacbce248bc46e5c315715 Author: Paul Nelson Commit: Arash Esbati Allow preprocessing of previews * preview.el.in (preview-preprocess-function): New variable. (preview-region): Use the new variable (if non-nil) to preprocess the region being previewed. (bug#70295) --- preview.el.in | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/preview.el.in b/preview.el.in index 95410439..2fbf3a52 100644 --- a/preview.el.in +++ b/preview.el.in @@ -4030,6 +4030,11 @@ stored in `preview-dumped-alist'." (preview-format-kill old-format) (setcdr old-format nil)) +(defvar preview-preprocess-function nil + "Function used to preprocess region before previewing. +The function bound to this variable will be called inside +`preview-region' with one argument which is a string.") + (defun preview-region (begin end) "Run preview on region between BEGIN and END." (interactive "r") @@ -4038,7 +4043,10 @@ stored in `preview-dumped-alist'." (concat (preview--counter-information begin) TeX-region-extra))) (TeX-region-create (TeX-region-file TeX-default-extension) - (buffer-substring-no-properties begin end) + (let ((str (buffer-substring-no-properties begin end))) + (if preview-preprocess-function + (funcall preview-preprocess-function str) + str)) (if buffer-file-name (file-name-nondirectory buffer-file-name) "")
Re: [PATCH] fix delete-property handling
Hi Artem, > Artem Yurchenko writes: > Hello, > I am sending two patches that fix delete-property handling. They improve > interaction of auctex with other «electric» modes. Thanks for your proposals. I'm now reading through the proposed codes. They basically look good to me. I think that AUCTeX can accept them and it requires copyright assignment. I assume that you haven't signed FSF copyright assignment form before, so please follow this instruction if you want to have your proposal incorporated into AUCTeX: https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future > This is my first time contributing and I expect to have made mistakes. I am > willing to react to comments and fix any deficiencies. I'd like to comment on the first patch now; I haven't read the second patch in detail yet. Commentary on the second would follow on another day. > +(defun TeX--put-electric-delete-selection (symbol electricp) > + "Set appropriate `delete-selection' property for electric functions. > + > +When the function bound to SYMBOL has «electric» behaviour, as > +determined by ELECTRICP, `delete-selection' is set to nil. In I think it should explicitly state that ELECTRICP is actually a predicate (function). > +However, when /our/ electric behaviour is disabled (ELECTRICP is > +nil), we want other electric modes to operate freely. Shouldn't it be "ELECTRICP returns nil" instead of "ELECTRICP is nil"? It seems as if ELECTRICP was just an boolean flag rather than a predicate. (This isn't a suggestion, just an impression.) > + (put symbol 'delete-selection > + (lambda () > + (unless (funcall electricp) > + (get #'self-insert-command 'delete-selection) Good simple solution. I wasn't aware that `delete-selection' property can return a function because of the commentary of delsel.el: ;; FUNCTION ;; For commands which need to dynamically determine this behavior. ;; FUNCTION should take no argument and return one of the above ;; values, or nil. In the latter case, FUNCTION should itself ;; do with the active region whatever is appropriate." I took that "one of the above values" doesn't include FUCTTION itself. However, `delete-selection-helper' is actually written to operate recursively, which I didn't realize. (That was the reason I wrote the current `delete-selection' property of `LaTeX-insert-left-brace' to discriminate the cases between '(yank supersede kill t nil) and a function.) (This is optional.) > +(defun LaTeX-insert-left-brace-electric () [...] > + (let ((lbrace (char-to-string last-command-event)) lmacro skip-p) [...] > +(insert last-command-event) Since `LaTeX-insert-left-brace-electric' is no longer a command bound to a key, I'm inclined to writing it to receive `last-command-event' as an argument of the function rather than to refer to the variable directly. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine #Gaza #StopMassiveKilling #CeasefireNOW
