emacs-devel
[Top][All Lists]
Advanced

[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: Thu, 16 Jul 2009 21:56:53 -0700

Stefan,

I did initially solve this problem with 
(let ((buffer-file-name yaddayadda)) (normal-mode))

I wasn't happy with that because I assume
that the binding of buffer-file-name should
be one of: nil, a local file, a remote file.
I don't know what code distributed with
Emacs or what third party Emacs code would
break under other conditions.  That is 
why my patch adds buffer-automode-file-name.

LIST-BUFFERS-DESCRIPTION differs from ...-DIRECTORY
by being better named (so people won't 
assume it necessarily refers to a "directory")
and with a doc string.   I don't know
to what extent third party code assumes that
LIST-BUFFERS-DIRECTORY is, well, a directory 
and so I didn't want to overload it. 

I'm not clear on what you suggest I do about
coding systems.

-t




On Thu, 2009-07-16 at 23:08 -0400, Stefan Monnier wrote:
> > As earlier explained, I have the case of creating
> > a buffer with no visited file, yet I would like
> > to use (normal-mode) to set the mode AS IF the
> > name of the visited file was a particular string.
> 
> You'll probbaly also want to reuse the coding-system auto-detection, and
> maybe more.
> 
> > It was also pointed out to me that I should make
> > sure "list-buffers-noselect" puts something helpful
> > where a file name would usually go.
> 
> What's the difference between list-buffers-description and 
> list-buffers-directory?
> 
> > I have accordingly patched lisp/files.el and lisp/buf-menu.el.
> 
> I'm not completely convinced that buffer-automode-file-name is
> a good idea.  Why not just let-bind buffer-file-name instead?
> Also, if let-binding buffer-file-name is not good enough, maybe I'd
> rather see a refactoring of the code.
> 
> 
>         Stefan





reply via email to

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