The large recent update to ncurses (stable) and other basic stuff (where can I look up the install historye?) has spoiled mc's behaviour in Terminal.app, in that cursor keys will not work anymore. They still do with mc in xterm, and they still do with other ASCII-graphical apps running in Terminal, like emacs or elinks, even inside mc's subshell.
In mc's main interface however, pressing a cursor key produces nothing but the letter that corresponds with the intended direction of movement (A, B, C or D), which suggests that mc fails to acknowledge the '^[[' before that letter. Although emacs-keybindings still work, they feel really awkward compared to mc's slick lynx-mode navigation using cursor keys. I have already rebuilt and reinstalled mc, to no avail. Redefining cursor keys through mc's "learn keys" dialog did not work, since the problematic ones will just not show up. Bash-binding e. g. '^[[1;C' or '^[^[[C', rather than '^[[C' only, to forward-char did not help, either. For the case this is just due to other-than-expected configuration on my side, here are some diffs: $ diff -dy ~/.mc_default/ini ~/.mc/ini | grep -Ee ' \|' verbose=1 | verbose=0 confirm_exit=1 | confirm_exit=0 full_eight_bits=0 | full_eight_bits=1 navigate_with_arrows=0 | navigate_with_arrows=1 drop_menus=0 | drop_menus=1 wrap_mode=1 | wrap_mode=-1 show_all_if_ambiguous=0 | show_all_if_ambiguous=1 editor_key_emulation=0 | editor_key_emulation=1 editor_tab_spacing=8 | editor_tab_spacing=4 editor_backspace_through_tabs=0 | editor_backspace_through_tabs=1 editor_fake_half_tabs=1 | editor_fake_half_tabs=0 editor_option_save_mode=0 | editor_option_save_mode=1 editor_option_backup_ext_int=-1 | editor_option_backup_ext_int=126 editor_edit_confirm_save=1 | editor_edit_confirm_save=0 equal_split=1 | equal_split=0 first_panel_size=105 | first_panel_size=54 permission_mode=0 | permission_mode=1 other_dir=/Users/sw | other_dir=/Users/sw/.mc current_is_left=1 | current_is_left=0 case_sensitive=1 | case_sensitive=0 user_mini_status=0 | user_mini_status=1 case_sensitive=1 | case_sensitive=0 list_mode=full | list_mode=user user_mini_status=0 | user_mini_status=1 $ diff -dy /tmp/xterm.stty-a /tmp/Terminal.stty-a | grep -Ee ' \|' 38400 | 9600 59 | 53 echok | -echok -ixany | ixany -imaxbel | imaxbel -brkint | brkint parenb | -parenb <undef>; | ^T; As mc is quite popular and the misbehaviour obvious, I wonder whether other people have encountered it. Maybe I am supposed to stick with xterm? Terminal.app has advantages I value and serves many purposes well, so I do not usually start X11 unless some application explicitely requires it. To the best of my knowledge, mc is none of them. Many thanks in advance for any useful hints. Zoo Loo -- Package manager version: 0.28.6 Distribution version: selfupdate-rsync Sun Mar 22 19:29:37 2009, 10.4, i386 Mac OS X version: 10.4.11 Xcode version: 2.5 gcc version: 4.0.1 (Apple Computer, Inc. build 5370) make version: 3.80 Feedback Courtesy of FinkCommander ____________________________________________________________ GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails ------------------------------------------------------------------------------ _______________________________________________ Fink-beginners mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.beginners
