I have not much of an opinion on it, other what I mentioned below.
@yegappan I think you might have some opinion here?

I'm used to the current behavior where the tag stack is copied to new windows
or tab pages. This allows me to jump to a tag in a new window while still
retaining the original context in the previous window - helpful for traversing
the tag stack without losing my place.

While adding yet another option to Vim always warrants consideration, I don't
see any major issues with supporting this behavior for users who prefer not to
copy the tag stack. That said, this change may introduce some usability
friction, as users would now need to be aware of which window holds a
particular tag stack in order to traverse it effectively

I'm used to the current behavior where the tag stack is copied to new windows or tab pages. This allows me to jump to a tag in a new window while still retaining the original context in the previous window - helpful for traversing the tag stack without losing my place.

Interesting, I haven't thought about this use-case myself.

This is a simple fix for an old issue #5742.

Some people find that default Vim's behavior of copying entire tag stack when splitting a window with unrelated file is confusing. This PR adds a flag (copytagstack) to give users control over this.

Instead of an option, could this be solved at the user-config level with an autocommand that clears the tagstack when a new window is opened?

That would avoid making Vim itself more complicated (more options: more cognitive load). Heck, I’m not sure if any plugin authors rely on this behavior.

The request is a bit similar to #17248. I don't think there is a way to clean the tag-stack.
I wondered if we can use a custom command modifier for such a thing, like :fresh :new that would prohibit copying options or the tagstack? not sure this will work.

This is a simple fix for an old issue #5742.
Some people find that default Vim's behavior of copying entire tag stack when splitting a window with unrelated file is confusing. This PR adds a flag (copytagstack) to give users control over this.

Instead of an option, could this be solved at the user-config level with an autocommand that clears the tagstack when a new window is opened?

You mean something like

autocmd BufWinEnter * :some_new_command_to_clean_tag_stack

? I guess this would work too and command to clean tag stack seems useful in general.

Heck, I’m not sure if any plugin authors rely on this behavior.

True, I'm not sure how to check this...

I wondered if we can use a custom command modifier for such a thing, like :fresh :new that would prohibit copying options or the tagstack?

Are there examples of such modifiers in current Vim ? Sorry, I'm not really a Vim expert.

This is a simple fix for an old issue #5742.

Some people find that default Vim's behavior of copying entire tag stack when splitting a window with unrelated file is confusing. This PR adds a flag (copytagstack) to give users control over this.

Instead of an option, could this be solved at the user-config level with an autocommand that clears the tagstack when a new window is opened?

You mean something like

autocmd BufWinEnter * :some_new_command_to_clean_tag_stack

? I guess this would work too and command to clean tag stack seems useful in general.

Yes, although for some reason I thought there was a function API for clearing it because I remembered working with related stuff in https://github.com/benknoble/tag-tracks

Heck, I’m not sure if any plugin authors rely on this behavior.

True, I'm not sure how to check this...

Me neither at the moment.

I wondered if we can use a custom command modifier for such a thing, like :fresh :new that would prohibit copying options or the tagstack?

Are there examples of such modifiers in current Vim ? Sorry, I'm not really a Vim expert.

Yes, if you count :botright, :vertical, :tab, :keeppatterns, :keepalt, etc.

This is a simple fix for an old issue #5742.

Some people find that default Vim's behavior of copying entire tag stack when splitting a window with unrelated file is confusing. This PR adds a flag (copytagstack) to give users control over this.

Instead of an option, could this be solved at the user-config level with an autocommand that clears the tagstack when a new window is opened?

You mean something like

autocmd BufWinEnter * :some_new_command_to_clean_tag_stack

? I guess this would work too and command to clean tag stack seems useful in general.

Something I omitted from my first reply (below), you probably want the WinNew event based on the issue description.

Yes, although for some reason I thought there was a function API for clearing it because I remembered working with related stuff in https://github.com/benknoble/tag-tracks

Indeed, it makes sense for :split to inherit all source window information, including the tagstack, but there may be cases where you don't want to carry over the tagstack when using :new. Since the patch in this PR applies the same behavior to both :split and :new, it doesn't meet my requirements.

By the way, even with the current implementation, you can clear the tagstack only for :new by setting up the following auto-command:

:au BufWinEnter * call settagstack(0, {'items' : []})

(In my case I’d use BufWinEnter, but for you it might be BufNew)

I tried to address all review comments from @chrisbra. I've also added an example cleartagstack command to clear tagstack in autocmds as suggested by @benknoble.

The final PR, I assume, will contain either option or command, not both. Using autocmd is fine with me, I'd appreciate if maintainers could comment whether this may be somehow inferior to a full-blown option.

And I still need to figure out the crash for linux (huge, gcc, uchar, testgui, true, dynamic) config.

Indeed, it makes sense for :split to inherit all source window information, including the tagstack

This may be up to some debate. E.g. if I'm in the middle of deep navigation stack for my app and decide to open a file from side project to check something, I'd personally prefer that side file to have a independent stack (e.g. to avoid accidentally returning to "inherited" stack when pressing Ctrl-T multiple times).

Since the patch in this PR applies the same behavior to both :split and :new, it doesn't meet my requirements.

I'd say split of different file should not inherit stack either. As some people can (and do, as we see) disagree I suggested to add an option, for end user to decide.

By the way, even with the current implementation, you can clear the tagstack only for :new by setting up the following auto-command:

Yup, in new patch I'm adding cleartagstack to make this a bit simpler.

Indeed, it makes sense for :split to inherit all source window information, including the tagstack, but there may be cases where you don't want to carry over the tagstack when using :new. Since the patch in this PR applies the same behavior to both :split and :new, it doesn't meet my requirements.

By the way, even with the current implementation, you can clear the tagstack only for :new by setting up the following auto-command:

:au BufWinEnter * call settagstack(0, {'items' : []})

(In my case I’d use BufWinEnter, but for you it might be BufNew)

@h-east FWIW I suggested WinNew in a previous comment. Though I now wonder in which window the autocommand callback runs.

It may just be that I'm on mobile, but the indentation in C files from the cleartagstack patch looks odd.

Indeed, it makes sense for :split to inherit all source window information, including the tagstack, but there may be cases where you don't want to carry over the tagstack when using :new. Since the patch in this PR applies the same behavior to both :split and :new, it doesn't meet my requirements.
By the way, even with the current implementation, you can clear the tagstack only for :new by setting up the following auto-command:

:au BufWinEnter * call settagstack(0, {'items' : []})

(In my case I’d use BufWinEnter, but for you it might be BufNew)

@h-east FWIW I suggested WinNew in a previous comment. Though I now wonder in which window the autocommand callback runs.

FYI I observe the following behaviours for different variants of autocmd ??? :call cleartagstack():

• WinNew:
  • :new, :sp, :sp some-other-file - new window has empty tagstack
• BufNew, BufWinEnter:
  • :new, :sp some-other-file - new windows has empty tagstack
  • :sp- new window has copy of tagstack
  • in some cases jumping to tag in original file resets existing tagstack (so this is probly unusable)

It may just be that I'm on mobile, but the indentation in C files from the cleartagstack patch looks odd.

Oh, sorry about that. Any file in particular? In general I tried to follow the existing code. In particular formatting of f_cleartagstack is copied from f_gettagstack. Formatting in clear_tagstack is mostly unchanged.

Summary of current status:

• this PR is experimental and implements two different approaches (notagstackcopy option and new cleartagstack command for use with autocmd)
• autocmd-based solution does not even need a new command as pointed out by @h-east

If no one can see potential issues with

:au WinNew * call settagstack(winnr(), {'items' : []})

I guess there is no need for any changes and PR can be closed (I could also experiment with it for some time and report my findings).

Can you please try out the autocmd solution? It seems like it is enough and we shouldn't require any code changes here. But I'll leave this open so you can report back how well this approach works in practice.