[Top][All Lists]

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

Re: 'make-comint' question

From: Thorsten Jolitz
Subject: Re: 'make-comint' question
Date: Wed, 31 Jul 2013 15:51:49 +0200
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux)

Tassilo Horn <> writes:

> Thorsten Jolitz <> writes:

Hi Tassilo,

>> I erase and save the buffer of an config-file for an external program
>> before applying 'make-comint on that program, and restore the file to
>> its old state afterwards:
>> #+begin_src emacs-lisp
>>   [...]
>>   (erase-config-file-for-external-process)
>>   (set-buffer
>>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>>   (rename-buffer "buffer-name")
>>   (restore-config-file-for-external-process)
>>   [...]
>> #+end_src
>> When I edebug my code, it does exactly what it should, and the new
>> inferior subprocess starts without the (unnecessary) configurations of
>> the erased config file, as it should.
>> However, when I simply run my code without debugging, the new inferior
>> subprocess starts _with_ the (unnecessary) configurations, what seems
>> quite strange to me.
>> Is there anything in the code example above that implies that the
>> execution order of the statements could be different from their
>> sequential ordering in the source-code?
> What's the definition of `erase-config-file-for-external-process'?
> Maybe it erases the config file asynchronously so that `make-comint' is
> called before it's erased?
> E.g., like in this contrieved example?
> (let ((f (make-temp-file "test")))
>   (shell-command (format "rm %s &" f))
>   (file-exists-p f)) ;; C-x C-e => t
> But why should you possibly do that?  `delete-file' should work as does
> moving the file away using `rename-file'...

No, the erasing is done with emacs lisp in a bit lengthy function, but here is
the simple logic in pseudo-code:


| Pseudo-code for
| `erase-config-file-for-external-process':

;; rename
rename-file "config-file" to "old-config-file"

;; after renaming, create new empty config file
with-current-buffer find-file-noselect "config-file"


but writing this, I found a possible source of the problem:

| (find-file-noselect FILENAME &optional NOWARN RAWFILE WILDCARDS)
| Read file FILENAME into a buffer and return the buffer.
| If a buffer exists visiting FILENAME, return that one, but
| verify that the file has not changed since visited or saved.

maybe I had an old buffer open that still showed the former content of
"config-file"? But even in this case, there should be a warning, and the
buffer would be erased anyway. 



reply via email to

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