Re: [PATCH] line_number_cache corruption with buffer_replace_char()

Synopsis: buffer_replace_char() forgets to check for \n insertions and deletions, potentially leaving the line-number cache out of sync with reality. To see it: - Visit a big buffer, like redisplay.c, with hs-minor-mode from hideshow.el turned on; `selective-display' will be `t'. - Invoke `hs-hide-all'. - Go to the bottom of the buffer; sensibly, the line number is low, because most of the `\n's in the buffer are now `^M's. - Invoke `hs-show-all'. - Watch the line number not change, because the cache is not invalidated, despite the transformation of all those `^M's back into `\n's again. If the buffer's big enough, moving backwards in units of less than LINE_NUMBER_FAR chars can give you a negative line number. This definitely affects subst-char-in-region (which hideshow uses), and might well affect translate-region and replace-match calls that don't change lengths too. I've tried to MULEize this, but this is my first exposure to MULE inside of XEmacs, so the patch, although tiny, may be wrong or wildly inefficient or not the idiomatic way to do things. If so, please fix and castigate :) diff -durN xemacs-orig/src/insdel.c xemacs/src/insdel.c --- xemacs-orig/src/insdel.c Mon Apr 16 23:33:02 2001 +++ xemacs/src/insdel.c Wed Jul 25 23:48:44 2001 ＠＠ -2922,8 +2922,19 ＠＠ MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) { mbuf->changes->newline_was_deleted = 1; + delete_invalidate_line_number_cache (mbuf, pos, pos+1); } } + + if (ch == '\n') + { + Bufbyte inserted_char[MAX_EMCHAR_LEN]; + Bytecount len; + + len = set_charptr_emchar (inserted_char, ch); + insert_invalidate_line_number_cache (buf, pos, inserted_char, len); + } + MARK_BUFFERS_CHANGED; if (!not_real_change) { -- `It's all about bossing computers around. Users have to say "please". Programmers get to say "do what I want NOW or the hard disk gets it".' -- Richard Heathfield on the nature of programming