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.