emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: M-x term and fringe problem


From: Kim F. Storm
Subject: Re: M-x term and fringe problem
Date: 05 Apr 2004 04:01:50 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Mark Plaksin <address@hidden> writes:

> With CVS Emacs from today in Debian unstable (and with other OSes, I
> assume), M-x term gets confused by the fringe.  When typing at a shell
> prompt and the cursor gets close to the fringe, term doesn't move to the
> next line like it should.
> 
> To reproduce:
> - emacs -q
> - M-x term
> - RET ; to accept bash as the shell
> - Type characters until there is space for one character between the
> cursor and the fringe.
> - Type one more character and the cursor moves to the beginning of the line.
> 
> A workaround:
> - emacs -q
> - M-: (setq overflow-newline-into-fringe nil)
> - M-x term
> - RET ; to accept bash as the shell
> - Type characters until there is space for one character between the
> cursor and the fringe.
> - Type one more character and the cursor moves to the beginning of the
> *next* line like it should.
> - This also leaves one empty space between the last character on the
> first line and the fringe.  I can't tell if this empty space is supposed
> to be there or not but it's much better than what happens when
> overflow-newline-into-fringe is t.

21.2 seems to do that same thing, i.e. get the window width wrong by
one column.  I guess it tries to emulate a terminal where the cursor
doesn't advance to the next line if it is located at the rightmost
column (at least some DEC terminals did that IIRC).  But it seems to
do that one column too early.


Actuallty, I have suspected for a long time that "vertical-motion" (at
the C level) has a bug on window systems, namely that it still counts
one column for the \ that used to be at the end of a continued line,
but it shown in the fringes now.

But I have not had a good test case to prove this -- maybe this is the
test case I have been looking for.  I will try to fix vertical-motion
and see if it fixes the problem you have reported.

> Should overflow-newline-into-fringe be buffer-local and nil in all
> terms? 

Let's see whether my fix to vertical-motion is enough... 
If not, I guess that would be the proper fix.

-- 
Kim F. Storm  http://www.cua.dk





reply via email to

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