emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#11261: closed (24.1.50; cursor doesn't move in a l


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11261: closed (24.1.50; cursor doesn't move in a long line)
Date: Tue, 17 Apr 2012 15:32:02 +0000

Your message dated Tue, 17 Apr 2012 18:29:22 +0300
with message-id <address@hidden>
and subject line Re: bug#11261: 24.1.50; cursor doesn't move in a long line
has caused the debbugs.gnu.org bug report #11261,
regarding 24.1.50; cursor doesn't move in a long line
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11261: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11261
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.1.50; cursor doesn't move in a long line Date: Tue, 17 Apr 2012 08:40:40 +0900 User-agent: Gnus/5.130004 (真 Gnus v0.4) Emacs/24.1.50 (i686-pc-cygwin)
Hi,

When I view an html source, of which lines are very long, I meet
with a symptom that C-f, C-b, and so forth don't move the cursor.
One discovered yesterday that it happens only when the header line
exists in a buffer (we use emacs-w3m that ises the header line for
the tab browsing).  Here's a recipe to reproduce this with Emacs -Q:

(let ((fox "The quick brown fox jumps over the lazy dog."))
  (pop-to-buffer "*testing*")
  (erase-buffer)
  (setq header-line-format fox)
  (dotimes (var 1000)
    (insert fox "  "))
  (goto-char (point-min))
  (search-forward "fox" nil t 500))

Could this be fixed?

Thanks in advance.
Regards,



--- End Message ---
--- Begin Message --- Subject: Re: bug#11261: 24.1.50; cursor doesn't move in a long line Date: Tue, 17 Apr 2012 18:29:22 +0300
> Date: Tue, 17 Apr 2012 05:56:52 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > Date: Tue, 17 Apr 2012 08:40:40 +0900
> > From: Katsumi Yamaoka <address@hidden>
> > 
> > (let ((fox "The quick brown fox jumps over the lazy dog."))
> >   (pop-to-buffer "*testing*")
> >   (erase-buffer)
> >   (setq header-line-format fox)
> >   (dotimes (var 1000)
> >     (insert fox "  "))
> >   (goto-char (point-min))
> >   (search-forward "fox" nil t 500))
> > 
> > Could this be fixed?
> 
> This is a clear regression, so I will look into it ASAP.

Fixed in revision 107846 on the emacs-24 branch.  The patch is below,
if you don't want to wait for the next pretest.

Thanks.

=== modified file 'src/ChangeLog'
--- src/ChangeLog       2012-04-13 18:08:18 +0000
+++ src/ChangeLog       2012-04-17 15:25:17 +0000
@@ -1,3 +1,14 @@
+2012-04-17  Eli Zaretskii  <address@hidden>
+
+       * xdisp.c (string_buffer_position_lim): Limit starting position to
+       BEGV.
+       (set_cursor_from_row): If called for a mode-line or header-line
+       row, return zero immediately.
+       (try_cursor_movement): If inside continuation line, don't back up
+       farther than the first row after the header line, if any.  Don't
+       consider the header-line row as "partially visible", even if
+       MATRIX_ROW_PARTIALLY_VISIBLE_P returns non-zero.  (Bug#11261)
+
 2012-04-13  Atsuo Ohki  <address@hidden>  (tiny change)
 
        * lread.c (lisp_file_lexically_bound_p): Fix hang at ";-*-\n" 
(bug#11238).

=== modified file 'src/xdisp.c'
--- src/xdisp.c 2012-04-09 12:46:34 +0000
+++ src/xdisp.c 2012-04-17 15:25:17 +0000
@@ -4979,7 +4979,7 @@ string_buffer_position_lim (Lisp_Object 
   Lisp_Object limit, prop, pos;
   int found = 0;
 
-  pos = make_number (from);
+  pos = make_number (max (from, BEGV));
 
   if (!back_p) /* looking forward */
     {
@@ -13690,6 +13690,13 @@ set_cursor_from_row (struct window *w, s
      comes from a text property, not from an overlay.  */
   int string_from_text_prop = 0;
 
+  /* Don't even try doing anything if called for a mode-line or
+     header-line row, since the rest of the code isn't prepared to
+     deal with such calamities.  */
+  xassert (!row->mode_line_p);
+  if (row->mode_line_p)
+    return 0;
+
   /* Skip over glyphs not having an object at the start and the end of
      the row.  These are special glyphs like truncation marks on
      terminal frames.  */
@@ -14906,6 +14913,8 @@ try_cursor_movement (Lisp_Object window,
          else if (rc != CURSOR_MOVEMENT_SUCCESS
                   && !NILP (BVAR (XBUFFER (w->buffer), 
bidi_display_reordering)))
            {
+             struct glyph_row *row1;
+
              /* If rows are bidi-reordered and point moved, back up
                 until we find a row that does not belong to a
                 continuation line.  This is because we must consider
@@ -14916,24 +14925,28 @@ try_cursor_movement (Lisp_Object window,
              /* FIXME: Revisit this when glyph ``spilling'' in
                 continuation lines' rows is implemented for
                 bidi-reordered rows.  */
-             while (MATRIX_ROW_CONTINUATION_LINE_P (row))
+             for (row1 = MATRIX_FIRST_TEXT_ROW (w->current_matrix);
+                  MATRIX_ROW_CONTINUATION_LINE_P (row);
+                  --row)
                {
                  /* If we hit the beginning of the displayed portion
                     without finding the first row of a continued
                     line, give up.  */
-                 if (row <= w->current_matrix->rows)
+                 if (row <= row1)
                    {
                      rc = CURSOR_MOVEMENT_MUST_SCROLL;
                      break;
                    }
                  xassert (row->enabled_p);
-                 --row;
                }
            }
          if (must_scroll)
            ;
          else if (rc != CURSOR_MOVEMENT_SUCCESS
              && MATRIX_ROW_PARTIALLY_VISIBLE_P (w, row)
+             /* Make sure this isn't a header line by any chance, since
+                then MATRIX_ROW_PARTIALLY_VISIBLE_P might yield non-zero.  */
+             && !row->mode_line_p
              && make_cursor_line_fully_visible_p)
            {
              if (PT == MATRIX_ROW_END_CHARPOS (row)



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]