emacs-devel
[Top][All Lists]
Advanced

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

Re: ";0c" in terminal with slow connections


From: Vincent Lefevre
Subject: Re: ";0c" in terminal with slow connections
Date: Sun, 9 Sep 2007 16:09:43 +0200
User-agent: Mutt/1.5.16-vl-r18739 (2007-09-04)

Hi,

On 2007-09-08 09:17:03 -0700, Dan Nicolaescu wrote:
> [Maybe you are not aware, but your tone sounds irritating. Please be
> more careful on this mailing list.]

Sorry if you felt that. I also found your tone irritating ("You are
missing the point..."). I really hate when I spent time to configure
my software (based on their documentation, standards and so on) and
some other software, trying to be smarter than the user, silently
overrides my configuration (and breaks the configuration of other
software at the same time).

> Vincent Lefevre <address@hidden> writes:
>   > On 2007-09-08 01:35:14 -0700, Dan Nicolaescu wrote:
>   > > Vincent Lefevre <address@hidden> writes:
>   > >   > Why not let the user configure his xterm the way he likes?
>   > > 
>   > > You are missing the point, this is done because we would like
>   > > the users to transparently take advantage of this feature
>   > > without having to configure anything.
>   > But what about users who are used to the current configuration
>   > or have their own configuration? 
> 
> Can you please give a precise example of what you mean?

e.g. with VT100 translations, as I mentioned below. (Now, I think
that VT100 translations have the precedence.)

But the user could have also set the configuration related to
modifyOtherKeys via the X11 resources (e.g. .app-defaults/XTerm).

>   > If this feature is so important to have it without configuring
>   > anything, then why doesn't xterm enable it by default?
> 
> Don't know, please find out from the xterm guys and report back here.

I'll ask Thomas about that.

>   > This is not sufficient:
>   >   * Emacs won't be able to do anything for screen users, after
>   >     detaching a session running Emacs or after switching the
>   >     screen window.
> 
> Screen sets TERM to screen, so this won't affect such users.

OK. Note that the value of TERM is configurable, though; and nothing
prevents the user from setting TERM to 'xterm-something' (and this
is not wrong as screen supports conventional xterm escape sequences
in some way). There is even documentation that says that this is OK.
For instance, http://linux.die.net/man/1/nsc says: Within
putty/screen, "TERM=xterm-color" works well.

I suppose that for SGR, screen resets the status when switching the
window or detaching the session. I don't know if it does this with
modifyOtherKeys, but this is not as standard (e.g. no terminfo
interface, AFAIK), and could lead to problems.

>   >   * If Emacs crashes (this hasn't happened yet with Emacs22,
>   >     though), the configuration will not be restored.
>   >   * In case of a SSH or dialup connection, if the connection closes
>   >     because of some network problem (this occurs quite frequently),
>   >     the configuration will not be restored either.
> 
> We can only do a best effort.

Only the user could configure his shell and whatever program that
calls Emacs in order to restore the configuration. But again, this
could lead to problems with some terminals, if the sequence does
something else.

>   > The user can bind some key sequences (in general, ones that are not
>   > used in the terminal itself) to some xterm functions (e.g. to do
>   > scrolling, paste strings and so on). This is done with the VT100
>   > translations resource. What is the effect of modifyOtherKeys on
>   > these bindings? (I don't have a xterm here to try...)
> 
> You seem to know about this stuff, why don't you try it and report any
> problems that you find here.

I'll try to do that tonight or during the week.

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)




reply via email to

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