GNU bug report logs - #58005
13.1.4; Can't work with indirect buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58005 in the body.
You can then email your comments to 58005 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Philipp G. Haselwarter" <philipp <at> haselwarter.org>
To: bug-auctex <at> gnu.org
Subject: 13.1.4; Can't work with indirect buffers
Date: Thu, 22 Sep 2022 14:26:04 +0200

Hi,

I often find myself jumping from latex to the current position in the
pdf via `pdf-sync-forward-search' from pdf-tools. This does not work
when the buffer I am editing is an indirect buffer, like what you get
from `C-x 4 c', i.e. `clone-indirect-buffer-other-window'.

In particular, `TeX-master-file' and `TeX-strip-extension' in `tex.el'
use `buffer-file-name', which reports `nil' in indirect buffers. One
solution would be to use `ff-buffer-file-name' from `find-file.el'
instead, which behaves correctly by returning the file name associated
to the `buffer-base-buffer' of an indirect buffer.  Or maybe simply
calling `(buffer-file-name (buffer-base-buffer))' would do.

Best regards,
Philipp

Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.17.6)
 of 2022-09-14
Package: 13.1.4

current state:
==============
(setq
 AUCTeX-date "2022-08-26"
 window-system 'pgtk
 LaTeX-version "2e"
 TeX-style-path '("~/.emacs.d/auctex"
                  "/home/philipp/.emacs.d/elpa/auctex-13.1.4/style"
                  "/home/philipp/.emacs.d/auctex/auto"
                  "/home/philipp/.emacs.d/auctex/style" "auto" "style")
 TeX-auto-save nil
 TeX-parse-self nil
 TeX-master t
 TeX-command-list '(("LatexMk"
                     "latexmk %(-PDF)%S%(mode) %(file-line-error)
%(extraopts) %t"
                     TeX-run-latexmk nil
                     (plain-tex-mode latex-mode doctex-mode) :help
                     "Run LatexMk")
                    ("LatexMk"
                     "latexmk %(-PDF)%S%(mode) %(file-line-error)
%(extraopts) %t"
                     TeX-run-latexmk nil
                     (plain-tex-mode latex-mode doctex-mode) :help
                     "Run LatexMk")
                    ("Skip" "skip" my-tex-skip nil t :help "Do nothing")
                    ("TeX"
                     "%(PDF)%(tex) %(file-line-error) %`%(extraopts)
%S%(PDFout)%(mode)%' %(output-dir) %t"
                     TeX-run-TeX nil
                     (plain-tex-mode ams-tex-mode texinfo-mode) :help
                     "Run plain TeX")
                    ("LaTeX" "%`%l%(mode)%' %T" TeX-run-TeX nil
                     (latex-mode doctex-mode) :help "Run LaTeX")
                    ("Makeinfo" "makeinfo %(extraopts) %(o-dir) %t"
                     TeX-run-compile nil (texinfo-mode) :help
                     "Run Makeinfo with Info output")
                    ("Makeinfo HTML"
                     "makeinfo %(extraopts) %(o-dir) --html %t"
                     TeX-run-compile nil (texinfo-mode) :help
                     "Run Makeinfo with HTML output")
                    ("AmSTeX"
                     "amstex %(PDFout) %`%(extraopts) %S%(mode)%'
%(output-dir) %t"
                     TeX-run-TeX nil (ams-tex-mode) :help "Run AMSTeX")
                    ("ConTeXt"
                     "%(cntxcom) --once --texutil %(extraopts) %(execopts)%t"
                     TeX-run-TeX nil (context-mode) :help "Run ConTeXt once")
                    ("ConTeXt Full" "%(cntxcom) %(extraopts) %(execopts)%t"
                     TeX-run-TeX nil (context-mode) :help
                     "Run ConTeXt until completion")
                    ("BibTeX" "bibtex %(O?aux)" TeX-run-BibTeX nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode context-mode)
                     :help "Run BibTeX")
                    ("Biber" "biber %(output-dir) %s" TeX-run-Biber nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Run Biber")
                    ("Texindex" "texindex %s.??" TeX-run-command nil
                     (texinfo-mode) :help "Run Texindex")
                    ("Texi2dvi" "%(PDF)texi2dvi %t" TeX-run-command nil
                     (texinfo-mode) :help "Run Texi2dvi or Texi2pdf")
                    ("View" "%V" TeX-run-discard-or-function t t :help
                     "Run Viewer")
                    ("Print" "%p" TeX-run-command t t :help "Print the file")
                    ("Queue" "%q" TeX-run-background nil t :help
                     "View the printer queue" :visible TeX-queue-command)
                    ("File" "%(o?)dvips %d -o %f " TeX-run-dvips t
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Generate PostScript file")
                    ("Dvips" "%(o?)dvips %d -o %f " TeX-run-dvips nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Convert DVI file to PostScript")
                    ("Dvipdfmx" "dvipdfmx -o %(O?pdf) %d" TeX-run-dvipdfmx
                     nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Convert DVI file to PDF with dvipdfmx")
                    ("Ps2pdf" "ps2pdf %f %(O?pdf)" TeX-run-ps2pdf nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Convert PostScript file to PDF")
                    ("Glossaries" "makeglossaries %(d-dir) %s"
                     TeX-run-command nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Run makeglossaries to create glossary file")
                    ("Index" "makeindex %(O?idx)" TeX-run-index nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Run makeindex to create index file")
                    ("upMendex" "upmendex %(O?idx)" TeX-run-index t
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Run upmendex to create index file")
                    ("Xindy" "texindy %s" TeX-run-command nil
                     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
                      texinfo-mode)
                     :help "Run xindy to create index file")
                    ("Check" "lacheck %s" TeX-run-compile nil (latex-mode)
                     :help "Check LaTeX file for correctness")
                    ("ChkTeX" "chktex -v6 %s" TeX-run-compile nil
                     (latex-mode) :help
                     "Check LaTeX file for common mistakes")
                    ("Spell" "(TeX-ispell-document \"\")" TeX-run-function
                     nil t :help "Spell-check the document")
                    ("Clean" "TeX-clean" TeX-run-function nil t :help
                     "Delete generated intermediate files")
                    ("Clean All" "(TeX-clean t)" TeX-run-function nil t
                     :help "Delete generated intermediate and output files")
                    ("Other" "" TeX-run-command t t :help
                     "Run an arbitrary command")
                    )
 )
-- 
Philipp G. Haselwarter

Message #8 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: "Philipp G. Haselwarter" <philipp <at> haselwarter.org>
Cc: 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Thu, 08 Dec 2022 19:47:56 +0900

Hi Philipp, very sorry for such a long delay to reply.

>>>>> "Philipp G. Haselwarter" <philipp <at> haselwarter.org> writes:
> Hi,
> I often find myself jumping from latex to the current position in the
> pdf via `pdf-sync-forward-search' from pdf-tools. This does not work
> when the buffer I am editing is an indirect buffer, like what you get
> from `C-x 4 c', i.e. `clone-indirect-buffer-other-window'.

> In particular, `TeX-master-file' and `TeX-strip-extension' in `tex.el'
> use `buffer-file-name', which reports `nil' in indirect buffers. One
> solution would be to use `ff-buffer-file-name' from `find-file.el'
> instead, which behaves correctly by returning the file name associated
> to the `buffer-base-buffer' of an indirect buffer.  Or maybe simply
> calling `(buffer-file-name (buffer-base-buffer))' would do.

I don't use indirect buffer, so please bear with me if I'm missing
points. So far AUCTeX didn't pay attention to indirect buffers, so I'm
afraid that numerous potential inconsistencies remain there even if your
suggestion is incorporated. For that reason, I'm reluctant to go in a
direction to tame AUCTeX to work properly with indirect buffers. Why do
you edit in an indirect buffer? (Even if there is good reason to do so,
I feel that it's enough to make C-c C-c (and similar commands) ask
whether to switch to base buffer when you are in indirect buffer.)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #11 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: "Philipp G. Haselwarter" <philipp <at> haselwarter.org>
Cc: 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Fri, 09 Dec 2022 18:20:24 +0900

Hi Philipp, please keep "Cc: 58005 <at> debbugs.gnu.org" when you reply so
that the thread of the discussion remain in the bug tracker.

>>>>> "Philipp G. Haselwarter" <philipp <at> haselwarter.org> writes:
> Dear Keita,
> Thank you for looking into this issue.

> I frequently use indirect buffers when editing longer tex documents.
> When I need to modify more than one part of a document at a time,
> I split the base buffer via C-x 4 c `clone-indirect-buffer-other-window`.
> This has the advantage that each view of the buffer has its own notion
> of region, point, and marks. Frankly, I'd be surprised if this didn't affect
> a fairly large number of users, as C-x 4 c is bound in vanilla Emacs.

> The `(buffer-file-name (buffer-base-buffer))` pattern is pretty common,
> for instance a simple grep in the emacs repo yields 58 hits alone, so I
> think it's a reasonable solution. I would of course be happy to test and
> report any other related issues that may arise.

Thank you for your reply. It's probably true that `buffer-base-buffer'
makes `buffer-file-name' usable in indirect buffers. However, what I'm
worrying is that other potential incompatibilities sparsely continue to
pop up and each ad-hoc deal eventually amounts to make AUCTeX unstable,
given a lot of subtlety regarding to `TeX-master-file'.[1]

Any takers out there? (My preliminary idea is, as I wrote in my previous
message, to modify C-c C-c and alikes so that they suggest to switch to
the base buffer and run there when they are called in an indirect
buffer.)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[1] Thread titled "Output to directory patch" in
https://lists.gnu.org/archive/html/auctex-devel/2021-02/threads.html
https://lists.gnu.org/archive/html/auctex-devel/2021-03/threads.html

Message #14 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58005 <at> debbugs.gnu.org, "Philipp G. Haselwarter" <philipp <at> haselwarter.org>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Thu, 07 Mar 2024 21:40:00 +0100

Ikumi Keita <ikumi <at> ikumi.que.jp> writes:

> Hi Philipp, please keep "Cc: 58005 <at> debbugs.gnu.org" when you reply so
> that the thread of the discussion remain in the bug tracker.
>
>>>>>> "Philipp G. Haselwarter" <philipp <at> haselwarter.org> writes:
>> Dear Keita,
>> Thank you for looking into this issue.
>
>> I frequently use indirect buffers when editing longer tex documents.
>> When I need to modify more than one part of a document at a time,
>> I split the base buffer via C-x 4 c `clone-indirect-buffer-other-window`.
>> This has the advantage that each view of the buffer has its own notion
>> of region, point, and marks. Frankly, I'd be surprised if this didn't affect
>> a fairly large number of users, as C-x 4 c is bound in vanilla Emacs.
>
>> The `(buffer-file-name (buffer-base-buffer))` pattern is pretty common,
>> for instance a simple grep in the emacs repo yields 58 hits alone, so I
>> think it's a reasonable solution. I would of course be happy to test and
>> report any other related issues that may arise.
>
> Thank you for your reply. It's probably true that `buffer-base-buffer'
> makes `buffer-file-name' usable in indirect buffers. However, what I'm
> worrying is that other potential incompatibilities sparsely continue to
> pop up and each ad-hoc deal eventually amounts to make AUCTeX unstable,
> given a lot of subtlety regarding to `TeX-master-file'.[1]

I agree, the "indirect buffers" feature is provided by vanilla Emacs,
but trying to support it inside AUCTeX may introduce a lot a headache.
I also vote not try to implement it.

> Any takers out there? (My preliminary idea is, as I wrote in my previous
> message, to modify C-c C-c and alikes so that they suggest to switch to
> the base buffer and run there when they are called in an indirect
> buffer.)

Patches are always welcome.  But for now, I'm closing this report.  We
can reopen if there are complete patches to discuss.

Best, Arash

Message #25 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: philipp <at> haselwarter.org, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Mon, 15 Apr 2024 00:01:32 +0900

Hi Vangelis,

>>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:
> I am using indirect buffers with auctex and I am affected by this. My use
> is to have an indirect buffer narrowed to the preamble of my file.
> Typically, if I want to define a new command, I switch to the narrowed
> buffer instead of jumping at the top of the buffer to type the command and
> then go back to where I was later. I implemented a patch (attached) where,
> essentially, I replace instances of `buffer-file-name' with a new function
> `TeX-buffer-file-name' defined as

> (defun TeX-buffer-file-name (&optional BUFFER)
>   (buffer-file-name (or (buffer-base-buffer BUFFER) BUFFER)))

Thank you for your proposal. I'd like to comment on it. Please bear with
me if I'm saying something stupid since I don't know indirect buffer well.

Current AUCTeX source has some references to the variable
`buffer-file-name', as well as call to the function of the same name. It
seems that the variable is nil in indirect buffers. Is it safe to leave
those references unchanged?

> I also added a condition in TeX-master-file to check for indirect
> buffer.

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?

There are still some calls to the function `buffer-file-name' which
weren't replaced by `TeX-buffer-file-name' in the source. You can see
them with
git grep -E "[^-]buffer-file-name"
on the repo directory. (This lists references to the variable
`buffer-file-name' as well.)

It seems that the proposed change doesn't work in indirect buffer if
`TeX-output-dir' is specified. To try:
1. Open the following file.
2. Type C-x 4 c
3. Type C-c C-c RET
4. Then AUCTeX signals error with "LaTeX errors in ‘*~/test-tex/<none> output*’. Use C-c ` to display."
Can you resolve this problem?
----------------------------------------------------------------------
\documentclass{article}
\begin{document}

dummy

\end{document}

%%% Local Variables:
%%% mode: LaTeX
%%% TeX-master: t
%%% TeX-output-dir: "build"
%%% End:
----------------------------------------------------------------------

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #28 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org,
 philipp <at> haselwarter.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Mon, 15 Apr 2024 00:08:52 +0900

>>>>> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
> . 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?

Sorry, I meant "first" here actually, rather than "second".

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #31 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: philipp <at> haselwarter.org, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Mon, 15 Apr 2024 10:48:02 +0100

[Message part 1 (text/plain, inline)]

Hi Ikumi.

Thank you for your email.

Current AUCTeX source has some references to the variable
> `buffer-file-name', as well as call to the function of the same name. It
> seems that the variable is nil in indirect buffers. Is it safe to leave
> those references unchanged?


You are correct. I can see a few cases:

./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.

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.

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.

I don't get the error that you mentioned. Can you please send me a
traceback?



On Sun, 14 Apr 2024 at 16:01, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> Hi Vangelis,
>
> >>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:
> > I am using indirect buffers with auctex and I am affected by this. My use
> > is to have an indirect buffer narrowed to the preamble of my file.
> > Typically, if I want to define a new command, I switch to the narrowed
> > buffer instead of jumping at the top of the buffer to type the command
> and
> > then go back to where I was later. I implemented a patch (attached)
> where,
> > essentially, I replace instances of `buffer-file-name' with a new
> function
> > `TeX-buffer-file-name' defined as
>
> > (defun TeX-buffer-file-name (&optional BUFFER)
> >   (buffer-file-name (or (buffer-base-buffer BUFFER) BUFFER)))
>
> Thank you for your proposal. I'd like to comment on it. Please bear with
> me if I'm saying something stupid since I don't know indirect buffer well.
>
> Current AUCTeX source has some references to the variable
> `buffer-file-name', as well as call to the function of the same name. It
> seems that the variable is nil in indirect buffers. Is it safe to leave
> those references unchanged?
>
> > I also added a condition in TeX-master-file to check for indirect
> > buffer.
>
> 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?
>
> There are still some calls to the function `buffer-file-name' which
> weren't replaced by `TeX-buffer-file-name' in the source. You can see
> them with
> git grep -E "[^-]buffer-file-name"
> on the repo directory. (This lists references to the variable
> `buffer-file-name' as well.)
>
> It seems that the proposed change doesn't work in indirect buffer if
> `TeX-output-dir' is specified. To try:
> 1. Open the following file.
> 2. Type C-x 4 c
> 3. Type C-c C-c RET
> 4. Then AUCTeX signals error with "LaTeX errors in ‘*~/test-tex/<none>
> output*’. Use C-c ` to display."
> Can you resolve this problem?
> ----------------------------------------------------------------------
> \documentclass{article}
> \begin{document}
>
> dummy
>
> \end{document}
>
> %%% Local Variables:
> %%% mode: LaTeX
> %%% TeX-master: t
> %%% TeX-output-dir: "build"
> %%% End:
> ----------------------------------------------------------------------
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
> #Gaza #StopMassiveKilling #CeasefireNOW
>

[Message part 2 (text/html, inline)]

Message #34 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: philipp <at> haselwarter.org, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Wed, 17 Apr 2024 23:23:02 +0900

Hi Vangelis,

>>>>> Vangelis Evangelou <evangelou <at> gmail.com> 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 (&optional 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 opens the base buffer first time and ready by the time
`TeX-master-file' is called in indirect buffer under usual
circumstances.

> I don't get the error that you mentioned. Can you please send me a
> traceback?

Sorry, my bad. It turned out that I was examining with code without your
patch. I confirmed that it actually runs without error. I apologize you.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #37 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 19:48:50 +0900

[ Please keep Cc: 58005 <at> debbugs.gnu.org when you reply so that the record remains in the bug tracker. ]

>>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:

> Regarding `TeX-master-file', I don't know what is the correct order that
> the various conditions need to be checked. There might be a situation where
> the file is shared between two master files. As far as I can tell, auctex
> allows for this by setting TeX-master to 'shared as a local variable. In
> that case you might want to have the main buffer set to one of the master
> files and the indirect buffer set to the other master file. Is that a
> desirable functionality? I personally don't use that options.

It isn't clear for me, too :-) In theory, base buffer and cloned buffer
can have different master file as you say and the user can make use of
that duality. However, the user must remember which buffer has which
master file in that case, between buffers with identical contents. That
doesn't seem a useful feature to me.

> I think there is a simpler way to approach this. We should have the
> function check at the beginning if the buffer is indirect, and switch
> temporarily to the base buffer before doing the rest of the operations.

This can be a solution, indeed.

> This is perhaps simpler, but does not allow for the situation I mentioned
> above with the two masters. The way to do that is with
>   (with-current-buffer
>      (or (buffer-base-buffer) (current-buffer)))
> at the beginning of the function. There is also another function that is
> affected: `TeX-normal-mode' which calls `normal-mode'. In the documentation
> is says:
> If invoked in a buffer that doesn’t visit a file, this function
> processes only the major mode specification in the -*- line and
> the local variables spec.
> I found that it doesn't correctly set the local variables if
> TeX-normal-mode is run on the indirect buffer.

OK.

> I attach the updated patch. I have tested this, and it works for me. Please
> let me know what you think.

A brief testing didn't show fatal behavior. Here are two notes I noticed:
1. In indirect buffer, preview-latex doesn't work. All preview images
   appear in the base buffer.
2. TeX Fold mode works independently in indirect and base buffers.

I suppose there will be dissatisfied users about item 1. Do you have any
good idea about it?
Item 2 can be a useful feature rather than a shortcoming, whereas some
users want to inherit the folded appearance when they clone a buffer.

Maybe we should regard these points as feature and announce them as
"known limitations".

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #40 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 13:08:08 +0200

> A brief testing didn't show fatal behavior. Here are two notes I noticed:
> 1. In indirect buffer, preview-latex doesn't work. All preview images
>    appear in the base buffer.
> 2. TeX Fold mode works independently in indirect and base buffers.
>
> I suppose there will be dissatisfied users about item 1. Do you have any
> good idea about it?
> Item 2 can be a useful feature rather than a shortcoming, whereas some
> users want to inherit the folded appearance when they clone a buffer.
>
> Maybe we should regard these points as feature and announce them as
> "known limitations".
>

I'd be happy to take a quick look at this if I could see the patch in
question.  (I've been using indirect buffers with my local copy of
preview-latex for years.  The key point, if I recall correctly, was to
trick "preview-region" into thinking it's being called in "non-file"
mode, so that "<none>" gets passed along to preview-parse-messages and
hence the previews are placed (correctly) in the command buffer rather
than (incorrectly, as you've observed here) in the buffer with the
same name as the master file.)

Message #43 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: ultrono <at> gmail.com, 58005 <at> debbugs.gnu.org, Ikumi Keita <ikumi <at> ikumi.que.jp>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 12:23:35 +0100

[Message part 1 (text/plain, inline)]

Sorry, I forgot to reply all in my previous email. The patch is attached
here.

---- Original message ----

Hi Ikumi.

Sorry I missed preview.el.in. Yes, I can change that too.

Regarding `TeX-master-file', I don't know what is the correct order that
the various conditions need to be checked. There might be a situation where
the file is shared between two master files. As far as I can tell, auctex
allows for this by setting TeX-master to 'shared as a local variable. In
that case you might want to have the main buffer set to one of the master
files and the indirect buffer set to the other master file. Is that a
desirable functionality? I personally don't use that options.

I think there is a simpler way to approach this. We should have the
function check at the beginning if the buffer is indirect, and switch
temporarily to the base buffer before doing the rest of the operations.
This is perhaps simpler, but does not allow for the situation I mentioned
above with the two masters. The way to do that is with
  (with-current-buffer
     (or (buffer-base-buffer) (current-buffer)))
at the beginning of the function. There is also another function that is
affected: `TeX-normal-mode' which calls `normal-mode'. In the documentation
is says:
If invoked in a buffer that doesn’t visit a file, this function
processes only the major mode specification in the -*- line and
the local variables spec.
I found that it doesn't correctly set the local variables if
TeX-normal-mode is run on the indirect buffer.

I attach the updated patch. I have tested this, and it works for me. Please
let me know what you think.

On Wed, 17 Apr 2024 at 15:23, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> Hi Vangelis,
>
> >>>>> Vangelis Evangelou <evangelou <at> gmail.com> 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 (&optional 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 opens the base buffer first time and ready by the time
> `TeX-master-file' is called in indirect buffer under usual
> circumstances.
>
> > I don't get the error that you mentioned. Can you please send me a
> > traceback?
>
> Sorry, my bad. It turned out that I was examining with code without your
> patch. I confirmed that it actually runs without error. I apologize you.
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
> #Gaza #StopMassiveKilling #CeasefireNOW
>

[Message part 2 (text/html, inline)]

[indirect2.patch (application/x-patch, attachment)]

Message #46 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 13:30:10 +0200

> Sorry, I forgot to reply all in my previous email. The patch is attached here.
>

Sorry to turn this thread into "git tech support", but when I try
applying this patch using "magit-apply", I get the error:

 128 git … am --3way --
/Users/au710211/.emacs.d/elpaca/repos/auctex/indirect2.patch
Patch format detection failed.

Could you tell me what steps to follow to apply it?

Message #49 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: Paul Nelson <ultrono <at> gmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 13:13:52 +0100

[Message part 1 (text/plain, inline)]

Can you try the following command on terminal? Replace auctex-dir below
with our auctex directory.
patch -ruN -d auctex-dir < indirect2.patch

On Tue, 23 Apr 2024 at 12:30, Paul Nelson <ultrono <at> gmail.com> wrote:

> > Sorry, I forgot to reply all in my previous email. The patch is attached
> here.
> >
>
> Sorry to turn this thread into "git tech support", but when I try
> applying this patch using "magit-apply", I get the error:
>
>  128 git … am --3way --
> /Users/au710211/.emacs.d/elpaca/repos/auctex/indirect2.patch
> Patch format detection failed.
>
> Could you tell me what steps to follow to apply it?
>

[Message part 2 (text/html, inline)]

Message #52 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 14:21:17 +0200

> Can you try the following command on terminal? Replace auctex-dir below with our auctex directory.
> patch -ruN -d auctex-dir < indirect2.patch

I'm trying this from the latest origin/master, but happy to try
something else if you think that'd be a good idea.

auctex % patch -ruN -d . < indirect2.patch

patch -ruN -d . < indirect2.patch
patching file bib-cite.el
patching file latex.el
Hunk #1 succeeded at 2569 (offset 8 lines).
Hunk #2 succeeded at 2590 (offset 8 lines).
patching file preview.el.in
Hunk #1 succeeded at 3073 (offset 20 lines).
Hunk #2 FAILED at 4046.
1 out of 2 hunks FAILED -- saving rejects to file uN
can't find file to patch at input line 62
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ru auctex-13.3/style/catchfilebetweentags.el
auctex-13.3-modified/style/catchfilebetweentags.el
|--- auctex-13.3/style/catchfilebetweentags.el 2024-01-17
14:55:20.000000000 +0000
|+++ auctex-13.3-modified/style/catchfilebetweentags.el 2024-04-15
15:05:27.480459053 +0100
--------------------------
File to patch:

Message #55 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Paul Nelson <ultrono <at> gmail.com>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 22:42:43 +0900

Hi,

>>>>> Paul Nelson <ultrono <at> gmail.com> writes:
>> Can you try the following command on terminal? Replace auctex-dir below with our auctex directory.
>> patch -ruN -d auctex-dir < indirect2.patch

> I'm trying this from the latest origin/master, but happy to try
> something else if you think that'd be a good idea.

> auctex % patch -ruN -d . < indirect2.patch

Vangelis'es patch doesn't apply straight to the current master. It
begins with
...
--- auctex-13.3/bib-cite.el          ...
+++ auctex-13.3-modified/bib-cite.el ...
...
, which means that he is playing with AUCTeX 13.3 source (probably,
installation from ELPA).

I used
patch -p1 < indirect2.patch
in the top directory of the local git repo and took care of the rejected
hunks manually.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #58 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 16:14:12 +0200

[Message part 1 (text/plain, inline)]

> I used
> patch -p1 < indirect2.patch
> in the top directory of the local git repo and took care of the rejected
> hunks manually.
>

Thanks Ikuya, I did this just now and tried the patch out (and have
attached the master-relative patch that I obtained after merging, in
case it's of convenience for anyone else).

For me, previews work fine in indirect buffers with this patch (based
on 20 mins of usage).  I don't see anything like what you described
(previews appearing in the base buffer).

If I undo the effects of the patch for bug#70307, then preview-latex
fails on indirect buffers when the master file does not appear in the
same folder as the current tex file, but that's also not quite what
you're encountering.

Paul

[0001-indirect2-patch.patch (application/x-patch, attachment)]

Message #61 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Paul Nelson <ultrono <at> gmail.com>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Wed, 24 Apr 2024 01:10:53 +0900

Hi Paul,

>>>>> Paul Nelson <ultrono <at> gmail.com> writes:
> For me, previews work fine in indirect buffers with this patch (based
> on 20 mins of usage).  I don't see anything like what you described
> (previews appearing in the base buffer).

Ah, I see. Thanks for confirmation. I didn't try region preview. The
previews do appear in the indirect buffer if I type C-c C-p C-b etc.

I expect you see what I described if you type C-c C-p C-d in the
indirect buffer.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #64 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Tue, 23 Apr 2024 18:34:37 +0200

Hi Ikumi,

> Ah, I see. Thanks for confirmation. I didn't try region preview. The
> previews do appear in the indirect buffer if I type C-c C-p C-b etc.
>
> I expect you see what I described if you type C-c C-p C-d in the
> indirect buffer.

OK, good -- we're on the same page then.

For whatever it's worth, in my opinion, this is the correct behavior:
preview-document should not be responsible for indirect buffers, a bit
like how it is not responsible for buffers having the given TeX-master
that do not appear \include'd in that TeX-master's source.


Paul

Message #67 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>, Paul Nelson <ultrono <at> gmail.com>
Cc: 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Wed, 24 Apr 2024 14:27:30 +0900

Hi Paul and Vangelis,

>>>>> Paul Nelson <ultrono <at> gmail.com> writes:
>> Ah, I see. Thanks for confirmation. I didn't try region preview. The
>> previews do appear in the indirect buffer if I type C-c C-p C-b etc.
>> 
>> I expect you see what I described if you type C-c C-p C-d in the
>> indirect buffer.

> OK, good -- we're on the same page then.

> For whatever it's worth, in my opinion, this is the correct behavior:
> preview-document should not be responsible for indirect buffers, a bit
> like how it is not responsible for buffers having the given TeX-master
> that do not appear \include'd in that TeX-master's source.

OK. Vangelis, what do you think about it? The same opinion?

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #70 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58005 <at> debbugs.gnu.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Wed, 24 Apr 2024 08:59:03 +0100

[Message part 1 (text/plain, inline)]

Hi all.

I'm not sure what the ideal outcome is. It depends on each user's case. In
principle, indirect buffers have identical text content as their base
buffer, but different view properties, so the previews not showing in the
indirect buffer agrees with this principle. I therefore, agree with Paul's
comment.

On your comment:

> In theory, base buffer and cloned buffer can have different master file as
> you say and the user can make use of that duality. However, the user must
> remember which buffer has which master file in that case, between buffers
> with identical contents. That doesn't seem a useful feature to me.

This can be achieved by renaming the buffer accordingly, for example
file.tex<foo> has master foo.tex and file.tex<bar> has master bar.

Best,
Vangelis

On Wed, 24 Apr 2024 at 06:27, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> Hi Paul and Vangelis,
>
> >>>>> Paul Nelson <ultrono <at> gmail.com> writes:
> >> Ah, I see. Thanks for confirmation. I didn't try region preview. The
> >> previews do appear in the indirect buffer if I type C-c C-p C-b etc.
> >>
> >> I expect you see what I described if you type C-c C-p C-d in the
> >> indirect buffer.
>
> > OK, good -- we're on the same page then.
>
> > For whatever it's worth, in my opinion, this is the correct behavior:
> > preview-document should not be responsible for indirect buffers, a bit
> > like how it is not responsible for buffers having the given TeX-master
> > that do not appear \include'd in that TeX-master's source.
>
> OK. Vangelis, what do you think about it? The same opinion?
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
> #Gaza #StopMassiveKilling #CeasefireNOW
>

[Message part 2 (text/html, inline)]

Message #73 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: 58005 <at> debbugs.gnu.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Wed, 24 Apr 2024 18:56:58 +0900

Hi Vangelis,

>>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:
> Hi all.
> I'm not sure what the ideal outcome is. It depends on each user's case. In
> principle, indirect buffers have identical text content as their base
> buffer, but different view properties, so the previews not showing in the
> indirect buffer agrees with this principle. I therefore, agree with Paul's
> comment.

Thank you. Then I think AUCTeX can incorporate your proposal. Can you
make an entry for doc/changes.texi and send the diff? 

To AUCTeX admins: Do you think Vangelis'es patch needs copyright
assignment? In my opinion, it doesn't because definition of
`TeX-buffer-file-name' is straightforward and other changes are trivial
(replacements of `buffer-file-name' -> `TeX-buffer-file-name' or
additions of `(with-current-buffer (or (buffer-base-buffer)
(current-buffer))...')

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #76 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58005 <at> debbugs.gnu.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Thu, 25 Apr 2024 09:46:19 +0100

[Message part 1 (text/plain, inline)]

OK. I attach the diff.

On Wed, 24 Apr 2024 at 10:57, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> Hi Vangelis,
>
> >>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:
> > Hi all.
> > I'm not sure what the ideal outcome is. It depends on each user's case.
> In
> > principle, indirect buffers have identical text content as their base
> > buffer, but different view properties, so the previews not showing in the
> > indirect buffer agrees with this principle. I therefore, agree with
> Paul's
> > comment.
>
> Thank you. Then I think AUCTeX can incorporate your proposal. Can you
> make an entry for doc/changes.texi and send the diff?
>
> To AUCTeX admins: Do you think Vangelis'es patch needs copyright
> assignment? In my opinion, it doesn't because definition of
> `TeX-buffer-file-name' is straightforward and other changes are trivial
> (replacements of `buffer-file-name' -> `TeX-buffer-file-name' or
> additions of `(with-current-buffer (or (buffer-base-buffer)
> (current-buffer))...')
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
> #Gaza #StopMassiveKilling #CeasefireNOW
>

[Message part 2 (text/html, inline)]

[indirect-changes.diff (text/x-patch, attachment)]

Message #79 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: philipp <at> haselwarter.org, 58005 <at> debbugs.gnu.org,
 Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Fri, 26 Apr 2024 01:16:40 +0900

[ To philipp <at> haselwarter.org: I'm sorry, the thread began to fail to
include you in Cc:; It seems to reach a reasonable solution. ]

>>>>> Vangelis Evangelou <evangelou <at> gmail.com> writes:
> OK. I attach the diff.
> On Wed, 24 Apr 2024 at 10:57, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

Thanks, I added small adaptaion and a paragraph explaining the
preview-document behavior, and pushed to the git repo. I'll close this
bug.

>> To AUCTeX admins: Do you think Vangelis'es patch needs copyright
>> assignment? In my opinion, it doesn't because definition of
>> `TeX-buffer-file-name' is straightforward and other changes are trivial
>> (replacements of `buffer-file-name' -> `TeX-buffer-file-name' or
>> additions of `(with-current-buffer (or (buffer-base-buffer)
>> (current-buffer))...')

I committed with "Copyright-paperwork-exempt: yes".
 
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #82 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, Paul Nelson <ultrono <at> gmail.com>,
 58005 <at> debbugs.gnu.org, philipp <at> haselwarter.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Thu, 25 Apr 2024 18:56:57 +0200

Hi Keita,

Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
>
>>> To AUCTeX admins: Do you think Vangelis'es patch needs copyright
>>> assignment? In my opinion, it doesn't because definition of
>>> `TeX-buffer-file-name' is straightforward and other changes are trivial
>>> (replacements of `buffer-file-name' -> `TeX-buffer-file-name' or
>>> additions of `(with-current-buffer (or (buffer-base-buffer)
>>> (current-buffer))...')
>
> I committed with "Copyright-paperwork-exempt: yes".

Thanks for looking after this report and sorry for the late response.
Indeed, the change is large, but looking at the complexity, I think we
can let it pass without copyright assignment.

Also thanks to Vangelis for providing the change.

Best, Arash

Message #85 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Paul Nelson <ultrono <at> gmail.com>
To: Arash Esbati <arash <at> gnu.org>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, Ikumi Keita <ikumi <at> ikumi.que.jp>,
 58005 <at> debbugs.gnu.org, philipp <at> haselwarter.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Sat, 4 May 2024 23:19:31 +0200

[Message part 1 (text/plain, inline)]

Somewhere between when I tried Vangelis's patch (earlier in this
thread) and when it was installed, it seems that a further change was
made to preview-region that breaks previews in indirect buffers.
Specifically, the substitution buffer-file-name ->
(TeX-buffer-file-name) was applied where it shouldn't be.

The issue is as explained in my earlier email in this thread -- we
actually want "<none>" to be the filename when doing previews for
indirect buffers, so that preview-parse-messages ultimately places
them according to the command buffer rather than according to the
filename.  (It might clarify here to note that AFAIK, the "original"
argument to TeX-region-create is relevant only when doing
preview-document, which is irrelevant for indirect buffers.)

I've attached a patch reverting this particular substitution, so that
previews once again work in indirect buffers.

Thanks, best,

Paul

[0001-Fix-previews-in-indirect-buffers.patch (application/octet-stream, attachment)]

Message #88 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>, Vangelis Evangelou <evangelou <at> gmail.com>
Cc: 58005 <at> debbugs.gnu.org, philipp <at> haselwarter.org,
 Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Sat, 04 May 2024 23:25:34 +0200

Paul Nelson <ultrono <at> gmail.com> writes:

> Somewhere between when I tried Vangelis's patch (earlier in this
> thread) and when it was installed, it seems that a further change was
> made to preview-region that breaks previews in indirect buffers.
> Specifically, the substitution buffer-file-name ->
> (TeX-buffer-file-name) was applied where it shouldn't be.
>
> The issue is as explained in my earlier email in this thread -- we
> actually want "<none>" to be the filename when doing previews for
> indirect buffers, so that preview-parse-messages ultimately places
> them according to the command buffer rather than according to the
> filename.  (It might clarify here to note that AFAIK, the "original"
> argument to TeX-region-create is relevant only when doing
> preview-document, which is irrelevant for indirect buffers.)
>
> I've attached a patch reverting this particular substitution, so that
> previews once again work in indirect buffers.

@Keita and Vangelis: Any comments on Paul's proposal?

Best, Arash

Message #91 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Arash Esbati <arash <at> gnu.org>
Cc: Vangelis Evangelou <evangelou <at> gmail.com>, 58005 <at> debbugs.gnu.org,
 philipp <at> haselwarter.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Sun, 05 May 2024 12:04:06 +0900

Hi all,

>>>>> Arash Esbati <arash <at> gnu.org> writes:
> Paul Nelson <ultrono <at> gmail.com> writes:
>> Somewhere between when I tried Vangelis's patch (earlier in this
>> thread) and when it was installed, it seems that a further change was
>> made to preview-region that breaks previews in indirect buffers.
>> Specifically, the substitution buffer-file-name ->
>> (TeX-buffer-file-name) was applied where it shouldn't be.
>> 
>> The issue is as explained in my earlier email in this thread -- we
>> actually want "<none>" to be the filename when doing previews for
>> indirect buffers, so that preview-parse-messages ultimately places
>> them according to the command buffer rather than according to the
>> filename.  (It might clarify here to note that AFAIK, the "original"
>> argument to TeX-region-create is relevant only when doing
>> preview-document, which is irrelevant for indirect buffers.)
>> 
>> I've attached a patch reverting this particular substitution, so that
>> previews once again work in indirect buffers.

> @Keita and Vangelis: Any comments on Paul's proposal?

Hmm, sorry. Contrary to what I said before, the current master puts the
preview images in the base buffer for both document preview (C-c C-p
C-d) and region preview (C-c C-p C-r etc.). Maybe I was doing something
wrong. :-(

It seems to me that Paul's approach makes sense. I'd like to hear
Vangelis'es opinion.

Best regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW

Message #94 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Vangelis Evangelou <evangelou <at> gmail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 58005 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>,
 philipp <at> haselwarter.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Sun, 5 May 2024 20:30:12 +0100

[Message part 1 (text/plain, inline)]

Hi all. I agree with Paul. Sorry for the oversight. For some reason, in my
local installation, I have what Paul suggests, which is why I hadn't picked
it up when I submitted the patch.

On Sun, 5 May 2024 at 04:04, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:

> Hi all,
>
> >>>>> Arash Esbati <arash <at> gnu.org> writes:
> > Paul Nelson <ultrono <at> gmail.com> writes:
> >> Somewhere between when I tried Vangelis's patch (earlier in this
> >> thread) and when it was installed, it seems that a further change was
> >> made to preview-region that breaks previews in indirect buffers.
> >> Specifically, the substitution buffer-file-name ->
> >> (TeX-buffer-file-name) was applied where it shouldn't be.
> >>
> >> The issue is as explained in my earlier email in this thread -- we
> >> actually want "<none>" to be the filename when doing previews for
> >> indirect buffers, so that preview-parse-messages ultimately places
> >> them according to the command buffer rather than according to the
> >> filename.  (It might clarify here to note that AFAIK, the "original"
> >> argument to TeX-region-create is relevant only when doing
> >> preview-document, which is irrelevant for indirect buffers.)
> >>
> >> I've attached a patch reverting this particular substitution, so that
> >> previews once again work in indirect buffers.
>
> > @Keita and Vangelis: Any comments on Paul's proposal?
>
> Hmm, sorry. Contrary to what I said before, the current master puts the
> preview images in the base buffer for both document preview (C-c C-p
> C-d) and region preview (C-c C-p C-r etc.). Maybe I was doing something
> wrong. :-(
>
> It seems to me that Paul's approach makes sense. I'd like to hear
> Vangelis'es opinion.
>
> Best regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
> #Gaza #StopMassiveKilling #CeasefireNOW
>

[Message part 2 (text/html, inline)]

Message #97 received at 58005 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Vangelis Evangelou <evangelou <at> gmail.com>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, Paul Nelson <ultrono <at> gmail.com>,
 philipp <at> haselwarter.org, 58005 <at> debbugs.gnu.org
Subject: Re: bug#58005: 13.1.4; Can't work with indirect buffers
Date: Mon, 06 May 2024 07:24:56 +0200

Vangelis Evangelou <evangelou <at> gmail.com> writes:

> Hi all. I agree with Paul. Sorry for the oversight. For some reason,
> in my local installation, I have what Paul suggests, which is why I
> hadn't picked it up when I submitted the patch.

Thank you all for your comments.  I installed that change (0caa170649).

Best, Arash

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.