auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Output filenames and the inconsistency of the `file` variable


From: Ikumi Keita
Subject: Re: Output filenames and the inconsistency of the `file` variable
Date: Wed, 26 Aug 2020 22:46:02 +0900

Hi Al,

>>>>> Al Haji-Ali <abdo.haji.ali@gmail.com> writes:
> The documentation of `TeX-view-program-list` does not mention `file`
> as a variable. So from this perspective, IMO it is justifiable to
> normalize the treatment of this variable.

I don't have strong objection about this perspective.

> With that being said, I understand that this could break some user
> configs that use undocumented variables.

For historical reason (again), AUCTeX has been permissive for such abuse
of dynamic scope variables in users' customization because it directs to
use undeclared dynamic scope variables in, e.g., hooks in
LaTeX-section-hook and TeX-arg-* functions used in TeX-parse-macro. So
in general we have to anticipate that some users use undocumented
variable `file' in their costom functions when we try to be very
conservative. I admit it's unfortunate but I suppose such care wouldn't
be dispensible.

> Although I would argue that changing the name of the variable (as the
> thread you linked earlier suggests) would also break these configs.

Yes. That must be the reason why Tassilo is very cautious in the thread
about carrying out such changes. When AUCTeX finally move to lexical
scope, it should be clearly advertised to users that those
dynamically-scoped variabales are no longer valid and AUCTeX should be
careful so that the cost of rewriting such code to conform to lexical
scoping would be reasonably low.

>> How about using functionp test or stringp test on the value of `file'
>> for the changes in TeX-pdf-tools-sync-view and TeX-evince-sync-view-1?
>> That would be rather safe way although there still remains doubled
>> identity, function name and string, of the variable `file'...
>> 
> I am not sure how to do this using `functionp` and `stringp`. The
> problem is the value of `file` is overwritten in `TeX-command` before
> the program is called so in `TeX-pdf-tools-sync-view` and
> `TeX-evince-sync-view-1` the function value of `file` is inaccessible.

Ah, then my assumption wasn't right. I guessed that you want to call
TeX-pdf-tools-sync-view or TeX-evince-sync-view-1 with `file' bound to
function name such as TeX-master-file or TeX-region-file, so I presumed
that it would be a low-cost hack to make those functions work with
whichever value of the variable `file', a function name or a string.

> One way to not break any past behavior would be to introduce a new
> dynamically-scoped variable `file-fn` that always has the function
> value. Although I am not sure if introducing yet another dynamically
> scoped variable is a good solution long-term.

Agreed.

>> Another possible idea is to stop relying on dynamic scope variable
>> `file' and just to call TeX-active-master in TeX-pdf-tools-sync-view and
>> TeX-evince-sync-view-1. My understanding is that TeX-active-master
>> serves for such purposes for most cases.
>> 
> This is what I thought at first. However, according to comments in
> tex.el, `file` can be `TeX-master-file', `TeX-region-file' or
> `TeX-active-master'.

TeX-active-master just calls TeX-master-file or TeX-region-file
depending on the value of TeX-current-process-region-p, which is set
early stage in TeX-command. So TeX-active-master would usually be a
drop-in replacement for TeX-master-file and TeX-region-file as long as
it is called inside TeX-command.

Best,
Ikumi Keita



reply via email to

[Prev in Thread] Current Thread [Next in Thread]