Hi, On Sun, Jan 22, 2012 at 15:59, Thomas Dickey <[email protected]> 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 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 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 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. 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. 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 -- [email protected] -- > 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 <[email protected]> > > > 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 <[email protected]> > 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----- > > -- 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
