Ticket #3770 (new enhancement)
Feature request: allow user to disable % macros on command line only
Reported by: | cri | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Future Releases |
Component: | mc-core | Version: | master |
Keywords: | Cc: | egmont | |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description
It would be useful to have a (runtime) configuration option to disable %x macro substitutions on mc command line (disabling them only there, not in user menu command definitions).
Rationale: I often have a hard time trying to understand why some commands lines don't work the way they are supposed to, just to find out that somewhere in the line there's a % character that is interpreted by mc as the start of a macro.
Since the % macros don't exist in my shell, I never use them in my command lines, so there's no need to have them in mc command lines too.
In fact it is essential that commands typed on the mc command line should work exactly as if they were typed on a regular terminal, without overimposing new syntactic features.
An example: % characters sometimes contained in URLs: even enclosing the URL in single or double quotes doesn't prevent mc from expanding the % macros.
So, it would be useful to have some macro_cl_enable configuration option in the ini file (of course, default on, for backwards compatibility).
Change History
comment:3 in reply to: ↑ 1 ; follow-up: ↓ 4 Changed 8 years ago by cri
Replying to egmont:
My problems with your approach:
- It still doesn't give a clue to new (or novice) users about what's going on, why their % character doesn't work.
Yes. Indeed, the optimal solution from my point of view would be to make macro substitution on the command line an optional feature and have it disabled by default. In my first message I suggested to leave it on, anticipating comments about breaking backwards compatibility, but if there are no such concerns, then it's even better to have it off by default.
- If you turn off this feature permanently, you actually lose a cool and useful feature with no replacement.
To me, it's not cool or useful. It's simply useless and annoying. When I type commands on the command line I am thinking in terms of my usual shell (bash), where % macro substitution doesn't exist, so I don't need that "feature".
In fact, almost all the % macros working on the command line deal with replacing file/directory names from the current/other panel: when I need this kind of magic on my command line, there are already shortcut keys to do it (Ctrl-Enter, Ctrl-X...P etc etc).
- If you plan to toggle this feature (at least every once in a while), you'll never be sure which setting you're currently on
This can apply to any other configuration option, I don't think this is cumbersome at all; but anyway I suspect % macro substitution is a love-or-hate feature, most users would want to have it either always on or always off, so maybe this is not a problem.
Let me offer two ideas for further discussion:
...
I don't think we need any of these features (see above), and I suspect they would imply quite a lot of work to be implemented.
I hope my proposal (just add an ini variable to disable % macros only on the command line) requires less work.
BTW, I forgot to mention an obvious workaround, in case anyone else is interested, to disable % macro substitution temporarily: press Ctrl-O (to hide the panels), enter your command line, enjoy the results, then pres Ctrl-O to get back to the panels.
comment:4 in reply to: ↑ 3 Changed 8 years ago by egmont
Replying to cri:
Yes. Indeed, the optimal solution from my point of view would be to make macro substitution on the command line an optional feature and have it disabled by default.
If we end up going with your proposed config option, I'd probably also vote for changing the default as well. Old users have their configs saved anyway so they won't see a behavior change. Only new users will get the new default, and I think that's fine.
In fact, almost all the % macros working on the command line deal with replacing file/directory names from the current/other panel: when I need this kind of magic on my command line, there are already shortcut keys to do it (Ctrl-Enter, Ctrl-X...P etc etc).
I love (and really rarely use) %t for inserting all the toggled files.
I suspect they would imply quite a lot of work to be implemented.
That's indeed absolutely true. Your proposal is much simpler to implement.
BTW, I forgot to mention an obvious workaround, in case anyone else is interested, to disable % macro substitution temporarily: press Ctrl-O (to hide the panels), enter your command line, enjoy the results, then pres Ctrl-O to get back to the panels.
Just for the record: I, for one, would like to see macro substitution disabled by default, while having a relatively easy way to turn it on for some one-off actions. It's not as easy in this direction as Ctrl-O.
To summarize: I'm not against your proposal, I just would like to have a little brainstorming about other possibilities as well (preferably other mc developers sharing their opinion).
comment:5 Changed 8 years ago by rdmo
Testing some simpler conflicts between the date command and mc's macro expansion...at the full-screen prompt – bash on my system AFAICT – available via Ctrl-O, expansion is done by mcthen date:
# date +%d 09 # date +%%d %d
...and from the single-line prompt on the mc GUI, macro/variable expansion is done for mc first, then date:
# date +%d # date +/the/current/working/directory /the/current/working/directory # date +%%d # date +%d 09
Whether this is a bug or a feature can be argued both ways. The double percentage %% resolves some simpler issues where commands run as typed rather than as calls to run external programs. Perhaps the need for more comprehensive documentation is the issue this bug begins to highlight. More complex examples I cannot suggest at the moment.
Hi,
I really share your concerns and love the idea to improve the situation here.
I'm not sure I like your proposal, though. So I'd prefer to have a little brainstrorming, throwing in some ideas and then choosing one :)
My problems with your approach:
Let me offer two ideas for further discussion: