[vim-multibyte] Re: PATCH: Fix for bold characters spilling over left side in GUI.
- Dear vim-dev and vim-multibyte teams,
I make another patch based on the Robert's work.
I make some code clean up.
screen_char_needs_redraw() is becomes lighter.
(I also changed the function name shorter.)
And the function has no side effects now. (no char_bytes setting)
This patch is based on the original vim-5.6 source.
Please test the newer patch. I've just tested it in the MULTI_BYTE environment
in console mode(xterm) only. ^^;
- On Sat, Mar 25, 2000 at 12:01:43PM +0100, Bram Moolenaar wrote:
>I fix it.
> 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
> - 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 theI fix it.
> combination of right-left text and multibyte works? Probably doesn't make
> sense anyway.
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)
-- ' Clarke's Third Law
"Any sufficiently advanced technology is indistinguishable from magic."
- Robert Webb wrote:
> I have attached a new patch, to be applied to the original screen.c,Very good. Now it's up to the others to check out this version of the patch.
> 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:Agree.
> 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 nameI suppose it could be "char_needs_redraw", since it's checking only one
> though. "needs_redraw" is a very general description, but I guess it'll do.
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 --/-/
- Hi Bram et al,
> Did you see the patch from Chong-Dae Park? I'll await your commentsYep, there were two. They look fine. There was one place with
> before including this.
"#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 theOnly if force is set I think, and it still doesn't matter. The only
> character just right of the screen.
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.