From: Sergey Organov <sorganov@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: How much I can rely on etc/TODO
Date: Tue, 09 Apr 2019 15:05:11 +0300 [thread overview]
Message-ID: <q8i1po$2i7f$1@blaine.gmane.org> (raw)
In-Reply-To: 83h8b77c0t.fsf@gnu.org
Eli Zaretskii <eliz@gnu.org> writes:
>> From: lxsameer <lxsameer@gnu.org>
>> Date: Tue, 9 Apr 2019 08:50:14 +0100
>>
>> So is "Give desktop.el a feature to switch between different named
>> desktops. " still valid ?
>
> Yes, I think so. The only existing way of controlling which desktop
> file is to be loaded is AFAIK either by specifying an explicit
> directory when invoking desktop-read, or by customizing desktop-path.
For about 15 years already we use package I wrote called 'desksess.el'
that does this (and a little bit more) atop of 'desktop.el' (and
'session.el'). I can share it if anybody is interested. Nothing very
fancy, but I think it could be useful at least as a source of some
inspirations.
Here is short package description (some statements about 'desktop.el'
could well be very outdated):
;; This package is a wrapper above desktop.el and session.el and depends on
;; them. Unfortunately each of these two nice packages lack essential
;; features available in another:
;;
;; session.el:
;; - no capability to save non-list globals
;; - no way to save/restore desktop state (to visit files on startup that
;; have been visited before exit)
;;
;; desktop.el:
;; - desktop files scattered over file-system
;; - no recent files menu capability
;; - no capability to save/restore point and other locals when previously
;; visited file is closed and re-opened later
;;
;; The desksess.el tries to use the above two packages to provide more
;; comprehensive and convenient desktop save/restore/switch capabilities.
;;
;; Unlike desktop.el, we store all desktops in a single directory and
;; refer to them by their names, either through menu or commands, so
;; one has single list of all the available desktops. Though loading
;; of arbitrary desktop files is also supported, it's not the primary
;; workflow mode.
;;
;; The package has been extensively tested on Emacs 23.x an 24.4.1.
-- Sergey
next prev parent reply other threads:[~2019-04-09 12:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 17:52 How much I can rely on etc/TODO Sameer Rahmani
2019-04-08 17:59 ` Eli Zaretskii
2019-04-08 18:26 ` Sameer Rahmani
2019-04-08 20:42 ` Basil L. Contovounesios
2019-04-08 22:14 ` Richard Stallman
2019-04-09 6:03 ` Eli Zaretskii
2019-04-09 7:50 ` lxsameer
2019-04-09 9:39 ` Eli Zaretskii
2019-04-09 12:05 ` Sergey Organov [this message]
2019-04-09 13:52 ` Drew Adams
2019-04-09 23:13 ` Richard Stallman
2019-04-10 15:48 ` Eli Zaretskii
2019-04-10 21:53 ` Richard Stallman
2019-04-11 14:12 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2019-04-11 1:34 Van L
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='q8i1po$2i7f$1@blaine.gmane.org' \
--to=sorganov@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).