[TC 11.02] cm_RenameOnly Issue

[sirksel]

I remapped Shift+X to cm_RenameOnly, as follows:
s+x=cm_RenameOnly

...but now it will not let you type a capital X in the filename as you are renaming. Actually, capital X suddenly replaces the entire filename you are trying to rename, even though no text is selected. It seems to be unique to this character, and only when this shortcut mapping is in effect. Try making the capital X the third or fourth character you type as you are renaming the file.

Are you all able to reproduce this? It seems to me the intended behavior is that TC would ignore such shortcut keys when editing the filename, correct?

Many thanks for the help.

[Dalai]

Recently there was a similar topic where someone remapped a single letter character to this command. IMO it's a bad idea to do something like this.

Regards
Dalai

[Horst.Epp]

Sorry, but what a strange idea to define capital x as hotkey.

[sirksel]

Sounds like you all don't use Vi/Vim or one of those modal editors, where single letter commands are common. I tend to place the most commonly used keys as close to home row as possible. For example, in gmail (assuming you use a QWERTY/QWERTZ/etc keyboard), have you ever tried using j and k to move through the messages list or to open the next/previous message? It comes from Vim, it's already built-in, and it's fast... because it moves navigation keys to the home row, so you're not constantly picking up your hand.

In TC, because I want to be able to jump to filenames simply by typing their starting letters (in a case-insensitive way), I never map an unmodified alphanumeric key. However, Shift+X (or any other shifted letter) for me is fair game precisely because quick jumping is case-insensitive. Also, I may be an edge case, but I have every combination of every key mapped in TC. They're all mapped logically, so they're easy to memorize. All modded varieties of the C key (s+c, c+c, cs+c, cas+c, etc.) are something about copying. Everything on X is something about cutting/moving/renaming. Everything on V is something about pasting. Everything on N is something about creating a New something. You get the idea. Not as ludicrous as it might seem at first glance.

The reason I reported this behavior separately is because:

1. Out of all the 26 letter keys I've mapped, the cm_RenameOnly function is the only one that has this problem. It happens regardless of which key you map to it. If you map Z, then you can't type a capital Z in the filename without this weird behavior.
2. It only occurs with the shift+key that is mapped to cm_RenameOnly, and not any other mapped Shift+letter key. For example, for me, Shift+D opens the directory hotlist. Yet I can still type a capital D in the cm_RenameOnly box. This issue only affects a single key... the one that activated the renaming. So to me, it seems highly unlikely that the intended behavior was to interrupt your renaming to begin another renaming of the same file.
3. Unlike some of the debates you reference about whether mapped hotkeys should function in the command line or quick view modes, there seems to be no use case I can think of why you would want to execute a hotkey in the 2-3 seconds while you're renaming a single file. Seems like hotkeys should be ignored while such a rename is in progress. (The exception here would be the up and down arrow keys, which by default move to renaming the prev/next file. This makes sense and is a great feature, as it saves a few keystrokes if you're renaming several adjacent files.)

Anyhow, this is why I thought it might be a bug, and that Mr. Ghisler might want to know about it.

[Fla$her]

IMO it's a bad idea to do something like this.

Sorry, but what a strange idea to define capital x as hotkey.

You guys surprise me. Why suddenly, in your opinion, the user cannot use the Shift+letter combinations? I have a lot of these hotkeys, and it's very usable.

If you map Z, then you can't type a capital Z in the filename without this weird behavior.

You may be surprised, but this is the combination I use for such a command. I'm not puzzling over why it should be Z and not X or something else, because it's (+Z for QWERTZ or +Y for QWERTY) just very usable and is one of the most frequently used (perhaps even the most frequently used) hotkeys.
So the good old solution that I used to use is very simple: Shift+<letter> = em_RenameOnly (cm_RenameOnly).
But in recent years, this hotkey has been executes the script that, in addition, allows me to edit names in some types of non-ZIP archives.

[Dalai]

2sirksel
Well, I don't use vi(m), but I know that these programs have an input mode and a command mode which make the same key do different things. Windows GUI programs rarely use such a concept, and that includes TC. There is just one mode.

Let's assume, TC were to ignore Shift+letter while renaming is active. What if somebody has mapped such a key combination to a different command like showing the file under the cursor in quick view or some external program. Why should TC ignore that key combination just because renaming mode is currently active? It could be fine if TC ignored cm_RenameOnly command while in rename mode, but it's also possible that there are people out there who expect it to work.

Regards
Dalai

[Fla$her]

Why should TC ignore that key combination just because renaming mode is currently active?

Because this is a new window, i.e. an input field. You won't get such a problem on the command line or in the filtering field (cm_QuickFilter/cm_ShowQuickSearch).

[petermad]

2Fla$her

So the good old solution that I used to use is very simple: Shift+<letter> = em_RenameOny (cm_RenameOny).

I thisnk it should say: Shift+<letter> = em_RenameOnly (cm_RenameOnly) - but smart workaround to wrap the cm_command in an em_command

[Fla$her]

2petermad
Fixed. Thanks. I accidentally missed the letter l during manual typing.

[sirksel]

2Dalai
Thanks for your explanation. I do understand your point. I guess I'm thinking that even the j/k shortcuts in gmail are modal to some extent. I agree, there are no explicit modes, but when you're composing a message in gmail, j/k do one thing (type their respective letters) and when you're in the message list, they do another. They are unmodified in both instances. Same with Chrome and Firefox and Edge. If you press space in a text box, it types out a literal space, it you type it while you're browsing a page without a text box in focus, it functions just like PageDown and doesn't require shifting your right hand position. Both are ubiquitous, even in Windows. So... explicitly modal? No. Functionally modal? I would say yes.

Also, as you say, if there's any case for hotkeys to be ignored, it's in cm_RenameOnly, since you're only there for a few seconds. Further, the current behavior of that hotkey doesn't make any sense, as no other hotkey works there... just the one that originally called RenameOnly. And it does something unexpected... it erases the entire filename. Try it and I think you'll see why I thought it was a bug.

2Fla$her
Thank you so much for the workaround! Just to be clear, I just created a custom command [em_RenameOnly] whose definition is cmd=cm_RenameOnly, and then mapped s+x=em_RenameOnly. I can't believe it, but it worked! Now I just wish I knew why. I shouldn't ask too many questions though. I'm just so happy to have a workaround.

For what it's worth, the fact that the workaround works underscores to me that the behavior I originally posted might be unintended and worth a look by Mr. Ghisler, whenever he has time. Low priority now, of course, since there's an easy workaround. You guys are the greatest!

P.S. Would you mind elaborating on the "executes a script" idea, when you have a minute? I'm always looking for good ideas, and you seem to have a lot of them!

[Fla$her]

2sirksel
You're welcome! )

Now I just wish I knew why.

Christian will explain it better. I think this has something to do with the fact that the execution of custom commands is ignored in such input fields, i.e. it is handled differently than for internal ones.

Would you mind elaborating on the "executes a script" idea, when you have a minute?

I think this is not the section where it should be discussed. We have already touched upon this subject here.

I'm always looking for good ideas, and you seem to have a lot of them!

Well, yes, I have enough of them.

[sirksel]

2Fla$her
I read your linked topic. The cartoon was funny, but I didn't see a link that had the script in it. Is it OK to continue that discussion in that thread even though it's old? Even if it relies on other library files and such, I more just was interested in seeing the kinds of things that are possible for rename. I'm sure reading it would solve problems I didn't even know I had. I would just use yours as an idea-starter to modify my own script ecosystem. It's so amazing that you have several hundred scripts. It also makes me feel better for my overgrown directory of bat/cmd files and autohotkey scripts! Thanks again.

[Fla$her]

Is it OK to continue that discussion in that thread even though it's old?

The time of topic creation does not matter. I suggested a more appropriate section there:

(here, for example)

I'm sure reading it would solve problems I didn't even know I had.

There's nothing very impressive there. Just a separate dialog for the object under the cursor in archives that can only be renamed with 7zG and rar.

It's so amazing that you have several hundred scripts. It also makes me feel better for my overgrown directory of bat/cmd files and autohotkey scripts!

[ghisler(Author)]

I think this has something to do with the fact that the execution of custom commands is ignored in such input fields

No, TC uses the same hotkey you define there to switch between selected name and selected name+extension. Which makes sense for something like F2, but not for Shift+letter. That's why it works when you use em_RenameOnly, because then TC doesn't see that the commands invokes the inplace editor and doesn't try to use the hotkey in the text field.

[ghisler(Author)]

This should be fixed in Total Commander 11.03 RC1, please check it!