Richard Stallman <[EMAIL PROTECTED]> writes: > > It turns out that vertical-motion was fontifying all the text that > > it moved over. That seems to be easy to fix. > > Did you try my suggestion of customizing jit-lock-defer-time? > > No, because I want to fix this, not work around it. vertical-motion > is a cursor motion function. It should not fontify anything.
vertical-motion is a built-in function in `C source code'. (vertical-motion LINES &optional WINDOW) Move point to start of the screen line LINES lines down. If LINES is negative, this means moving up. This function is an ordinary cursor motion function which calculates the new position based on how text would be displayed. The new position may be the start of a line, or just the start of a continuation line. [...] I don't see how vertical-motion can be expected to calculate the new position based on how text would be displayed if it is not allowed to figure out how text would be displayed. So for its correct behavior, it is mandatory to do the font locking. The only exception to that would be if the user would have specified that it is ok to work with unfontified text. One way to do that is to set jit-lock-defer-time. I think it would be reasonable if jit-lock-defer-time (currently defaulting to nil) would instead default to 0, with 0 meaning that font locking will occur without delay before displaying stuff, but not otherwise (maybe that setting already does that, but I have not checked). This would mean that paging back and forth over previously nonfontified stuff would not necessarily lead to the same position, but that still no surprisingly unfontified stuff would show up on the display. But with the current settings, it appears to me that vertical-motion can't reasonably do something different. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
