Re: Moving handlers out of desktop.el

[Lars Hansen <larsh@math.ku.dk>]

Juri Linkov wrote:

>I think moving the desktop functions AS IS to respective packages is
>not good, because these packages shouldn't depend on the desktop package.
>  
>
IMHO one module ought not "hack into" another module because such hacks 
are difficult to understand and may be broken unintentionally. OTOH it 
is OK and unavoidable that a module use "general services". I know very 
well that terms like "module", "hack into" and "general service" may be 
understood differently by different developers.
In my view, desktop "hacks into" four other modules, dired, rmail, mh 
and info. And I view desktop as a "general service".

Consider the following scenario. Actually, it is from real life (the 
user is me):
A user have made a module foo implementing foo-mode. He wants desktop 
saving for foo buffers but they do not visit a file. Thus he has to 
write a function `desktop-buffer-foo' and add it to 
`desktop-buffer-handlers' in his .emacs file. He wants the foo module to 
play together with Emacs out-of-the-box, so he cannot put 
`desktop-buffer-foo' into desktop.el. Instead he puts it into foo.el, 
which is natural since it is a foo related function. Now desktop is 
independent of foo, but foo depends on desktop since it uses desktop 
services. The only problem is that foo has to be loaded from .emacs to 
make `desktop-buffer-foo' available to the desktop module.

My question is: Why should `desktop-buffer-foo' be placed _outside_ 
desktop.el but the handlers for dired, rmail, mh and info _inside_ 
desktop.el?

>Making general functions (with an autoload cookie) from them would be
>good.  Such functions could have general arguments and be useful
>for other purposes as well.
>  
>
I don't think I understand what kind of functions you mean.

>This could be done independently from the first item.
>  
>
Yes, but I see no point in doing it.