all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Processing a file that may already be open
@ 2011-10-17  6:57 Sean McAfee
       [not found] ` <jwvobxfpvav.fsf-monnier+gnu.emacs.help@gnu.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Sean McAfee @ 2011-10-17  6:57 UTC (permalink / raw)
  To: help-gnu-emacs

I'd like to be able to write a routine that opens a file and reads it,
and potentially modifies its contents and saves it back to disk.  The
slightly tricky bit is that if there are any open buffers visiting that
file, they should be updated immediately.  (I don't want to modify the
file behind any buffers' backs, that is.)

I've written the following macro to encapsulate what seems to be the
necessary logic:

(defmacro with-visited-file (path &rest body)
  (let ((retain (gensym))
        (buffer (gensym)))
    `(let* ((,retain (find-buffer-visiting ,path))
            (,buffer (find-file ,path)))
       (unwind-protect
           (save-excursion
             (save-restriction
               (widen)
               (beginning-of-buffer)
               ,@body))
         (or ,retain (kill-buffer ,buffer))))))

It seems to work okay, but are there any lurking gotchas?  Or, is there
any better approach?


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Processing a file that may already be open
       [not found] ` <jwvobxfpvav.fsf-monnier+gnu.emacs.help@gnu.org>
@ 2011-10-18  6:45   ` Sean McAfee
  0 siblings, 0 replies; 2+ messages in thread
From: Sean McAfee @ 2011-10-18  6:45 UTC (permalink / raw)
  To: help-gnu-emacs

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (defmacro with-visited-file (path &rest body)
[...]

> - use make-symbol rather than gensym: it's faster, doesn't pollute the
>   global symbol table (aka obarray), and doesn't rely on CL.

gensym is just a thin wrapper around make-symbol; how could it pollute
the global symbol table?

I usually prefer gensym because I don't like to be obliged to give the
new symbol a name.  I don't care what it's named.  And I don't mind
relying on CL.  It's the closest I get to being able to use Common Lisp
on a regular basis.

> - avoid evaluating "file" multiple times (in case the caller does
>   (with-visited-file (setq foo (concat foo ".el")) blabla))

Good point.

> - avoid find-file: find-file is a user-level command, Elisp code should
>   use find-file-noselect instead.  find-file will call switch-to-buffer
>   to display the buffer, which can fail or pop up a new window or a new
>   frame, none of which we want to see happen here.

Also a good point.  Thanks.

There's still a few minor issues to be worked out, though.  Like, should
I save the buffer after editing it?  Obviously yes, if the buffer didn't
exist before.  But if any buffers were already visiting the file, I
should probably only save it if none of them have been modified since
the file was last saved.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-10-18  6:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-17  6:57 Processing a file that may already be open Sean McAfee
     [not found] ` <jwvobxfpvav.fsf-monnier+gnu.emacs.help@gnu.org>
2011-10-18  6:45   ` Sean McAfee

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.