bug#58005: 13.1.4; Can't work with indirect buffers

[Ikumi Keita]

Hi Vangelis,

>>>>> Vangelis Evangelou <evangelou@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