[dev] [st] Unexpected Insert key behavior in mc
It seems that in current version of st it is impossible to select files in mc using Insert key, instead it enters 4h in command prompt. I do not know why this happens, but I know that this did not happen in 0.2.
Re: [dev] [st] Unexpected Insert key behavior in mc
On Mon, Dec 10, 2012 at 10:08 AM, Edgaras dev...@gmail.com wrote: It seems that in current version of st it is impossible to select files in mc using Insert key, instead it enters 4h in command prompt. I do not know why this happens, but I know that this did not happen in 0.2. Seems this is another shortcoming of the well-intended table of keycode-to-escape sequences in config.h... I submitted a patch last night for the delete keys that didn't work and found another, HOME key issue while writing the submission mail in st / sandy. I'll have to dig into these issues about either the tables' values and/or those kp-appkey tests in kmap() in general even. cheers! mar77i
Re: [dev] [st] delete key didn't work correctly
Now, st's delete key didn't work, and I looked into the code long enough to say with confidence, there's nothing wrong with kmap(). I can see that you change the order of Delete definitions in your patch. Theoretically this should not work because the keypdap column is different. If your patch fixs the problem then we have other problem in kmap. Now great, the next problem is already here, in which HOME isn't working pro- perly in st + sandy, works in xterm and sandy, as well as in st + nano. What value of value of TERM are you using?
Re: [dev] [st] Unexpected Insert key behavior in mc
It seems that in current version of st it is impossible to select files in mc using Insert key, instead it enters 4h in command prompt. I do not know why this happens, but I know that this did not happen in 0.2. I have tested it with the HEAD and works fine for me. What value of TERM do you have?, and are you sure you have installed last version of the terminfo definition?.
Re: [dev] [st] delete key didn't work correctly
On 10 December 2012 13:27, Roberto E. Vargas Caballero k...@shike2.com wrote: Now, st's delete key didn't work, and I looked into the code long enough to say with confidence, there's nothing wrong with kmap(). I can see that you change the order of Delete definitions in your patch. Theoretically this should not work because the keypdap column is different. If your patch fixs the problem then we have other problem in kmap. On my machine, just toggling the keypad values on the delete lines worked at first (the ordering of them doesn't seem to matter for me), but then I did a make install and they stopped working. I copied over some old versions of st terminfo files (I can't remember from when) and they started working again. So is there a bug in the terminfo file also? -- Daniel
Re: [dev] [st] Unexpected Insert key behavior in mc
On Mon, Dec 10, 2012 at 12:32:58PM +0100, Roberto E. Vargas Caballero wrote: It seems that in current version of st it is impossible to select files in mc using Insert key, instead it enters 4h in command prompt. I do not know why this happens, but I know that this did not happen in 0.2. I have tested it with the HEAD and works fine for me. What value of TERM do you have?, and are you sure you have installed last version of the terminfo definition?. I did git pull before compiling today. Since I did not do install previously I have tested it after doing install, thus with updated terminfo, it still does not work correctly. My term is st-256color .
Re: [dev] [st] Unexpected Insert key behavior in mc
On Mon, Dec 10, 2012 at 1:39 PM, Edgaras dev...@gmail.com wrote: I have tested it with the HEAD and works fine for me. What value of TERM do you have?, and are you sure you have installed last version of the terminfo definition?. I did git pull before compiling today. Since I did not do install previously I have tested it after doing install, thus with updated terminfo, it still does not work correctly. My term is st-256color . same here with st-256color. I'm half way planning to look into this once more tonight. Thanks for the hint with mc, I'll use that (beside bash and sandy) for reference. Also also take note of entries in your ~/.terminfo which will take precedence afaik. cheers! mar77i
[dev] [st] [patch] alternate screen selection bugfix
To trace the glitch, I added
fprintf(stderr, %d %d\n, sel.alt, !!IS_SET(MODE_ALTSCREEN));
into the draw() function.
What happens:
1. Start st. Type something: both sel.alt and IS_SET(MODE_ALTSCREEN)
are 0.
2. Run man man. MODE_ALTSCREEN is set to 1.
3. Press LMB. sel.alt is 0, MODE_ALTSCREEN is 1, selection is not
displayed because of the '(sel.alt != 0) ^ alt)' check.
4. Release mouse: sel.alt is set to 1, but selection is still not
displayed.
5. Select again: everything is ok.
After I quit man, MODE_ALTSCREEN is set to 0 and the same thing
happens again, now sel.alt is 1. So selection is displayed only the
second time.
The problem is that sel.alt is set to IS_SET(MODE_ALTSCREEN) only when
selcopy is called, i.e. when mouse button is released. So I moved
sel.alt = IS_SET(MODE_ALTSCREEN) to getbuttoninfo.
Patch is attached.
I also made IS_SET always return 0 and 1 to make things simplier.
diff --git a/st.c b/st.c
index 900b567..04515dc 100644
--- a/st.c
+++ b/st.c
@@ -73,7 +73,7 @@
#define BETWEEN(x, a, b) ((a) = (x) (x) = (b))
#define LIMIT(x, a, b)(x) = (x) (a) ? (a) : (x) (b) ? (b) : (x)
#define ATTRCMP(a, b) ((a).mode != (b).mode || (a).fg != (b).fg || (a).bg !=
(b).bg)
-#define IS_SET(flag) (term.mode (flag))
+#define IS_SET(flag) ((term.mode (flag)) != 0)
#define TIMEDIFF(t1, t2) ((t1.tv_sec-t2.tv_sec)*1000 +
(t1.tv_usec-t2.tv_usec)/1000)
#define VT102ID \033[?6c
@@ -624,6 +624,7 @@ selected(int x, int y) {
void
getbuttoninfo(XEvent *e) {
+ sel.alt = IS_SET(MODE_ALTSCREEN);
sel.ex = x2col(e-xbutton.x);
sel.ey = y2row(e-xbutton.y);
@@ -722,7 +723,6 @@ selcopy(void) {
}
*ptr = 0;
}
- sel.alt = IS_SET(MODE_ALTSCREEN);
xsetsel(str);
}
@@ -869,16 +869,17 @@ bmotion(XEvent *e) {
return;
}
- if(sel.mode) {
- oldey = sel.ey;
- oldex = sel.ex;
- getbuttoninfo(e);
+ if(!sel.mode)
+ return;
- if(oldey != sel.ey || oldex != sel.ex) {
- starty = MIN(oldey, sel.ey);
- endy = MAX(oldey, sel.ey);
- tsetdirt(starty, endy);
- }
+ oldey = sel.ey;
+ oldex = sel.ex;
+ getbuttoninfo(e);
+
+ if(oldey != sel.ey || oldex != sel.ex) {
+ starty = MIN(oldey, sel.ey);
+ endy = MAX(oldey, sel.ey);
+ tsetdirt(starty, endy);
}
}
@@ -1510,7 +1511,7 @@ tsetmode(bool priv, bool set, int *args, int narg) {
case 1049: /* = 1047 and 1048 */
case 47:
case 1047: {
- alt = IS_SET(MODE_ALTSCREEN) != 0;
+ alt = IS_SET(MODE_ALTSCREEN);
if(alt)
tclearregion(0, 0, term.col-1,
term.row-1);
if(set ^ alt) /* set is always 1 or 0
*/
@@ -2603,9 +2604,9 @@ drawregion(int x1, int y1, int x2, int y2) {
int ic, ib, x, y, ox, sl;
Glyph base, new;
char buf[DRAW_BUF_SIZ];
- bool ena_sel = sel.bx != -1, alt = IS_SET(MODE_ALTSCREEN) != 0;
+ bool ena_sel = sel.bx != -1;
- if((sel.alt != 0) ^ alt)
+ if(sel.alt ^ IS_SET(MODE_ALTSCREEN))
ena_sel = 0;
if(!(xw.state WIN_VISIBLE))
return;
Re: [dev] [st] Unexpected Insert key behavior in mc
Greetings. On Mon, 10 Dec 2012 15:05:42 +0100 Martti Kühne mysat...@gmail.com wrote: On Mon, Dec 10, 2012 at 1:39 PM, Edgaras dev...@gmail.com wrote: I have tested it with the HEAD and works fine for me. What value of TERM do you have?, and are you sure you have installed last version of the terminfo definition?. I did git pull before compiling today. Since I did not do install previously I have tested it after doing install, thus with updated terminfo, it still does not work correctly. My term is st-256color . same here with st-256color. I'm half way planning to look into this once more tonight. Thanks for the hint with mc, I'll use that (beside bash and sandy) for reference. Also also take note of entries in your ~/.terminfo which will take precedence afaik. I now applied your patch correctly. Because it wasn’t a proper patchfile I had to manually apply it. This big array was an invention of k0ga. He should get it right. I will only intervene, if some key combination I use does not work. Sincerely, Christoph Lohmann
Re: [dev] [st] Unexpected Insert key behavior in mc
I did git pull before compiling today. Since I did not do install previously I have tested it after doing install, thus with updated terminfo, it still does not work correctly. My term is st-256color . same here with st-256color. I'm half way planning to look into this once more tonight. Thanks for the hint with mc, I'll use that (beside bash and sandy) for reference. Also also take note of entries in your ~/.terminfo which will take precedence afaik. Could you send here the output of infocmp command?. If Insert or delete are not working is due some mismatch between the values generated by st and the terminfo entry. For delete the important value is dhc1, that should be \E[P; in the instert case the important value is ich1, that should be \E[2~. You can test what values st is generating using cat: cat /dev/tty ^[= #this sequence enables the keypad application mode ^[[1h #this sequence enables the cursor application mode #you can check now what values each key generate ... (^[ of counse means the esc key)
Re: [dev] [st] delete key didn't work correctly
On my machine, just toggling the keypad values on the delete lines worked at first (the ordering of them doesn't seem to matter for me), but then I did a make install and they stopped working. I copied over some old versions of st terminfo files (I can't remember from when) and they started working again. So is there a bug in the terminfo file also? You can follow the discussion about this issue in Unexpected Insert key behavior in mc thread, and if you can follow the steps that I give there and send here the information, it should be great. Thanks
Re: [dev] [st] [patch] alternate screen selection bugfix
Greetings. On Mon, 10 Dec 2012 20:46:11 +0100 p37si...@lavabit.com wrote: Patch is attached. Thank you very much for this patch! That was a really nasty bug. Of course the patch is now applied in tip. Sincerely, Christoph Lohmann
Re: [dev] [st] Unexpected Insert key behavior in mc
On Mon, Dec 10, 2012 at 3:43 PM, Roberto E. Vargas Caballero k...@shike2.com wrote: Could you send here the output of infocmp command?. If Insert or delete are not working is due some mismatch between the values generated by st and the terminfo entry. For delete the important value is dhc1, that should be \E[P; in the instert case the important value is ich1, that should be \E[2~. You can test what values st is generating using cat: cat /dev/tty ^[= #this sequence enables the keypad application mode ^[[1h #this sequence enables the cursor application mode #you can check now what values each key generate Guys, um Since we had these two discussions goin on parallel, my guts told me to revert my patch to config.h today. Then I did something a bit different. It now works for both sandy and mc correctly, likewise for DEL, INS and HOME which were making trouble yesterday. Attached is the patch which works here. Please test and report back. cheers! mar77i navigation-keys-fix-2.diff Description: Binary data
Re: [dev] [st] Unexpected Insert key behavior in mc
Since we had these two discussions goin on parallel, my guts told me
to revert my patch to config.h today. Then I did something a bit
different. It now works for both sandy and mc correctly, likewise for
DEL, INS and HOME which were making trouble yesterday. Attached is the
patch which works here. Please test and report back.
Your patch is changing the idea of the table, and making others keys don't
work. Taken from the comment in config.def.h:
* keypad value:
* * 0: no value
* * 0: keypad application mode enabled
* * = 2: term.numlock = 1
* * 0: keypad application mode disabled
So, the changes:
diff --git a/st.c b/st.c
index fc64a77..43ce496 100644
--- a/st.c
+++ b/st.c
@@ -2737,12 +2737,12 @@ kmap(KeySym k, uint state) {
if(!match(mask, state))
continue;
- if(kp-appkey 0) {
+ if(kp-appkey 0) {
if(!IS_SET(MODE_APPKEYPAD))
continue;
if(term.numlock kp-appkey == 2)
continue;
- } else if (kp-appkey 0 IS_SET(MODE_APPKEYPAD)) {
+ } else if (kp-appkey 0 IS_SET(MODE_APPKEYPAD)) {
continue;
}
are making the table act in the reverse mode, changing it to:
* keypad value:
* * 0: no value
* * 0: keypad application mode enabled
* * = 2: Does not matter because it is impossible enter in the first if...
* * 0: keypad application mode disabled,
Doing that XK_KP_0 until XK_KP_9 are not working any more, and for example
XK_End change its behaviour.
Please, could you send the information (infocmp and cat /dev/tty) I request
in the previous mail?. I suspect that maybe sandy is not writing the
sequence smkx, that is the sequence needed for putting the keypad in
application mode. I just have tested all the keys before these last patches
and it seems they were working fine.
