[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: read syntax for window configs

From: Drew Adams
Subject: RE: read syntax for window configs
Date: Sat, 6 Mar 2010 11:32:26 -0800

> > Read syntax for window (and frame) configs would be very welcome.
> >
> > Currently, we have things like desktop.el that save some 
> > session state, but they don't save window/frame configs.
> There is a task in etc/TODO:
>   ** Make desktop.el save the "frame configuration" of Emacs (in some
>     useful sense).

Better to separate that feature out. Have a separate feature (library) to save
window/frame configs. And then let desktop.el optionally make use of that
separate feature.

IOW, saving/restoring buffers, variables, etc. (what desktop does today) is
different from saving/restoring window/frame configs. There is no reason to
couple them by putting them in the same library - no reason to require code that
needs only one of the features to load a big library that does both.

> > FWIW, one of my libraries bookmarks desktops, so you can 
> > more easily switch among different contexts (desktop files).
> This looks like another task in etc/TODO:
>   ** Give desktop.el a feature to switch between different named
>     desktops.

Desktop has an unfortunate limitation (IMO) that is also, it seems, somewhat
gratuitous: It expects (and therefore pretty much requires) only one desktop
file per directory. All of the desktop.el functions are written that way - they
drive off of a directory name. 

That means that trying to use the desktop.el code to do something more flexible,
switching among arbitrary desktop files located anywhere, is ugly. My code has
to jump through some otherwise unnecessary hoops to do this. I had to duplicate
and modify some of the desktop.el code, just to get around this function

Anyway, the TODO item you cite is fine, but a welcome preliminary TODO item
would be to change the desktop.el functions to accept (at least optionally) a
desktop file location (file name), and not just rely on a directory.

See also thread "desktop.el - only one desktop file per directory?",


FWIW, my bookmark code is a trivial extension to bookmark.el, which defines a
`desktop' bookmark type. I just define:

1. A command to set a desktop bookmark (reads a file name and writes a desktop

2. A function to make a desktop bookmark record ( records the desktop file and a
desktop bookmark handler).

3. A desktop bookmark handler (gets the desktop file name from the bookmark and
changes to that saved desktop).

The code is here:

Because I allow multiple desktop files per dir, the code for #1 and #3 is more
involved that it should need to be. With more reasonable desktop.el functions,
which accepted a desktop file name, it would be short and simple.

Note: My code doesn't worry about multiple users and sessions wrt locks - it is
rudimentary (hence fragile) wrt locking. While I allow multiple desktop files
per dir, I haven't bothered to try to handle multiple lock files per dir etc.

Really, it is an individual desktop file (not a directory) that should have an
associated lock. Truly breaking with the current directory-level granularity
would require handling locks on a per-file basis, I imagine (but I'm no expert
on how the locking works).

If the TODO item I proposed were implemented, then the necessary file-level
locking would hopefully be taken care of also.

reply via email to

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