[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] lisp/files.el and lisp/buf-menu.el
From: |
Thomas Lord |
Subject: |
Re: [PATCH] lisp/files.el and lisp/buf-menu.el |
Date: |
Fri, 17 Jul 2009 10:56:43 -0700 |
Stefan,
Thanks.
For buff-menu.el how would you feel about a patch
that:
Declares LIST-FILES-DIRECTORY obsolete.
Declares LIST-FILES-DIRECTORY to be an alias for
LIST-FILES-DESCRIPTION.
Otherwise renames LIST-FILES-DIRECTORY in lisp/*.el lisp/*/*.el
The other one, files.el and the case of BUFFER-FILE-MODE
vs. SET-AUTO-MODE: could we discuss that a little
further?
I get that PCL-CVS gets away with a let-binding
for BUFFER-FILE-MODE but that strikes me as a kludge
and a kludge with the potential to break things.
I think that third party code should be free to
assume that if BUFFER-FILE-MODE is not nil
then it is, as the name implies, the name of
a (potentially remote) file. I'm thinking
about, for example, what someone might put
in a mode hook in their ~/.emacs
At the same time, I'm apparently not the first
person that wants a mechanism to tweak what
SET-AUTO-MODE does by providing an override string
to use against the auto-mode alist. So,
I'm still kind of fond of the files.el patch
although, ultimately, of course, I defer to the
maintainers.
Finally,
> > I'm not clear on what you suggest I do about
> > coding systems.
> I'm just pointing out you may want to reuse more of the code used to
> open files, so it also obeys things like the -*- coding -*- tags as well
> as file-coding-system-alist.
I'll look into it.
-t