bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

When I run

  emacs -Q -eval '(setq xterm-extra-capabilities t)' tst.c

on a remote machine via SSH in an xterm, garbage is sometimes inserted
at the beginning of the buffer. Typing "C-h v xterm-extra-capabilities"
confirms that xterm-extra-capabilities is set to t. The comments in the
following bugs

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6758
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11129

say that setting xterm-extra-capabilities to t should be a way to avoid
the bug (and that's the reason why these bugs have been closed). So,
the problem is not solved... or has reappeared.


In GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
 of 2012-09-05 on xvii
Configured using:
 `configure '--prefix=/usr/local/emacs-24.2' '--enable-asserts''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_DK
  value of $LANG: POSIX
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
ESC [ > 0 ; 2 7 8 ; 0 c ESC x r e p o r t - e m TAB 
RET

Recent messages:
("emacs" "-eval" "(setq xterm-extra-capabilities t)" "tst.c")
For information about GNU Emacs and the GNU system, type C-h C-a.
tst.c has auto save data; consider M-x recover-this-file
Auto-saving...done

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Glenn Morris]

Vincent Lefevre wrote:

>   emacs -Q -eval '(setq xterm-extra-capabilities t)' tst.c

By experiment, -eval is processed too late to affect the relevant
portion of start-up. Try putting the setting in .emacs.

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2012-09-05 12:59:30 -0400, Glenn Morris wrote:
> Vincent Lefevre wrote:
> 
> >   emacs -Q -eval '(setq xterm-extra-capabilities t)' tst.c
> 
> By experiment, -eval is processed too late to affect the relevant
> portion of start-up. Try putting the setting in .emacs

I had

  '(xterm-extra-capabilities (quote (modifyOtherKeys reportBackground)))

in the custom variables, but got the same problem.

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

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2012-09-05 20:44:24 +0200, Vincent Lefevre wrote:
> On 2012-09-05 12:59:30 -0400, Glenn Morris wrote:
> > Vincent Lefevre wrote:
> > 
> > >   emacs -Q -eval '(setq xterm-extra-capabilities t)' tst.c
> > 
> > By experiment, -eval is processed too late to affect the relevant
> > portion of start-up. Try putting the setting in .emacs
> 
> I had
> 
>   '(xterm-extra-capabilities (quote (modifyOtherKeys reportBackground)))
> 
> in the custom variables, but got the same problem.

The .emacs is executed too late as well: if I introduce an error in the
code below (e.g. zzz before the first when), I can see it reported. In
xterm.el, the problem is:

  (if (eq xterm-extra-capabilities 'check)
      ;; Try to find out the type of terminal by sending a "Secondary
      ;; Device Attributes (DA)" query.
      (xterm--query "\e[>0c"
                    ;; Some terminals (like OS X's Terminal.app) respond to
                    ;; this query as if it were a "Primary Device Attributes"
                    ;; query instead, so we should handle that too.
                    '(("\e[?" . xterm--version-handler)
                      ("\e[>" . xterm--version-handler)))

    (when (memq 'reportBackground xterm-extra-capabilities)
      (xterm--query "\e]11;?\e\\"
                    '(("\e]11;" .  xterm--report-background-handler))))

    (when (memq 'modifyOtherKeys xterm-extra-capabilities)
      (terminal-init-xterm-modify-other-keys)))

If I introduce a network delay with:

  tc qdisc add dev eth0 root netem delay 2000ms

the problem always occurs. But if I also remove the above code, then
it no longer occurs.

So, the above (eq xterm-extra-capabilities 'check) test seems to be
useless, and there should be a way to disable it. IMHO, this query
is ugly and should be removed entirely in favor of checking the
environment, in addition to user side settings. If the issue is that
not all xterm's behave in the same way because of new features, you
can test the XTERM_VERSION environment variable. If the default guess
is not OK, the user should have a way to fix it in his ".emacs".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Stefan Monnier]

>> > By experiment, -eval is processed too late to affect the relevant
>> > portion of start-up. Try putting the setting in .emacs
>> I had
>> '(xterm-extra-capabilities (quote (modifyOtherKeys reportBackground)))
>> in the custom variables, but got the same problem.
> The .emacs is executed too late as well:

That's not my experience: I added

  (message "xterm-extra-capabilities = %S" xterm-extra-capabilities)

right before the `if' and it does give me the value I set in my ~/.emacs.

> if I introduce an error in the
> code below (e.g. zzz before the first when), I can see it reported.

That seems right as well: the code after (xterm--query "\e[>0c" ...)
is run only if (eq xterm-extra-capabilities 'check) is false, i.e. only
if your ~/.emacs code was run.

> So, the above (eq xterm-extra-capabilities 'check) test seems to be
> useless, and there should be a way to disable it.

It works for my test (which is "emacs -nw").

> IMHO, this query is ugly and should be removed entirely in favor of
> checking the environment, in addition to user side settings. If the
> issue is that not all xterm's behave in the same way because of new
> features, you can test the XTERM_VERSION environment variable.

   echo "$XTERM_VERSION"

returns the empty string for me (running in an xterm, under Debian testing).
It's just one datapoint, maybe there are cases where it works, but at
least not for my own usecase.


        Stefan

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2015-06-28 21:01:02 -0400, Stefan Monnier wrote:
> >> > By experiment, -eval is processed too late to affect the relevant
> >> > portion of start-up. Try putting the setting in .emacs
> >> I had
> >> '(xterm-extra-capabilities (quote (modifyOtherKeys reportBackground)))
> >> in the custom variables, but got the same problem.
> > The .emacs is executed too late as well:
> 
> That's not my experience: I added
> 
>   (message "xterm-extra-capabilities = %S" xterm-extra-capabilities)
> 
> right before the `if' and it does give me the value I set in my ~/.emacs.

Sorry, I agree. I had removed too much code in my test: the whole
"if", including the ELSE part.

In fact, reportBackground also yields the garbage problem.
So, there's a bug here:

    (when (memq 'reportBackground xterm-extra-capabilities)
      (xterm--query "\e]11;?\e\\"
                    '(("\e]11;" .  xterm--report-background-handler))))

If I understand correctly, there's a timeout here, but since the
feature is claimed to be supported, the timeout should be removed.

> > IMHO, this query is ugly and should be removed entirely in favor of
> > checking the environment, in addition to user side settings. If the
> > issue is that not all xterm's behave in the same way because of new
> > features, you can test the XTERM_VERSION environment variable.
> 
>    echo "$XTERM_VERSION"
> 
> returns the empty string for me (running in an xterm, under Debian testing).

Debian 6.0.10:

$ echo $XTERM_VERSION
XTerm(261)

Debian 7.8:

$ echo $XTERM_VERSION
XTerm(278)

Debian 8.1:

$ echo $XTERM_VERSION
XTerm(312)

Debian unstable:

$ echo $XTERM_VERSION
XTerm(318)

However it is not passed by default via SSH, though this could be
fixed in later versions.

Now, the end user can set the value of xterm-extra-capabilities
depending on $XTERM_VERSION. The only remaining problem is the
one I've mentioned above.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Stefan Monnier]

> In fact, reportBackground also yields the garbage problem.
> So, there's a bug here:

>     (when (memq 'reportBackground xterm-extra-capabilities)
>       (xterm--query "\e]11;?\e\\"
>                     '(("\e]11;" .  xterm--report-background-handler))))

> If I understand correctly, there's a timeout here, but since the
> feature is claimed to be supported, the timeout should be removed.

The timeout is present because we prefer having garbage in those
(presumably rare) cases where the terminal answers too late, over having
Emacs hang forever (tho it's not a hard-hang) when the terminal doesn't
understand the request.

You try the patch below, and set xterm-query-timeout to some value of
your choosing (e.g. nil).


        Stefan


diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 45da1bd..54c46de 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -688,6 +688,10 @@ string bytes that can be copied is 3/4 of this value."
           ;;(xterm--init-activate-get-selection)
           (xterm--init-activate-set-selection))))))
 
+(defvar xterm-query-timeout 2
+  "Seconds to wait for an answer from the terminal.
+Can be nil to mean \"no timeout\".")
+
 (defun xterm--query (query handlers &optional no-async)
   "Send QUERY string to the terminal and watch for a response.
 HANDLERS is an alist with elements of the form (STRING . FUNCTION).
@@ -696,7 +700,8 @@ We run the first FUNCTION whose STRING matches the input events."
   ;; rather annoying (bug#6758).  Maybe we could always use the asynchronous
   ;; approach, but it's less tested.
   ;; FIXME: Merge the two branches.
-  (if (and (input-pending-p) (not no-async))
+  (if (and (or (null xterm-query-timeout) (input-pending-p))
+           (not no-async))
       (progn
         (dolist (handler handlers)
           (define-key input-decode-map (car handler)
@@ -714,7 +719,7 @@ We run the first FUNCTION whose STRING matches the input events."
       (let ((handler (pop handlers))
             (i 0))
         (while (and (< i (length (car handler)))
-                    (let ((evt (read-event nil nil 2)))
+                    (let ((evt (read-event nil nil xterm-query-timeout)))
                       (or (eq evt (aref (car handler) i))
                           (progn (if evt (push evt unread-command-events))
                                  nil))))

> However it is not passed by default via SSH,

Ah, indeed, that's my case: I almost only use "-nw" in an SSH session.


        Stefan

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2015-06-29 09:12:01 -0400, Stefan Monnier wrote:
> > In fact, reportBackground also yields the garbage problem.
> > So, there's a bug here:
> 
> >     (when (memq 'reportBackground xterm-extra-capabilities)
> >       (xterm--query "\e]11;?\e\\"
> >                     '(("\e]11;" .  xterm--report-background-handler))))
> 
> > If I understand correctly, there's a timeout here, but since the
> > feature is claimed to be supported, the timeout should be removed.
> 
> The timeout is present because we prefer having garbage in those
> (presumably rare) cases where the terminal answers too late, over having
> Emacs hang forever (tho it's not a hard-hang) when the terminal doesn't
> understand the request.

Won't C-g have any effect? In such a case, the user could hit C-g
then modify his settings. Or see below.

Note that reaching the timeout isn't that rare. It happened recently
to someone else here, who didn't notice and committed his changes to
the repository, with the consequence that the file could no longer be
compiled. IMHO, with the default configuration (i.e. with "check"),
Emacs should make sure that files cannot be silently corrupted.

Perhaps, in case of timeout and some data have been written to the
buffer before a cursor move, Emacs should warn about this when the
user saves the buffer (or perhaps earlier). When this happens, there
are two possibilities:

1. There is indeed garbage because the terminal was slow to respond,
   and the user removes this garbage (and he may want to increase the
   timeout value, in particular if this occurs too often).

2. No garbage, the terminal didn't respond, in which case the user may
   want to modify his configuration to avoid a timeout in all cases.

So, in either case, the warning would be beneficial to the user.

> You try the patch below, and set xterm-query-timeout to some value of
> your choosing (e.g. nil).

Thanks.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Stefan Monnier]

>> The timeout is present because we prefer having garbage in those
>> (presumably rare) cases where the terminal answers too late, over having
>> Emacs hang forever (tho it's not a hard-hang) when the terminal doesn't
>> understand the request.
> Won't C-g have any effect?

As I said, it's not a hard hang.  Even just hitting any key should get
you out of it (but the key is eaten along the way).

> Perhaps, in case of timeout and some data have been written to the
> buffer before a cursor move, Emacs should warn about this when the
> user saves the buffer (or perhaps earlier). When this happens, there
> are two possibilities:

If you look at the code, you'll hopefully see that there are 2 code
paths (one synchronous with a timeout, and one asynchronous), and
a comment saying that the two should be merged.
I.e. when using the synchronous path, after hitting the timeout, we
should switch to the async path.
Or simply just "always" use the async path.


        Stefan

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Stefan Monnier]

> If you look at the code, you'll hopefully see that there are 2 code
> paths (one synchronous with a timeout, and one asynchronous), and
> a comment saying that the two should be merged.
> I.e. when using the synchronous path, after hitting the timeout, we
> should switch to the async path.
> Or simply just "always" use the async path.

I installed the patch below which switches to the async method in case
of a timeout.  That should hopefully solve your use case.


        Stefan


diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index f7f8007..350ab3c 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -688,6 +688,10 @@ string bytes that can be copied is 3/4 of this value."
           ;;(xterm--init-activate-get-selection)
           (xterm--init-activate-set-selection))))))
 
+(defvar xterm-query-timeout 2
+  "Seconds to wait for an answer from the terminal.
+Can be nil to mean \"no timeout\".")
+
 (defun xterm--query (query handlers &optional no-async)
   "Send QUERY string to the terminal and watch for a response.
 HANDLERS is an alist with elements of the form (STRING . FUNCTION).
@@ -696,25 +696,37 @@
   ;; rather annoying (bug#6758).  Maybe we could always use the asynchronous
   ;; approach, but it's less tested.
   ;; FIXME: Merge the two branches.
-  (if (and (input-pending-p) (not no-async))
-      (progn
+  (let ((register
+         (lambda (handlers)
         (dolist (handler handlers)
           (define-key input-decode-map (car handler)
             (lambda (&optional _prompt)
-              ;; Unregister the handler, since we don't expect further answers.
+                 ;; Unregister the handler, since we don't expect
+                 ;; further answers.
               (dolist (handler handlers)
                 (define-key input-decode-map (car handler) nil))
               (funcall (cdr handler))
-              [])))
+                 []))))))
+    (if (and (or (null xterm-query-timeout) (input-pending-p))
+             (not no-async))
+        (progn
+          (funcall register handlers)
         (send-string-to-terminal query))
     ;; Pending input can be mistakenly returned by the calls to
-    ;; read-event below.  Discard it.
+      ;; read-event below: discard it.
+      (discard-input)
     (send-string-to-terminal query)
     (while handlers
       (let ((handler (pop handlers))
             (i 0))
         (while (and (< i (length (car handler)))
-                    (let ((evt (read-event nil nil 2)))
+                      (let ((evt (read-event nil nil xterm-query-timeout)))
+                        (if (and (null evt) (= i 0) (not no-async))
+                            ;; Timeout on the first event: fallback on async.
+                            (progn
+                              (funcall register (cons handler handlers))
+                              (setq handlers nil)
+                              nil)
                       (or (eq evt (aref (car handler) i))
                           (progn (if evt (push evt unread-command-events))
                                  nil))))
@@ -724,7 +736,7 @@
                    (funcall (cdr handler)))
           (while (> i 0)
             (push (aref (car handler) (setq i (1- i)))
-                  unread-command-events)))))))
+                      unread-command-events)))))))))
 
 (defun xterm--push-map (map basemap)
   ;; Use inheritance to let the main keymaps override those defaults.

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2015-06-30 23:19:11 -0400, Stefan Monnier wrote:
> > If you look at the code, you'll hopefully see that there are 2 code
> > paths (one synchronous with a timeout, and one asynchronous), and
> > a comment saying that the two should be merged.
> > I.e. when using the synchronous path, after hitting the timeout, we
> > should switch to the async path.
> > Or simply just "always" use the async path.
> 
> I installed the patch below which switches to the async method in case
> of a timeout.  That should hopefully solve your use case.

I don't know whether this is related, but I've compiled the the master
branch (3d759f4f6f2a20abbc05225a55d35c5daf093ff6), and Emacs freezes
(in an xterm, via SSH). I need to type C-g.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Stefan Monnier]

> I don't know whether this is related, but I've compiled the the master
> branch (3d759f4f6f2a20abbc05225a55d35c5daf093ff6), and Emacs freezes
> (in an xterm, via SSH). I need to type C-g.

Yeah, I only tested one case and didn't catch the paren-typo in
the other.  Sorry, should be fixed now,


        Stefan

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2015-07-02 10:49:50 -0400, Stefan Monnier wrote:
> > I don't know whether this is related, but I've compiled the the master
> > branch (3d759f4f6f2a20abbc05225a55d35c5daf093ff6), and Emacs freezes
> > (in an xterm, via SSH). I need to type C-g.
> 
> Yeah, I only tested one case and didn't catch the paren-typo in
> the other.  Sorry, should be fixed now,

Thanks. I can no longer reproduce the problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Noam Postavsky]

tags 12354 fixed
close 12354 
quit

Vincent Lefevre <vincent@vinc17.net> writes:

> On 2015-07-02 10:49:50 -0400, Stefan Monnier wrote:

>> Yeah, I only tested one case and didn't catch the paren-typo in
>> the other.  Sorry, should be fixed now,
>
> Thanks. I can no longer reproduce the problem.

Therefore closing.

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Andreas Schwab]

Does this help?

Andreas.

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 28fb9da..b93bc5e 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -519,6 +519,9 @@ The relevant features are:
       ;; Device Attributes (DA)" query.
       (send-string-to-terminal "\e[>0c")
 
+      ;; Wait a bit before trying to read the answer
+      (sleep-for 0.1)
+
       ;; The reply should be: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
       ;; If the timeout is completely removed for read-event, this
       ;; might hang for terminals that pretend to be xterm, but don't
@@ -541,6 +544,7 @@ The relevant features are:
                      (>= version 242)))
 	(discard-input)
         (send-string-to-terminal "\e]11;?\e\\")
+	(sleep-for 0.1)
         (when (and (equal (read-event nil nil 2) ?\e)
                    (equal (read-event nil nil 2) ?\]))
           (setq str "")

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12354: 24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

[Vincent Lefevre]

On 2012-09-08 11:57:50 +0200, Andreas Schwab wrote:
> Does this help?

Not tried yet, but due to high-latency connection, several seconds may
be needed. I can see 2 solutions:

  * Have a way to disable this check (early enough, of course),
    letting the user to provide information in another way if he
    wants to benefit from additional features. For instance, how
    about checking an environment variable first, which could hold
    the data Emacs is looking for or just tell Emacs not to do the
    check?
    An environment variable would be fine, as it could be set by
    the terminal (or the initial shell) and transmitted by SSH
    (if the variable name starts with LC_, it wouldn't require
    specific config in practice).

  * Wait *until* the string is sent back by the terminal. Because
    of race condition (due to a possibly high-latency connection),
    Emacs needs to separate user input from the string in question
    (this would be a heuristic, but may work).

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