[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kenichi Handa
Subject: Re: carriage-return no longer works quite right in shell-mode
Date: Fri, 29 Feb 2008 20:31:48 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Romain Francoise <address@hidden> writes:

> Stefan Monnier <address@hidden> 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);

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]