* cc: onlyjob@… (added)
* priority: minor => major
Comment:
This is more serious than it looks.
Create nested folder structure with the following command:
{{{
for n in $(seq 100); do DN="${DN}/notsolongdirnametotestnested_$n";
done; mkdir -p "./${DN}"
}}}
and then enter as deep as possible using mc. Around #25 I feel slowdown,
but entering one between #34 and #40 breaks the panels. Then MC hang when
I press "Ctrl+o" to hide/restore panels.
Sometimes it print out "Warning: Cannot change to..."
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:11>
Midnight Commander <http://www.midnight-commander.org>
Midnight Development Center
Comment (by egmont):
About the performance: I have the same problems with bash 3.2.48, tracing
mc shows it spends way too much time in feed_subshell(). I cannot
reproduce the speed problem with bash 4.0.38, 4.1 or 4.2, they are all
very fast.
The "cannot change to..." is indeed another problem, I guess we're hitting
the OS limit on path length or something like that.
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:12>
Comment (by onlyjob):
If you try to enter long nested directories with MC with subshell enabled
(bash 4.2) you will feel slowdown. Perhaps it was worse with older bash
but most recent bash didn't make this problem go away.
It has nothing to do with OS limit and apparently only a problem with
bash. (I couldn't reproduce with other shells).
I think partially this problem because MC changing current working
directory by passing full path to subshell.
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:13>
* version: 4.7.1 => 4.8.2
Comment:
setting version to 4.8.2, since latest release is affected as well.
I can not change to 33rd directory if hierarchy created as described in
comment 11.
Hiding panels hang MC.
Just a thought - perhaps 'cd' algorithm can be optimised to change only
from current working directory rather than from root (which implies using
the longest path for every 'cd' operation).
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:14>
Comment (by pytnik89):
I have the same problem with version 4.8.15. MC enters in directories very
slow, but without subshell (mc -u) all works perfectly. Is the way to
solve it?
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:15>
Comment (by zaytsev):
Try `zsh`? Use `mc -u`?
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:16>
Comment (by pytnik89):
Replying to [comment:16 zaytsev]:
> Try `zsh`? Use `mc -u`?
Of course I did. I use zsh. And with 'mc -u' all is perfect.
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:17>
Comment (by zaytsev):
Oh, if you '''already''' use `zsh`, then it's sad. I'm not sure what we
can do about that at `mc` side. The best solution I think would be to
profile the shells to see why they are so slow at `cd`'ing and try to fix
this. The alternative suggestion of using relative paths sounds like
something that's going to be difficult to get right and will probably work
unreliably.
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:18>
Comment (by pytnik89):
Replying to [comment:18 zaytsev]:
> Oh, if you '''already''' use `zsh`, then it's sad. I'm not sure what we
can do about that at `mc` side. The best solution I think would be to
profile the shells to see why they are so slow at `cd`'ing and try to fix
this. The alternative suggestion of using relative paths sounds like
something that's going to be difficult to get right and will probably work
unreliably.
Thx for u reply, Yes it's a problem of zsh, and specialy with it zsh-
suggestion plugin.
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:19>
* cc: baltazar.bz@… (added)
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:20>
Comment (by balta2ar):
> I'm not sure what we can do about that at mc side
@zaytsev It is true that zsh plugins like zsh-autosuggestions and z are
contributing to the delay here. But on the other hand, I think that there
IS something we could do on mc side.
zsh has this bracketed paste magic mode (https://github.com/zsh-
users/zsh/blob/master/Functions/Zle/bracketed-paste-magic) which can be
used to tell zsh to temporarily stop processing every incoming character.
I believe this could vastly improve the responsiveness of mc+zsh.
I tried to do that by my own. I described my attempts here:
https://github.com/zsh-users/zsh-
autosuggestions/issues/136#issuecomment-220615998. Also see this commit:
https://github.com/balta2ar/mc/commit/f17ebb89791ce5ff64608929f62658fa04f4556d.
Unfortunately, it didn't help in this form and I believe it's just my lack
of understanding how mc handles interaction with a shell and related IO
code.
As you can see, this issue has been attempted to be fixed by several
parties including zsh-autosuggestions (https://github.com/zsh-users/zsh-
autosuggestions/issues/136) and z (https://github.com/rupa/z/issues/191).
They mitigated the issue to some extent but it's still there. On top of
that, other shells seem to be experiencing the same problem:
https://github.com/zeit/hyper/issues/1276
Taking all that into account, could you please consider using bracket
paste magic with zsh as a special case?
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:21>
Comment (by zaytsev):
I'm not quite sure what do you want us to do. It seems that you've tried
bracketed paste mode for zsh, and it didn't make any difference, or did I
get it wrong? Besides, I'm unconvinced that we should even be doing
something like that at mc side in the first place.
How about resource hungry plugins trying to detect that cd command comes
from mc and disable themselves ;-) ? It is actually very easy, the cds we
send are always preceded with a space, and that's very rarely done by
humans. Maybe introduce additional flag, like disable suggestions on a cd
preceded with space...
--
Ticket URL: <http://www.midnight-commander.org/ticket/2072#comment:22>