bug#70348: [PATCH] Make preview placement more flexible
Yes, good for me. Thanks > ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Paul Nelson writes: >> Sorry about that, I was sloppy in splitting up a commit. The fix is: > > In more detail, the "fix" is contained in the patch I submitted later > at #70442, and the issue arose when I split some commit into this > patch and that one. One way to proceed would be to squash those two > patches, if the latter looks OK. If you don't mind, I install this small change to fix the issue at hand: --8<---cut here---start->8--- diff --git a/preview.el.in b/preview.el.in index 5625d9c0..925ea3eb 100644 --- a/preview.el.in +++ b/preview.el.in @@ -3619,7 +3619,7 @@ name(\\([^)]+\\))\\)\\|\ tempdir (cdr open-data))) (ov (car ovl))) -(setq close-data (nconc ovl close-data)) +(setq close-data (nconc ovl close-data))) (with-current-buffer run-buffer (preview-log-error (list 'error --8<---cut here---end--->8--- and we can the go on and discuss the other patches. It will probably produce a little work at your end, but I hope you bear with me. Ok? Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
> Sorry about that, I was sloppy in splitting up a commit. The fix is: In more detail, the "fix" is contained in the patch I submitted later at #70442, and the issue arose when I split some commit into this patch and that one. One way to proceed would be to squash those two patches, if the latter looks OK. ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Sorry about that, I was sloppy in splitting up a commit. The fix is: (setq close-data (nconc ovl close-data)) -> (setq close-data (nconc ovl close-data))) If it's easier for you, I'm happy to resend the patch. ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Arash Esbati writes: > Paul Nelson writes: > >> See attached, and let me know if I missed anything else. > > Thanks for your swift response. I installed the change (e4def30851), > and closing. Bad news, AUCTeX doesn't build after this commit. The error is: In toplevel form: preview.el: Error: End of file during parsing make: *** [Makefile:249: lisp] Error 1 Can you please have another look? I think there is a closing paren mismatch. TIA. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70443: Keep track of when previews are being generated
This patch makes the following changes, having no effect on behavior: - The variable preview--region-begin, introduced in the fix to Bug#62445, is replaced with preview-current-region, which is a cons cell (begin . end) keeping track of the complete region. - That variable is set to nil in preview-parse-messages. The effect is to give a way for (e.g.) external packages to keep track of when and where previews are being generated. Thanks, best, Paul 0001-Keep-track-of-when-previews-are-being-generated.patch Description: Binary data ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70379: [PATCH] Make preview section commands preserve mark
Paul Nelson writes: > preview-section and preview-clearout-section activate the region, but > I don't think they should, hence this patch. Thanks, installed with commit 18a3dc7b, and closing. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70378: fixed patch
Paul Nelson writes: > I'm checking the other patches I sent to see if I messed any of them > up, and noticed that I did with this one. Attaching the fixed patch Thanks for checking Paul. I installed the last version with commit 2fe75e67, therefore closing this report. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70442: [PATCH] Open new previews when they cover point
Steps to reproduce: - Create test.tex with a valid equation environment. - Put the point inside the equation environment. - preview-buffer When the preview generates, the point is ejected from the equation environment due to the new overlay. With this patch, the preview instead temporarily opens, as if the user had entered it. I view the latter behavior as "clearly" better, but if I missed some advantage of the current approach or if my suggestion is deemed subjective, then I would be happy to resubmit the patch with this behavior enabled by a user option. Thanks, best, Paul 0001-Open-new-previews-when-they-cover-point.patch Description: Binary data ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70370: [PATCH] Add section folding commands
Paul Nelson writes: > This patch adds section folding commands, so as to bring the interface > for folding more in line with that for previewing. Thanks, installed with commit f61de0abe, and closing. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70378: fixed patch
I'm checking the other patches I sent to see if I messed any of them up, and noticed that I did with this one. Attaching the fixed patch 0001-Make-locating-previews.-message-configurable.patch Description: Binary data ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70369: [PATCH] Fix folding glitch with tmm disabled
Arash Esbati writes: > Again, can't apply the patch. Can you please try to fix as well? Scratch that, my bad, sorry. Installed with commit 5abc3d7f68. Thanks for your contribution. Closing. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70369: [PATCH] Fix folding glitch with tmm disabled
Whew, thanks. (I was about to respond with "Hmm, with this one, the patch works for me, and when I attempt to regenerate the patch using the latest fetch from master, the resulting patch is identical to the one that I had sent." Glad it worked out!) On Wed, Apr 17, 2024 at 10:35 PM Arash Esbati wrote: > > Arash Esbati writes: > > > Again, can't apply the patch. Can you please try to fix as well? > > Scratch that, my bad, sorry. Installed with commit 5abc3d7f68. Thanks > for your contribution. Closing. > > Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70369: [PATCH] Fix folding glitch with tmm disabled
Paul Nelson writes:
> Steps to reproduce:
> - Disable transient-mark-mode.
> - Create test.tex containing "\emph{foo} \emph{bar}".
> - Move point inside "foo" and set the mark (C-SPC). Note that this
> does not "activate the region".
> - TeX-fold-buffer (C-c C-o C-b).
> - Move the point into "bar".
>
> What should happen is that the second fold is revealed. Instead, both
> folds are revealed.
>
> The fix is to replace mark-active with (TeX-active-mark) inside
> TeX-fold-post-command.
>
> I looked for other places where "mark-active" was used incorrectly,
> and fixed a couple minor ones, involving menu entries.
Again, can't apply the patch. Can you please try to fix as well?
TIA. Best, Arash
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Paul Nelson writes: > See attached, and let me know if I missed anything else. Thanks for your swift response. I installed the change (e4def30851), and closing. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
See attached, and let me know if I missed anything else. Thanks, best, Paul 0001-Make-preview-placement-more-flexible.patch Description: Binary data ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Hi Arash, sorry, must have messed up - I’ll be happy to redo and resend it. Thanks, best, Paul ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#70348: [PATCH] Make preview placement more flexible
Hi Paul, Paul Nelson writes: > This patch has no effect on current behavior, but introduces a > variable preview-find-end-function that would allow (e.g.) an external > package to modify how previews overlays are placed, without resorting > to advice. > > The code needed to be rearranged a bit because the implementation of > preview-find-end-function that I have in mind requires the beginning > of the region as an argument, which thus needs to be computed outside > the argument list of preview-place-preview. > > This patch complements the preprocessing step introduced in bug#70295. > I'd be happy to supply more detailed motivation if that would be > helpful. I can't install the patch with 'git am' and get: Applying: Make preview placement more flexible error: patch failed: preview.el.in:3273 error: preview.el.in: patch does not apply Patch failed at 0001 Make preview placement more flexible Do have the chance to look at this and resolve this? Otherwise I'll have to have a closer look. TIA. Best, Arash ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#58005: 13.1.4; Can't work with indirect buffers
Hi Vangelis, > Vangelis Evangelou writes: > ./tex.el:2440: (and buffer-file-name > ./tex.el:2441: (file-name-directory buffer-file-name))) > In the above, I think that part of the code is in fact redundant. That's > because if the function's `expand-file-name' second argument is nil, then > it's taken to be the default-directory. Quoting from the help page: > Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative > (does not start with slash or tilde); both the directory name and > a directory’s file name are accepted. If DEFAULT-DIRECTORY is nil or > missing, the current buffer’s value of ‘default-directory’ is used. > NAME should be a string that is a valid file name for the underlying > filesystem. > So, with the current code, the second argument will be something like > /home/me/file.tex, while if nil, it is assumed to be /home/me/ which in the > end has the same effect. I can't imagine a situation where that's not the > case. I see. I agree with your argument. > For all other cases: > ./style/catchfilebetweentags.el:70: (buffer-file-name > (current-buffer) > ./style/pdfsync.el:40:(file-relative-name (buffer-file-name) > ./tex-info.el:707: (unless (file-exists-p > (buffer-file-name)) > ./toolbar-x.el:1465: (buffer-file-name > (buffer-base-buffer)) > ./toolbar-x.el:1469: :visible (or buffer-file-name > ./toolbar-x.el:1479::visible (or buffer-file-name > ./latex.el:2564: (let ((name (file-name-nondirectory buffer-file-name))) > ./latex.el:2585: (file-name-nondirectory buffer-file-name > I believe we can change buffer-file-name to (TeX-buffer-file-name) where > the file "tex.el" is loaded for consistency. The function with nil argument > has the same effect as the variable. I'm happy to make the changes to that > too if that's OK with you. Thanks, no problem. But note that preview.el.in (used as template to generate preview.el) has other references to `buffer-file-name' as well. I'd like you to have look at them, too. > The major portion of the addition is >> (cond >> [...] >> ;; Indirect buffer >> (my-buffer >> (with-current-buffer my-buffer >> (TeX-master-file nil nondirectory ask))) >> ^^^ >> . Why is the first argument always nil? The original function receives >> the second argument as `extension'. Aren't there cases that we should >> provide the same argument `extension' here? > As far as I understand the variable TeX-master always points to the name of > the file *without* the extension. That's why the first argument is nil. > Otherwise, if extension is say "pdf", then the TeX-master for the indirect > buffer will be something like "foo.pdf". The extension part is added later > in the code in the function TeX-master-file. After reading the surrounding code, I came to think that I should change the question. The function `TeX-master-file' has the following structure: -- (defun TeX-master-file ( extension nondirectory ask) [...] (save-excursion [...] ;; Indirect buffer (my-buffer (with-current-buffer my-buffer (TeX-master-file nil nondirectory ask))) [...] ;; Ask the user (but add it as a local variable). (ask (TeX-master-file-ask) <-- END OF `save-excursion' (let ((name (if (stringp TeX-master) [...] name <-- END OF `let' (and `defun') -- The return value of this function comes from the last `let' form; nothing returned in the `save-excursion' form are used. Hence `TeX-master-file' works as follows in indirect buffer if I understand correctly: (1) The added piece of code (TeX-master-file nil nondirectory ask))) runs in the base buffer. Its return value is just discarded, so it runs only for these side effects: (1a) Sets up `TeX-master', if not ready yet. (1b) Adds file local variables section when necessary. (2) The remaining `let' form runs in the indirect buffer to compute and return the file name associated with the base buffer, with possible extension. It seems that the `cond' clauses which set up `TeX-master' are skipped in indirect buffer except when this clause runs: -- ((and TeX-transient-master (or (not TeX-master) (eq TeX-master 'shared))) (setq TeX-master TeX-transient-master)) -- Are all these your intention? If so, it is reasonable to have fixed nil as the first argument in the above (1) because it is indeed irrelevant. On the other hand, I'm not sure the necessity of the above (1) itself; It seems to me that both (1a) and (1b) are to have been established when emacs
