Re: console-ncurses discoveries / Alt-F# console selection patch.

[Marcus Brinkmann]

On Mon, Aug 26, 2002 at 01:16:36PM -0400, David Walter wrote:
> I  am liking console-ncurses the more  I use it,  the more I am liking
> it.

Thanks, glad to hear that :)  Note that detach and multi-attach is also
supported by screen, which you can use if console-ncurses is not stable
enough yet.

> I think I have exposed  some minor bug  though,

I wouldnot be surprised if you expose more than one :)

> I notice that the text
> client for xemacs moves the cursor  one character forward when it does
> a  display-time update, but  this doesn't seem  to happen when running
> under a normal console, so I  don't know if this  is an xemacs problem
> or the console client problem.

What is a normal console?  You mean non-new-console code at all?  The first
thing to find out is what terminal xemacs things it is running under.  All
applications which output to the console server (independent of the client
you use to display the servers content, and where you run this client) need
to have TERM set to "hurd" with the hurd.ti I checked in loaded into the
system with "tic hurd.ti".  So, make sure xemacs sees the TERM=hurd setting.
(You can verify this with the msgport program, which you can use to dumpt
the environment of a running process, try it out, it rocks!).

Then, the console client needs to see the right TERM setting for the
terminal it is running on.  So if you run console-ncurses in an xterm, it
needs to be TERM=xterm for the console-ncurses program.

By the way, there is another bug:  If you load lynx www.slashdot.org, and
scroll down the page, at some point you will get artifacts on the screen.  I
believe this to be a bug in ncursesw, because I debugged it and saw how I
correctly emitted the \x20 to delete the next character, but ncurses only
emitted a cursor forward sequence instead a blank.

So, one thing you can try is to check out if the cursor is really moved, or
if this is an artefact of the ncurses client running.  Just detach and
reattach right after seeing something weird happening.  If the weird stuff
is still visible after reattaching (switching the console forth and back has
the same effect, btw), then somehow the console server got the wrong
sequence or behaved badly, otherwise it is the client solely.

The console server (TERM=hurd) doesn't have full VT100 emulation, so that
might trigger some bugs here or there.  I believe the terminfo description
to be accurate, though.

> And because emacs is more or less my home I wanted to ask if the
> following --compatibility option would be acceptable as a patch.
> 
> Rationale: C-w is cut a region, I use this more than A-F# keys in
> emacs.

Oh yes, certainly.  The issue is that the native console client (for VGA
card and PC keyboard) will use A-F# to switch consoles, of course.  So the
ncurses client settings would conflict with the system console, just like in
GNU/Linux with screen.  But in X I guess this is not a problem.

All settings like this should be easily configurable like in screen, of
course.

I won't apply your patch right now because of this more general issue, your
change is too specific.  But I generally agree with you that the current
code isn't any better, and that the situation of conflicting with any
program is not desirable.  The reason I chose ^W is that it is close to the
left shift key, doesn't conflict with screen, will not conflict with the
next generation native console, and is not ^Q, ^S, ^Z, all of which are used
by the terminal itself.
 
Thanks!
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/