Re: Onwards to lexical binding (attempt 1)

[Tassilo Horn]

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

>> I think `preview-region' should bind TeX-current-process-region-p
>> permanently by `setq', not `let', so that TeX-active-master returns
>> intended file name even in process sentinels.
>
> This incident made me aware that it has been long that AUCTeX lost the
> simultaneity, under certain condition, stated in the last sentence of
> this comment of tex-buf.el:
> ,----
> | ;; The general idea is, that there is one process and process buffer
> | ;; associated with each master file, and one process and process buffer
> | ;; for running TeX on a region.   Thus, if you have N master files, you
> | ;; can run N + 1 processes simultaneously.
> `----
> The reason is that sentinel functions `TeX-LaTeX-sentinel' and those in
> preview.el call `TeX-active-master', which depends on the global dynamic
> scope variable 'TeX-current-process-region-p'. Suppose that Alice types
> C-c C-c in a fairly large document.  The LaTeX process takes, say, 20
> seconds or more. Before it finishes, Alice spans a region in the buffer
> and types C-c C-r.
> Then 'TeX-current-process-region-p' is overwritten by that C-c C-r, thus
> `TeX-master-file', called in the process sentinel of the first process
> invoked by C-c C-c, doesn't work as expected.

Hm, isn't it actually even worse, i.e., Alice could compile one large
document and then compile/preview a region in some completely different
document?  AFAICS, `TeX-current-process-region-p' isn't even
buffer-local which would at least help with the "different documents"
case.

> What should we do? I don't think personally that this is a serious
> problem because it isn't much likely to run the master file process
> and the region file process in parallel in actual situation of editing
> LaTeX document.  In fact, it seems that nobody claimed about this
> problem in the past.

Yes, that's also my reasoning.

> So it's only a matter of inconsistency of comment in tex-buf.el and we
> can easily update the relavant sentence, IMHO.

Well, if we've had that working at some point in time, I'd say it would
be good if we could restore that.

But how did it work?  I mean, the sentinel function runs much later
outside of the dynamic scope of the command starting the process.  E.g.,
with

--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-

(defvar th/dynmamic-test-var "Default")

(defun th/test-process-sentinel ()
  (interactive)
  (let* ((p (start-process "foo" nil "sleep" "5"))
         (th/dynmamic-test-var "dyn bound value")
         (copy-of-cur-val th/dynmamic-test-var))
    (set-process-sentinel p (lambda (_p _s)
                              (message "th/dynmamic-test-var: %S
copy-of-cur-val: %S"
                                       th/dynmamic-test-var
                                       copy-of-cur-val)))
    (message "Started process %S" p)))
--8<---------------cut here---------------end--------------->8---

the sentinel function prints the value "Default" for
th/dynmamic-test-var (but "dyn boun value" for the closed over lexical
var copy-of-cur-val)...

> On the other hand, if this problem must be considered as a serious
> defect, then we should turn 'TeX-current-process-region-p' into a kind
> of "process local variable" like `TeX-command-next'.

I'd say it's not serious but we should address it anyway, and making it
local in the process buffer seems like a suitable approach.

Bye,
Tassilo