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

cursor width on gtk

Expand Messages
  • Yasuhiro Matsumoto
    Hello vim-multibyte and bram. this is a small fix for cursor width on gtk. thanks.
    Message 1 of 7 , Jul 11, 2001
    • 0 Attachment
      Hello vim-multibyte and bram.

      this is a small fix for cursor width on gtk.

      thanks.
    • Yasuhiro Matsumoto
      ... Sorry, It was a mistaked patch.
      Message 2 of 7 , Jul 11, 2001
      • 0 Attachment
        Yasuhiro Matsumoto wrote:
        >
        >Hello vim-multibyte and bram.
        >
        >this is a small fix for cursor width on gtk.
        >
        >thanks.

        Sorry, It was a mistaked patch.
      • Bram Moolenaar
        ... Could you please explain this? It looks like a longer string gets a width of just the first character. And why does nothing have to be changed for UTF-8?
        Message 3 of 7 , Jul 11, 2001
        • 0 Attachment
          Yasuhiro Matsumoto wrote:

          > Hello vim-multibyte and bram.
          >
          > this is a small fix for cursor width on gtk.

          Could you please explain this? It looks like a longer string gets a width of
          just the first character. And why does nothing have to be changed for UTF-8?

          --
          Rule #1: Don't give somebody a tool that he's going to hurt himself with.

          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
          ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
        • Yasuhiro Matsumoto
          ... Could you get my second patch? (By way of precaution, it sends again.) if string include euc-jp half character, the width will be large more than len .
          Message 4 of 7 , Jul 11, 2001
          • 0 Attachment
            Bram Moolenaar wrote:
            >Yasuhiro Matsumoto wrote:
            >
            >> Hello vim-multibyte and bram.
            >>
            >> this is a small fix for cursor width on gtk.
            >
            >Could you please explain this? It looks like a longer string gets a width of
            >just the first character. And why does nothing have to be changed for UTF-8?

            Could you get my second patch?
            (By way of precaution, it sends again.)

            if string include euc-jp half character,
            the "width" will be large more than "len".
            so cursor width of there will be double width.
          • Yasuhiro Matsumoto
            ... Ahh... I forgat about UTF-8. Sorry please change enc_dbcs - has_mbyte.
            Message 5 of 7 , Jul 11, 2001
            • 0 Attachment
              Yasuhiro Matsumoto wrote:
              >
              >Bram Moolenaar wrote:
              >>Yasuhiro Matsumoto wrote:
              >>
              >>> Hello vim-multibyte and bram.
              >>>
              >>> this is a small fix for cursor width on gtk.
              >>
              >>Could you please explain this? It looks like a longer string gets a width of

              >>just the first character. And why does nothing have to be changed for UTF-8?

              >
              >Could you get my second patch?
              >(By way of precaution, it sends again.)
              >
              >if string include euc-jp half character,
              > the "width" will be large more than "len".
              >so cursor width of there will be double width.

              Ahh...

              I forgat about UTF-8.
              Sorry please change enc_dbcs -> has_mbyte.
            • Bram Moolenaar
              ... No, nothing was attached. ... I suspect the problem would then be that the caller has made a mistake, and it will also be wrong for other GUIs. Could you
              Message 6 of 7 , Jul 11, 2001
              • 0 Attachment
                Yasuhiro Matsumoto wrote:

                > >> Hello vim-multibyte and bram.
                > >>
                > >> this is a small fix for cursor width on gtk.
                > >
                > >Could you please explain this? It looks like a longer string gets a width
                > >of just the first character. And why does nothing have to be changed for
                > >UTF-8?
                >
                > Could you get my second patch?
                > (By way of precaution, it sends again.)

                No, nothing was attached.

                > if string include euc-jp half character,
                > the "width" will be large more than "len".
                > so cursor width of there will be double width.

                I suspect the problem would then be that the caller has made a mistake, and it
                will also be wrong for other GUIs. Could you please explain how to reproduce
                the problem you noticed?

                --
                hundred-and-one symptoms of being an internet addict:
                181. You make up words that go with the "happy tune" your modem makes
                while dialing your ISP.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              • Yasuhiro Matsumoto
                ... a len of gui_mch_draw_string is length of bytes. but width should not be len. on other platform, cells or width was re-calced.
                Message 7 of 7 , Jul 11, 2001
                • 0 Attachment
                  Bram Moolenaar wrote:
                  >I suspect the problem would then be that the caller has made a mistake, and it

                  >will also be wrong for other GUIs. Could you please explain how to reproduce
                  >the problem you noticed?

                  a len of gui_mch_draw_string is length of bytes.
                  but width should not be len.
                  on other platform, cells or width was re-calced.
                Your message has been successfully submitted and would be delivered to recipients shortly.