unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Robert Cochran <robert@cochranmail.com>
Cc: Robert Cochran <robert-emacs@cochranmail.com>, emacs-devel@gnu.org
Subject: Re: [PATCH] tab-bar.el: add defcustoms for functions to call after opening and before closing
Date: Sun, 08 Dec 2019 00:25:03 +0200	[thread overview]
Message-ID: <87muc3ixj4.fsf@mail.linkov.net> (raw)
In-Reply-To: <8736dyfk63.fsf@cochranmail.com> (Robert Cochran's message of "Thu, 05 Dec 2019 15:05:08 -0800")

> ;; From the examples in the last email
> (#'tab-ex/kill-non-file-buffers-in-tab #'tab-ex/tab-has-unsaved-files)
>
> then when closing a tab, you'd first kill all of the non-file buffers,
> and then check to see if you should close the tab based on whether or
> not there are any visible unsaved buffers. But at this point, you've
> already run cleanup functions regardless of whether or not you
> ultimately decide to close the tab. Mixing cleanup tasks and deciding
> whether or not to close the tab leads to weird edge-cases and being
> dependent on function ordering. I think that's too much complexity to
> wrangle in a single hook.

Indeed, this is better than to depend on the ordering of function calls
in the hook.

> The only 'technical' problem with a post-close hook is that the tab
> information is now gone because it's been deleted from the list. A hook
> gets slightly less contextual information if we decide to hold off on
> running the hook until the end. While I'll agree that it might make a
> little more sense to run the hook at the end, I'm going to counter by
> saying that we should arrange for the hook to be able to get as much
> information as it can get, because you'll never know when someone wants
> all of it. It's better to have to filter out information you don't need
> than to be stuck without the information you do need.

Right, more contextual information is available when the tab is still
attached to the tab bar.

> I tested this again just now and found out that it actually does work to
> just get the alist from frame-parameter and modify it directly. I had an
> incorrect understanding about what did and did not work. My appologies;
> I thought I had tested that better.  With that misunderstanding cleared
> up, my original point is moot, and moving the call to
> run-hooks-with-args to after the tab is put into the frame-parameters
> list isn't problematic - life is still easy to modify tab parameters.

Then let's agree on a general principle: both open and close hooks
should operate on the tab when it is still attached to the tab bar.

> I've fixed it in this version of the patch.

Thanks, now your patch is pushed to master.



  reply	other threads:[~2019-12-07 22:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 19:57 [PATCH] tab-bar.el: add defcustoms for functions to call after opening and before closing Robert Cochran
2019-11-10 20:42 ` Juri Linkov
2019-12-02 22:46   ` Robert Cochran
2019-12-03 23:19     ` Juri Linkov
2019-12-04 20:29       ` Robert Cochran
2019-12-04 22:45         ` Juri Linkov
2019-12-05 23:05           ` Robert Cochran
2019-12-07 22:25             ` Juri Linkov [this message]
2019-12-11 18:32               ` Robert Cochran

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=87muc3ixj4.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=emacs-devel@gnu.org \
    --cc=robert-emacs@cochranmail.com \
    --cc=robert@cochranmail.com \
    /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).