unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vincent Lefevre <vincent@vinc17.org>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca
Subject: Re: ";0c" in terminal with slow connections
Date: Sun, 9 Sep 2007 16:09:43 +0200	[thread overview]
Message-ID: <20070909140943.GT9115@prunille.vinc17.org> (raw)
In-Reply-To: <200709081617.l88GH8f3016049@oogie-boogie.ics.uci.edu>

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 <vincent@vinc17.org> writes:
>   > On 2007-09-08 01:35:14 -0700, Dan Nicolaescu wrote:
>   > > Vincent Lefevre <vincent@vinc17.org> 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 <vincent@vinc17.org> - 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	other threads:[~2007-09-09 14:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070903105723.GA4091@prunille.vinc17.org>
2007-09-04 16:45 ` ";0c" in terminal with slow connections Richard Stallman
2007-09-04 19:49   ` Stefan Monnier
2007-09-04 22:15     ` Vincent Lefevre
2007-09-05  6:16     ` Richard Stallman
2007-09-06  5:34       ` Dan Nicolaescu
2007-09-06 12:50         ` Vincent Lefevre
2007-09-06 15:28           ` Davis Herring
2007-09-07  6:32           ` Richard Stallman
2007-09-07  9:33             ` Vincent Lefevre
2007-09-07 14:13             ` Dan Nicolaescu
2007-09-08  7:00               ` Richard Stallman
2007-09-08  8:32                 ` Dan Nicolaescu
2007-09-08  8:21               ` Vincent Lefevre
2007-09-08  8:35                 ` Dan Nicolaescu
2007-09-08  9:32                   ` Vincent Lefevre
2007-09-08 16:17                     ` Dan Nicolaescu
2007-09-09 14:09                       ` Vincent Lefevre [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070909140943.GT9115@prunille.vinc17.org \
    --to=vincent@vinc17.org \
    --cc=dann@ics.uci.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).