I didn't seem to get your mail On Wed, Dec 13, 2023 at 07:36:32PM -0500, Thomas Dickey wrote: > On Wed, Dec 13, 2023 at 11:09:41PM +0100, наб wrote: > > On Wed, Dec 13, 2023 at 03:49:48PM +0100, наб wrote: > > > On Wed, Dec 13, 2023 at 02:09:35PM +0100, наб wrote: > > > > On Tue, Dec 12, 2023 at 08:30:02PM -0500, Thomas Dickey wrote: > > > > > mouseinterval(0) tells it to not wait for mouse events, > > > > Well, mouseinterval(3curses) says > > > > Use mouseinterval(0) to disable click resolution. > > > > which is different from "not wait for mouse events". > > > Even funnier, it also says that > > > The mouseinterval function sets the maximum time (in thousands of > > > a second) that can elapse between press and release events for them to > > > be recognized as a click. > > > and it appears to only actually be used for coalescing adjacent click > > > events into double and triple clicks (testing confirms this), > > > so the manual sure reads like disinformation. > > Okay so it does appear to be true... on NetBSD. > > > > Admittedly, curses_mouse(3) simultaneously says > > "There is currently no actual mouse support" and > > "The mouse functions were added in NetBSD 10.0"; > > the default is 200ms. > I've noticed that they added stubs (mainly to allow some programs to link), > but probably won't take a close look until NetBSD 10.0 is actually released. > > [...] > > So I'd hold off on discussing what NetBSD curses does, until they get around > to actually doing it. You're right; I had installed and linked to pkgsrc ncurses 6.2, but man mouseinterval showed me the the NetBSD curses manual.
Indeed, NetBSD 10 RC1 curses still doesn't have mouse support at all. > > Why do I have to learn of this by gruesome experimentation > > (the ISO was 743.78M 33.8KB/s in 5h 39m) > > and an off-hand comment instead of this being in the manual? > This particular function is little used, but generally speaking, > having an idea of how click-resolution _has_ to be computed > (like function-key stuff), it's not effective to use zero-delays. > > Currently it's used in one test program, and I see that it's using zero > there (I didn't write that one, but have made several corrections to it - > overlooked this detail). It's also used in many other programs with 0 because the default value of 166 adds a 166ms delay after each click where nothing happens, and this is obviously unacceptable: https://codesearch.debian.net/search?q=mouseinterval%280&literal=1 To re-iterate, mouse(3ncurses) says of mouseinterval(): The mouseinterval function sets the maximum time (in thousands of a second) that can elapse between press and release events for them to be recognized as a click. Use mouseinterval(0) to disable click resolution. this simply doesn't appear to be true. Oddly, you say it does this (above) but suggest it doesn't: > > > > > I'd have used a 5msec delay (or 1msec for "modern" computers :-) which corresponds to a clicking frequency of 200Hz and 1kHz. Which obviously isn't realistic. Since you yourself said "use strace", here's a strace that trivially proves this: poll([{fd=0, events=POLLIN}], 1, 0) = 0 (Timeout) <0.000013> rt_sigaction(SIGTSTP, {sa_handler=0x7f1db7eaffe0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f1db7cb7fd0}, NULL, 8) = 0 <0.000012> read(0, "\33", 1) = 1 <1.157825> poll([{fd=0, events=POLLIN}], 1, 1000) = 1 ([{fd=0, revents=POLLIN}]) <0.000176> read(0, "[", 1) = 1 <0.000169> poll([{fd=0, events=POLLIN}], 1, 1000) = 1 ([{fd=0, revents=POLLIN}]) <0.000169> read(0, "M", 1) = 1 <0.000024> read(0, " :#", 3) = 3 <0.000166> poll([{fd=0, events=POLLIN}], 1, 166) = 0 (Timeout) <0.166421> read(0, "\33", 1) = 1 <5.766872> poll([{fd=0, events=POLLIN}], 1, 1000) = 1 ([{fd=0, revents=POLLIN}]) <0.000178> read(0, "[", 1) = 1 <0.000178> poll([{fd=0, events=POLLIN}], 1, 1000) = 1 ([{fd=0, revents=POLLIN}]) <0.000169> read(0, "M", 1) = 1 <0.000106> read(0, "#:#", 3) = 3 <0.000023> poll([{fd=0, events=POLLIN}], 1, 166) = 0 (Timeout) <0.166414> rt_sigaction(SIGTSTP, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f1db7cb7fd0}, {sa_handler=0x7f1db7eaffe0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f1db7cb7fd0}, 8) = 0 <0.000172> this corresponds to (1.5s after program startup): mousedown, ~6s of delay, mouseup. We can observe that after the mousedown is read fully, the 166ms delay lapses, but getch() ignores this goes into read(). When the mouseup arrives 5.76s later, it's read fully, the 166ms delay lapses, and getch() correctly returns KEY_MOUSE with BUTTON1_CLICKED. Indeed, what the mouse interval appears to do is: (a) coalesce multiple consecutive click events into DOUBLE_CLICKED/TRIPLE_CLICKED ‒ indeed, with mouseinterval(0), I cannot double-click, and with mi(500) I can double-click at 2Hz. (b) make single CLICKED detexion reliable, as you note: > > And in a quite-slow VM, under X and uxterm, > > mouseinterval(0) works sporadically but mouseinterval(5) works always. The ktrace from ncurses 6.2 on NetBSD under its distro X and uxterm demonstrates (b) and demonstrates a drastically different reporting behaviour(?) which may explain why we seem to disagree here. (I had set mouseinterval(500) (0x1f4) for the trace, and deleted lines with "gettimeofday"): 506 506 urlview-n-500 0.000010470 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 10.335101802 GIO fd 0 read 1 bytes "\^[" 506 506 urlview-n-500 0.000008600 CALL poll(0xbfb01cbc,1,0x3e8) 506 506 urlview-n-500 0.000010120 RET poll 1 506 506 urlview-n-500 0.000008270 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 0.000010430 GIO fd 0 read 1 bytes "[" 506 506 urlview-n-500 0.000007790 CALL poll(0xbfb01cbc,1,0x3e8) 506 506 urlview-n-500 0.000009060 RET poll 1 506 506 urlview-n-500 0.000007880 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 0.000008930 GIO fd 0 read 1 bytes "<" 506 506 urlview-n-500 0.000009330 CALL read(0,0xbfb01c78,1) 506 506 urlview-n-500 0.000008920 GIO fd 0 read 1 bytes "0" 506 506 urlview-n-500 0.000008510 CALL read(0,0xbfb01c79,1) 506 506 urlview-n-500 0.000009070 GIO fd 0 read 1 bytes ";" 506 506 urlview-n-500 0.000008210 CALL read(0,0xbfb01c7a,1) 506 506 urlview-n-500 0.000012360 GIO fd 0 read 1 bytes "2" 506 506 urlview-n-500 0.000008460 CALL read(0,0xbfb01c7b,1) 506 506 urlview-n-500 0.000009460 GIO fd 0 read 1 bytes "5" 506 506 urlview-n-500 0.000008230 CALL read(0,0xbfb01c7c,1) 506 506 urlview-n-500 0.000009370 GIO fd 0 read 1 bytes ";" 506 506 urlview-n-500 0.000008530 CALL read(0,0xbfb01c7d,1) 506 506 urlview-n-500 0.000009390 GIO fd 0 read 1 bytes "3" 506 506 urlview-n-500 0.000008280 CALL read(0,0xbfb01c7e,1) 506 506 urlview-n-500 0.000009380 GIO fd 0 read 1 bytes "M" 506 506 urlview-n-500 0.000007950 CALL poll(0xbfb01cbc,1,0x1f4) 506 506 urlview-n-500 0.000008680 RET poll 1 506 506 urlview-n-500 0.000008260 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 0.000008960 GIO fd 0 read 1 bytes "\^[" 506 506 urlview-n-500 0.000007760 CALL poll(0xbfb01cbc,1,0x3e8) 506 506 urlview-n-500 0.000008330 RET poll 1 506 506 urlview-n-500 0.000008340 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 0.000008850 GIO fd 0 read 1 bytes "[" 506 506 urlview-n-500 0.000007790 CALL poll(0xbfb01cbc,1,0x3e8) 506 506 urlview-n-500 0.000008280 RET poll 1 506 506 urlview-n-500 0.000007840 CALL read(0,0xbfb01d0c,1) 506 506 urlview-n-500 0.000008730 GIO fd 0 read 1 bytes "<" 506 506 urlview-n-500 0.000008220 CALL read(0,0xbfb01c78,1) 506 506 urlview-n-500 0.000008970 GIO fd 0 read 1 bytes "0" 506 506 urlview-n-500 0.000007900 CALL read(0,0xbfb01c79,1) 506 506 urlview-n-500 0.000008820 GIO fd 0 read 1 bytes ";" 506 506 urlview-n-500 0.000007840 CALL read(0,0xbfb01c7a,1) 506 506 urlview-n-500 0.000008760 GIO fd 0 read 1 bytes "2" 506 506 urlview-n-500 0.000007900 CALL read(0,0xbfb01c7b,1) 506 506 urlview-n-500 0.000008760 GIO fd 0 read 1 bytes "5" 506 506 urlview-n-500 0.000008010 CALL read(0,0xbfb01c7c,1) 506 506 urlview-n-500 0.000008780 GIO fd 0 read 1 bytes ";" 506 506 urlview-n-500 0.000007940 CALL read(0,0xbfb01c7d,1) 506 506 urlview-n-500 0.000009140 GIO fd 0 read 1 bytes "3" 506 506 urlview-n-500 0.000007950 CALL read(0,0xbfb01c7e,1) 506 506 urlview-n-500 0.000008980 GIO fd 0 read 1 bytes "m" 506 506 urlview-n-500 0.000007850 CALL poll(0xbfb01cbc,1,0x1f4) 506 506 urlview-n-500 0.509193233 RET poll 0 506 506 urlview-n-500 0.000065160 CALL __sigaction_sigtramp(SIGTSTP,0xaf8114a4,0xaf81148c,0xaf657c40,1) 506 506 urlview-n-500 0.000010550 RET __sigaction_sigtramp 0 506 506 urlview-n-500 0.000009170 CALL poll(0xbfb01c40,1,0) 506 506 urlview-n-500 0.000012330 RET poll 0 506 506 urlview-n-500 0.000013870 CALL poll(0xbfb01c40,1,0) 506 506 urlview-n-500 0.000008820 RET poll 0 For the same sequence of events, we see a completely different behaviour: the first read takes 10s, and everything else is <1ms. So, AFAICT, uxterm didn't report a separate mousedown/mouseup, and just reported both after mouseup. My tests on ncurses under Debian were conducted with st https://git.suckless.org/st/file/st.info.html so maybe the reporting mode is the critical difference? The manual ought to be updated to say that: this is the delay between consecutive clicks to get coalesced into DOUBLE/TRIPLE_CLICKED if you don't care about those events, set it to 5 (not 0) because on some terminals 0 renders single CLICKED parsing unreliable (I defer to you to know why the latter is true, it doesn't immediately jump out to me ‒ barring terminfo/terminal-probing effects ‒ why the poll() returning 0 in the second trace would behave different than in the first). Best, наб
signature.asc
Description: PGP signature
