> Hi,
>
> On Sun, Jan 22, 2012 at 15:59, Thomas Dickey <dickey@his.com> wrote:
>
> >
> > The reader is still going to do a check at the end, and discard unexpected
> > input as an error. If the inputs follow the same syntax rules, then it's
> > less problem to implement and maintain.
> >
> > I'm not expecting someone to just match "\e[<" and blindly sscanf looking
> > for a given number of integer parameters and then skip the next character
> > without examining it. 1006 uses the final character to distinguish
> > button press/release.
> >
>
> Of course one has to check the final character :) And if I was to
> implement an application from scratch, I'd say that the standard is great,
> I'd implement a framework for collecting numeric parameters up to the final
> letter and then parse the whole stuff, it's easy.
>
> Now, however, support should be patched into many already existing
> applications whose code I don't understand, don't maintain, and are not
> built along these lines. I'd like to patch quite a few of them, without
> spending too much time. Substantially rewriting them by me or anyone
> contributing a patch is not really feasible.
>
> Please take a very quick look at emacs-23-3b. lisp/xt-mouse.el L246
> registers the xterm-mouse-translate lisp-method to be called on \e[M.
> This, in turn, calls xterm-mouse-event-read three times to read the
Actually it first calls read-char three times, to read \e[M (three bytes).
It does a little error checking there, e.g.,
(unless is-click
(unless (and (eq (read-char) ?\e)
(eq (read-char) ?\[)
(eq (read-char) ?M))
(error "Unexpected escape sequence from XTerm")))
It then calls xterm-mouse-event-read to read the coordinates.
> arguments, and then processes them. The input_decode_map is apparently
> looked up in src/term.c, although I don't understand that code yet. If
> there's a new unique prefix then that can be registered in the lisp file
I'd assume that one would start by doing a
(define-key input-decode-map "\e[<" 'xterm-extended-mouse-translate))
...along with a suitable new function. It's been a while since I
programmed in lisp, but it's usually readable. Aside from cut/paste/massage
of text already in the file, there's not much to lookup.
> too, and the whole business of mouse coordinate parsing solved locally in
> lisp, which I guess even I would be able to do despite knowing nothing
That's the preferred method for emacs (changes to the C code are done
only to provide ways for the lisp code to do more).
> about lisp. If there's no unique prefix, i.e. if \e[< can mean mouse
> coordinate but can mean something else as well, then adding support would
> require much more complex architecture changes from someone who much more
> deeply understands emacs' structure.
>
> I'm not asking you to come up with a patch to emacs or anything like that,
> but please take a very quick look at the source and estimate how much work
> it'd be to add support in one case or in the other. I hope you'll agree
> that it's much more work to add proper support if there is no unique prefix.
It doesn't have to be unique - the reader simply has to check that the
input is in the expected format.
For someone who knows their way around emacs, this would be a couple of
hours work. If I had to do it, hmm - perhaps a day or two.
> I personally think it's important that extended mouse support should be
> easy to add into applications, and should not require architecture
> redesign. I think it's a key to getting the feature deployed quickly and
> widely across apps.
there are a lot of applications :-(
> thanks,
> egmont
>
>
>
> >
> > (Correctly parsing 1015 also would involve checking the final character,
> > of course).
> >
> > > I think anything as simple as a fixed letter following the '<' sign, if
> > > it's not used anywhere else right now, would do it. Or alternatively
> > \e[M
> > > followed by a single fixed letter that is currently out of use would also
> > > do it.
> > >
> > > Also, I'm not sure about the purpose of "private" mode, but shouldn't we
> > > aim to provide something that will quickly become a new standard, not
> > > something "private"?
> >
> > "private" in this regard means that it's not part of ECMA-48.
> >
> > Take a look at the various "CSI ?" and "CSI >" listed in ctlseqs to see
> > how xterm (and DEC) use private modes. The existing mouse controls are
> > for instance private modes.
> >
> > CSI ? 1 0 0 1 h
> > Ps = 1 0 0 1 -> Use Hilite Mouse Tracking.
> >
> > > > The first three are used in various ways in different terminals. The
> > last
> > > > seems to be rarely used, so I chose to use that.
> > > >
> > > > Conceivably some other escape sequence could be implemented (I don't
> > have
> > > > any plans for that). I'm assuming that vim will check the final
> > character.
> > > >
> > >
> > >
> > > Thanks a lot,
> > > egmont
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > > Once this is done, it'll be okay to add 1006 support to Vim. (In the
> > > > mean
> > > > > time I guess 1015 support could be dropped; this would make extended
> > > > mouse
> > > > > coords stop working in some versions of some terminals, but would
> > > > probably
> > > > > also simplify Vim's code. But it's okay to keep 1015 too.)
> > > > >
> > > > > thanks,
> > > > > egmont
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Note that in ctlseqs.html in the DECSET list 1006 and 1015 are not
> > > > > > documented.
> > > > > >
> > > > > > --
> > > > > > CRONE: Who sent you?
> > > > > > ARTHUR: The Knights Who Say GNU!
> > > > > > CRONE: Aaaagh! (she looks around in rear) No! We have no
> > licenses
> > > > here.
> > > > > > "Monty Python and the Holy editor wars" PYTHON (MONTY)
> > > > SOFTWARE
> > > > > > LTD
> > > > > >
> > > > > > /// Bram Moolenaar -- Bram@Moolenaar.net --
> > http://www.Moolenaar.net
> > > > > > \\\
> > > > > > /// sponsor Vim, vote for features --
> > > > http://www.Vim.org/sponsor/\\\
> > > > > > \\\ an exciting new programming language -- http://www.Zimbu.org
> > > > > > ///
> > > > > > \\\ help me help AIDS victims --
> > http://ICCF-Holland.org
> > > > > > ///
> > > > > >
> > > > > > --
> > > > > > You received this message from the "vim_use" maillist.
> > > > > > Do not top-post! Type your reply below the text you are replying
> > to.
> > > > > > For more information, visit http://www.vim.org/maillist.php
> > > > > >
> > > >
> > > > --
> > > > Thomas E. Dickey <dickey@invisible-island.net>
> > > > http://invisible-island.net
> > > > ftp://invisible-island.net
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.9 (GNU/Linux)
> > > >
> > > > iEYEARECAAYFAk8cG2IACgkQcCNT4PfkjtucogCfdZesPECwenLZNHe6xx/oc5s7
> > > > tiMAn2n1zVIgYEMMoZyl/RUwWkVJ1gtZ
> > > > =DJIQ
> > > > -----END PGP SIGNATURE-----
> > > >
> > > >
> >
> > --
> > Thomas E. Dickey <dickey@invisible-island.net>
> > http://invisible-island.net
> > ftp://invisible-island.net
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAk8cJDoACgkQcCNT4PfkjttF+ACeP3kEskL7sUExPndJIKSfgIBs
> > n0gAoJ7VGKBTLJJjIdn40t3hTNw6qeSC
> > =JCNQ
> > -----END PGP SIGNATURE-----
> >
> >
--
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
No comments:
Post a Comment