Moving handlers out of desktop.el

Moving handlers out of desktop.el

[Lars Hansen]

For a long time it has annoyed me that desktop.el has pieces of code 
that really ought not be there. I am talking about the functions
   `desktop-buffer-dired'
   `desktop-buffer-rmail'
   `desktop-buffer-mh'
   `desktop-buffer-info'
that holds code specific to dired, rmail, mh and info respectively, and 
therefore ought to be in those modules. Not only does it IMHO look 
messy, it also makes it more likely that one of these modules are 
changed but desktop.el forgotten.

The reason that the functions above are in desktop.el is, I guess, the 
following: When the desktop module restores a buffer, i calls the 
functions in `desktop-buffer-handlers' until one returns a buffer. By 
default desktop-buffer-handlers holds the four functions above together 
with a more general function `desktop-buffer-file'. If the functions 
above were moved to the respective modules, these would have to be 
loaded prior to desktop, and that's not good.

The functions in `desktop-buffer-misc-functions' also belong in their 
respective modules (dired and info), but I think they can be moved 
without problems since they are called at desktop save.

How about this change:
1. Move the functions above to their respective modules and give each an 
autoload cookie.
    Also move the two in `desktop-buffer-misc-functions'.
2. Add in desktop.el a new variable `desktop-buffer-mode-handlers' with 
a default value like
    (('dired-mode . 'desktop-buffer-dired)
     ('rmail-mode . 'desktop-buffer-rmail)
     ('mh-folder-mode 'desktop-buffer-mh)
     ('Info-mode . 'desktop-buffer-info))
3. Replace in `desktop-buffer-handlers' the four functions above with a 
function `desktop-buffer-special-mode' looking in the alist above for a 
handler.

What do you think about this?

Lars

Re: Moving handlers out of desktop.el

[Juri Linkov]

Lars Hansen <larsh@math.ku.dk> writes:
> How about this change:
> 1. Move the functions above to their respective modules and give each
>    an autoload cookie.
>     Also move the two in `desktop-buffer-misc-functions'.
> 2. Add in desktop.el a new variable `desktop-buffer-mode-handlers'
>    with a default value like
>     (('dired-mode . 'desktop-buffer-dired)
>      ('rmail-mode . 'desktop-buffer-rmail)
>      ('mh-folder-mode 'desktop-buffer-mh)
>      ('Info-mode . 'desktop-buffer-info))
> 3. Replace in `desktop-buffer-handlers' the four functions above with
>    a function `desktop-buffer-special-mode' looking in the alist above
>    for a handler.
>
> What do you think about this?

This is somehow related to what is discussed on emacs-pretest-bug@gnu.org:
if `Info-mode' was able to set a literally visited Info file to Info mode,
then no handler would be needed in desktop.el, because just calling
`Info-mode' from `desktop-buffer-file' on a restored Info file would do
exactly what `desktop-buffer-info' currently does.

If all other special modes would do the same then no new variable like
`desktop-buffer-mode-handlers' will be needed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Moving handlers out of desktop.el

[Lars Hansen]

Juri Linkov wrote:

>if `Info-mode' was able to set a literally visited Info file to Info mode,
>then no handler would be needed in desktop.el, because just calling
>`Info-mode' from `desktop-buffer-file' on a restored Info file would do
>exactly what `desktop-buffer-info' currently does.
>
>If all other special modes would do the same then no new variable like
>`desktop-buffer-mode-handlers' will be needed.
>  
>
This is true for buffers visiting a file only. It would not work for 
dired buffers.

Re: Moving handlers out of desktop.el

[Juri Linkov]

Lars Hansen <larsh@math.ku.dk> writes:
> Juri Linkov wrote:
>>if `Info-mode' was able to set a literally visited Info file to Info mode,
>>then no handler would be needed in desktop.el, because just calling
>>`Info-mode' from `desktop-buffer-file' on a restored Info file would do
>>exactly what `desktop-buffer-info' currently does.
>>
>>If all other special modes would do the same then no new variable like
>>`desktop-buffer-mode-handlers' will be needed.
>>  
> This is true for buffers visiting a file only. It would not work for
> dired buffers.

Why not?  Calling (find-file-noselect directory-name) creates a buffer
in Dired mode.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Moving handlers out of desktop.el

[Lars Hansen]

>>This is true for buffers visiting a file only. It would not work for
>>dired buffers.
>>    
>>
>
>Why not?  Calling (find-file-noselect directory-name) creates a buffer
>in Dired mode.
>  
>
Ok, I get your point.

Re: Moving handlers out of desktop.el

[Lars Hansen]

>>> This is true for buffers visiting a file only. It would not work for
>>> dired buffers.
>>>   
>>
>>
>> Why not?  Calling (find-file-noselect directory-name) creates a buffer
>> in Dired mode.
>>  
>>
> Ok, I get your point.
>
But it is not as easy at that: The handler `desktop-buffer-dired' uses 
some extra data saved in the desktop buffer. This means that 
subdirectories inserted in the desktop buffer will be restored. You 
would loose that if  you just call (find-file-noselect directory-name).

Re: Moving handlers out of desktop.el

[Juri Linkov]

Lars Hansen <larsh@math.ku.dk> writes:
> How about this change:
> 1. Move the functions above to their respective modules and give each
>    an autoload cookie.
>     Also move the two in `desktop-buffer-misc-functions'.

I think moving the desktop functions AS IS to respective packages is
not good, because these packages shouldn't depend on the desktop package.
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.  Otherwise, if such generalization is not
possible, the current desktop implementation is good enough.

> 2. Add in desktop.el a new variable `desktop-buffer-mode-handlers'
>    with a default value like
>     (('dired-mode . 'desktop-buffer-dired)
>      ('rmail-mode . 'desktop-buffer-rmail)
>      ('mh-folder-mode 'desktop-buffer-mh)
>      ('Info-mode . 'desktop-buffer-info))
> 3. Replace in `desktop-buffer-handlers' the four functions above with
>    a function `desktop-buffer-special-mode' looking in the alist above
>    for a handler.

This could be done independently from the first item.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Moving handlers out of desktop.el

[Stefan Monnier]

>> 1. Move the functions above to their respective modules and give each
>> an autoload cookie.
>> Also move the two in `desktop-buffer-misc-functions'.

> I think moving the desktop functions AS IS to respective packages is
> not good, because these packages shouldn't depend on the desktop package.

They wouldn't depend on desktop AFAIK.  They'd simply provide some help to
desktop (i.e. "add support for desktop"), just like many major modes setup
variables for outline-minor-mode or for font-lock or for ...


        Stefan

Re: Moving handlers out of desktop.el

[Lars Hansen]

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.

Re: Moving handlers out of desktop.el

[Juri Linkov]

Lars Hansen <larsh@math.ku.dk> writes:
> 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?

I believe the question whether to place these functions into a service
module or a client module is mostly a matter of taste.  The desktop
package at least currently consistently uses the former approach,
placing all mode handling functions in desktop.el.

But there are Emacs packages which are inconsistent in this question.
For example, why the speedbar package has the code for Info support
in info.el, but speedbar support for dired in speedbar.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.

For example, as you already noted, `desktop-buffer-dired' restores
subdirectories by inserting them in the dired buffer.  Instead
of the following code in desktop.el:

      (let* ((dired-dir (car desktop-buffer-misc))
	     (dir (if (consp dired-dir) (car dired-dir) dired-dir)))
	(if (file-directory-p (file-name-directory dir))
	    (progn
	      (dired dired-dir)
	      (mapcar 'dired-maybe-insert-subdir (cdr desktop-buffer-misc))
	      (current-buffer))
	  (message "Directory %s no longer exists." dir)
	  (sit-for 1)
	  'ignored))

it would be better to add a new argument SUBDIRECTORIES
to the `dired' function:

(dired DIRNAME &optional SWITCHES SUBDIRECTORIES)

and call from desktop.el only one dired function:

      (let* ((dired-dir (car desktop-buffer-misc))
	     (dir (if (consp dired-dir) (car dired-dir) dired-dir)))
	(dired dir nil (cdr desktop-buffer-misc)))

And the `(message "Directory %s no longer exists." dir)' is not needed
in desktop.el, because the function `dired' already raises an error.
Only desktop.el should have the code to catch this error and continue
to restore the rest of the desktop file.

So, I think the code for getting saved parameters from the desktop file
(like parsing the `desktop-buffer-misc' data) should belong to desktop.el.
And some code of desktop.el should be generalized and placed into
respective packages.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Moving handlers out of desktop.el

[Juri Linkov]

Juri Linkov <juri@jurta.org> writes:
> I believe the question whether to place these functions into a service
> module or a client module is mostly a matter of taste.  The desktop
> package at least currently consistently uses the former approach,
> placing all mode handling functions in desktop.el.
>
> But there are Emacs packages which are inconsistent in this question.
> For example, why the speedbar package has the code for Info support
> in info.el, but speedbar support for dired in speedbar.el?

dired is not a good example, since speedbar doesn't use functions from
dired package.  But speedbar.el uses imenu, etags, ange-ftp.  However,
this is not too wrong.  What actually is wrong is the speedbar related
code in info.el.  Polluting info.el with the code supporting all
packages that might use Info internal functions is too bad.  I think
all speedbar related code should be moved from info.el either to
speedbar.el or to a new file with the name like speedbar-info.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Moving handlers out of desktop.el

[Lars Hansen]

I have now moved handlers out of desktop and into the modules where they 
belong.
That applies to dired, info, rmail and mh-e.

The idea is as follows: The desktop module handles buffers visiting a 
file. For buffers not visiting a file, desktop needs help from the major 
mode module. The major mode module must define a function to restore 
desktop buffers, and the function must be listed in 
`desktop-buffer-mode-handlers'. If the major mode needs to save 
auxiliary information in the desktop file, it must also define a 
function returning that information and assign the function to the 
buffer local variable `desktop-buffer-misc-data-function' in the mode 
function.

Re: Moving handlers out of desktop.el

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> Lars Hansen <larsh@math.ku.dk> writes:
> > How about this change:
> > 1. Move the functions above to their respective modules and give each
> >    an autoload cookie.
> >     Also move the two in `desktop-buffer-misc-functions'.
> 
> I think moving the desktop functions AS IS to respective packages is
> not good, because these packages shouldn't depend on the desktop package.
> 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.  Otherwise, if such generalization is not
> possible, the current desktop implementation is good enough.

Except that it is not maintainable.  This thread started with a
complaint about that.

> > 2. Add in desktop.el a new variable `desktop-buffer-mode-handlers'
> >    with a default value like
> >     (('dired-mode . 'desktop-buffer-dired)
> >      ('rmail-mode . 'desktop-buffer-rmail)
> >      ('mh-folder-mode 'desktop-buffer-mh)
> >      ('Info-mode . 'desktop-buffer-info))
> > 3. Replace in `desktop-buffer-handlers' the four functions above with
> >    a function `desktop-buffer-special-mode' looking in the alist above
> >    for a handler.
> 
> This could be done independently from the first item.

But it does not make sense without putting the handlers where they
belong.  And where the byte compiler will warn if they are using bad
variables and so on.  And where they'll be autoloaded along with the
respective mode only when they are needed.

I find the original proposal much better.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Moving handlers out of desktop.el

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> This could be done independently from the first item.
>
> But it does not make sense without putting the handlers where they
> belong.  And where the byte compiler will warn if they are using bad
> variables and so on.  And where they'll be autoloaded along with the
> respective mode only when they are needed.

I agree with your arguments.  And just for the same reasons I suggested
to create generalized functions in respective modes.

Currently, mode handling functions in desktop.el have references
to desktop global variables desktop-buffer-misc, desktop-buffer-file-name,
desktop-buffer-name, etc.  These variables should stay in desktop.el.
And new mode handling functions should be created in respective modes
with no free references to desktop variables.  The values should be
given to these general functions only via function arguments.

-- 
Juri Linkov
http://www.jurta.org/emacs/