Re: Making AUCTeX ELPA releases from the master branch
>> Duh: it's `:doc`, not `:manual`! >> Sorry! > Haha, and then it works just fine. ;-) Yay! Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes: >>> [ This assumes that the `:manual ...` thingy does >>> successfully build the docs. ] >> >> This is where I'm not sure. At least it doesn't seem to have an effect >> when running "make auctex.tar" locally (as said in my other mail). The >> tar file only contains the *.info files and the dir file in doc/ which >> are build by running "make all". > > Duh: it's `:doc`, not `:manual`! > Sorry! Haha, and then it works just fine. ;-) Thanks! Tassilo
preview-auto.el & preview-tailor.el
Here are a couple further packages I'm hoping to submit (after 14.0.5), this time related to preview. * preview-auto requires the latest master (4731168eca3f103732a026f70912597faef8bd99). It adds a keybinding "C-c C-p C-a" that activates a minor mode in which previews automatically generate near the visible part of the buffer. It combines well with the following recently-added settings: (setq preview-protect-point t) (setq preview-locating-previews-message nil) (setq preview-leave-open-previews-visible t) The following is also useful, since DVI's generate faster than PDF's. (setq preview-LaTeX-command-replacements '(preview-LaTeX-disable-pdfoutput)) * preview-tailor provides a preview-scale-function that is intended to be easy to customize on a per-monitor basis (and otherwise): just add (preview-tailor-init) to your init file, use M-x preview-tailor-set-multiplier to change the scale for the current monitor, and M-x preview-tailor-save to save your settings. Both attached and available at https://github.com/ultronozm/preview-auto.el and https://github.com/ultronozm/preview-tailor.el. Any feedback welcome. Thanks, best, Paul preview-auto.el Description: Binary data preview-tailor.el Description: Binary data
Re: Making AUCTeX ELPA releases from the master branch
> Yes, it is. But I need the distinction if the current version got > there just now (in HEAD) or previously. So just a "yes/no" kind of information? I wonder what you use it for. >> [ This assumes that the `:manual ...` thingy does >> successfully build the docs. ] > > This is where I'm not sure. At least it doesn't seem to have an effect > when running "make auctex.tar" locally (as said in my other mail). The > tar file only contains the *.info files and the dir file in doc/ which > are build by running "make all". Duh: it's `:doc`, not `:manual`! Sorry! Stefan
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes:
>>> Why do you need to look at diffs?
>> In order to extract the version number.
>
> I don't understand: it's right there in the file, you don't need the
> diffs to extract it, no?
Yes, it is. But I need the distinction if the current version got there
just now (in HEAD) or previously.
>> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa
>> to build the docs again although the recipe's :make "all" did already
>> build them (but at the "wrong" location)?
>
> Yup (the two know nothing of each other).
Ok.
>> That would be ok for me; I would also be willing to add a special
>> elpa make target moving the files or generating another top-level dir
>> file.
>
> You could also replace the "make all" with another target that doesn't
> build the docs.
Yes, I can do that, too.
> [ This assumes that the `:manual ...` thingy does
> successfully build the docs. ]
This is where I'm not sure. At least it doesn't seem to have an effect
when running "make auctex.tar" locally (as said in my other mail). The
tar file only contains the *.info files and the dir file in doc/ which
are build by running "make all".
>> But I certainly want the additional benefit of having the docs
>> linked.
>
> That happens only if you use `:manual ...`.
Alright.
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
>> Why do you need to look at diffs?
> In order to extract the version number.
I don't understand: it's right there in the file, you don't need
the diffs to extract it, no?
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make "all" did already build
> them (but at the "wrong" location)?
Yup (the two know nothing of each other).
> That would be ok for me; I would also be willing to add a special elpa
> make target moving the files or generating another top-level dir file.
You could also replace the "make all" with another target that doesn't
build the docs.
[ This assumes that the `:manual ...` thingy does successfully
build the docs. ]
> But I certainly want the additional benefit of having the docs linked.
That happens only if you use `:manual ...`.
Stefan
master 4731168e: Allow opened previews to remain visible
branch: master
commit 4731168eca3f103732a026f70912597faef8bd99
Author: Paul Nelson
Commit: Arash Esbati
Allow opened previews to remain visible
* preview.el.in (preview-leave-open-previews-visible): New user
option.
(preview-gs-place, preview-disable, preview-inactive-string)
(preview-place-preview, preview-check-changes): Use it.
(preview-clearout): New optional argument, EXCEPTION.
* doc/preview-latex.texi (The Emacs interface): Document the
new user option.
* NEWS.org (Added): Announce the new custom option. (bug#70455)
---
NEWS.org | 6 --
doc/preview-latex.texi | 4
preview.el.in | 51 +-
3 files changed, 50 insertions(+), 11 deletions(-)
diff --git a/NEWS.org b/NEWS.org
index b0c8676a..21b98e30 100644
--- a/NEWS.org
+++ b/NEWS.org
@@ -21,11 +21,13 @@
- Add new custom option ~TeX-fold-auto-reveal~ which contols how the
original source text is revealed when user clicks the folded portion
by mouse.
+- Add new custom option ~TeX-fold-region-functions~ which is a list of
+ additional functions to call when folding a region.
- Add new custom option ~preview-protect-point~ which determines whether
previews generated on top of the current point should be temporarily
opened (~nil~ by default).
-- Add new custom option ~TeX-fold-region-functions~ which is a list of
- additional functions to call when folding a region.
+- Add new custom option ~preview-leave-open-previews-visible~ which
+ determines if the preview code stays visible once opened.
- Support query and insert of ~mcite~ compatibility macro
(=style/biblatex.el=).
- Support the =\verbatiminput*= macro (=style/verbatim.el=).
diff --git a/doc/preview-latex.texi b/doc/preview-latex.texi
index 07adc2a9..0c1fb730 100644
--- a/doc/preview-latex.texi
+++ b/doc/preview-latex.texi
@@ -672,6 +672,10 @@ accordingly @code{split} is one entry in
This boolean variable determines whether previews generated on top of the
current point should be temporarily opened. Default value is @code{nil}.
+@item preview-leave-open-previews-visible
+This boolean variable determines whether to leave preview images visible
+(above their generating TeX code) when they are opened.
+
@end vtable
@node The preview images, Misplaced previews, The Emacs interface, For
advanced users
diff --git a/preview.el.in b/preview.el.in
index 5e6b556c..1f65f728 100644
--- a/preview.el.in
+++ b/preview.el.in
@@ -1210,6 +1210,13 @@ is located."
(setcdr (car img) (cdar replacement))
(setcdr img (cdr replacement
+(defcustom preview-leave-open-previews-visible nil
+ "Whether to leave previews visible when they are opened.
+If nil, then the TeX preview icon is used when the preview is opened.
+If non-nil, then the preview image is moved above the text."
+ :group 'preview-appearance
+ :type 'boolean)
+
(defun preview-gs-place (ov snippet box run-buffer tempdir ps-file _imagetype)
"Generate an image placeholder rendered over by Ghostscript.
This enters OV into all proper queues in order to make it render
@@ -1231,7 +1238,21 @@ for the file extension."
(overlay-put ov 'queued
(vector box nil snippet))
(overlay-put ov 'preview-image
- (list (preview-icon-copy preview-nonready-icon)))
+ (let ((default (list (preview-icon-copy
preview-nonready-icon
+ (if preview-leave-open-previews-visible
+ (if-let ((img
+ (car
+(delq
+ nil
+ (mapcar
+ (lambda (ovr)
+(and
+ (eq (overlay-start ovr) (overlay-start
ov))
+ (overlay-get ovr 'preview-image)))
+ (overlays-at (overlay-start ov)))
+ img
+ default)
+ default)))
(preview-add-urgentization #'preview-gs-urgentize ov run-buffer)
(list ov))
@@ -1895,6 +1916,11 @@ Disable it if that is the case. Ignores text
properties."
text (overlay-get ov 'preview-prechange)))
(overlay-put ov 'insert-in-front-hooks nil)
(overlay-put ov 'insert-behind-hooks nil)
+(when (and preview-leave-open-previews-visible
+ (eq (overlay-get ov 'preview-state) 'active))
+ ;; This is so that remote commands, such as `undo',
+ ;; open active previews before disabling them.
+ (preview-toggle ov))
(preview-disable ov)
(error nil))
(overlay-put ov 'preview-prechange nil))
@@ -2190,10 +2216,12 @@ active (`transient-mark-mode'), it is run through
`preview-region'."
"Change overlay
Re: Making AUCTeX ELPA releases from the master branch
Tassilo Horn writes:
>> Our tarball build scripts can take care of building the Info files
>> and the `dir` (and moving them as needed), so maybe you can just add
>>
>> :manual ("doc/auctex.texi" "doc/preview-latex.texi")
>>
>> to the spec and that'll do the trick (with the advantage that the
>> manual will then also be made available at
>> `elpa.gnu.org/packages/doc/auctex.html`).
>
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make "all" did already
> build them (but at the "wrong" location)?
At least in my local tests, with
(auctex :url "https://git.savannah.gnu.org/git/auctex.git;
:news "NEWS.org"
:make "all"
:manual ("doc/auctex.texi" "doc/preview-latex.texi")
and then "make auctex.tar", the manuals & dir file are there only inside
doc/ where running :make "all" has generated them.
> That would be ok for me; I would also be willing to add a special elpa
> make target moving the files or generating another top-level dir file.
> But I certainly want the additional benefit of having the docs linked.
> Whatever is best for elpa.
Bye,
Tassilo
Re: Making AUCTeX ELPA releases from the master branch
Stefan Monnier writes:
>> Why would I need the date of the last release?
>
> Don't know. I guess I misundersood what you meant by:
>
> Instead of looking at specially formatted lines in ChangeLog, it
> just looks at the git diffs to check when there was a "+;;
> Version: ..." change in auctex.el. ...
>
> Why do you need to look at diffs?
In order to extract the version number. Previously that was extracted
from ChangeLog which relied on the exact wording of release commits.
>> Oh, no, one thing doesn't: the fine manuals. I've changed it so that
>> they stay in doc/ and there's also the dir file referencing the
>> auctex and preview-latex manual. Do they need to be top-level for
>> elpa (in which case I'd just add an elpa make target doing the move)
>> or can I somehow make that work?
>
> Indeed, they need to be moved: `package.el` won't see your manual if
> the `dir` is not in the top-level directory (and the Info viewer won't
> search in subdirs, so either you need the Info files to be at
> top-level or you need to change the `dir` file so it refers to
> `doc/auctex`).
Ok.
> Our tarball build scripts can take care of building the Info files and
> the `dir` (and moving them as needed), so maybe you can just add
>
> :manual ("doc/auctex.texi" "doc/preview-latex.texi")
>
> to the spec and that'll do the trick (with the advantage that the
> manual will then also be made available at
> `elpa.gnu.org/packages/doc/auctex.html`).
Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
build the docs again although the recipe's :make "all" did already build
them (but at the "wrong" location)?
That would be ok for me; I would also be willing to add a special elpa
make target moving the files or generating another top-level dir file.
But I certainly want the additional benefit of having the docs linked.
Whatever is best for elpa.
Bye,
Tassilo
