Juri Linkov <juri@linkov.net> writes:

>> To be clear, `tab-bar-tab-pre-close-functions` didn't go away. I'm not
>> exactly sure of a situation where it really really matters from the
>> perspective of a hook function whether or not it's clean up task happens
>> before or after a tab is technically closed, but I'm not opposed to
>> having both a pre and post close hook. However, I do believe that
>> there's more information available to a hook function about a tab before
>> the tab is formally closed.
>
> Does tab-bar-tab-prevent-close-functions have the same information?
> Then why should we have two exactly the same pre-hooks?
>
> To me it makes more sense cleaning the workplace after the work is done,
> not before.  So killing the buffers is safer after closing the tab.
> If something goes wrong, then buffers are still here when the tab is not closed.
> Or are there some technical problems with using a post-close hook for such task?

pre-close-functions and prevent-close-functions get all of the same
information, yes. I decided to separate them into two separate things
because otherwise you run into function dependency issues.

For example, if tab-bar-pre-close-functions worked the way I had
original defined it, where it did double duty of what I'm now proposing
to be pre-close-functions and prevent-close-functions, then if the hook
were to look something like this:

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

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.

>> Perhaps then we should also split `tab-bar-tab-post-open-functions` into
>> pre and post variants (run before and after the tab is added to the
>> frame parameters respectively)? I won't deny that an arrangement like
>> that could possibly be confusing (Ex: "why is my hook not working to rename
>> my tab?" -> "oh, you have to put that in the pre open hook, not the post
>> open hook"),
>
> Why tab renaming works only in the pre-open hook, but not in the post-open hook?
> I see no possible reasons why this shouldn't be possible.
>
>> but I personally find that a more attractive alternative
>> that expecting hooks to have to grovel through the frame parameters
>> themselves or to write a bunch of accessor functions to cover all the
>> possible use-cases.
>
> I think the user should have the final word - after the command that
> created a new tab and added it to the frame's tab list, the user
> should have freedom to customize the result of the command using hooks.
> This is possible only when the hook is run at the very end of the command.
>

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.
I've fixed it in this version of the patch.

Thanks,
-- 
~Robert Cochran