[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 <tsdh@gnu.org> writes:
> Thorsten Jolitz <tjolitz@gmail.com> 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:
#+begin_quote
,------------------------------------------
| 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"
erase-buffer
save-buffer
kill-buffer
#+end_quote
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.
hmm...strange
--
cheers,
Thorsten