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

[vim-multibyte] Re: PATCH: Fix for bold characters spilling over left side in GUI.

Expand Messages
  • Park Chong-Dae
    ... I fix it. ... I fix it. ... I fix it. Is there a charset that uses right-left and multibyte? I know some codes in MULTI_BYTE have rlflag settings. It could
    Message 1 of 10 , Mar 25 6:01 AM
    • 0 Attachment
      On Sat, Mar 25, 2000 at 12:01:43PM +0100, Bram Moolenaar wrote:
      >
      > Park Chong-Dae wrote:
      >
      > > I make another patch based on the Robert's work.
      >
      > I didn't check if this patch works properly, but spotted a few things:
      >
      > - is_need_update() has ANSI style declarations. Old compilers can't handle
      > this.

      I fix it.

      > - The last two "if" statements in is_need_update() can be combined.

      I fix it.

      > - The "endcol = Columns" can be put inside the "if (rlflag)". I wonder of the
      > combination of right-left text and multibyte works? Probably doesn't make
      > sense anyway.

      I fix it.
      Is there a charset that uses right-left and multibyte?
      I know some codes in MULTI_BYTE have rlflag settings.
      It could be removed. But I don't know about it. You can clean up the code.

      > - It looks like it's possible that update_next is set for the character just
      > right of the screen.

      ??

      This is yet another patch. And I tune up some code for performance and
      safe bound check. (removed a IsTrailByte() call)

      --
      Chong-Dae Park
      -- ' Clarke's Third Law
      "Any sufficiently advanced technology is indistinguishable from magic."
    • Bram Moolenaar
      ... Very good. Now it s up to the others to check out this version of the patch. ... Agree. ... I suppose it could be char_needs_redraw , since it s checking
      Message 2 of 10 , Mar 27 3:46 AM
      • 0 Attachment
        Robert Webb wrote:

        > I have attached a new patch, to be applied to the original screen.c,
        > which includes both of Chong-Dae Park's patches. I have also made the
        > new fix for bold fonts only take place in the GUI, not in xterm as
        > well, as per Bram's request.

        Very good. Now it's up to the others to check out this version of the patch.

        > I also renamed a few things:
        > update_this --> redraw_this
        > update_next --> redraw_next
        > is_needs_update --> needs_redraw
        >
        > I think "redraw" is a more specific description of the action required
        > than "update", and "needs_redraw" just reads better.

        Agree.

        > I still think that function could do with a longer more descriptive name
        > though. "needs_redraw" is a very general description, but I guess it'll do.

        I suppose it could be "char_needs_redraw", since it's checking only one
        character.

        --
        FATHER: Did you kill all those guards?
        LAUNCELOT: Yes ... I'm very sorry ...
        FATHER: They cost fifty pounds each!
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
      • Robert Webb
        Hi Bram et al, ... Yep, there were two. They look fine. There was one place with #if MULTI_BYTE instead of #ifdef MULTI_BYTE which I ve fixed. I have
        Message 3 of 10 , Mar 27 5:09 AM
        • 0 Attachment
          Hi Bram et al,

          > Did you see the patch from Chong-Dae Park? I'll await your comments
          > before including this.

          Yep, there were two. They look fine. There was one place with
          "#if MULTI_BYTE" instead of "#ifdef MULTI_BYTE" which I've fixed.

          I have attached a new patch, to be applied to the original screen.c,
          which includes both of Chong-Dae Park's patches. I have also made the
          new fix for bold fonts only take place in the GUI, not in xterm as
          well, as per Bram's request.

          I also renamed a few things:
          update_this --> redraw_this
          update_next --> redraw_next
          is_needs_update --> needs_redraw

          I think "redraw" is a more specific description of the action required
          than "update", and "needs_redraw" just reads better. I still think
          that function could do with a longer more descriptive name though.
          "needs_redraw" is a very general description, but I guess it'll do.

          > - It looks like it's possible that update_next is set for the
          > character just right of the screen.

          Only if force is set I think, and it still doesn't matter. The only
          place that the flag is tested for (other than next time around the
          loop, which won't be reached in this case), is for the new bold trick,
          in which case it might decide to redraw the current character
          unnecessarily. But if this only happens when force is set, then it'll
          get redrawn anyway, so no harm done.

          Rob.
        Your message has been successfully submitted and would be delivered to recipients shortly.