micro icon indicating copy to clipboard operation
micro copied to clipboard

Enhance Tab Bar

Open cutelisp opened this issue 5 months ago • 10 comments

This is a PR to implement tab dragging.

I chose the most simple approach I could think of.

Notes:

  • In case this pull request is merged, it will enhance the dragging experience.
  • If hovering tabbar arrows make scrolling continuesly, it will enhance the dragging experience (Needs a PR).
  • Making tabbar scrolling possible while dragging is possible?

cutelisp avatar Jul 01 '25 09:07 cutelisp

By the time you made the review I already had refactor most of this, thanks for the feedback anyways it will be helpful.

I was adding the features of deleting and creating tab but to make verifies it was getting messy with lots of variables inside the struct.

Note that here I tried to enhance TB as a whole i found this https://github.com/zyedidia/micro/issues/3417 which addresses the problems. If we want to make sure that drags on TB don't mess with buffers and vice versa + adding TB features such as scrolling, dragging etc. adding t.actionName = T/F for each "action" is not ideal IMO. I was trying more elegant ways to implement this. I think I should probably change the name of the PR for something more general and start by refactoring (t *TabList) HandleEvent a bit.

cutelisp avatar Jul 12 '25 23:07 cutelisp

I'm not sure I understand what you are talking about. https://github.com/zyedidia/micro/issues/3417 doesn't address problems, it reports problems, and AFAICS all the problems it reports are already addressed by your PR in its current state? As for the features like deleting and creating tabs, they can be implemented separately as a next step (if at all), we don't need to mess with those features in the same PR (certainly not in the same commit)? And it isn't clear to me why would you need t.actionName = T/F for those features in the first place.

dmaluka avatar Jul 13 '25 00:07 dmaluka

doesn't address problems, it reports problems

English issue.

all the problems it reports are already addressed by your PR in its current state?

Yes

And it isn't clear to me why would you need t.actionName = T/F for those features in the first place.

For the same reason as dragging. https://github.com/zyedidia/micro/pull/3795#discussion_r2188439914

we don't need to mess with those features in the same PR (certainly not in the same commit)?

Right, I just felt to add the add/remove features on top of this PR as it is I would need to refactor a bit the function so it's odd to make 2 PR in a row changing "the same thing" twice. Anyway, I might be overcomplicating this problem. I'll test a few things and update the PR. But just to be clear, is add/remove on m3 an accepted feature, feature-wise?

cutelisp avatar Jul 13 '25 01:07 cutelisp

For the same reason as dragging. #3795 (comment)

I can't see why. Adding/removing a tab is triggered by a mouse click (even if it's a double click), not by a mouse move, so it doesn't depend on the global "release" state, all we need is to check if this click is on the tabbar or not, right?

But just to be clear, is add/remove on m3 an accepted feature, feature-wise?

What is m3?

dmaluka avatar Jul 13 '25 01:07 dmaluka

I can't see why. Adding/removing a tab is triggered by a mouse click (even if it's a double click), not by a mouse move, so it doesn't depend on the global "release" state, all we need is to check if this click is on the tabbar or not, right?

Sounds right

What is m3?

mouse3 -> mouse middle/scroll click

cutelisp avatar Jul 13 '25 01:07 cutelisp

mouse3 -> mouse middle/scroll click

Ok, so, closing tab when clicking the middle button on this tab, and opening a new tab when clicking the middle button on the empty area of the tabbar? Sounds good to me, why not.

dmaluka avatar Jul 13 '25 09:07 dmaluka

It's not clear to me what is the best behavior for deleting on middle click perhaps someone can give their opinion.

If a tab contains only unmodified buffers, the behavior is straightforward, we can simply delete the tab on click.

But what should happen if the tab contains modified buffers?

  • Should we show a save prompt for each modified buffer individually, or group them?
  • If the tab has a mix of modified and unmodified buffers, should the unmodified ones be closed immediately on click, or only when (and if) the entire tab is confirmed for removal?
  • Could we show a single prompt like: “Do you want to discard the changes in X modified buffers?”

cutelisp avatar Jul 15 '25 06:07 cutelisp

But what should happen if the tab contains modified buffers? [...]

Interesting dilemma... From a pure usability standpoint, I'm really not sure which option is the best one. From simplicity point view, the last option (a single prompt, all or nothing) seems the most attractive (and it seems not bad from the usability standpoint either)?

dmaluka avatar Jul 15 '25 21:07 dmaluka

the last option (a single prompt, all or nothing) seems the most attractive

Right, I was leaned towards that option too

cutelisp avatar Jul 15 '25 21:07 cutelisp

As discussed above added new tab bar features: add, delete & drag. Made separated commits for review process.

cutelisp avatar Jul 16 '25 23:07 cutelisp