zooloo wrote: > The large recent update to ncurses (stable) and other basic stuff (where > can I look up the install historye?) The dates of files in /sw/fink/debs would be one way. > 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 > > ____________________________________________________________ > G What do you get from "printenv TERM" when you're under Terminal.app? My recollection is that on 10.4 I had to set TERM to "xterm" or "xterm-color" to get reasonable behavior out of mc.
------------------------------------------------------------------------------ _______________________________________________ Fink-beginners mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.beginners
