Easy renaming of files
Egmont Koblinger
egmont at gmail.com
Tue Jan 29 15:08:32 UTC 2013
On Mon, Jan 28, 2013 at 2:58 PM, Felix Miata <mrmazda at earthlink.net> wrote:
> On 2013-01-28 10:45 (GMT+0100) Egmont Koblinger composed:
>
> Marco wrote:
>>
>
> when I hit F6 to rename a file the “to:†field is pre-populated with
>>>
>>> the path of the other panel. That's handy if you want to move files,
>>> but annoying if you want to rename the file and the renaming just
>>> adds an extension or removes two characters at the beginning of a
>>> 50-character file name. If I start typing I have to retype the
>>> entire file name.
>>>
>>
> Is there an easier way to rename files, for instance a shortcut to
>>> pre-populate the field with the current file name?
>>>
>>
> Shift+F6 should do it.
>>
>
> But it doesn't when running on a tty in runlevel[2,3,5] in every distro I
> can recall using. In the tty case it's inexplicably Shift-F4, just like
> copy with edit name instead of Shift-F5 is Shift-F3. Why? I know it has
> something to do with 10 function keys vs. 12 function keys, but shouldn't
> there be a simple solution? Is there?
>
This seems to be a problem with the console-data or kbd or whichever
similar package of Linux distros... They offer multiple keymaps, and define
function keys differently in them.
E.g. type "loadkeys us" -> with the U.S. keymap pressing Shift+F4 will do
what you'd expect from Shift-F6.
But type "loadkeys ru" -> with the Russian keymap Shift+F6 works as
expected.
Seems that the kernel's builtin keymap makes the Shift key offset the
function keys by 10 (drivers/tty/vt/defkeymap.map says «keycode 64 = F6
F16» and later «string F16 = "\033[29~"»), and this is what mc expects too
(mc.lib: «f16=\\e[29~»). Unfortunately, many keymaps, including the
probably most widely used "us" wants to be able to assign separate action
to F11 and Shift+F1, so they shift by 12 and define «keycode 64 = F6 F18».
There's nothing mc could do about this right now, first all the keymaps
should be made consistent.
cheers,
egmont
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20130129/433c744f/attachment.html>
More information about the mc-devel
mailing list