mc-4.8.14 hangs on select for 10 seconds at startup
I'm working over a Mandriva 2011 distro to get it working just the
way I like it. It came with mc-4.7.53, and it works. I decided to
compile 4.8.14 on the PC, pretty standard stuff:
GNU Midnight Commander 4.8.14
Built with GLib 2.16.6
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;
On startup it hangs for 10 seconds, apparently on a select() call.
I've edited this strace dump for brevity:
[code]
...
04:20:19 open(/dev/ptmx, O_RDWR) = 6
04:20:19 statfs(/dev/pts, {f_type=DEVPTS_SUPER_MAGIC, f_bsize=4096,
f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0},
f_namelen=255, f_frsize=4096}) = 0
04:20:19 ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
04:20:19 ioctl(6, TIOCGPTN, [3])= 0
04:20:19 stat64(/dev/pts/3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
04:20:19 getuid32() = 501
04:20:19 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
04:20:19 connect(7, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110)
= -1 ENOENT (No such file or
directory)
04:20:19 close(7) = 0
04:20:19 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
04:20:19 connect(7, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110)
= -1 ENOENT (No such file or directory)
04:20:19 close(7) = 0
04:20:19 open(/etc/group, O_RDONLY|O_CLOEXEC) = 7
04:20:19 fstat64(7, {st_mode=S_IFREG|0644, st_size=669, ...}) = 0
04:20:19 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7189000
04:20:19 read(7, root:x:0:\nbin:x:1:\ndaemon:x:2:\ns..., 4096) = 669
04:20:19 close(7) = 0
04:20:19 munmap(0xb7189000, 4096) = 0
04:20:19 ioctl(6, TIOCSPTLCK, [0]) = 0
04:20:19 ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
04:20:19 ioctl(6, TIOCGPTN, [3])= 0
04:20:19 stat64(/dev/pts/3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
04:20:19 open(/dev/pts/3, O_RDWR|O_LARGEFILE) = 7
04:20:19 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
04:20:19 pipe([8, 9]) = 0
04:20:19 clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb74f7728) = 12097
04:20:19 write(6, PROMPT_COMMAND=${PROMPT_COMMAND..., 75) = 75
04:20:19 rt_sigaction(SIGINT, {0x8096d10, [], 0}, NULL, 8) = 0
04:20:19 select(9, [6 8], NULL, NULL, {10, 0}) = 1 (in [6], left {9,
998268})
04:20:19 read(6, PROMPT_COMMAND=${PROMPT_COMMAND..., 128) = 76
04:20:19 select(9, [6 8], NULL, NULL, {9, 998268}) = 1 (in [6], left {9,
971360})
04:20:19 read(6, [miven@cobra ~]$ PROMPT_COMMAND..., 128) = 55
04:20:19 select(9, [6 8], NULL, NULL, {9, 971360}) = 1 (in [6], left {9,
971353})
04:20:19 read(6, MPT_, 128) = 4
04:20:19 select(9, [6 8], NULL, NULL, {9, 971353}) = 1 (in [6], left {9,
971347})
04:20:19 read(6, COM, 128)= 3
04:20:19 select(9, [6 8], NULL, NULL, {9, 971347}) = 1 (in [6], left {9,
971341})
04:20:19 read(6, MAN, 128)= 3
04:20:19 select(9, [6 8], NULL, NULL, {9, 971341}) = 1 (in [6], left {9,
971335})
04:20:19 read(6, D;, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971335}) = 1 (in [6], left {9,
971329})
04:20:19 read(6, }', 128)= 3
04:20:19 select(9, [6 8], NULL, NULL, {9, 971329}) = 1 (in [6], left {9,
971323})
04:20:19 read(6, pw, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971323}) = 1 (in [6], left {9,
971317})
04:20:19 read(6, d, 128)= 3
04:20:19 select(9, [6 8], NULL, NULL, {9, 971317}) = 1 (in [6], left {9,
971311})
04:20:19 read(6, 9;, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971311}) = 1 (in [6], left {9,
971305})
04:20:19 read(6, kil, 128)= 3
04:20:19 select(9, [6 8], NULL, NULL, {9, 971305}) = 1 (in [6], left {9,
971299})
04:20:19 read(6, l , 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971299}) = 1 (in [6], left {9,
971293})
04:20:19 read(6, -S, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971293}) = 1 (in [6], left {9,
971287})
04:20:19 read(6, TO, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971287}) = 1 (in [6], left {9,
971281})
04:20:19 read(6, P , 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971281}) = 1 (in [6], left {9,
971275})
04:20:19 read(6, $$, 128) = 2
04:20:19 select(9, [6 8], NULL, NULL, {9, 971275}) = 1
Re: mc is over!?
Bah. Mc is not over. Things change, that's all. I've been into mc since I don't know when. The first time I used it. Mid/late 90s I'm guessing. I saw how it floundered in the 4.6 series. I shrugged and kept tweaking and hacking my version. A few years went by and I looked it up again, purely out of curiosity. I was delighted that someone had given it a full work over into the 4.8 series. There were some persistent, puzzling, and very annoying bugs that are now gone. Excellent work, gentlemen. Thank you very much. My list of personal patches went from ~30 down to ~5, where they sit now, mostly minor interface tweaks. Mc works, and it works very well. If development stagnates for a while, so be it. There is actually very little to do. Mc is as close to perfect as software gets. There will always be bugs and minor tweaks, and that's what needs to be worked on, now and forever. Yes, mc in its current incarnation is a model from the 1990s. I like it that way. I'm not a big fan of C++. I also don't like eye candy in a tool that is all about functionality and utility, and I very much appreciate a file manager that can operate when XWindows cannot, or the system is barely bootable. It's the perfect size: big enough to be feature-rich and highly usable, yet small enough that a single individual can (theoretically) get his head around the entire code base. It's also fun to hack. I cannot guarantee 20hrs/week, but I would be very interested to work through bug reports and small enhancement requests at my own pace, and see what I can get done. As a last thought for this email: I suppose what we have here is a complete lack of consensus as to the direction to take if we were to move into a 5.0 series. My thinking is along the lines of complete modularity: a basic interface design (that already exists) and everything else is plugins. What if I want to use mc for inventory control? Make a plugin to work with SQL instead of filesystem. Perhaps there needs to be room for people to experiment with this sort of thing. A 4.9beta branch that starts off as mess and arguments but slowly gets sorted into something with vision. That's my 2 cents worth. Take care, and best wishes for those who are moving on to bigger and better things. Thank you for your labors. -- Peace and Cheer ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
listbox hotkeys
I use Directory hotlist a lot. Constantly, really.
It's always bugged me that I can only access the
first 10 items with the keys 0-9. After sitting on
my TODO list for about 2 years, I finally had a
scratch at the issue.
Keys a-z are very often used by the menu of the
dialog the listbox is in, but keys A-Z are not.
So I did this:
[code]
--- lib/widget/listbox.c~ 2015-03-20 11:06:04.0 -0700
+++ lib/widget/listbox.c2015-05-24 09:21:52.0 -0700
@@ -328,10 +328,15 @@ listbox_key (WListbox * l, int key)
return MSG_NOT_HANDLED;
/* focus on listbox item N by '0'..'9' keys */
-if (key = '0' key = '9')
+if ((key = '0' key = '9')||(key = 'A' key = 'Z'))
{
int oldpos = l-pos;
-listbox_select_entry (l, key - '0');
+if (key = 'A' key = 'Z') {
+listbox_select_entry (l, key - 55);
+} else {
+listbox_select_entry (l, key - '0');
+}
+
/* need scroll to item? */
if (abs (oldpos - l-pos) WIDGET (l)-lines)
[/code]
Diffed from 4.8.14 tarball.
It seems to work fine. Now I can access the top 36
items instead of just the top 10. But, of course, it
affects all listboxes program-wide. It seems OK to me
so far.
My question this:
Does this seem like a useful feature (ie ticket-worthy)
or am I missing some far-reaching consequence I have not
uncovered yet?
--
Peace and Cheer
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: error or i don't understend some thing
Message: 2 Date: Wed, 24 Dec 2014 20:47:07 +0600 From: Igor) dubrovi...@gmail.com To: mc-devel@gnome.org Subject: error or i don't understend some thing Message-ID: canxhswze4u0ty_f-oxssmsozkuwhtyy2plvoa9tvihdrc-4...@mail.gmail.com Content-Type: text/plain; charset=utf-8 hello, my name is Igor i have a question how can i create file in mc? shift+f4 not working now i using echo flie.name in terminal mode(ctrl+o) mc version 4.8.11 os ubuntu 14.04 shift+F4 is move file for me. If I want to edit a new file I type vim file and hit enter. After that F4 will edit it if it exists. touch file will also create new empty file (easier to type than echo file). -- Peace and Cheer ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Happy 20th Birthday!
On Thu, 30 Oct 2014 05:00:05 -0700, mc-devel-requ...@gnome.org wrote: Today's Topics: 1. Happy 20th Birthday! (Egmont Koblinger) ... Sadly, as this post points out, mc almost died twice already ? and the really sad aspect that casts a shadow to the current birthday is that I personally feel it's dying again for the third time. The initial passion from the new maintainers has faded. They hardly have time to work on the project. Many patches or important bugreports go unnoticed for long months or even years. Some tickets have heated technical discussions between some non-maintainers, yet the maintainers remain silent. Some contributors have already expressed that they've lost motivation due to the lack of response from developers, and alas more (including myself) are likely to follow. (This whole issue has been raised in [5].) I really don't know how this problem could be solved... I'm just hoping that we'll be able to figure out something. Anyways, for now, let's celebrate 20 years of Midnight Commander :) 1994? Yes, there are few records of the history of this obscure code. I've been using mc since the days when it sucked. The 4.6 years were pretty good, it worked well already, and some major things were hacked out. 4.8 series is awesome. I got away from it for a few years, came back, and some clever people had worked it right over. Sure, they missed a few things, but the code cleanup was great. Thank you who ever you are. I would help, I have a bunch of patches I apply to every new version. I don't understand the ticket system. I set one up, someone made a bizarre reply to it, and that's all that happened. I even showed the exact code that accomplished it. Nobody said yes or no, there was no dialog whether it sucked or was good. Someone just told me to make a ticket. Sounds like Russians to me. :) I would love to help. Tell me how. ps I like having my personal hacks for something like mc. It is my file manager. I don't use Nautilus or whatever. Maybe mc-4.8.13 is getting very close to as perfect as software can get. It is very effective. I think forums work better than mailing lists. I want to frame things up and respond to critique. And make it easy to do so. Developers *are* users. mc is not Twinkies(tm) in crisp plastic wrap. It's more like something you cook at home. There ya go. Midnight Commander Cookbook. A million magic hacks. -- Peace and Cheer ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
mc startup with single specified path
Hello.
I'm having some puzzlement over the initial startup behavior of mc-4.8.10
when paths are specified on the command line.
To quote the manual:
[quote]
If both paths are specified, the first path name is the
directory to
show in the left panel; the second path name is the directory
to be
shown in the right panel.
If one path is specified, the path name is the directory to show in
the
active panel; current directory is shown in the passive panel.
If no paths are specified, current directory is shown in the
active
panel; value of other_dir from panels.ini is the directory
to be
shown in the passive panel.
[/quote]
Paragraph #1:
This seems correct and intuitive.
Paragraph #2:
What I *expect* to happen when I specify only one path on the command
line, is for that directory to appear in the left panel with the focus on
it. As it works right now, it appears to be random which panel it shows up
in, and which panel has focus. I know that it depends on the last time I
hit Save Setup and the setting of current_is_left in panels.ini, but it
always seems to do the wrong thing. As a matter of fact, the behavior I'm
witnessing, is that that specified directory appears in the *inactive*
panel, and the CWD appears in the *active* panel. I think that is
counter-intuitive, a bit annoying, and exactly *not* what the manual says.
Paragraph #3:
This also seems correct and intuitive. Resort to default behavior if
nothing is specified.
---
I believe the issue is in midnight.c, static void create_panels(), around
lines 619-624 and 646-651, both bits are identical, and they shouldn't be:
[code]
else/* mc_run_param0 != NULL mc_run_param1
== NULL */
{
/* one argument */
current_dir = NULL; /* assume current dir */
other_dir = (char *) mc_run_param0;
}
[/code]
Is it just me, or does this seem *exactly* backwards?
I've changed these bits like this (the 1st is when the left panel is
active):
[code]
--- midnight.c~ 2013-08-02 11:02:40.0 -0700
+++ midnight.c 2013-10-16 13:59:48.541659334 -0700
@@ -619,8 +619,8 @@ create_panels (void)
else/* mc_run_param0 != NULL mc_run_param1
== NULL */
{
/* one argument */
-current_dir = NULL; /* assume current dir */
-other_dir = (char *) mc_run_param0; /* Wrong. */
+current_dir = (char *) mc_run_param0; /* Left panel gets the
path */
+other_dir = NULL; /* assume other dir */
}
}
else
@@ -648,6 +648,7 @@ create_panels (void)
/* one argument */
current_dir = NULL; /* assume current dir */ ;
other_dir = (char *) mc_run_param0; /* Left panel gets the
path */
+boot_current_is_left = TRUE; /* make left panel active (user
called it, there must be a reason.) */
}
}
[/code]
and it now behaves the way I would expect.
After doing a bit more research, it looks as if create_panels() was
freshly re-written for 4.8.10. In 4.8.9 I see this bit:
[code]
if (mc_run_param0 != NULL)
{
current_dir = NULL;
other_dir = (char *) mc_run_param0;
}
else
{
current_dir = NULL;
other_dir = mc_run_param1;
}
[/code]
Hmmm... Is it even possible to have mc_run_param1 *without* mc_run_param0?
Also, what if both are set? No wonder it got re-written.
--
Peace and Cheer
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
little bug in option.c
I was playing with option.c and ran across this tiny
bug. If you change PANEL_OPTIONS the dialog doesn't
display properly anymore. Atached is the diff to make
it work and be consistent with the way OTHER_OPTIONS
is handled also.
--- mc-cvs-4.6.0-030207/src/option.cSat Dec 7 20:16:30 2002
+++ mc-draft-4.6.0-030207/src/option.c Sun Feb 9 11:16:02 2003
@@ -229,7 +230,7 @@
/* Add checkboxes for panel options */
for (i = 0; i PANEL_OPTIONS; i++) {
check_options[i + OTHER_OPTIONS].widget =
- check_new (PY + (6 - i), PX + 2, XTRACT (i + OTHER_OPTIONS));
+ check_new (PY + (PANEL_OPTIONS - i), PX + 2, XTRACT (i + OTHER_OPTIONS));
add_widget (conf_dlg, check_options[i + OTHER_OPTIONS].widget);
}
}
mouse behavior discussion
Hello. I wonder amongst mc-users, what should the mousewheel do in the panels? Right now, for me, it scrolls by a page every time, and moves the selected along with it. This behavior I do not like, and is always the first patch I apply to fresh cvs. I have two questions: 1. Should mousewheel scroll_by_pages or scroll_by_line? (IMHO that's what that artifact panel_scroll_pages was originally for, although I don't know for sure.) 2. Behavior of panel-selected: In editor the traditional way is to have cursor follow mousewheel to avoid typing in wrong area of file after scrolling with mouse, but in a file listing (in all other file managers I've used), it stays in place while only the listing scrolls. The adjustments are simple, but I'm not sure if others like what it does now, and if so, why. Maybe nobody uses mousewheel? They are so common where I live I throw 2 button mice in garbage :) Please reply to mailing list to help discussion on this matter. Cheers and thank you in advance. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
pre2a Xevent problem?
Oh boy, there's something really wrong here. I just compiled the freshest cvs AS IS, the configure options seemed appropriate to my uses. It works fine from the console, but in a gnome-terminal (mandrake8.2) it seems to buffer Xevents (keyboard and mouse) and then spew them out after about three have happened. I haven't yet had a chance to inspect the problem much closer. Does anyone know where this is coming from? I'm sorry I don't have the time to figure this one out for myself at this point. The closest I can get is that I used to use both --with-x and --with-tm-x-support. Perhaps it has to do with the changes to the default configuration? Cheers. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Panel_Mousewheel_Scroll.patch
Trivial Patch #10262:
This patch scrolls one line at at time instead of one page at a time
when spinning the mousewheel.
Does anyone like it or find it useful?
--- mc-cvs-4.6.0-pre1b-021217/src/screen.c Sun Dec 15 22:42:17 2002
+++ mc-draft-4.6.0-pre1b-021217/src/screen.cTue Dec 17 12:31:22 2002
@@ -2261,11 +2261,22 @@ panel_event (Gpm_Event *event, WPanel *p
/* Mouse wheel events */
if ((event-buttons GPM_B_UP) (event-type GPM_DOWN)) {
- prev_page (panel);
+ if ( panel_scroll_pages ) {
+ panel-top_file -= 1;
+ if (panel-top_file 0) panel-top_file = 0;
+ paint_dir (panel);
+}
return MOU_NORMAL;
}
if ((event-buttons GPM_B_DOWN) (event-type GPM_DOWN)) {
- next_page (panel);
+ if ( panel-count ITEMS (panel) panel_scroll_pages ){
+ panel-top_file += 1;
+ if (panel-top_file panel-count - ITEMS (panel))
+ panel-top_file = panel-count - ITEMS (panel);
+ paint_dir (panel);
+}
return MOU_NORMAL;
}
