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