Wed 23 Nov 2016 07:28:14 PM UTC, comment #16:
fixed here:
http://git.savannah.gnu.org/cgit/nano.git/commit/?h=ecea413802314afb1519d7e359c95138632a72fe
|
Tue 22 Nov 2016 08:25:21 PM UTC, comment #15:
sure i'll take care of it
|
Mon 21 Nov 2016 06:44:01 PM UTC, comment #14:
Will you fix configure.ac, Mike? Because I don't understand what's wrong.
|
Sun 20 Nov 2016 11:25:47 AM UTC, comment #13:
turns out Gentoo has those symbols enabled. the difference is that i have a sep libtinfo.so library which ncurses provides optionally. when that's used, things like key_defined aren't in libncurses{,w}.so, they're in the libtinfo{,w}.so library.
in other words, the configure check in nano is broken. all the AC_CHECK_LIB invocations need to include $CURSES_LIB in their link lines.
|
Fri 18 Nov 2016 08:22:29 PM UTC, comment #12:
indeed mine says no:
configure:8505: checking for NCURSESW
configure:8512: $PKG_CONFIG --exists --print-errors "ncursesw"
configure:8515: $? = 0
configure:8529: $PKG_CONFIG --exists --print-errors "ncursesw"
configure:8532: $? = 0
configure:8570: result: yes
configure:9010: result: Using ncursesw as the curses library
configure:9015: checking for use_default_colors in -lncursesw
configure:9050: result: yes
configure:9059: checking for key_defined in -lncursesw
configure:9094: result: no
looking at the ncurses source, key_defined is not exported by default. it's behind NCURSES_SP_FUNCS which is the non-default --enable-sp-funcs option. i guess your system turns it on explicitly.
i'll look into it and see if it changes the ABI and if not, turn it on in Gentoo.
|
Fri 18 Nov 2016 12:23:25 PM UTC, comment #11:
My Manjaro system has ncurses-6.0, but there Ctrl+Space worked fine also before the patch. Running your configure followed by '| grep -i curse' gives this:
checking for NCURSESW... yes
Using ncursesw as the curses library
checking for use_default_colors in -lncursesw... yes
checking for key_defined in -lncursesw... yes
But for you the last line will say "no". Why?
|
Thu 17 Nov 2016 09:02:11 PM UTC, comment #10:
i don't have an opinion on the open/closed status -- feel free to manage as you like :)
i'm using ncurses-6.0 in case that matters.
i vaguely recall up/down arrows not working as it makes it easy to do things like:
- hold ctrl
- press u or k
- press down arrow
- press u or k
- press down arrow
- etc...
- release ctrl
not a big deal ... i can mess with local bindings.
|
Thu 17 Nov 2016 08:38:10 PM UTC, comment #9:
(I normally close bugs when the fix has been released.)
If you use ncurses, how come then that HAVE_KEY_DEFINED is not defined in your build? The AC_CHECK_LIB() is not detecting it?
(The Ctrl+Left/Right keys work since about nano-2.5.0. The Ctrl+Up/Down ones are very recent.)
|
Thu 17 Nov 2016 08:04:46 PM UTC, comment #8:
i don't use slang ... i see no value (to me) in that project. i use ncurses everywhere.
here's my configure line:
./configure \
--enable-color \
--enable-multibuffer \
--enable-nanorc \
--disable-wrapping-as-root \
--enable-libmagic \
--enable-speller \
--disable-justify \
--disable-debug \
--enable-nls \
--enable-utf8 \
--disable-tiny \
--without-slang \
--with-wordbounds
i've never thought to use ctrl+arrow keys before. using current git, the behavior i see:
ctrl+right: same as ctrl+space
ctrl+left: same as alt+space
ctrl+up: jumps up one paragraph
ctrl+down: jumps down one paragraph
i'll prob start using these more :).
|
Thu 17 Nov 2016 05:12:46 PM UTC, comment #7:
So... this means that on your system key_defined() does not exist? Do you use --with-slang? Or is your ncurses somehow trimmed? Or...?
Anyway, fixed in git, f2c72bf.
Thanks for running nano on a strange system. :)
(No need any more to test with xterm or --enable-debug.)
By the way, do Ctrl+Left and Ctrl+Right work normally, jumping words? And do Ctrl+Up and Ctrl+Down jump blocks? Or do all those key combos get grabbed for something else?
|
Thu 17 Nov 2016 02:36:19 PM UTC, comment #6:
thanks, that patch indeed fixed things
i don't have easy access (currently) to xterm to be able to test your previous request ... it was going to be a while before i could set up such a system
|
Thu 17 Nov 2016 07:56:14 AM UTC, comment #5:
I am guessing that attached patch will fix it.
(file #38999)
|
Wed 16 Nov 2016 07:46:32 PM UTC, comment #4:
Do things work correctly when you run nano in an xterm? Here it does. But if your Konsole is doing it wrong, I can't imagine that an xterm would do it right...
Please compile with --enable-debug --disable-libmagic, run src/nano README 2>TRAIL, type Ctrl+Space Ctrl+Space Alt+Space AAA Ctrl+Left Ctrl+Right Ctrl+Up Ctrl+Down ^X N. Then run 'grep -A3 "hex codes" TRAIL', and paste the output.
|
Wed 16 Nov 2016 05:53:25 PM UTC, comment #3:
yes, same behavior with --ignorercfiles
i'm using SecureShell (hterm) and Konsole and both exhibit this behavior
after that patch, ctrl+space still goes backwards, but now it also seems to highlight the text that it went back over as it goes ?
not sure what info to provide ... i know the key sequences can be tricky to handle
|
Wed 16 Nov 2016 08:42:03 AM UTC, comment #2:
Hi Mike,
Hm. I'm not seeing this. Ctrl+Space always jumps a word forward for me, in all nanos, both on a console and in a Gnome Terminal. Do you also see the misbehavior when you use --ignorercfiles?
In any case, please try the attached patch.
(file #38985)
|
Tue 15 Nov 2016 11:09:33 PM UTC, comment #1:
simple example of what i mean:
$ echo 'a b c d e f' > foo
$ nano-2.6.3 foo
<hitting ctrl+space will jump from a to b to c to e>
$ nano-2.7.0 foo
<hit right arrow key a few times>
<hitting ctrl+space will jump back by words instead of forward>
|
Tue 15 Nov 2016 11:07:42 PM UTC, original submission:
bisecting down found this commit:
c661506681077c811e96483cafd93fbf50c1bf77
before that, alt+space would go back by one word while ctrl+space would go forward by one word. now they both go back by one word.
|