From: Juanma Barranquero <lekktu@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Freezing frameset-restore
Date: Mon, 10 Mar 2014 06:26:43 +0100 [thread overview]
Message-ID: <CAAeL0SSuhj+REAMwmf+w503AGTWO5to7wYOvVr0PP4463qrcYQ@mail.gmail.com> (raw)
In-Reply-To: <jwvfvmqbtoa.fsf-monnier+emacs@gnu.org>
On Mon, Mar 10, 2014 at 5:29 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Make it just (defvar frameset--action-map).
Plus let-bind later. OK.
> I suggest the following changes:
> - Get rid of the LIST case (it's not used and the caller could use
> PRED instead anyway to get the same result).
Well, the list is handy if you have a pre-made list or just want to
reuse one frame, but I'm OK with this change.
> - I prefer it when keywords are used only for the argument names and not
> for their values, so you don't need to count them to know which
> is which. So I'd favor using `all', `none', and `match'. Tho that
> slightly clashes with the PRED case. So I'd then suggest to rename
> `all' to t, `none' to nil, and to get rid of `match' (i.e. use the
> PRED case for it, probably providing a handy function for it).
I'd like to avoid this, if possible. I happen to really like keywords
as argument values, instead of normal symbols, and I dislike the idea
of providing a matching function for the match case. Also, keywords
are also used in the variable `frameset-filter-alist' (and, though
slight, the possibility of clash with a function called never or
restore isn't null). This also would meant to change
`desktop-restore-reuses-frames' and `desktop-restore-forces-onscreen'.
If you really insist on getting rid of the keyword values, I'd prefer
to keep 'match, 'all and 'none and let the user be smart enough not to
use a PRED function with these names. Consider that reusing all seems
generally more desirable that reusing none (reusing all is more likely
to produce a better user experience by reducing the flicker of frame
deletion / frame creation), but your change makes none (nil) the
default.
> Maybe a hash-table would be better than an alist. This would save us
> from the hideous cl-acons/assq-delete-all.
Funnily enough, my previous patch *used* a hash table. I changed it to
an alist to avoid having to build the action-map list at the end. But
I certainly prefer the hash table, so I'll revert that part of the
change.
> Allowing a list of actions is over-engineering it.
Except that the presumably common case of deleting all non-restored is
'(((:ignored :rejected) delete-frame)), which seems nicer that
'((:ignored . delete-frame) (:rejected . delete-frame)). But I can
change it if you feel strongly against it.
> (pcase-dolist
> (`(,frame . ,action)
> (frameset-restore (aref data 0)
> :filters frameset-session-filter-alist
> :reuse-frames (if current-prefix-arg nil :match)))
> (with-demoted-errors "Error cleaning up frame: %S"
> (pcase action
> (`:rejected
> (if current-prefix-arg (delete-frame frame) (iconify-frame frame)))
> ;; In the unexpected case that a frame was a candidate (matching frame
> ;; id) and yet not restored, remove it because it is in fact
> ;; a duplicate.
> (`:ignored (delete-frame frame)))))
>
> It's admittedly longer than your version, but I'm not convinced it
> justifies the complexity of frameset-restore-cleanup.
I'm no fan of frameset-restore-cleanup (I much preferred having a
CLEANUP argument, because separating this from frameset-restore seems
to me to make an artificial distinction between two phases of the same
process, which is, to restore a frameset), but I'm still less fan of
the code you propose, which even uses an undocumented macro
(pcase-dolist ;-).
Doing it your way means repeating some logic, like the error checking,
at each point of call of frameset-restore (yes, there's currently only
two uses, but I'm designing this thinking that some other uses will be
found). The call to frameset-restore you're rewriting here is
admittedly ugly (in both your and my versions) because
frame-configuration-to-register had this weird behavior of iconifying
by default and deleting with C-u that I'm imitating.
As I see it, for the cleanup there are only three "cases", two common
(leave everything as it is; and delete everything that wasn't
restored), and a less common one (which lumps everything else, like
iconifying, or customized functions). That's why I'm strongly
convinced that having
(frameset-restore fs :cleanup 'keep)
(frameset-restore fs :cleanup 'delete)
(frameset-restore fs :cleanup #'my-custom-function)
and let frameset-restore worry about looping, error protection and
default cases is much, much cleaner that the alternatives we've been
hashing for the past couple days (not to mention more efficient: the
action-map is only built when needed) and more correct (the cleanup is
called before checking whether there's still at least one visible
frame, while with your proposal, it is possible for the cleanup code
to do something to all visible frames and leave only non-visible
ones).
J
next prev parent reply other threads:[~2014-03-10 5:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 0:03 Freezing frameset-restore Juanma Barranquero
2014-03-06 17:27 ` martin rudalics
2014-03-06 17:33 ` Juanma Barranquero
2014-03-06 18:16 ` martin rudalics
2014-03-06 18:35 ` Juanma Barranquero
2014-03-06 18:41 ` Juanma Barranquero
2014-03-07 7:38 ` martin rudalics
2014-03-07 11:28 ` Juanma Barranquero
2014-03-07 15:16 ` martin rudalics
2014-03-07 20:32 ` Stefan Monnier
2014-03-07 21:34 ` Juanma Barranquero
2014-03-07 21:40 ` Juanma Barranquero
2014-03-08 0:34 ` Stefan Monnier
2014-03-08 1:42 ` Juanma Barranquero
2014-03-08 2:25 ` Juanma Barranquero
2014-03-08 4:31 ` Stefan Monnier
2014-03-08 6:00 ` Juanma Barranquero
2014-03-08 14:27 ` Stefan Monnier
2014-03-08 16:34 ` Juanma Barranquero
2014-03-08 23:45 ` Juanma Barranquero
2014-03-10 4:29 ` Stefan Monnier
2014-03-10 5:26 ` Juanma Barranquero [this message]
2014-03-10 13:04 ` Juanma Barranquero
2014-03-10 14:19 ` Stefan Monnier
2014-03-10 15:06 ` Juanma Barranquero
2014-03-10 18:33 ` Juanma Barranquero
2014-03-10 23:10 ` Stefan Monnier
2014-03-11 0:47 ` Juanma Barranquero
2014-03-10 20:32 ` Stefan Monnier
2014-03-10 21:07 ` Juanma Barranquero
2014-03-09 12:29 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAeL0SSuhj+REAMwmf+w503AGTWO5to7wYOvVr0PP4463qrcYQ@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.