unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: How to persist registers across sessions?
Date: Sat, 2 Jul 2022 11:46:49 +0300	[thread overview]
Message-ID: <YsAF+StCYeVzRfnG@protected.localdomain> (raw)
In-Reply-To: <83tu80cb54.fsf@gnu.org>

* Eli Zaretskii <eliz@gnu.org> [2022-07-02 08:55]:
> > Date: Fri, 1 Jul 2022 15:27:20 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2022-07-01 10:20]:
> > > I don't think you described what exactly you'd like to do with the
> > > window config information.  So the answers you get don't satisfy your
> > > needs, because you didn't describe those needs in sufficient detail.
> > 
> > I wish to save window configuration as Lisp object. I wish to be able
> > to transform window configuration by using prin1-to-string so that I
> > can later read-from-string and store it back to register.
> 
> For what purpose? how would you like to use the stored Lisp object in
> your Emacs sessions?

I am Hyperbole user so this is how I store within session a named
window configuration: {C-h h w a My-Conf RET} and this is how I
restore it {C-h h w r My-Conf RET}, and it does not last over
sessions. There is plan by Hyperbole author to make it.

Compare that flow to desktop.el and you will understand that there is
speed and efficiency in saving window configuration and restoring
it. There can be multiple window configurations. With few keys I may
get access to it.

However, all what I can see in there is #<window-configuration> so I
do not know how to get Lisp data where it will be said which window
belongs to which file, and how windows are split. That is why I am
asking you about it. 

Maybe such Lisp data about window configuration does not exist.

In desktop.el I can see that it generates lisp as string pieces to
write it to desktop.el and I would prefer not that but Lisp data.

Purpose is to isolate that information and become able to store it on
file or inside of the database, so that I can use a key to set some of
preset window configurations from session to session and in quick
manner.

Desktop.el saves everything, and offers directory to user to save
it. Saving hundreds of buffers takes long time and loading desktop
again simply does not work on my side. My buffers are many, like now
there is 795 buffers. Then it starts first that I have to confirm
variables, then I see million messages how some directories do not
exist as Dired was accessing mounted disks, it really takes long
time. From 795 buffers, I get 294 buffers.

It is definitely NOT that what I want, it is not practical.

What I want is:

1) Having 3-5 buffers in specific window configuration. Regardless of
   other buffers, I wish to be able to restore such window
   configuration. 

2) Having possibility to save multiple such window configurations and
   quickly with minimum keys or with menu get access to it.

If at least I get clue how to get the split parameters of a frame,
modes, its sizes of windows, as Lisp data, then I would be fine with
it, and then I can myself assign something to those buffers. My
buffers are too often buffers related to database, table, column and
ID and do not have files attached.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/








  reply	other threads:[~2022-07-02  8:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27  3:24 How to persist registers across sessions? Pankaj Jangid
2022-06-27 12:01 ` Michael Heerdegen
2022-06-28 18:03 ` Jean Louis
2022-06-29 15:35 ` Visuwesh
2022-06-30 12:50   ` Jean Louis
2022-06-30 13:55     ` Michael Heerdegen
2022-06-30 14:00     ` Eli Zaretskii
2022-06-30 14:23       ` Michael Heerdegen
2022-06-30 15:50         ` Eli Zaretskii
2022-06-30 14:33       ` Jean Louis
2022-06-30 16:01         ` Eli Zaretskii
2022-06-30 21:55           ` Jean Louis
2022-07-01  6:02             ` Eli Zaretskii
2022-07-01  7:03               ` Jean Louis
2022-07-01  7:19                 ` Eli Zaretskii
2022-07-01 12:27                   ` Jean Louis
2022-07-02  5:54                     ` Eli Zaretskii
2022-07-02  8:46                       ` Jean Louis [this message]
2022-07-02  9:04                         ` Eli Zaretskii
2022-07-02 17:19                           ` Jean Louis
2022-07-02 17:40                             ` Eli Zaretskii
2022-07-02 18:03                               ` Jean Louis
2022-07-02 18:42                                 ` Eli Zaretskii
2022-07-02 18:52                                   ` Jean Louis
2022-07-03  5:02                                     ` Eli Zaretskii
2022-07-01 14:29                 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-07-01 16:07                 ` [External] : " Drew Adams
2022-07-02 11:00       ` Pankaj Jangid
2022-07-02 11:48         ` Eli Zaretskii
2022-07-04  3:26           ` Pankaj Jangid

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=YsAF+StCYeVzRfnG@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@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.
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).