How to permanently disable one of the panels? One is enough!

[eugenesv]

My point was that TC is DESIGNED to work like that, but you suggest that it is supposed to work different.

Yeah, explain that to the Total Commander 32bit version which behaves exactly like I want it to behave, not like the imaginary OFM specification that you've come up with that somehow forces Tab to switch to an invisible panel.

Well, you're free to suggest it

Extremely easy, take your pick:

• 1. Continue as is except for Tab since my issue is more narrow and deals with panel switching, but not other functions.
  2. Just copy&paste what other managers do (see Far example)
  3. Do nothing (aka disable), which also makes sense — if there is no 2nd panel, you can't really expect a "Copy to the 2nd panel" function to work.

but in the same suggestion you should explain what TC should do in case of all functions that involve the Target/Source concept..

Nope, there is again exactly 0 reason why it should be a universal-cure-all. I'd be happy with any option from the above with any degree of completeness for #2.

I already explained that OFM is basically the target/source concept.

And I've already given you two real-life examples of why you're wrong. One example is Total Commander itself (32bit version), another one if Far.

[eugenesv]

Yes, you are right, but the idea was that VirtualPanel is maybe less harm than any real folder. Just an idea. 

Sorry, didn't understand what you meant. But you're correct, it is potentially less harmful, so i'll leave my 0% panel with Virtual Panel and wait for the bug to be fixed. Thanks for the suggestion.

[milo1012]

Yeah, explain that to the Total Commander 32bit version which behaves exactly like I want it to behave, not like the imaginary OFM specification that you've come up with that somehow forces Tab to switch to an invisible panel.

What are you talking about?
You said in OP:

Is there a chance to add an option that would completely disable the second pane and leave me with all the extra configurable awesomeness of of TC + addons?

If it's just that tab-bug in x64 that was bothering you, maybe you should have explained it in the first place.

Extremely easy, take your pick:

Not picking, but making a specific concept, as it's your suggestion.
But because it seems that you just wanted to prevent the tab key, it's probably useless to discuss it any further.

And I've already given you two real-life examples of why you're wrong. One example is Total Commander itself (32bit version), another one if Far.

And again: nope.
We were talking about the target/source concept.
If you use TC 32-bit, you will still have the paths from the invisible panel suggested for all target/source operations.
This wasn't about right or wrong, but about your mistakable request in the OP.

And BTW, just an example:
Trying to use TC's packer operation w/o an active 2nd panel is a pain.
I have to manually enter the path to the target archive every time.

[eugenesv]

What are you talking about?
You said in OP:

Is there a chance to add an option that would completely disable the second pane and leave me with all the extra configurable awesomeness of of TC + addons?

If it's just that tab-bug in x64 that was bothering you, maybe you should have explained it in the first place.

I'm talking about a very simple thing — your imaginary restrictions on what OFM can't do are just that — imaginary, they're not part of the OFM spec as proved by some pretty classic OFMs that live just fine without a second file panel if the user wishes so.
Also, if only you'd read the line above, you'd see the tab issue pointed out specifically

but it's still there and sometimes I'd switch to it by mistake by hitting tab or something.

Also, if you just bothered to read other messages in the thread, you'd realize that I had no idea this was a bug specific to x64 until Dalai did a few tests and discovered it. And after he'd discovered it, I've done exactly that — specified that tab is the main issue and other features of invisible panel are less important (would be nice if TC were smart about a hidden panel and change functions like Far does, but it's not a big deal).

Not picking, but making a specific concept, as it's your suggestion.

Then you shouldn't have asked for a suggestion you're not interested in.

But because it seems that you just wanted to prevent the tab key, it's probably useless to discuss it any further.

That's the main thing. I wouldn't mind other features matching Far, but that's pretty minor — that's why I'd be fine if they weren't implemented. Also, hidden panel still takes some resources on launch (e.g. I have an addon that automatically calculates folder size), but that I'm able to fix with the Virtual Panel Stefan2 suggested.

We were talking about the target/source concept.
If you use TC 32-bit, you will still have the paths from the invisible panel suggested for all target/source operations.
This wasn't about right or wrong, but about your mistakable request in the OP.

But it was, you started mentioning the OFM concept as though it proved the request without merit even though that concept proved exactly nothing — all the restrictions are something you've imagined. Not sure why you keep ignoring the inconvenient fact that Far is smart enough to realize there is no second panel and NOT offer any paths from the "invisible" disabled panel. Far is explicitly listed in that wiki you linked to. Ergo, smart handling of disabled panels is not a violation of OFM.
It's just that in this specific instance TC is not as smart as Far to handle this exception properly and has a weird artifact of taking into account invisible panel when it should just ignore it (either by disabling the corresponding functions or by changing how they behave). But it's a feature of a specific TC implementation (or rather lack thereof), not a restriction of the OFM.

[milo1012]

your imaginary restrictions on what OFM can't do are just that — imaginary, they're not part of the OFM spec as proved by some pretty classic OFMs that live just fine without a second file panel if the user wishes so.
...
all the restrictions are something you've imagined
...
Ergo, smart handling of disabled panels is not a violation of OFM.

It's not about what an OFM is and what not, but that TC is currently limited to a source/target operation, which itself - as an operational concept - is bound to two separate windows in TC.
I never talked about "restrictions", but about the current state of the program.
Additionally, there is no such thing as an OFM spec. If you look at the list of OFM on Wikipedia, you'll see that most of them rely on the source/target operation,
but of course there are exceptions, just like with any other types of programs.
Well, congratulations on finding such exception with FAR. Do we really want to talk about commonplaces?
We were talking about the problem at hand: TC and it's current capabilities. Apples and oranges.

Also, if only you'd read the line above, you'd see the tab issue pointed out specifically

Yes, and also, if you read my quote about your OP, you'd see that your request is highly mistakable,
and this was the very starting point of our disputation.
And BTW, MVV also understood your request that way:

You can only set second panel with to 0% but not to disable it.

Also, if you just bothered to read other messages in the thread, you'd realize that I had no idea this was a bug specific to x64

I read all messages, you know, but thanks for the imputation.
But again: apples and oranges.
I concentrated on the OP part I quoted above, while other users investigated the tab issue.

Then you shouldn't have asked for a suggestion you're not interested in.

I'm interested in all suggestions to TC, as I use the program constantly, promote it to other people,
help other users with problems (arising from current limitations), and even program plug-ins for it.
I simply pointed out that your mistakable suggestion "completely disable the second pane" lacked details.


But as we now clarified that all you were interested in was the tab-bug, maybe we should spare any additional clarifications.

[eugenesv]

I never talked about "restrictions", but about the current state of the program.

Yeah, right, here is you a couple of messages above:

An orthodox file manager just works this way, and that's why it's basically not possible to disable it completely.

If that is not "talking about restrictions" then you should check what that word means.
That's my key issue with all of your responses — baseless dogmatism of what is and isn't possible in the OFM spec even when facts prove you wrong. Despite what you think, it is possible to disable it completely and there are OFMs that do just that. Unless, of course, your next step is to argue that disabling isn't really disabling and in e.g. in Far it still "exists" even though none of the operations interact with it.

Additionally, there is no such thing as an OFM spec.

Except there is, it's even conveniently referenced on that wikipage. There might be no such thing as THE spec that everyone agrees on, but a spec is there nonetheless.

If you look at the list of OFM on Wikipedia, you'll see that most of them rely on the source/target operation, but of course there are exceptions, just like with any other types of programs.

Nope, Far also relies on source/target operation, it's not an exception in this regard. You keep conflating two rather separate things:

• 1) Relying on S/T — which is a defining feature of OFMs
  2) Ability to disable either S or T (with various implications for user interface, commands etc) — which has nothing to do with the concept of OFM, it's just a feature some OFMs have and some don't

Please stop mixing these up, they are different things. That's why you're wrong to say "not possible to disable it completely". It is possible. What's not possible is having an OFM app that doesn't support S/T operations and claims to be OFM.

Well, congratulations on finding such exception with FAR. Do we really want to talk about commonplaces?

Sidestepping the issue that you are making the same mistake of conflating 1) and 2) above, which ones have you actually tested for this feature to make that bold mistaken claim?
I think the DOS-based e.g. Norton/Volkov Commander supported this (though my memory might be rusty). Another classic — Midnight commander — supports one-panel view as well without tab/copy/move affecting it (with a trick). As well as Free Commander. As well as XYplorer. As well as Directory Opus... Well, that's what, like a lot of the classics and some of the most popular file managers out there?

We were talking about the problem at hand: TC and it's current capabilities. Apples and oranges.

And you brought the oranges by bringing up the OFM concept as though it had any relevance to my request for a specific feature. Now you're complaining about it.

your request is highly mistakable

No it's not, the mistake is entirely is your interpretation of the OFM concept based on a logical flaw (conflating 1) & 2) above) + lack of knowledge about other file managers (which happily have this feature). But hey, maybe they just don't know about OFM limitations.

I read all messages, you know, but thanks for the imputation.

Well, then it's even worse — you either can't understand them or (even worse) misrepresented them. Otherwise there is no way to blame me for not mentioning a bug in a post even though it's obvious I've only learned about that bug after the post was written.

But as we now clarified that all you were interested in was the tab-bug, maybe we should spare any additional clarifications

Failure of comprehension and/or misrepresentation comes again: "all ... was tab-bug" is not the same as "other features of invisible panel are less important (would be nice if TC were smart about ". It's not the same as "nothing" is not the same as "something"

[HolgerK]

Now, I know that I can minimize the second file pane to 0% and not see it, but it's still there and sometimes I'd switch to it by mistake by hitting tab or something. This is a minor annoyance.

Maybe it's enough to avoid this minor annoyance by adding the following to your wincmd.ini/usercmd.ini

[Configuration]
ResolutionSpecific=0
[Shortcuts]
TAB=em_NOP
[AllResolutions]
Divider=1000

[em_NOP]
button=
cmd=cd

Regards
Holger

[milo1012]

your request is highly mistakable

No it's not, the mistake is entirely is your interpretation of the OFM concept based on a logical flaw (conflating 1) & 2) above) + lack of knowledge about other file managers (which happily have this feature). But hey, maybe they just don't know about OFM limitations.
...
you either can't understand them or (even worse) misrepresented them
...
Failure of comprehension and/or misrepresentation comes again ...

I won't repeat myself, therefore, for a last time:
It is mistakable, because you said:
"Is there a chance to add an option that would completely disable the second pane"
but then you said:
"Yeah, explain that to the Total Commander 32bit version which behaves exactly like I want it to behave, not like the imaginary OFM specification that you've come up with that somehow forces Tab to switch to an invisible panel."
This gave me the understanding, that all you were interested in was the issue with the tab key,
because the 2nd pane is still there nonetheless, and it's paths are used for any t/s operation (F5/F6 et. al.).
But not a single time you seemed to understand the ambiguous, or at least vague nature of your OP question.
So I tried to make clear that we have a misunderstanding of your original topic / request,
to which I responded in the way I understood it: with the practical consequences this would have for TC.
But you ignored it and continue to blame me for a single sentence instead, which is based on the general OFM concept,
rather than the practical issues for TC, which this thread is about.
I also told you that another user interpreted your OP in the same manner.

If that is not "talking about restrictions" then you should check what that word means.
That's my key issue with all of your responses — baseless dogmatism of what is and isn't possible in the OFM spec even when facts prove you wrong.

As far as I can see, the only place where I used restrictions or maybe dogmatism was my sentence:
"An orthodox file manager just works this way, and that's why it's basically not possible to disable it completely."

All of your replies are based on this mere statement.
All my later responses were based on the difficulty to implement your idea in TC.
So I tell what all your responses are: your opinion about what an OFM can do and what not.
And I have mine, of course.
You're trying to prove a point, where there is no point to prove, pedantically re-parsing a single statement of opinion over and over.
When I said "An orthodox file manager just works this way", I meant it exactly like that, because TC currently follows that concept,
because I interpreted your OP as I already explained it before: as you were demanding that TC should optionally drop the 2nd panel completely
(and not arguing about general OFM concepts),
where I told you to provide alternate solutions for all existing s/t operations, which you didn't.
I'm reading this forum since the beginning, and I think I have a certain idea of what Christian wants in TC and what not,
and I know that you best provide a full concept for any suggestions you make here.
So are we talking about dogmatism, or about different concepts in two people's mind, which are actually off-topic here?

1) Relying on S/T ...
2) Ability to disable either S or T ...
...
Please stop mixing these up, they are different things.

And where exactly did I mix these?
Maybe I should have said: "completely rely on the t/s concept ...", sure,
but we were in fact talking about disabling the 2nd panel, so that you need to MANUALLY provide the target for any t/s op,
like you said yourself: "Far is smart enough to realize there is no second panel and NOT offer any paths from the "invisible" disabled panel",
but not about dropping the t/s concept completely.
If you drop a t/s concept, you're basically only left with a copy&paste (cut&paste) concept.
In TC, this would mean dropping any operation like F5/F6, packing, checksums, mime encoding, FTP downloading, etc.

[eugenesv]

Maybe it's enough to avoid this minor annoyance by adding the following to your wincmd.ini/usercmd.ini

[Configuration]
ResolutionSpecific=0
[Shortcuts]
TAB=em_NOP
[AllResolutions]
Divider=1000

[em_NOP]
button=
cmd=cd

Regards
Holger

Thanks for the suggestion!
I like the idea, but not sure I understand whether the result is what is expected.
Currently, when I press Tab I get Function not implemented! em_NOP.
This is better than switching to an invisible panel, but just wanted to confirm that this is indeed how it should work (maybe there is an empty command that would do nothing without the warning?)

[HolgerK]

(maybe there is an empty command that would do nothing without the warning?)

You can create one by putting the mentioned lines

Code: Select all

[em_NOP]
button=
cmd=cd

into a textile called usercmd.ini in the same directory as wincmd.ini.

Or alternatively:
- enter cm_CommandBrowser in the commandline
- select usercmd.ini in the left panel
- [New] "em_NOP" [OK]
- Command: cd
- OK,OK

Regards
Holger

[eugenesv]

You can create one by putting the mentioned lines

Code: Select all

[em_NOP]
button=
cmd=cd

into a textile called usercmd.ini in the same directory as wincmd.ini.

Awesome, thank you very much! I've put the lines, but now I see that I forgot the [em_NOP] header
I bound it to

Code: Select all

cmd=cm_SwitchToNextTab

so that I can use that in addition to "Ctrl-Tab" to switch tabs
Last question — is there a way to make tab do the following

• 1. Switch between command line and main file panel?
  2. Arrow Down key

Also, is semicolon the comment symbol in usercmd.ini or something else? I just want to put several commands by the same name and comment out the ones I don't use to test out different Tab functions.
Thanks again for this fix

[eugenesv]

This gave me the understanding, that all you were interested in was the issue with the tab key

And any ambiguity of that phrase is irrelevant after you read a pretty unambiguous phrase I've already quoted: "other features of invisible panel are less important (would be nice if TC were smart about ".
The fact that you ignored this precise phrase and went on to make a conclusion based on a less precise context-dependent one just further proves my point.

But not a single time you seemed to understand the ambiguous, or at least vague nature of your OP question.

Like you'd know what I understood. Again, my main problem with your initial and subsequent comments is that you insist the request (beyond the tab-switch fix) is impossible to implement because ... OFM and hence wrong.

But you ignored it

Except that I didn't and provided you with 3 options to pick from re how the request can be implemented.

continue to blame me for a single sentence instead

And when you stop repeating your mistake that OFM somehow prevents disabling second pane thus rendering the request incorrect, I'll stop blaming you for this mistake.

rather than the practical issues for TC, which this thread is about.

And yet you're the only one arguing from the general OFM concept. Other users have kindly suggested ways around the issue and even went so far as file a bug.

I also told you that another user interpreted your OP in the same manner.

And yet again, he didn't say "oh noes, that's impossible because OFM"? Nor "well, I don't use it myself, yet I can tell you it's not a problem"

...restrictions or maybe dogmatism was my sentence: "An orthodox file manager just works this way, and that's why it's basically not possible to disable it completely."

That + every other sentence where you say my request is wrong based on this.

you will still have the paths from the invisible panel ... about your mistakable request in the OP.

Except that it's not wrong and invisible panel can behave in a way as to not display those artifacts.

All of your replies are based on this mere statement.

That statement + every other one based off it. I had no problem when you asked what should be done, gave you several options depending on how much effort can be put in there.

All my later responses were based on the difficulty to implement your idea in TC.

One of the options I offered would be to simply "Continue as is except for Tab". What's so difficult about it?

So I tell what all your responses are: your opinion about what an OFM can do and what not.
And I have mine, of course.

Sure thing, except that yours contradict the facts — I've provided enough examples to prove your OFM limitations wrong.

You're trying to prove a point, where there is no point to prove

There is and that point is "OFM does not prevent disabling second panel, as seen in examples A, B, C..."

because TC currently follows that concept,

Except that your understanding of what the concept allows is wrong. Even if TC had my suggested feature implemented, it would also follow that concept, no change there.

as you were demanding that TC should optionally drop the 2nd panel completely

Yes, that would be awesome — I'd love to use all the customization of TC (including F5/F6 copy and keyboard shortcuts to compress files with packer being smart enough to understand it should compress the files to the same folder rather than to the invisible panel etc.) without bothering with the invisible panel. I'd prefer to have a smaller panel showing just the favorite folders without any trees or anything (so I can choose whether to use Ctrl-D shortcut or just click on it).

where I told you to provide alternate solutions for all existing s/t operations, which you didn't.

Except that I already explained that you don't need to provide solutions to all existing s/t operations. It is also possible to have some of them continue to behave as is. Not ideal, but it's still better than having none of them work properly with 2nd panel disabled. It's a typical cost vs benefit tradeoff, and not all operations are of the same value. Like currently the main ones that come to mind are copy/move/archive. Your insistence on a comprehensive solution is just as dogmatic as your argument about OFM concept preventing implementation of disabled 2nd panel.

By the way, here is another idea — if e.g. target panel is disabled, you can just pass the source panel as target to all the operations/addons that require a target panel.
Or silently set the target to be the same path as source (and dynamically change it in the background). So, in this case, the packer addon would use your current folder to create a new archive instead of using that invisible path.
Take your pick.

I'm reading this forum since the beginning, and I think I have a certain idea of what Christian wants in TC and what not, and I know that you best provide a full concept for any suggestions you make here.

And I wouldn't want the amount of work needed for the comprehensive solution to scare him from doing anything. So I'll just leave these several ideas here (will move them to OP later) and let him assess the trade-offs

And where exactly did I mix these?

Everywhere where you invoke the concept of OFM as preventing disabling the second panel and the consequences of such a feature on other operations/addons etc.

you need to MANUALLY provide the target for any t/s op

Not necessarily, for some operations you can AUTOMATICALLY provide the target=source.
For others, yes, instead of manually navigating to the needed folder in the target panel you can just as well manually navigate to that folder in another tab and then point to that tab as the target during operation (for example with a simple 1-9 number of that tab).

If you drop a t/s concept

Yeah, I don't know why you need to make up a new concept. "Disable second pane" is not the same as "drop a t/s concept" whatever you mean by that.

In TC, this would mean dropping any operation like F5/F6, packing, checksums, mime encoding, FTP downloading, etc.

No it wouldn't, for each and every one there is perfectly viable alternative in the one-panel view. IF, of course, that's indeed something you need. For example, I'd prefer to have my FTP two-panel way. F5/F6 I could use to copy/move (i.e. quick&dirty batch rename) files in place.
Or here is another idea — if you need those operations, just enable the second panel again. Problem solved. No need to spend development time adjusting each of those operations to the single panel view.

[milo1012]

If you consider your statement:

Then consider this thread a bump to that bug report
...
If that's too much work (not sure why, but maybe it is) I would be fine if this didn't happen. I can't hit F5/F6 "by accident" when 2nd panel is not visible, which is very much unlike Tab

equal to

And after he'd discovered it, I've done exactly that — specified that tab is the main issue and other features of invisible panel are less important

then I think we found our culprit, communication-wise, as I don't see it to be completely comparable.

But it continued.
You clarified that:

explain that to the Total Commander 32bit version which behaves exactly like I want it to behave

but contradicted with:

all ... was tab-bug" is not the same as "other features of invisible panel are less important (would be nice if TC were smart about ". It's not the same as "nothing" is not the same as "something"

So if you consider "behaves exactly like I wanted" equal to "main issue found, but would be nice to have additional functionality",
then we'd have another round.
I'm tired of this. You tell me that you make non-ambiguous statements, but I tell you that this is not case,
but you continue to blame me for not actually reading your posts.
I suggest that for your next thread you actually keep your posts in a logical, non-ambiguous style.

that you insist the request (beyond the tab-switch fix) is impossible to implement because ... OFM and hence wrong
...
stop repeating your mistake that OFM somehow prevents disabling second pane thus rendering the request incorrect

And again: we're going in circles. I already said in my third post:
"If you can come up with reasonable suggestions for all the places where the target/source concept normally applies, I wouldn't see any problem with your request."
So I think with this I confirmed that it would work, if you provide reasonable alternative concepts.

And yet you're the only one arguing from the general OFM concept.

Because you keep thinking so, although I already explained to you more than once that I argued with the practical problems in TC.
My only OFM statement was the quoted sentence.
Circles...

And yet again, he didn't say "oh noes, that's impossible because OFM"? Nor "well, I don't use it myself, yet I can tell you it's not a problem"
...
Sure thing, except that yours contradict the facts — I've provided enough examples to prove your OFM limitations wrong.
...
There is and that point is "OFM does not prevent disabling second panel, as seen in examples A, B, C..."

Circles again: blaming me again and again for my only sentence in that matter which we talked about earlier.

That + every other sentence where you say my request is wrong based on this.

Alright, that's it, I'm out of here.
I'm not willing to continue on repetitious communication based issues that have an insulting undertone.
Thanks for the nice talk, though.

Last question — is there a way to make tab do the following

1. Switch between command line and main file panel?
2. Arrow Down key

Concerning 1.:
If you have the default quick search options (Ctrl+Alt+Letter),
typing any letter would focus the command line, pressing escape would switch back to file panel.

But for using the tab key, there are the internal commands:
cm_FocusCmdLine
cm_FocusLeft
cm_FocusRight
and maybe also
cm_GoToFirstFile

You can assign them to tab just like any other command.
But you can't "cycle" them, as you would need to check which element has the focus first.
Not sure if TCFS2 with a custom command would help.
Otherwise you probably best use an AHK script which reacts on the tab key.
The same applies to 2.

Also, is semicolon the comment symbol in usercmd.ini or something else?...

It's a standard Windows ini file, like any other ini file used by TC.
So yes, a semicolon at the very start of a line would make that line a comment.

[eugenesv]

I don't see it to be completely comparable

And if you take out weasel-word completely you should see that they are, in fact, comparable. Both specify different issues with different value (to me). The former adds an assessment of whether I consider other issues worth "too much work" — that's the difference.

but contradicted with:

There is no contradiction, but a difference in assumptions. I assumed the 32bit version was disabling the second pane because Tab worked fine. This assumption turned out to be wrong and TC "has a weird artifact of taking into account invisible panel when it should just ignore it".

@So if you consider "behaves exactly like I wanted" equal to "main issue found, but would be nice to have additional functionality"
It'd be equal if my assumption were correct. It's incorrect, so not equal.

You tell me that you make non-ambiguous statements

Not quite, I told you that "a pretty unambiguous phrase" later makes potential ambiguity in the previous mute. After I explicitly state I care about A+B you can't keep saying that I only care about A.

Circles again: blaming me again and again for my only sentence

Not your only sentence, but all the ones based off this that claim request is "mistakable". Oh, wait, we are going in circles

that have an insulting undertone.

I'm sorry, didn't mean to insult you . I was just refuting your arguments.

you can't "cycle" them. Not sure if TCFS2 with a custom command would help.

Ok, thanks for clarification! I'm using TCFS actually for opening my favorite folders in TC with WinKey+# shortcuts Maybe will check it out to see if that indeed is possible. Though at the moment I like the Tab key as a tab cycle, so maybe will just leave it at that.