Re: Find file dialog in mc-4.6.0-pre3
Hello, Thanks, for tracking this down! I guess I was the one responsible for this bug being introduced. On Sun, 26 Jan 2003, Arpi wrote: Hi, I've scanned a TODO list and found the item - Make find dialog more responsive - inside After 4.6.1 on 4.6.x branch section. But I think the responsiveness of the dialog is unacceptable for the 4.6.0 release. I missed the moment when it became so bad, (may be 1-3 I agree. So i went and hunted down the bug :) It's a nice 100l one, said in MPlayer terminology... In src/key.c, the is_idle() function is broken. It's called by the dialog loop (used by Find File too) to decide if call the callback fv (search for files) or handle the key/mouse events. The original code ends this way: timeout.tv_sec = 0; timeout.tv_usec = 0; select (maxfdp, select_set, 0, 0, timeout); return !FD_ISSET (0, select_set); which is, according to 'man select' broken at 2 points: int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); n is the highest-numbered descriptor in any of the three sets, plus 1. ^^ so it should be: select (maxfdp+1, select_set, 0, 0, timeout); this may work on some select() implementations, i've heard that some ignores the first parameter and calculates it from the fd sets. but it's better fixed. and: FD_ISSET(int fd, fd_set *set); FD_ISSET tests to see if a descriptor is part of the set; this is useful after select returns. so it should be: return !FD_ISSET (input_fd, select_set); (the original code works only if input_fd==0) after changing these, find is responsive again! btw, NOTE: i didn't handled the gpm events, they need extra code, so the current is_idle() should be changed deep. I've just summarized the idea about the bug. If you want, i can prepare a commitable patch. A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Find file dialog in mc-4.6.0-pre3
Hi, Thank you. The code you found is completely broken. However, your changes don't seem to make any difference for me. Could you please send a strange. it solved the problem completely for me, and it seems for others too. Your patch makes the difference when looking for filenames without searching file contents. Searching contents is still not responsive. It makes difference for bot, at least here, but... src/find.c::do_search() tries match on 32 files before it returns, so if scanning 32 files took more than 0.1-1 seconds then it's slow response. the worst case when you search inside a single very big file, it's no way to fix without big changes of teh find.c code. (being able to suspend search inside a file, save the position and then later (next call) continue from that point.) anyway that '32 files in a grpup' approach is quite lame, it would be better to measure time, and update panel/rot.dash and return at every 0.25 seconds or so. Or at least call is_idle() from inside do_search() after each file and return immediately (break the 32 counter) if zero. Applied. Thank you! thanks. By the way, it was my error. I cannot believe I wrote all that. I also wondered when realized those bugs :) A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu However, many people beg for its inclusion in Debian. Why? - Gabucino Because having new software in Debian is good. - Josselin Mouette Because having good software in Debian is new. - Gabucino ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Find file dialog in mc-4.6.0-pre3
Hi, anyway that '32 files in a grpup' approach is quite lame, it would be better to measure time, and update panel/rot.dash and return at every 0.25 seconds or so. Or at least call is_idle() from inside do_search() after each file and return immediately (break the 32 counter) if zero. Maybe this is_idle() checking could be added to the regexp matching code of find.c, so it chould stop matching file immediately when key/mouse event received. Drawback is that matching will be restarted from pos 0 after processed the event :( But it's still better than waiting forever for the search to end... Imho 99% of events is 'cancel' so it should be ok as a hotfix for now. Btw i have some more ideas for the find code, if you don't mind i'll start hacking it. At first, I want that binary file matches show hex file position instead of line number, which is useless. And F3 start viewer in hex mode, at the position of the match. Currently it never shows the match for binary files... anyway the new find-contents code is very nice, compared to the old egrep-hack. A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu However, many people beg for its inclusion in Debian. Why? - Gabucino Because having new software in Debian is good. - Josselin Mouette Because having good software in Debian is new. - Gabucino ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Find file dialog in mc-4.6.0-pre3
Hi, I've scanned a TODO list and found the item - Make find dialog more responsive - inside After 4.6.1 on 4.6.x branch section. But I think the responsiveness of the dialog is unacceptable for the 4.6.0 release. I missed the moment when it became so bad, (may be 1-3 I agree. So i went and hunted down the bug :) It's a nice 100l one, said in MPlayer terminology... In src/key.c, the is_idle() function is broken. It's called by the dialog loop (used by Find File too) to decide if call the callback fv (search for files) or handle the key/mouse events. The original code ends this way: timeout.tv_sec = 0; timeout.tv_usec = 0; select (maxfdp, select_set, 0, 0, timeout); return !FD_ISSET (0, select_set); which is, according to 'man select' broken at 2 points: int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); n is the highest-numbered descriptor in any of the three sets, plus 1. ^^ so it should be: select (maxfdp+1, select_set, 0, 0, timeout); this may work on some select() implementations, i've heard that some ignores the first parameter and calculates it from the fd sets. but it's better fixed. and: FD_ISSET(int fd, fd_set *set); FD_ISSET tests to see if a descriptor is part of the set; this is useful after select returns. so it should be: return !FD_ISSET (input_fd, select_set); (the original code works only if input_fd==0) after changing these, find is responsive again! btw, NOTE: i didn't handled the gpm events, they need extra code, so the current is_idle() should be changed deep. I've just summarized the idea about the bug. If you want, i can prepare a commitable patch. A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
