I plan to add clickable region support for tabpanel as well in a follow-up.

Thanks, unfortunately ASAN detected a memory leak.

thanks, but I think we should try to be compatible with Neovim here and I believe they are using the %@ atom?

But the arguments passed to the function is also different:

	@ N   Start of execute function label. Use %X or %T to end the label,
	      e.g.: %10@SwitchBuffer@foo.c%X.  Clicking this label runs the
	      specified function: in the example when clicking once using left
	      mouse button on "foo.c", a `SwitchBuffer(10, 1, 'l', '    ')`
	      expression will be run.  The specified function receives the
	      following arguments in order:
	      1. minwid field value or zero if no N was specified
	      2. number of mouse clicks to detect multiple clicks
	      3. mouse button used: "l", "r" or "m" for left, right or middle
	         button respectively; one should not rely on third argument
	         being only "l", "r" or "m": any other non-empty string value
	         that contains only ASCII lower case letters may be expected
	         for other mouse buttons
	      4. modifiers pressed: string which contains "s" if shift
	         modifier was pressed, "c" for control, "a" for alt and "m"
	         for meta; currently if modifier is not pressed string
	         contains space instead, but one should not rely on presence
	         of spaces or specific order of modifiers: use |stridx()| to
	         test whether some modifier is present; string is guaranteed
	         to contain only ASCII letters and spaces, one letter per
	         modifier; "?" modifier may also be present, but its presence
	         is a bug that denotes that new mouse button recognition was
	         added without modifying code that reacts on mouse clicks on
	         this label.

So using the same atom doesn't really help (and may lead to user mistakes).

Because statusline treats %@ as a newline character, it was not possible to make it have the same interface as neovim. #18871 #19123 #19622

Note that Neovim's statusline click handler uses %@FuncName@...%X syntax, which conflicts with Vim in two places:

• %@ — Vim uses this for line breaks (STL_LINEBREAK), Neovim uses it to start a clickable region
• %X — Vim uses this for tab page close button number (STL_TABCLOSENR), Neovim uses it to end a clickable region

The %[FuncName] syntax proposed here avoids both conflicts, which is nice.

Also, the callback currently receives a single Dictionary argument with no room for additional parameters in the future. It might be worth considering whether the signature should be extensible (e.g., allowing additional arguments to be added later without breaking existing callbacks).

I see, makes sense. But I don't understand the comment about extending the dictionary in the future. We can simply add new keys in the future, right? So it should be fine as is.

Yes, exactly. My point was that Neovim's positional arguments approach would require changing the interface when extending, whereas the dictionary approach we use here allows adding new keys without breaking existing callbacks. So we're on the same page.

Thanks, I think this is fine now

@mattn I was looking into adding support to vim-airline, but how does the function know the field value for which it has been defined? E.g. for Neovim I know the minwid which is the value I have to use to find out the buffer number to switch to.

@chrisbra Same idea as Neovim — use %N[FuncName]. The number N before [ is delivered to the callback as a:info.minwid, so you can identify which field was clicked exactly as you do on the Neovim side.

ah, makes sense. Thanks

but it doesn't seem to work in the tabline?

Confirmed — the tabline path in win_redr_custom() discards the parsed click regions (the save step is guarded by wp != NULL), and tabline clicks are dispatched via TabPageIdxs[] which doesn't know about %[FuncName]. So this is an implementation gap. I'll wire it up in a follow-up.