Loading ...
Sorry, an error occurred while loading the content.
 

clipboard considerations

Expand Messages
  • Maiorana, Jason
    ... Me too, I would like actual user feed back :) Also for the gvim change. Im happily using them on my system. I havent gotten any XIM servers to work for me
    Message 1 of 4 , Aug 21, 2002
      Bram wrote:
      >I would like to get some feedback on this patch.

      Me too, I would like actual user feed back :) Also for the gvim
      change. Im happily using them on my system. I havent gotten any
      XIM servers to work for me yet: unfortunatly most of them have
      poor utf-8 support, and are terribly dependant upon locales.
      (I have no utf-8 locales, and I would really like to use many
      languages at once- not just one, so a locale doesnt make sense
      to me) But now at least I can paste text in from other sources.
      (Imagine mixed vietnamese+japanese in one copy/paste)


      >I wonder if we should also add a _VIM_UTF8_TEXT atom. It would contain
      >UTF-8 text and an indication of character/line/blockwise selection.
      >_VIM_TEXT does this, but it doesn't say anything about the encoding.
      >Even better may be _VIM_ENC_TEXT, which provides the text in 'encoding'
      >and adds the encoding name to the selection. This will avoid a double
      >conversion when 'encoding' is something like ISO-8859-9. Having two
      >Vims with the same 'encoding' is very likely to happen.

      I am still not convinced this is necessary. Copy/Paste happens at a
      glacial speed, so the efficiency concerns of double-conversion are
      moot afaic. Now, if there are encodings suffering a serious degredation
      in the conversion, that would be more of an issue, but I doubt it would
      happen with valid data. If someone had mixed SJIS and binary, and they
      wished to copy/paste that, then the conversion will surely fail because
      it doesnt know which parts are supposed to be binary. At youre totally
      out of luck if you mix a statefull encoding with binary, is any case.

      So the real utility of a specified encoding would be to allow binary
      transfers of invalid text.

      As for the use of a new _VIM_UTF8_TEXT atom:
      If _VIM_TEXT where changed intstead, to have backwards incompatibility,
      one would have to be running multiple versions of vim on one x server
      and copy/paste between them to have a problem. Since thats about as
      likely as running two vims with different encodings, Id argue that
      it would be no more backwards-incompatible than it already is.
      (setting the same vim to two different p_encs is incompat right now)
      (sorry if im still arguing a lost point)


      Having a bunch of encoding detection/conversion/encoding machinery is
      overkill for copy/paste imo. Vim is not a binary file editor, so not
      having the ability to copy/paste arbitrary binary can be written off
      imo. (Having to convert utf-8 to p_enc is needed because p_enc isnt
      always utf-8)

      In the medium/long run, utf-8 may be taking over, esp on the linux side.
      The next version of redhat is going utf-8 more completely, and that
      will be a big plus. We wont have to worry about conversion issues
      because
      both vim, gtk, mozilla, etc will all be using UTF8_STRING for clipboard.
      (gnome+redhat changes always seem to trickle down to other software)

      I guess the next most important thing will become rejection of overcoded
      sequences. They are real problems because they break searches, they sort
      improperly, and are total security holes (imagine you are editing system
      configuration files) I use other tools to fix them right now, but
      having vim treat them as binary trash is a big deal, imo
    • Bram Moolenaar
      ... You can edit many languages in UTF-8, but you won t have real locale support (case swapping, for example). I have complained before that it s not possible
      Message 2 of 4 , Aug 21, 2002
        Jason Maiorana wrote:

        > Bram wrote:
        > >I would like to get some feedback on this patch.
        >
        > Me too, I would like actual user feed back :) Also for the gvim
        > change. Im happily using them on my system. I havent gotten any
        > XIM servers to work for me yet: unfortunatly most of them have
        > poor utf-8 support, and are terribly dependant upon locales.
        > (I have no utf-8 locales, and I would really like to use many
        > languages at once- not just one, so a locale doesnt make sense
        > to me) But now at least I can paste text in from other sources.
        > (Imagine mixed vietnamese+japanese in one copy/paste)

        You can edit many languages in UTF-8, but you won't have real locale
        support (case swapping, for example). I have complained before that
        it's not possible to use several locales at the same time (in Vim it
        would be local to the buffer).

        > >I wonder if we should also add a _VIM_UTF8_TEXT atom. It would contain
        > >UTF-8 text and an indication of character/line/blockwise selection.
        > >_VIM_TEXT does this, but it doesn't say anything about the encoding.
        > >Even better may be _VIM_ENC_TEXT, which provides the text in 'encoding'
        > >and adds the encoding name to the selection. This will avoid a double
        > >conversion when 'encoding' is something like ISO-8859-9. Having two
        > >Vims with the same 'encoding' is very likely to happen.
        >
        > I am still not convinced this is necessary. Copy/Paste happens at a
        > glacial speed, so the efficiency concerns of double-conversion are
        > moot afaic.

        I'm not worried about the speed, but about the availability of a
        conversion library. Not all systems have one that supports UTF-8, or
        have none at all (on FreeBSD it is an optional package).

        Another reason is that some Vims are compiled without multi-byte
        support. You can't use UTF-8 at all then.

        > As for the use of a new _VIM_UTF8_TEXT atom:
        > If _VIM_TEXT where changed intstead, to have backwards incompatibility,
        > one would have to be running multiple versions of vim on one x server
        > and copy/paste between them to have a problem. Since thats about as
        > likely as running two vims with different encodings, Id argue that
        > it would be no more backwards-incompatible than it already is.
        > (setting the same vim to two different p_encs is incompat right now)
        > (sorry if im still arguing a lost point)

        I don't think we should do something backwards incompatible unless there
        is a good reason. I haven't heard that reason yet. Adding a bit of
        extra code for this is not enough of a reason.

        > I guess the next most important thing will become rejection of overcoded
        > sequences. They are real problems because they break searches, they sort
        > improperly, and are total security holes (imagine you are editing system
        > configuration files) I use other tools to fix them right now, but
        > having vim treat them as binary trash is a big deal, imo

        How would you (accidentally) produce an overlong sequence? If this is
        very unlikely to happen, only the security issue remains.

        --
        hundred-and-one symptoms of being an internet addict:
        262. Your computer has it's own phone line - but your daughter doesn't.

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Maiorana, Jason
        ... Thank you, Ive been waiting for others besides me to care about this! Any single locale wont help me. What i need are apps where the locale can be changed
        Message 3 of 4 , Aug 21, 2002
          Bram wrote:
          >You can edit many languages in UTF-8, but you won't have real locale
          >support (case swapping, for example). I have complained before that
          >it's not possible to use several locales at the same time (in Vim it
          >would be local to the buffer).

          Thank you, Ive been waiting for others besides me to care about this!
          Any single locale wont help me. What i need are apps where the locale
          can be changed in increments and simultaneously.

          If anyone is interested, I have a bit of code that can create a unicode
          case mapper (UPPER/lower) that works for all languages, to an extent
          (none of the multi-letter mappings in the extended case extensions,just
          simple single char to single char) which should work for all unicode.

          Imagine this:
          encoding: utf-8
          date-format: US/english
          error-messages: US-english
          case translation: Unicode-simple
          buffer1
          language collation: vietnamese
          input method: viqr
          buffer 2
          language collation: japanese/a ka sa ta
          input method: roumaji
          buffer 3
          language collation: japanese/alphabetic
          input method: roumaji
          buffer 4
          language collation: german
          case-translation: german double S thingy
          input method: straight




          >How would you (accidentally) produce an overlong sequence? If this is
          >very unlikely to happen, only the security issue remains.

          Yes, it generally happens on purpose. Making it impossible to
          use/ignore/read/miss is the goal.
        • Tony Mechelynck
          ... From: Maiorana, Jason To: Sent: Wednesday, August 21, 2002 11:58 PM Subject: RE: clipboard considerations
          Message 4 of 4 , Aug 21, 2002
            ----- Original Message -----
            From: "Maiorana, Jason" <jmaiorana@...>
            To: <vim-multibyte@...>
            Sent: Wednesday, August 21, 2002 11:58 PM
            Subject: RE: clipboard considerations


            > Bram wrote:
            > >You can edit many languages in UTF-8, but you won't have real locale
            > >support (case swapping, for example). I have complained before that
            > >it's not possible to use several locales at the same time (in Vim it
            > >would be local to the buffer).
            >
            > Thank you, Ive been waiting for others besides me to care about this!
            > Any single locale wont help me. What i need are apps where the locale
            > can be changed in increments and simultaneously.
            >
            > If anyone is interested, I have a bit of code that can create a unicode
            > case mapper (UPPER/lower) that works for all languages, to an extent
            > (none of the multi-letter mappings in the extended case extensions,just
            > simple single char to single char) which should work for all unicode.

            I'm interested, at least for latin scripts (including French, German and
            Esperanto), Greek and Russian. Is it a binary or a vim script? If the
            latter, maybe you should publish it at vim-online. If the former, is it for
            M$W, for U*X, or do I have to compile it myself? (I don't have a working
            compiler for M$W at the moment.) And I'm sure there are other people,
            non-subscribers to vim-multibyte, who'd be interested in such a case mapper
            too. (Vim-multibyte apparently is mostly for developers. Lots of Vimmers --
            IMHO -- use Unicode without subscribing to this particular ML.)
            >
            > Imagine this:
            > encoding: utf-8
            > date-format: US/english
            > error-messages: US-english
            > case translation: Unicode-simple
            > buffer1
            > language collation: vietnamese
            > input method: viqr
            > buffer 2
            > language collation: japanese/a ka sa ta
            > input method: roumaji
            > buffer 3
            > language collation: japanese/alphabetic
            > input method: roumaji
            > buffer 4
            > language collation: german
            > case-translation: german double S thingy
            > input method: straight
            >
            or maybe the same but date format: dd-Mon-yyyy and error-messages: en_US ?

            Is Japanes a-ka-sa-ta different from Japanese-a-i-u-e-o which I had
            explained to me? (a i u e o ka ki ku ke ko sa si su se so ta ti tu te to
            IIUC) And I suppose that, using vim sorting scripts, you could sort indexes
            from a-i-u-e-o to i-ro-ha-ni-ho-he-to and vice-versa almost as easily as you
            convert files from Latin1 to utf-8 or from dos (CR-NL) to unix (NL only)...

            Nice to have if it doesn't break something else. But how far in the future?
            >
            >
            > >How would you (accidentally) produce an overlong sequence? If this is
            > >very unlikely to happen, only the security issue remains.
            >
            > Yes, it generally happens on purpose. Making it impossible to
            > use/ignore/read/miss is the goal.
            >
            >
            >

            Regards,
            Tony.
          Your message has been successfully submitted and would be delivered to recipients shortly.