[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100961: Enable ICANON (Bug#6771)
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100961: Enable ICANON (Bug#6771). Any long line problem must be solved differently.
Thu, 05 Aug 2010 17:28:20 +0200
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:184.108.40.206) Gecko/20100713 Thunderbird/3.1.1
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
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.