Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100961: Enable ICANON (Bug#6771). Any long line problem must be solved differently.

["Jan Djärv" <jan.h.d@swipnet.se>]

Stefan Monnier skrev 2010-08-04 17.56:
> I agree with the commit that reverts my ICANON change.  Yet:
>
>> There is AFAIK no bug report or test case for the long line problem.
>
> AFAIK, the missing bug-report is the one that shows the ills of sending
> EOFs, while the bug-report for long-lines is bug#6149, which should be
> re-opened.

As I said in relation to this, I could not reproduce the error in 6149.  But 
AFAIK, this all depends on the underlying tty code, so a longer input string 
might trigger the error.  But if a line is longer than MAX_CANON, it will be 
truncated by the tty code.

>
>> +  /* There is no more "send eof to flush" going on (which is wrong and
>> +     unportable in itself), and disabling ICANON breaks a lot of stuff
>> +     and shows literal ^D in many cases.  The correct way to handle too
>> +     much output is to buffer what could not be written and then write it
>> +     again when select returns ok for writing.
>
> Could you spell out more precisely how it's different from what we do
> now: we already check emacs_write's output to see if the buffer is full,
> in which case we wait, don't we?

Yes, but we wait a small time and then try to write again (if I read the code 
correctly).  If nobody is reading, that can turn into a (sort of) busy wait.
The point of handing it off to select is then we don't write until we know we 
can write something.

>
>> +  s.main.c_lflag |= ICANON;	/* Enable line editing and eof processing */
>> +  s.main.c_cc[VEOF] = 'D'&037;	/* Control-D */
>>     s.main.c_cc[VMIN] = 1;
>>     s.main.c_cc[VTIME] = 0;
>
> IIUC VMIN and VTIME not only are specific to the non-ICANON mode, but
> also they use the same slot as some of the other settings (specifically
> the slots may be shared with VEOL and VEOF, according to my manpage).

That is correct.

	Jan D.