bug#9065: 24.0.50; ESC-> does not seem to function

bug#9065: 24.0.50; ESC-> does not seem to function

[Peter Dyballa]

Hello!

In GNU Emacs 24.0.50.1 (powerpc-apple-darwin9.8.0, GTK+ Version 2.24.4)
  of 2011-07-02 on ip-109-91-229-51.unitymediagroup.de
Windowing system distributor `The X.Org Foundation', version  
11.0.11002000
configured using `configure  '--without-sound' '--without-dbus' '-- 
without-pop' '--without-gconf' '--without-gpm' '--without-gsettings'  
'--with-x-toolkit=gtk' '--enable-locallisppath=/Library/Application  
Support/Emacs/calendar24:/Library/Application Support/Emacs' 'CFLAGS=- 
g -H -pipe -fPIC -fno-common -mcpu=7450 -mtune=7450 -maltivec - 
faltivec -mabi=altivec -Os -mfused-madd -mmultiple -ftree-vectorize'  
'LDFLAGS=-Wl,-dead_strip_dylibs -Wl,-bind_at_load -Wl,-t' 'CC=gcc-4'  
'CPP=cpp-4' 'PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/opt/local/share/ 
pkgconfig:/usr/lib/pkgconfig''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Compilation

Minor modes in effect:
   shell-dirtrack-mode: t
   text-scale-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Launched with -Q, to see whether effects I encounter in customised  
copy might be due to the customisation. Here in a *compilation* buffer  
the compilation of GCC happens – 100,000 or so lines of output. When I  
want to go the bottom of the buffer and type ESC-> the wristwatch  
cursor appears. It can stay of minutes, maybe even longer. No movement  
of the text in the buffer happens. But when I press C-g the cursor is  
at once at the end of the buffer and is pushed further forward from  
the output just happening.

I have the impression that a few thousand lines have to be between the  
point where I type ESC-> and the end of the buffer – and maybe text  
insertion has to happen. One constraint could also be heavy CPU load  
and GNU Emacs swapped out due to leaving it untouched for hours. It  
behaves very inert when I pick it to be the active X client. The  
cursor appears after seconds and heavy disk activity is indicated.

--
Greetings

   Pete

Imbecility, n.:
	A kind of divine inspiration, or sacred fire affecting censorious  
critics of this dictionary.
				– Ambrose Bierce: _The Devil's Dictionary_

bug#9065: 24.0.50; ESC-> does not seem to function

[Lars Magne Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Launched with -Q, to see whether effects I encounter in customised
> copy might be due to the customisation. Here in a *compilation* buffer
> the compilation of GCC happens – 100,000 or so lines of output. When I
> want to go the bottom of the buffer and type ESC-> the wristwatch
> cursor appears. It can stay of minutes, maybe even longer. No movement
> of the text in the buffer happens. But when I press C-g the cursor is
> at once at the end of the buffer and is pushed further forward from
> the output just happening.

Try (setq debug-on-quit t) and then `C-g'.  Post the backtrace here.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#9065: 24.0.50; ESC-> does not seem to function

[Peter Dyballa]

Am 11.09.2011 um 06:23 schrieb Lars Magne Ingebrigtsen:

> Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:
>
>> Launched with -Q, to see whether effects I encounter in customised
>> copy might be due to the customisation. Here in a *compilation*  
>> buffer
>> the compilation of GCC happens – 100,000 or so lines of output.  
>> When I
>> want to go the bottom of the buffer and type ESC-> the wristwatch
>> cursor appears. It can stay of minutes, maybe even longer. No  
>> movement
>> of the text in the buffer happens. But when I press C-g the cursor is
>> at once at the end of the buffer and is pushed further forward from
>> the output just happening.
>
> Try (setq debug-on-quit t) and then `C-g'.  Post the backtrace here.

The failure is never so severe that it comes to debugging ... But I  
found the cause for the slow down, when I repeated this a lot in  
*compilation* buffers with warnings in them: the cursor is not just  
moved to the end of the buffer, while this happens the text is scanned  
for warnings, errors, etc. The same seems to be true when using  
isearch. It's also pretty slow in *compilation* buffers.

I don't know whether this is documented (it should be). What I'd wish  
is that I could configure/customise the (large, > 10,000 lines)  
*compilation* buffers (often compiling with -H and -Wl,-t) that it is  
not scanned for compiler reports, either unconditionally or  
conditionally based on the number of lines in the buffer, that this  
scanning stops when the number becomes greater than a certain value.  
There are means to search for these compiler reports, so there should  
not be a side-project performed when moving the mark or isearch'ing.

--
Greetings

   Pete

Almost anything is easier to get into than out of.
				– Allen's Law

bug#9065: 24.0.50; ESC-> does not seem to function

[Stefan Monnier]

retitle 9065 Speed up compile.el scanning
thanks

Yes, the scanning performed is problematic for large buffers.
There are several ways to improve the problem:
1- make the job more lazy.  E.g. split compilation--ensure-parse into 3 parts:
   a- a position independent part (that can be done one a region
      regardless of preceding text) to use in font-lock.
   b- a position-dependent part doing all the heavy lifting, used in next-error.
   c- the rest is also position-dependent but also used from font-lock,
      i.e. works just like the current compilation--ensure-parse and hence
      is the source of performance problem (so it should do as little as
      possible).
2- speed up the scanning done in syntax-propertize.

I suspect most of the time is spent regexp-matching, and this regexp
matching can be done some other way (instead of a loop over various
regexps each one matched via re-search-forward using a backtracking
matcher, we could combine them all into a single regexp matched via
a non-backtracking matcher, except for the few regexps using back-refs).

I.e. option (2) is clearly possible and could reduce the performance
problem by a very large amount.

But option (1) is also possible and highly desirable.

Patches welcome.


        Stefan