Very strange problem with Vim + gnu screen
 

I have keyboard shortcuts to open new "tabs" in Vim and to navigate them: Alt+Left is the same as :tabp and Alt+Right is the same as :tabn.

On GNU screen, I routinely have one file open on the first terminal and random things in other terminals.

Well, I just found out that the Alt+Left and Alt+Right combinations do not work on screen... on the first terminal only. They either have no effect or they seem to delete three lines, or something like that.

I always do eveything in Tilda, but I have tried it on other terminals not Tilda, I have closed Vim and opened random on empty files on the first screen terminal, I have tried many other terminals except the first one and I have tried killing Tilda then restarting it to try it all over again.

It is very consistent: the Alt+Left and Alt+Right combinations ALWAYS and ONLY fail on GNU screen's first terminal.

I've never seen any report like this. Have you?

(Is this gnome?) I guess it is a bug in the GUI driver somewhere. Try to specify Alt-Ctrl-Left or something else to check if that works.

Alt+Left/Right deletes three lines. Ctrl+Alt+Left/Right deletes seven.

And does not navigate tabs. :-\

all i can think of is "libncurses, termcap, bash, vi" are all integral (depending on distro if your not using LFS) can make vi (and other things) act unusual

i've had strange things like having to press Ctrl-L frequently when using a remote computer: when there was something amiss with cursor libs (ie, compiled against diff. version w/in the mix above)

this never happened in the "real hardware color cursor terminal" days. terminals just don't have phy support anymore :)

i assume you know if your (bash is) in posix-C environment and whether your linux remaps keymaps to be "intl compat"

allot of todays intl compat are hacks that "supposedly supply intl users ability to run linux in a foreign lang" (ever used?) but at any rate destroy things

for example: i had a horrid time with wicked depends issues compiling LFS due to intl depends (various .po support various versions demanded). i even had one proggie that required an .m4 during automake which injected in a bug (a bug of tampering LD_PATH having NOTHING to do with intl) no less than about 1000 times checking itself to insure it was present - and if it was would cause build to fail. it was as if it was there to prevent the pkg from building.

i think allot of intl hacks never understood unix they are win95 intl users who somehow got PGP keys from their mom

No, I have no idea about those things you mentioned.

I do have key customizations on ~/.Xmodmap. But still, why would the odd behavior only happen on
GNU screen and even worse, only on the first terminal?

Computers are weird.

obviously If your using X11 or worse X.org (i assume NO you are NOT since you didn't say so): the keys may be stolen before the terminal gets it. if your using Xterm some "stolen keys" are not stolen and passed. some gui have "passkeys" options. whole diff topic and quite a mess additionally.

obviously insure Ctrl-left does not generate Ctrl-A (they can overlap depending)

------------------------

the C library (cursor related and terminal related) has undergone changes since gnu screen was released (complicated code). i assume your aware that might be hit or miss as hackers today do not seem to give a damn what they wreck as long as redhat has a "new more dominant version works for just them in their env"

# objdump -a -x gnuscreen, see what libs, see if these libs have depends and are all met

-----------------
you appear to say it's reproduceable and how, ok

you have not given out versions for others (which gnu screen which linux distro etc), -1 pt

to isolate the problem here is one easy step you can take (and should, since gnu screen use is infrequent though i've used it on very rare occasion)

YOU CAN: run in (older) chroot, see if having a different / (hopefully from, say, older version of a different linux) has the same problem. if it does, then you might begin to blame gnuscreen

YOU CAN: use gdb(1) and trace where the program "filters Ctrl-A Key" ("advertised as only key stolen by gnu screen") and see if Ctrl-left makes it through unharmed. if so - then you'd begin to blame the libc or ncurses or what.

(NOTE!! many distros are famous tamperers of options away from their usual defaults. make sure gnuscreen was not hacked to )

----------------
what else ? i can't think of a think assuming your using a "regular 101 keymap" that generates expected codes for things like Ctrl-A and Ctrl-left

OK. Let's see:

1) The output of objdump is gibberish to me. Should I post it here?

2) I have Screen version 4.02.01 (GNU) 28-Apr-14 on Debian Jessie.

3) What do you mean by "older" chroot? Does that mean I would have to install another different Linux in parallel to debug this? I am not willing to go that far.

4) I don't know how to use gdb, and I do not use Ctrl+a on screen, I use Ctrl-\ (it's next to z on my ABNT2 keyboard).

Thank you for your attention.