Re: carriage-return no longer works quite right in shell-mode

[Kenichi Handa <handa@m17n.org>]

In article <87wsoow3zx.fsf@elegiac.orebokech.com>, Romain Francoise <romain@orebokech.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > So it indeed, looks like a problem introduced by the unicode merge: for
> > some reason, the unicode code just sends the \r eagerly before it can
> > tell whether the next char is a \n.
> > I'll keep it in my todo list, but it may take me a little while to get
> > back to it, so if someone wants to do it before, he's welcome,

> This bug is very annoying...

> Handa-san, perhaps you have an idea about what broke this, and where
> someone could start investigating?

Sorry for not responding on this thread.

I found two problems are related.

One is that the default-process-coding-system is now set to
XXX-unix, but previously it doesn't specify eol-format
(i.e. auto-detect).  comint.el changes the eol-format to
XXX-dos only if eol-format is not specifed.

The other is in the new code conversion routine as Stefan
wrote above.

I'll fix the latter bug in haste.  Could someone figure out
why default-process-coding-system specifies eol-format now?

By the way, I think the way of processing CR in comint is
not good.  For instance, with the follwoing program, you
can't see the tailing "times" in *shell*.

#include <stdio.h>
main() {
  int i;
  printf ("  times");
  for (i = 0; i < 10; i++) {
    printf("\r%d", i);
    fflush(stdout);
    sleep(1);
  }
  printf("\n");
}

I think it should be modified not to rely on the fact that
the decoding of CR is suspended until the next byte arrives.

---
Kenichi Handa
handa@ni.aist.go.jp