Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
10-18-2015, 09:52 PM
|
#1
|
Senior Member
Registered: Aug 2005
Location: Brazil
Distribution: Debian
Posts: 1,552
Rep: 
|
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?
|
|
|
10-21-2015, 06:53 AM
|
#2
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 24,215
|
(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.
|
|
|
10-21-2015, 11:49 PM
|
#3
|
Senior Member
Registered: Aug 2005
Location: Brazil
Distribution: Debian
Posts: 1,552
Original Poster
Rep: 
|
Alt+Left/Right deletes three lines. Ctrl+Alt+Left/Right deletes seven.
And does not navigate tabs. :-\
|
|
|
10-23-2015, 09:05 PM
|
#4
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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 
|
|
1 members found this post helpful.
|
10-23-2015, 09:10 PM
|
#5
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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
|
|
|
10-23-2015, 09:13 PM
|
#6
|
Senior Member
Registered: Aug 2005
Location: Brazil
Distribution: Debian
Posts: 1,552
Original Poster
Rep: 
|
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.
|
|
|
10-23-2015, 09:25 PM
|
#7
|
Member
Registered: Oct 2014
Location: U.S.A.
Distribution: mixed, mostly debian slackare today
Posts: 207
Rep: 
|
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
Last edited by debguy; 10-23-2015 at 09:26 PM.
|
|
|
10-23-2015, 09:35 PM
|
#8
|
Senior Member
Registered: Aug 2005
Location: Brazil
Distribution: Debian
Posts: 1,552
Original Poster
Rep: 
|
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.
|
|
|
All times are GMT -5. The time now is 10:49 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|