bug#41640: 28.0.50; shell startup very slow when init file is used

[Pip Cet]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pip Cet <pipcet@gmail.com>
>> Cc: jsynacek@redhat.com,  41640@debbugs.gnu.org
>> Date: Fri, 05 Jun 2020 08:30:11 +0000
>> 
>> > The code and the comments don't say why we used sleep-for, which your
>> > patch removes.  Did you succeed in understanding what was that for,
>> > and if so, can you describe that reason and the rationale for removing
>> > the sleep?
>> 
>> I'll try. (According to git, this code has been here since 1990).
>
> Yes.  But Jim Blandy, who clearly had some problem he tried to solve,
> didn't describe the problem itself, just the solution.

Thanks for calling me out on that. Yes, you're right, we don't know why
the code has been like this for 30 years.

>> The code inserted the file contents of the startfile at (point-max)
>> in the comint *output* buffer. I believe the concern was that
>> insert-file-contents would accept process output, corrupting the
>> start file, and it's possible this may happen, at least with tramp
>> handlers. Therefore, to avoid the process output being sent back to
>> the process, I think the sleep-for was added as a way to ensure the
>> program was done displaying the prompt.
>
> So you are saying that the wait is there to allow us to receive the
> shell's prompt, so that the contents of start file don't mix with that
> prompt?

Sorry, I should have been clearer: this is speculation. I'm not prepared
to suggest the patch for master until I've at least tried to reproduce
the original problem using file handlers.

There's also an alternative explanation, which is that the systems
available back then might have discarded input arriving before the
prompt was first written. But, if that's the case today, it's likely to
be done for a reason, and we shouldn't try to prevent it.