Hi Cosmin,
I see you responded to me privately, rather than to the list. I'm not
sure if this was your intent.
I'm not sure either. It's the use case I had in mind: I have 3
> I can certainly add another option for the ^U shortcut (to move all tabs or
> only the current tab). I can also add a menu entry to move the current tab
> on the other panel. On the other hand, I prefer to have the tabs separately.
> If anyhow, somebody wishes to have them common for both panels I can develop
> something like this (as an option) to be included in mc. But for me, I don't
> think it's necessary.
directories (A, B, C), and I'd like to copy files from A to B, from B
to C, and from A to C (or C to A, whatever). With your current
design, at least one of them would needed to be duplicated in both
panels (e.g. left panel: A and C, right panel: B and C), which is not
necessarily bad, I'm just wondering if it's a bit too complicated and
a different design would make it simpler. This is really just a heads
up that this use case might also be valid. I'm really not sure what
the best solution would be, I've never used a two-panel filemanager
with tab support, so apparently you have more experience here.
Also, config options that heavily change the behavior are IMHO usually
a bad idea. A config option for having the tabs on the top or bottom
or hidden is fine. The ones you have now (where the new tabs open)
take effect only at one particular well defined part of the source,
these are also okay. But having an option for per-panel or global
tabs would IMHO be a maintainability nightmare, as plenty of things
would behave very differently in the two worlds. Probably it's better
to decide on one and implement that only. Your approach fits much
better the generic concept of how tabs work (even though it's uncommon
to have two tab bars), while mine addresses a particular use case I
had in my mind, but the relation of the panel and tab bars would be
uncommon. Anyway, it's something for you to think about, and if you
(and other commenters) decide to keep the current design, I'm totally
fine with that :)
It's not just my personal preference. Mouse works all across MC, I'm
> The truth is that I don't use the mouse with mc. This is why the tabs are
> not responsive to the mouse. But again, if you would like to include it in
> the official code repository I can also make it responsive to the mouse.
sure the mainstream developers wouldn't accept your patch without
mouse support (and I'd agree with this decision).
Thanks again, let's wait to see what others say.
egmont