desktop.el - only one desktop file per directory?

desktop.el - only one desktop file per directory?

[Drew Adams]

For anyone familiar with Desktop or its code -

(I tried contacting the author, but the email address for him in desktop.el is
apparently no longer valid.)

I haven't used desktop.el. I was thinking of using it from some Lisp code.
Looking over the code, it seems that it only allows for a single desktop file
per directory.

Is that right? If so, is it an important restriction (to maintain)?

With code I can of course create multiple desktop files in a dir. But
`desktop-read' seems to expect only one.

I guess I can plow through the `desktop-read' code and figure out which bits of
it I really need (beyond just calling `load' for the file). But I thought I'd
ask here first. Suggestions about which bits of the `desktop-read' code are
essential?

Is there a good reason that the basic functions don't just accept a (full) file
name (and potentially allow for multiple files per dir)?

Would the mere existence of more than one desktop file in some dir wreak havoc
with the normal use of Desktop (provided it is not pointed to such a dir and
thus left guessing)? Lock or owner problems, perhaps?

RE: desktop.el - only one desktop file per directory?

[Drew Adams]

I did come up with something that seems to work OK.

But if someone has answers to any of the questions I posed, I'd still be
interested.

In particular, I'd like to know more about the potential problems of ignoring
(i.e. just releasing) locks and loading the same or another desktop file. I'm
not turning on `desktop-save-mode' at all; I'm just saving (without locking) and
loading desktop files willy-nilly. ;-)

RE: desktop.el - only one desktop file per directory?

[Davis Herring]

> In particular, I'd like to know more about the potential problems of
> ignoring (i.e. just releasing) locks and loading the same or another
> desktop file.  I'm not turning on `desktop-save-mode' at all; I'm just
> saving (without locking) and loading desktop files willy-nilly. ;-)

The only problem that comes immediately to mind is that `desktop-read'
moves the buffers it creates (eagerly, which is often all of them) to the
front of the buffer list, which might be undesired.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: desktop.el - only one desktop file per directory?

[Drew Adams]

Thanks to Davis for his replies about this.

If I have any more questions (none for the moment), I now know whom to follow up
with.

Thx - Drew

Re: desktop.el - only one desktop file per directory?

[Davis Herring]

> For anyone familiar with Desktop or its code -

As a preliminary/cursory reply -

> (I tried contacting the author, but the email address for him in
> desktop.el is apparently no longer valid.)

I'm the maintainer for it now, I think.  I wrote the locking code, anyway.

> Is that right? If so, is it an important restriction (to maintain)?

You could let-bind `desktop-base-file-name', of course.  The reason it's
that way is basically the variable `desktop-path', so that Emacs can find
one of several desktop files (depending on the current directory) with
minimal user intervention.

> I guess I can plow through the `desktop-read' code and figure out
> which bits of it I really need (beyond just calling `load' for the
> file). But I thought I'd ask here first. Suggestions about which bits
> of the `desktop-read' code are essential?

If you ever have `desktop-restore-eager' non-t, the desktop file may just
set up requests to create buffers, and you'll still have to actually make
them.  You can just call `desktop-lazy-complete' to force it immediately.

> Is there a good reason that the basic functions don't just accept a (full)
> file name (and potentially allow for multiple files per dir)?

(See above.)

> Would the mere existence of more than one desktop file in some dir
> wreak havoc with the normal use of Desktop (provided it is not pointed
> to such a dir and thus left guessing)? Lock or owner problems,
> perhaps?

If it doesn't have the correct name, Desktop will obviously never know
it's there any more than it would any other random Elisp file.  Since
Desktop thinks there's just one per directory, it might cause an erroneous
lock collision if you were using a "real" desktop file and a faux desktop
file in the same directory, but you could just let-bind
`desktop-base-lock-name' (too) to avoid that.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.