From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#23009: 25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates Date: Sat, 19 Mar 2016 17:15:10 +0000 Message-ID: References: <83y49lc8o8.fsf@gnu.org> <83d1qvbp59.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c244b011daba052e6a020e X-Trace: ger.gmane.org 1458407785 391 80.91.229.3 (19 Mar 2016 17:16:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Mar 2016 17:16:25 +0000 (UTC) Cc: 23009@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 19 18:16:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ahKU2-0000lM-1y for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Mar 2016 18:16:14 +0100 Original-Received: from localhost ([::1]:49768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahKTy-0001K7-3P for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Mar 2016 13:16:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahKTu-0001Jm-1p for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 13:16:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahKTq-0005Ez-19 for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 13:16:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahKTp-0005Ev-UP for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 13:16:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ahKTp-0000PB-OO for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 13:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Mar 2016 17:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23009 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23009-submit@debbugs.gnu.org id=B23009.14584077271514 (code B ref 23009); Sat, 19 Mar 2016 17:16:01 +0000 Original-Received: (at 23009) by debbugs.gnu.org; 19 Mar 2016 17:15:27 +0000 Original-Received: from localhost ([127.0.0.1]:53878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahKTH-0000OM-7x for submit@debbugs.gnu.org; Sat, 19 Mar 2016 13:15:27 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:35818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahKTF-0000O8-Db for 23009@debbugs.gnu.org; Sat, 19 Mar 2016 13:15:25 -0400 Original-Received: by mail-lb0-f169.google.com with SMTP id bc4so105640202lbc.2 for <23009@debbugs.gnu.org>; Sat, 19 Mar 2016 10:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rrSoTDhE012EJs9Cof9O23TYcQsfXvRwV46jNP60IOw=; b=so4RWL2hOmKA2fSmD66k5cCFfaU3SyUI5eg1XOdLHHQF8mpNdRcfJu6uLu+6hC9YnG 6+JrqoE85r14k7IvlXEEVVuc/0BiKemO4o/sLSYjSBxi8f+/NORsCCnt8DpEMMVAb/10 UYZNVRnsE+HaPh0vEdZnm4q71G8f/bxd+5xl2Gt7e8YvXbJx5XFgB6WaQjsKku3wCQqc fCfnBR62Zzs2Pq35dd7NMHQkpzw6Y5ou5hrg+cidLOUWWI6drKUIsEjguOyjiMiIDKbx jE8ASdZrgGuSyKMC51ChMrgAnuXMuam4yoc1Og1f/TvD9UOp8Evc2yhJZWjbds5l2y5A HgWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rrSoTDhE012EJs9Cof9O23TYcQsfXvRwV46jNP60IOw=; b=kfvUXMwpB0I4l6VAlMMlPc214ZUC4l9CR1dhiHlihVAfia+aOYRzwiAf8SrStPfwo+ GQit9H1s/ZX0XVk57c8Tnc0KtU7bnI4RGPXJCKzxs1CYomeGluft3zwzR6qywjiJHyj+ KOVaZ1pkxf+Cis8M7p4gYEfqajbqi8S8ty1ix3EtQi+c9sIbUHJwZT6ZG8e3P2/qNrG3 LBgR8QtqFjTEH2YQV88cIX7sU77QZO60bRs56KU+iFgDoyZf4oUTGjjvZYdHedYYUah7 2kpUMDwU4sIq9TREXyFRzkkt78Z02UoF+EO8tY98NeHN408fEtD1NJRRKUNPqYeYhQP0 K1cQ== X-Gm-Message-State: AD7BkJLxgPA1F8ogZjMWWqskFxRij8uHfqFet18qyIrlcVvMo/nHKV+5V9/9QqrTz49L/M8nLSm6vHk0zLMHlg== X-Received: by 10.112.190.4 with SMTP id gm4mr7954624lbc.74.1458407719687; Sat, 19 Mar 2016 10:15:19 -0700 (PDT) In-Reply-To: <83d1qvbp59.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115093 Archived-At: --001a11c244b011daba052e6a020e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii schrieb am Di., 15. M=C3=A4rz 2016 um 18:57 Uh= r: > > From: Philipp Stephani > > Date: Mon, 14 Mar 2016 23:03:21 +0000 > > Cc: 23009@debbugs.gnu.org > > > > Added a patch. I've had to use latin-1 instead of no-conversion to > prevent resetting the meta mode. > > Not sure I understand the problem you had with no-conversion. Can you > elaborate? > > > --- a/lisp/international/mule.el > > +++ b/lisp/international/mule.el > > @@ -1484,6 +1484,9 @@ set-keyboard-coding-system > > (set-keyboard-coding-system-internal coding-system terminal) > > (setq keyboard-coding-system coding-system)) > > > > +(gv-define-setter keyboard-coding-system (coding-system &optional > terminal) > > + `(set-keyboard-coding-system ,coding-system ,terminal)) > > I don't think you can do that: mule.el is preloaded, while gv.el > isn't. > > It isn't a catastrophe to temporarily switch keyboard encoding "the > dull way". > OK, done. > > > + ;; Use Latin-1 instead of no-conversion to avoid > > + ;; flicker due to `set-keyboard-coding-system' changing > > + ;; the meta mode. > > Ah, so that's the problem... Did you try raw-text instead? > > Same issue, with both raw-text and no-conversion the set-keyboard-coding-system function switches the meta mode between t and nil, leading to flicker. I guess if the meta mode was nil initially, it would flicker with latin-1. I'm quite puzzled about this behavior and the meta mode in general now. It seems that for this purpose (reading a single byte from the terminal) both nil (ignore top bit) and t (treat top bit as meta) seem wrong, but both lead to the correct result (i.e. the byte is returned as-is, without interpretation of the top bit). Ideally there were a function to read a single byte, ignoring the meta mode and all conversions. > And anyway, doesn't latin-1 give you trouble for bytes in the 128..159 > range? > > It works at least in HTerm without flicker or other issues. --001a11c244b011daba052e6a020e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 15. M=C3=A4rz 2016 um 18:57=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 14 Mar 2016 23:03:21 +0000
> Cc: 23009@d= ebbugs.gnu.org
>
> Added a patch. I've had to use latin-1 instead of no-conversion to= prevent resetting the meta mode.

Not sure I understand the problem you had with no-conversion.=C2=A0 Can you=
elaborate?

> --- a/lisp/international/mule.el
> +++ b/lisp/international/mule.el
> @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
>=C2=A0 =C2=A0 (set-keyboard-coding-system-internal coding-system termin= al)
>=C2=A0 =C2=A0 (setq keyboard-coding-system coding-system))
>
> +(gv-define-setter keyboard-coding-system (coding-system &optional= terminal)
> +=C2=A0 `(set-keyboard-coding-system ,coding-system ,terminal))

I don't think you can do that: mule.el is preloaded, while gv.el
isn't.

It isn't a catastrophe to temporarily switch keyboard encoding "th= e
dull way".

OK, done.
=C2= =A0

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Use Latin-1= instead of no-conversion to avoid
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; flicker due= to `set-keyboard-coding-system' changing
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; the meta mo= de.

Ah, so that's the problem...=C2=A0 Did you try raw-text instead?


Same issue, with both raw-text and no-= conversion the set-keyboard-coding-system function switches the meta mode b= etween t and nil, leading to flicker.
I guess if the meta mode wa= s nil initially, it would flicker with latin-1.
I'm quite puz= zled about this behavior and the meta mode in general now. It seems that fo= r this purpose (reading a single byte from the terminal) both nil (ignore t= op bit) and t (treat top bit as meta) seem wrong, but both lead to the corr= ect result (i.e. the byte is returned as-is, without interpretation of the = top bit).
Ideally there were a function to read a single byte, ig= noring the meta mode and all conversions.
=C2=A0
And anyway, doesn't latin-1 give you trouble for bytes in the 128..159<= br> range?

=C2=A0
It works at least in HTerm without f= licker or other issues.
--001a11c244b011daba052e6a020e--