Re: [PATCH] tab-bar.el: add defcustoms for functions to call after opening and before closing

[Juri Linkov]

> ;; 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.