gfxterm/pager regression

gfxterm/pager regression

[Colin Watson]

gfxterm is behaving very oddly for me with 'set pager=1' right now; the
--MORE-- prompt appears after only a few lines of text have been output.
It looks rather as if it is counting the number of output characters as
if they were the number of output lines.  This doesn't happen when the
terminal output is an ordinary VGA console.

Looking at normal/term.c:put_glyphs_terminal, it seems that it
increments state->num_lines after every glyph.  This seems pretty odd.
Doesn't it need to do something a bit smarter than that?  Vladimir, is
this a regression from your bidi branch merge?

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: gfxterm/pager regression

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]

On 07/05/2010 02:47 PM, Colin Watson wrote:
> gfxterm is behaving very oddly for me with 'set pager=1' right now; the
> --MORE-- prompt appears after only a few lines of text have been output.
> It looks rather as if it is counting the number of output characters as
> if they were the number of output lines.  This doesn't happen when the
> terminal output is an ordinary VGA console.
>
> Looking at normal/term.c:put_glyphs_terminal, it seems that it
> increments state->num_lines after every glyph.  This seems pretty odd.
> Doesn't it need to do something a bit smarter than that?  Vladimir, is
> this a regression from your bidi branch merge?
>
>   
Looks this way. Please test attached patch.
> Thanks,
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: charnl.diff --]
[-- Type: text/x-diff; name="charnl.diff", Size: 989 bytes --]

=== modified file 'normal/term.c'
--- normal/term.c	2010-07-02 16:20:48 +0000
+++ normal/term.c	2010-07-06 00:05:55 +0000
@@ -616,16 +616,18 @@
       if (visual_ptr->base == '\n')
 	grub_print_spaces (term, margin_right);
       putglyph (visual_ptr, term);
-      if (state && ++state->num_lines
-	  >= (grub_ssize_t) grub_term_height (term) - 2)
-      {
-	state->backlog_glyphs = visual_ptr + 1;
-	state->backlog_len = visual_len - (visual - visual_ptr) - 1;
-	return 1;
-      }
+      if (visual_ptr->base == '\n')
+	{
+	  if (state && ++state->num_lines
+	      >= (grub_ssize_t) grub_term_height (term) - 2)
+	    {
+	      state->backlog_glyphs = visual_ptr + 1;
+	      state->backlog_len = visual_len - (visual - visual_ptr) - 1;
+	      return 1;
+	    }
 
-      if (visual_ptr->base == '\n')
-	grub_print_spaces (term, margin_left);
+	  grub_print_spaces (term, margin_left);
+	}
       grub_free (visual_ptr->combining);
     }
   return 0;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: gfxterm/pager regression

[Colin Watson]

On Tue, Jul 06, 2010 at 02:06:47AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 07/05/2010 02:47 PM, Colin Watson wrote:
> > gfxterm is behaving very oddly for me with 'set pager=1' right now; the
> > --MORE-- prompt appears after only a few lines of text have been output.
> > It looks rather as if it is counting the number of output characters as
> > if they were the number of output lines.  This doesn't happen when the
> > terminal output is an ordinary VGA console.
> >
> > Looking at normal/term.c:put_glyphs_terminal, it seems that it
> > increments state->num_lines after every glyph.  This seems pretty odd.
> > Doesn't it need to do something a bit smarter than that?  Vladimir, is
> > this a regression from your bidi branch merge?
> 
> Looks this way. Please test attached patch.

This looks good and works much better.  Thanks!

-- 
Colin Watson                                       [cjwatson@ubuntu.com]