Re: [bug]org-mode with flyspell-mode freezes emacs

Re: [bug]org-mode with flyspell-mode freezes emacs

[Leo]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Here is a bug report and feedback from org-mode author Carsten Dominik.

------------------
On Thu, 12/10/06 03:10 +0100, Leo wrote:

    Dear all,
   
    Starting emacs with "emacs -q -l test test.org". Then press "C-x
    ]". Emacs will freeze.
   
    "test" and "test.org" are attached.
   
    Tested on GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
    of 2006-10-04 running under fedora core 5.

[-- Attachment #2: test --]
[-- Type: application/octet-stream, Size: 153 bytes --]

(setq inhibit-startup-message t)
(add-hook 'text-mode-hook
	  (lambda nil
	    (flyspell-mode t)))
(add-to-list 'auto-mode-alist '("\\.org" . org-mode))

[-- Attachment #3: test.org --]
[-- Type: application/octet-stream, Size: 51 bytes --]

dddd

[[mailto:tt308@cat.ac.uk][TT308@cat.ac.uk]]


[-- Attachment #4: Type: text/plain, Size: 3801 bytes --]


On Thu Oct 12 10:51:51 2006 +0100, Carsten Dominik wrote:

    I can reproduce this under Emacs 22, but I have not been able to
    figure out what is causing this, because Emacs hangs so that it cannot
    even be stopped with C-g.
    
    It seems to be caused by links which contain hidden and intangible text.
    
    Don't really know where to go from here.
    
    - Carsten

On Thu Oct 12 17:29:46 2006 +0100, Carsten Dominik wrote:

    > Do you mind if I forward my original bug report and your comments in
    > this email to emacs-devel list?
    >
    
    Not at all.  Additional info:  This seems to happen when the cursor
    gets into the white space after a link.  Emacs gets stuck in
    accept-process-output' from the ispell process.  That call is wrapped
    into with-local-quit, which may have to do with the fact that this
    cannot be exited with keyboard-quit.
    
    The work ispell is supposed to be looking up is "uk", and the word is
    extracted from the buffer without text properties, so the fact that I
    am using intangible and invisible text properties should not play a
    role with this.  In fact, I have no idea what might be causing this,
    but I don't see how org-mode could be the true reason.
    
    Here is the backtrace from just before the hangup.  When I press "d",
    emacs will get stuck.
    
    Debugger entered--beginning evaluation of function call form:
    * (accept-process-output ispell-process)
    * (progn (accept-process-output ispell-process) (not (string= "" ...)))
    * (while (progn (accept-process-output ispell-process) (not ...)))
    * (let ((inhibit-quit nil)) (while (progn ... ...)))
    * (condition-case nil (let (...) (while ...)) (quit (setq quit-flag t)
    (eval ...)))
    * (with-local-quit (while (progn ... ...)))
    * (cond ((and ... flyspell-mark-duplications-flag ...)
    (flyspell-highlight-incorrect-region start end ...) nil) ((and
    ... ... ...) flyspell-word-cache-result) ((and ... ...)
    (flyspell-unhighlight-at start) (if ... ...) t) (t (setq
    flyspell-word-cache-start start) (setq flyspell-word-cache-end end)
    (setq flyspell-word-cache-word word) (ispell-send-string "%\n")
    (ispell-send-string ...) (set-process-query-on-exit-flag
    ispell-process nil) (with-local-quit ...) (setq ispell-filter ...) (or
    ispell-filter ...) (if ... ...) (let ... ... ... res)))
    * (progn (setq start (car ...) end (car ...) word (car flyspell-word))
    (cond (... ... nil) (... flyspell-word-cache-result) (... ... ... t)
    (t ... ... ... ... ... ... ... ... ... ... ...)))
    * (if (or (eq flyspell-word nil) (and ... ...)) t (progn (setq start
    ... end ... word ...) (cond ... ... ... ...)))
    * (let* ((cursor-location ...) (flyspell-word ...) start end poss word
    ispell-filter) (if (or ... ...) t (progn ... ...)))
    * (save-excursion (flyspell-accept-buffer-local-defs) (let*
    (... ... start end poss word ispell-filter) (if ... t ...)))
    * flyspell-word()
    * (progn (quote (flyspell-debug-signal-word-checked)) (flyspell-word)
    (setq flyspell-pre-pre-buffer (current-buffer)) (setq
    flyspell-pre-pre-point (point)))
    * (if (flyspell-check-word-p) (progn (quote ...) (flyspell-word) (setq
    flyspell-pre-pre-buffer ...) (setq flyspell-pre-pre-point ...)) (progn
    (setq flyspell-pre-pre-buffer nil) (setq flyspell-pre-pre-point nil)
    (if ... ...)))
    * (let ((command this-command) deactivate-mark) (if
    (flyspell-check-pre-word-p) (with-current-buffer flyspell-pre-buffer
    ... ...)) (if (flyspell-check-word-p) (progn ... ... ... ...) (progn
    ... ... ...)) (while (and ... ...) (let ... ... ...)) (setq
    flyspell-previous-command command))
    * flyspell-post-command-hook()
    * run-hooks(post-command-hook)

-- 
Leo

[-- Attachment #5: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [bug]org-mode with flyspell-mode freezes emacs

[Richard Stallman]

    On Thu Oct 12 10:51:51 2006 +0100, Carsten Dominik wrote:

    I can reproduce this under Emacs 22, but I have not been able to
    figure out what is causing this, because Emacs hangs so that it cannot
    even be stopped with C-g.
    
    It seems to be caused by links which contain hidden and intangible text.
    
    Don't really know where to go from here.
    
    - Carsten


Can you run Emacs under GDB, stop it while it is in this loop,
and send us the backtrace?

As a next step, you could follow the advice in etc/DEBUG about
investigating an infinite loop.  This information could probably enable
someone else to debug the Emacs bug.

For others' information, the initial bug report:

From: Leo <sdl.web@gmail.com>

    Starting emacs with "emacs -q -l test test.org". Then press "C-x
    ]". Emacs will freeze.
   
    "test" and "test.org" are attached.
   
    Tested on GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
    of 2006-10-04 running under fedora core 5.


(setq inhibit-startup-message t)
(add-hook 'text-mode-hook
	  (lambda nil
	    (flyspell-mode t)))
(add-to-list 'auto-mode-alist '("\\.org" . org-mode))

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

On Oct 15, 2006, at 6:20, Richard Stallman wrote:

>     On Thu Oct 12 10:51:51 2006 +0100, Carsten Dominik wrote:
>
>     I can reproduce this under Emacs 22, but I have not been able to
>     figure out what is causing this, because Emacs hangs so that it 
> cannot
>     even be stopped with C-g.
>
>     It seems to be caused by links which contain hidden and intangible 
> text.
>
>     Don't really know where to go from here.
>
>     - Carsten
>
>
> Can you run Emacs under GDB, stop it while it is in this loop,
> and send us the backtrace?

I am unable to reproduce this bug under gdb.  That is, I tried, but
Emacs does not hang when run under gdb.

- Carsten


>
> As a next step, you could follow the advice in etc/DEBUG about
> investigating an infinite loop.  This information could probably enable
> someone else to debug the Emacs bug.
>
> For others' information, the initial bug report:
>
> From: Leo <sdl.web@gmail.com>
>
>     Starting emacs with "emacs -q -l test test.org". Then press "C-x
>     ]". Emacs will freeze.
>
>     "test" and "test.org" are attached.
>
>     Tested on GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 
> 2.8.20)
>     of 2006-10-04 running under fedora core 5.
>
>
> (setq inhibit-startup-message t)
> (add-hook 'text-mode-hook
> 	  (lambda nil
> 	    (flyspell-mode t)))
> (add-to-list 'auto-mode-alist '("\\.org" . org-mode))
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

Apologies for my previous message in which I said I could not reproduce 
this error under gdb.  This was a mistake on my side, caused by an 
alias expansion of the command emacs that make "gdb emacs" refer to 
emacs 21 instead of Emacs 22.

Anyway, I do now have a backtrace for this problem.  Can anyone extract 
something useful from this?

Thanks.

- Carsten



(gdb) run -l test test.org
Starting program: /Users/dominik/bin/ne -l test test.org
Reading symbols for shared libraries ++++. done
^C
Program received signal SIGINT, Interrupt.
0x00157454 in validate_interval_range (object=20860132, 
begin=0xbfffd8e8, end=0xbfffd8e8, force=0) at textprop.c:135
135       CHECK_NUMBER_COERCE_MARKER (*end);
(gdb) backtrace
#0  0x00157454 in validate_interval_range (object=20860132, 
begin=0xbfffd8e8, end=0xbfffd8e8, force=0) at textprop.c:135
#1  0x001573c4 in validate_interval_range (object=20860132, 
begin=0xbfffd8e8, end=0xbfffd8e8, force=0) at textprop.c:129
#2  0x00158274 in Ftext_properties_at (position=432, object=20860128) 
at textprop.c:590
#3  0x0015830c in Fget_text_property (position=432, prop=-1073751832, 
object=-1073751832) at textprop.c:611
#4  0x0015a7b0 in text_property_stickiness (prop=58879617, pos=0, 
buffer=20860132) at textprop.c:1789
#5  0x00156284 in adjust_for_invis_intang (pos=20860132, test_offs=0, 
adj=20860132, test_intang=2729760) at intervals.c:1989
#6  0x00156540 in set_point_both (buffer=0x13e4ce4, charpos=20860128, 
bytepos=20860132) at intervals.c:2112
#7  0x000e8558 in search_command (string=28183443, bound=432, 
noerror=58720825, count=0, direction=0, RE=0, posix=0) at search.c:1008
#8  0x00114d54 in Ffuncall (nargs=432, args=0x1) at eval.c:3003
#9  0x00142110 in Fbyte_code (bytestr=17315416, vector=1, maxdepth=1) 
at bytecode.c:679
#10 0x001152e8 in funcall_lambda (fun=1, nargs=0, arg_vector=0x3800239) 
at eval.c:3180
#11 0x00114e88 in Ffuncall (nargs=432, args=0x1) at eval.c:3050
#12 0x00142110 in Fbyte_code (bytestr=17315416, vector=1, maxdepth=1) 
at bytecode.c:679
#13 0x001152e8 in funcall_lambda (fun=1, nargs=0, arg_vector=0x3800239) 
at eval.c:3180
#14 0x00114e88 in Ffuncall (nargs=432, args=0x1) at eval.c:3050
#15 0x00142110 in Fbyte_code (bytestr=17315416, vector=1, maxdepth=1) 
at bytecode.c:679
#16 0x001152e8 in funcall_lambda (fun=1, nargs=0, arg_vector=0x3800239) 
at eval.c:3180
#17 0x00114e88 in Ffuncall (nargs=432, args=0x1) at eval.c:3050
#18 0x00114604 in run_hook_with_args (nargs=0, args=0x1, cond=28183443) 
at eval.c:2652
#19 0x00114410 in Frun_hooks (nargs=432, args=0x1b0) at eval.c:2515
#20 0x00114d18 in Ffuncall (nargs=432, args=0x38109e1) at eval.c:2996
#21 0x00114850 in call1 (fn=432, arg1=432) at eval.c:2774
#22 0x00112860 in internal_condition_case (bfun=0xa9040 
<safe_run_hooks_1>, handlers=58720825, hfun=0xa9080 
<safe_run_hooks_error>) at eval.c:1477
#23 0x000a9160 in safe_run_hooks (hook=432) at keyboard.c:2131
#24 0x000a8584 in command_loop_1 () at keyboard.c:1875
#25 0x00112860 in internal_condition_case (bfun=0xa7364 
<command_loop_1>, handlers=58767017, hfun=0xa6a84 <cmd_error>) at 
eval.c:1477
#26 0x000a6f48 in command_loop_2 () at keyboard.c:1326
#27 0x00112218 in internal_catch (tag=432, func=0xa6f08 
<command_loop_2>, arg=58720777) at eval.c:1218
#28 0x000a6ea0 in command_loop () at keyboard.c:1305
#29 0x000a66c0 in recursive_edit_1 () at keyboard.c:1003
#30 0x000a6878 in Frecursive_edit () at keyboard.c:1064
#31 0x000a52e0 in main (argc=1601296, argv=0x2d0210) at emacs.c:1794




On Oct 15, 2006, at 6:20, Richard Stallman wrote:

>     On Thu Oct 12 10:51:51 2006 +0100, Carsten Dominik wrote:
>
>     I can reproduce this under Emacs 22, but I have not been able to
>     figure out what is causing this, because Emacs hangs so that it 
> cannot
>     even be stopped with C-g.
>
>     It seems to be caused by links which contain hidden and intangible 
> text.
>
>     Don't really know where to go from here.
>
>     - Carsten
>
>
> Can you run Emacs under GDB, stop it while it is in this loop,
> and send us the backtrace?
>
> As a next step, you could follow the advice in etc/DEBUG about
> investigating an infinite loop.  This information could probably enable
> someone else to debug the Emacs bug.
>
> For others' information, the initial bug report:
>
> From: Leo <sdl.web@gmail.com>
>
>     Starting emacs with "emacs -q -l test test.org". Then press "C-x
>     ]". Emacs will freeze.
>
>     "test" and "test.org" are attached.
>
>     Tested on GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 
> 2.8.20)
>     of 2006-10-04 running under fedora core 5.
>
>
> (setq inhibit-startup-message t)
> (add-hook 'text-mode-hook
> 	  (lambda nil
> 	    (flyspell-mode t)))
> (add-to-list 'auto-mode-alist '("\\.org" . org-mode))
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[Richard Stallman]

    Anyway, I do now have a backtrace for this problem.  Can anyone extract 
    something useful from this?

Please follow the advice in etc/DEBUG to find the function which
doesn't exit.

Re: [bug]org-mode with flyspell-mode freezes emacs

[Nick Roberts]

 > Anyway, I do now have a backtrace for this problem.  Can anyone extract 
 > something useful from this?

If Emacs is hanging, a static backtrace is unlikely to be much use.  You need
to follow the instructions in DEBUG:

  If Emacs is in an infinite loop, try to determine where the loop
  starts and ends.  The easiest way to do this is to use the GDB command
  `finish'.  Each time you use it, Emacs resumes execution until it
  exits one stack frame.  Keep typing `finish' until it doesn't
  return--that means the infinite loop is in the stack frame which you
  just tried to finish.

  Stop Emacs again, and use `finish' repeatedly again until you get back
  to that frame.  Then use `next' to step through that frame.  By
  stepping, you will see where the loop starts and ends.  Also, examine
  the data being used in the loop and try to determine why the loop does
  not exit when it should.

Also when a C backtrace is useful, it usually helps to include lisp backtrace.
This is output automatically with `bt' if you run Emacs under GDB from the src
directory otherwise you need to source .gdbinit (in the src directory) first.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

On Oct 17, 2006, at 6:33, Nick Roberts wrote:

>> Anyway, I do now have a backtrace for this problem.  Can anyone 
>> extract
>> something useful from this?
>
> If Emacs is hanging, a static backtrace is unlikely to be much use.  
> You need
> to follow the instructions in DEBUG:

I have not been able to do this well, the results are very confusing to 
me, I sometimes end up in the garbage collection, sometimes in search 
functions like looking-at-1 or search-buffer.  So for now I don't have 
better information on this bug, and I don't have much time for going 
much further on this.

However, on the Lisp level, I have been able to dig deeper and found 
the following.

This error happens if flyspell is trying to check a word that is 
followed by a character with the `intangible' text property.  The words 
in the buffer where Emacs enters an infinite loop look like this

    something]]

where the "]]" carry both the invisible and the intangible text 
property.  If I remove the intangible text property and only keep 
invisible, there is no problem and Emacs functions normally. If I 
remove invisible and keep intangible, the error still happens.

> Also when a C backtrace is useful, it usually helps to include lisp 
> backtrace.
> This is output automatically with `bt' if you run Emacs under GDB from 
> the src
> directory otherwise you need to source .gdbinit (in the src directory) 
> first.

A typical lisp backtrace looks like this:

Lisp Backtrace:
"flyspell-get-word" (0x3800209)
"flyspell-word-search-backward" (0x1add4e3)
"flyspell-word" (0x3800209)
"flyspell-post-command-hook" (0x0)
"run-hooks" (0x3809c69)

or

Lisp Backtrace:
"re-search-forward" (0x1b0d1b3)
"flyspell-get-word" (0x3800209)
"flyspell-word-search-backward" (0x1add4e3)
"flyspell-word" (0x3800209)
"flyspell-post-command-hook" (0x0)
"run-hooks" (0x3809c69)

This is strange because it looks like there is an infinite loop on the 
lisp level, but when I use the lisp debugger, it is the call to 
accept-process-output where Emacs gets stuck.

I guess as a temporary fix I could remove the intangible text property, 
since invisible text is handled by the point-motion functions much like 
intangible text, so it is not really necessary to have both.  Is this a 
correct assessment?

Thanks, and sorry that I cannot be more helpful.

- Carsten

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

And here is one more piece of the puzzle:

I just found out that the emacs-wiki and muse people have been 
struggling with the same problem.  Their fix was to use 
inhibit-point-motion-hooks.  This points into the direction that a 
search function gets thrown off into a loop by the point-motion-hooks.

- Carsten



On Oct 17, 2006, at 12:57, Carsten Dominik wrote:

>
> On Oct 17, 2006, at 6:33, Nick Roberts wrote:
>
>>> Anyway, I do now have a backtrace for this problem.  Can anyone 
>>> extract
>>> something useful from this?
>>
>> If Emacs is hanging, a static backtrace is unlikely to be much use.  
>> You need
>> to follow the instructions in DEBUG:
>
> I have not been able to do this well, the results are very confusing 
> to me, I sometimes end up in the garbage collection, sometimes in 
> search functions like looking-at-1 or search-buffer.  So for now I 
> don't have better information on this bug, and I don't have much time 
> for going much further on this.
>
> However, on the Lisp level, I have been able to dig deeper and found 
> the following.
>
> This error happens if flyspell is trying to check a word that is 
> followed by a character with the `intangible' text property.  The 
> words in the buffer where Emacs enters an infinite loop look like this
>
>    something]]
>
> where the "]]" carry both the invisible and the intangible text 
> property.  If I remove the intangible text property and only keep 
> invisible, there is no problem and Emacs functions normally. If I 
> remove invisible and keep intangible, the error still happens.
>
>> Also when a C backtrace is useful, it usually helps to include lisp 
>> backtrace.
>> This is output automatically with `bt' if you run Emacs under GDB 
>> from the src
>> directory otherwise you need to source .gdbinit (in the src 
>> directory) first.
>
> A typical lisp backtrace looks like this:
>
> Lisp Backtrace:
> "flyspell-get-word" (0x3800209)
> "flyspell-word-search-backward" (0x1add4e3)
> "flyspell-word" (0x3800209)
> "flyspell-post-command-hook" (0x0)
> "run-hooks" (0x3809c69)
>
> or
>
> Lisp Backtrace:
> "re-search-forward" (0x1b0d1b3)
> "flyspell-get-word" (0x3800209)
> "flyspell-word-search-backward" (0x1add4e3)
> "flyspell-word" (0x3800209)
> "flyspell-post-command-hook" (0x0)
> "run-hooks" (0x3809c69)
>
> This is strange because it looks like there is an infinite loop on the 
> lisp level, but when I use the lisp debugger, it is the call to 
> accept-process-output where Emacs gets stuck.
>
> I guess as a temporary fix I could remove the intangible text 
> property, since invisible text is handled by the point-motion 
> functions much like intangible text, so it is not really necessary to 
> have both.  Is this a correct assessment?
>
> Thanks, and sorry that I cannot be more helpful.
>
> - Carsten
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[martin rudalics]

Does it happen with the following?

(defun flyspell-word-search-backward (word bound)
   (save-excursion
     (let ((r '())
	  p
	  (oldp t))
       (while (and (not r) (setq p (search-backward word bound t)))
	(let ((lw (flyspell-get-word '())))
	  (cond
	   ((and (consp lw) (string-equal (car lw) word))
	    (setq r p))
	   ((equal p oldp)
	    (setq r t))
	   (t
	    (setq oldp p)
	    (goto-char p)))))
       r)))

Re: [bug]org-mode with flyspell-mode freezes emacs

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

 > I just found out that the emacs-wiki and muse people have been
 > struggling with the same problem.  Their fix was to use
 > inhibit-point-motion-hooks.  This points into the direction that a
 > search function gets thrown off into a loop by the point-motion-hooks.

Indeed binding `inhibit-point-motion-hooks' is more decent than my
earlier proposal.  Try the attached patch.

[-- Attachment #2: flyspell.patch --]
[-- Type: text/plain, Size: 677 bytes --]

*** flyspell.el.~1.106.~	Sat Sep 23 11:08:58 2006
--- flyspell.el	Tue Oct 17 19:31:34 2006
***************
*** 959,964 ****
--- 959,965 ----
  (defun flyspell-word-search-backward (word bound)
    (save-excursion
      (let ((r '())
+ 	  (inhibit-point-motion-hooks t)
  	  p)
        (while (and (not r) (setq p (search-backward word bound t)))
  	(let ((lw (flyspell-get-word '())))
***************
*** 973,978 ****
--- 974,980 ----
  (defun flyspell-word-search-forward (word bound)
    (save-excursion
      (let ((r '())
+ 	  (inhibit-point-motion-hooks t)
  	  p)
        (while (and (not r) (setq p (search-forward word bound t)))
  	(let ((lw (flyspell-get-word '())))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [bug]org-mode with flyspell-mode freezes emacs

[Richard Stallman]

    I have not been able to do this well, the results are very confusing to 
    me, I sometimes end up in the garbage collection, sometimes in search 
    functions like looking-at-1 or search-buffer.

This problem is not in GC.  We know that GC is simply being called
over and over.  So if it is in GC when you stop it, just continue and
stop it again.  Only the cases outside GC are interesting.

    A typical lisp backtrace looks like this:

    Lisp Backtrace:
    "flyspell-get-word" (0x3800209)
    "flyspell-word-search-backward" (0x1add4e3)
    "flyspell-word" (0x3800209)
    "flyspell-post-command-hook" (0x0)
    "run-hooks" (0x3809c69)

    or

    Lisp Backtrace:
    "re-search-forward" (0x1b0d1b3)

This proves that the loop is in a loop that calls re-search-forward,
but not re-search-forward.  However, the loop in flyspell-get-word
does not call re-search-forward.

I think that means that the loop is in a higher level frame.

Can you use the Lisp debugger to arrange to stop on returning
to the various frames, and then continue, and thus see which
frames get returned to?

Re: [bug]org-mode with flyspell-mode freezes emacs

[martin rudalics]

 > This proves that the loop is in a loop that calls re-search-forward,
 > but not re-search-forward.  However, the loop in flyspell-get-word
 > does not call re-search-forward.
 >
 > I think that means that the loop is in a higher level frame.

The bug is in the following loop of `flyspell-word-search-backward'

       (while (and (not r) (setq p (search-backward word bound t)))
	(let ((lw (flyspell-get-word '())))
	  (if (and (consp lw) (string-equal (car lw) word))
	      (setq r p)
	    (goto-char p))))

which, IIUC, is run by a `post-command-hook' and thus does not permit
quitting.  On the other hand, the intangibility property doesn't permit
to move to the desired position and thus the loop is never exited.  The
patch I sent earlier should correct this (although, I think, that loop
_is_ asking for troubles).

As an aside: This is the first time I try flyspell and I noticed that
it's unbearably slow.  Shouldn't the checking stuff be run by a timer?

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

I can confirm that Martin's patch does fix the problem.  This patch 
should go into Emacs CVS at least for the time being.

Thanks Martin, thank everyone who helped to debug this problem.

- Carsten


On Oct 17, 2006, at 19:49, martin rudalics wrote:

> > I just found out that the emacs-wiki and muse people have been
> > struggling with the same problem.  Their fix was to use
> > inhibit-point-motion-hooks.  This points into the direction that a
> > search function gets thrown off into a loop by the 
> point-motion-hooks.
>
> Indeed binding `inhibit-point-motion-hooks' is more decent than my
> earlier proposal.  Try the attached patch.
> *** flyspell.el.~1.106.~	Sat Sep 23 11:08:58 2006
> --- flyspell.el	Tue Oct 17 19:31:34 2006
> ***************
> *** 959,964 ****
> --- 959,965 ----
>   (defun flyspell-word-search-backward (word bound)
>     (save-excursion
>       (let ((r '())
> + 	  (inhibit-point-motion-hooks t)
>   	  p)
>         (while (and (not r) (setq p (search-backward word bound t)))
>   	(let ((lw (flyspell-get-word '())))
> ***************
> *** 973,978 ****
> --- 974,980 ----
>   (defun flyspell-word-search-forward (word bound)
>     (save-excursion
>       (let ((r '())
> + 	  (inhibit-point-motion-hooks t)
>   	  p)
>         (while (and (not r) (setq p (search-forward word bound t)))
>   	(let ((lw (flyspell-get-word '())))
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[Stefan Monnier]

> I can confirm that Martin's patch does fix the problem.  This patch should
> go into Emacs CVS at least for the time being.

I guess I agree.  But I think it points out a few other problems:
- the with-local-quit in flyspell.el is probably badly located: maybe it
  should be moved so that it makes it possible to break out of a bad loop
  like the above.
- `intangible' is evil.  Why do you use it in org-mode?


        Stefan

Re: [bug]org-mode with flyspell-mode freezes emacs

[Lennart Borgman]

Stefan Monnier wrote:
> - `intangible' is evil.  Why do you use it in org-mode?
>   

Why is `intangible' evil?

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Stefan Monnier wrote:
>> - `intangible' is evil.  Why do you use it in org-mode?
>>   
>
> Why is `intangible' evil?

Because it violates basic assumptions of a loooot of code.  It is
better to use post-command-hook to move the cursor out of forbidden
areas (and pre-command-hook to figure out from which direction the
forbidden area was entered, so that one can move out the other side):
that way, the effect is restricted to the command loop and does not
cause surprises to normal code.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [bug]org-mode with flyspell-mode freezes emacs

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Stefan Monnier wrote:
>>     
>>> - `intangible' is evil.  Why do you use it in org-mode?
>>>   
>>>       
>> Why is `intangible' evil?
>>     
>
> Because it violates basic assumptions of a loooot of code.  It is
> better to use post-command-hook to move the cursor out of forbidden
> areas (and pre-command-hook to figure out from which direction the
> forbidden area was entered, so that one can move out the other side):
> that way, the effect is restricted to the command loop and does not
> cause surprises to normal code.
>   

Thanks, I see. But is there then a reason why not intangible mimics the 
behaviour that you describe?

Is it even possible to look at this as a bug?

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

On Oct 18, 2006, at 0:03, Stefan Monnier wrote:

>> I can confirm that Martin's patch does fix the problem.  This patch 
>> should
>> go into Emacs CVS at least for the time being.
>
> I guess I agree.  But I think it points out a few other problems:
> - the with-local-quit in flyspell.el is probably badly located: maybe 
> it
>   should be moved so that it makes it possible to break out of a bad 
> loop
>   like the above.
> - `intangible' is evil.  Why do you use it in org-mode?

Good question.  I am using links like

  [[http://www.google.com][Google Search]]

that will be displayed as "Google Search" in a buffer.  The remaining 
characters are hidden, using both invisible and intangible properties.  
I am in the process of realizing that `invisible' will be enough to do 
the job, and that `intangible' is not needed.

The reason why `intangible' is in there is because emacs-wiki does it 
this way, and I learned from looking at this code.  Anyway, I will 
probably remove `intangible' from org-mode anyway, just need to 
convince myself that is is safe to do so.

Thanks

- Carsten



--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>   
>>> Stefan Monnier wrote:
>>>     
>>>> - `intangible' is evil.  Why do you use it in org-mode?
>>>>         
>>> Why is `intangible' evil?
>>
>> Because it violates basic assumptions of a loooot of code.  It is
>> better to use post-command-hook to move the cursor out of forbidden
>> areas (and pre-command-hook to figure out from which direction the
>> forbidden area was entered, so that one can move out the other
>> side): that way, the effect is restricted to the command loop and
>> does not cause surprises to normal code.
>>   
>
> Thanks, I see. But is there then a reason why not intangible mimics
> the behaviour that you describe?

Botched-up design.

> Is it even possible to look at this as a bug?

More like a misfeature.  intangible behaves as documented.  It is just
that the documented behavior can cause a lot of ugly surprises except
in very tightly controlled circumstances, since normal movement
commands skid on intangible areas like on banana peels.  What will
some convenience function like "mark-word" do in the presence of
intangible?  There is really no way to find out from reading its DOC
string.  You have to read every code line to figure out where it
merely calculates cursor distances, and where it tries moving there.

And when the circumstances are very tightly controlled so that
intangible is not encountered by any function not expecting it, you
don't actually need intangible.

In my opinion, it might be a good idea to introduce another property
(like `unpleasant') which is merely not used as a final resting place
in the command loop, at the same time deprecating `intangible', and
removing it at some later time.

I don't think there is much _reliably_ working code using it around,
anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: [bug]org-mode with flyspell-mode freezes emacs

[Drew Adams]

    In my opinion, it might be a good idea to introduce another property
    (like `unpleasant')...

I like the name, anyway. Very nice...er...unnice.

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Oct 18, 2006, at 0:03, Stefan Monnier wrote:
>
>>> I can confirm that Martin's patch does fix the problem.  This patch
>>> should
>>> go into Emacs CVS at least for the time being.
>>
>> I guess I agree.  But I think it points out a few other problems:
>> - the with-local-quit in flyspell.el is probably badly located:
>> maybe it
>>   should be moved so that it makes it possible to break out of a bad
>> loop
>>   like the above.
>> - `intangible' is evil.  Why do you use it in org-mode?
>
> Good question.  I am using links like
>
>  [[http://www.google.com][Google Search]]
>
> that will be displayed as "Google Search" in a buffer.  The remaining
> characters are hidden, using both invisible and intangible properties.
> I am in the process of realizing that `invisible' will be enough to do
> the job, and that `intangible' is not needed.
>
> The reason why `intangible' is in there is because emacs-wiki does it
> this way, and I learned from looking at this code.  Anyway, I will
> probably remove `intangible' from org-mode anyway, just need to
> convince myself that is is safe to do so.

Why do you need anything in the buffer at all?  What is the actual
purpose of it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [bug]org-mode with flyspell-mode freezes emacs

[Stefan Monnier]

> that will be displayed as "Google Search" in a buffer.  The remaining
> characters are hidden, using both invisible and intangible properties.  I am
> in the process of realizing that `invisible' will be enough to do the job,
> and that `intangible' is not needed.

> The reason why `intangible' is in there is because emacs-wiki does it this
> way, and I learned from looking at this code.  Anyway, I will probably
> remove `intangible' from org-mode anyway, just need to convince myself that
> is is safe to do so.

The code that moves point outside of invisible text is new in Emacs-22.
Before that, you either had to do it yourself by hand with
a post-command-hook or use `intangible'.


        Stefan

Re: [bug]org-mode with flyspell-mode freezes emacs

[Chong Yidong]

Carsten Dominik <dominik@science.uva.nl> writes:

> I can confirm that Martin's patch does fix the problem.  This patch
> should go into Emacs CVS at least for the time being.

Committed.  Thanks Martin.

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

On Oct 18, 2006, at 0:49, David Kastrup wrote:
>> Good question.  I am using links like
>>
>>  [[http://www.google.com][Google Search]]
>>
>> that will be displayed as "Google Search" in a buffer.  The remaining
>> characters are hidden, using both invisible and intangible properties.
>> I am in the process of realizing that `invisible' will be enough to do
>> the job, and that `intangible' is not needed.
>>
>> The reason why `intangible' is in there is because emacs-wiki does it
>> this way, and I learned from looking at this code.  Anyway, I will
>> probably remove `intangible' from org-mode anyway, just need to
>> convince myself that is is safe to do so.
>
> Why do you need anything in the buffer at all?  What is the actual
> purpose of it?

It is a clickable link, very much like

  <a href="www.google.com">Google Search</a>

- Carsten

Re: [bug]org-mode with flyspell-mode freezes emacs

[Carsten Dominik]

That is important information, thank you.

- Carsten

On Oct 18, 2006, at 2:28, Stefan Monnier wrote:

>> that will be displayed as "Google Search" in a buffer.  The remaining
>> characters are hidden, using both invisible and intangible 
>> properties.  I am
>> in the process of realizing that `invisible' will be enough to do the 
>> job,
>> and that `intangible' is not needed.
>
>> The reason why `intangible' is in there is because emacs-wiki does it 
>> this
>> way, and I learned from looking at this code.  Anyway, I will probably
>> remove `intangible' from org-mode anyway, just need to convince 
>> myself that
>> is is safe to do so.
>
> The code that moves point outside of invisible text is new in Emacs-22.
> Before that, you either had to do it yourself by hand with
> a post-command-hook or use `intangible'.
>
>
>         Stefan
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Oct 18, 2006, at 0:49, David Kastrup wrote:
>>> Good question.  I am using links like
>>>
>>>  [[http://www.google.com][Google Search]]
>>>
>>> that will be displayed as "Google Search" in a buffer.  The remaining
>>> characters are hidden, using both invisible and intangible properties.
>>> I am in the process of realizing that `invisible' will be enough to do
>>> the job, and that `intangible' is not needed.
>>>
>>> The reason why `intangible' is in there is because emacs-wiki does it
>>> this way, and I learned from looking at this code.  Anyway, I will
>>> probably remove `intangible' from org-mode anyway, just need to
>>> convince myself that is is safe to do so.
>>
>> Why do you need anything in the buffer at all?  What is the actual
>> purpose of it?
>
> It is a clickable link, very much like
>
>  <a href="www.google.com">Google Search</a>

The question is why the information of the link has to be in the
buffer text.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [bug]org-mode with flyspell-mode freezes emacs

[Richard Stallman]

    As an aside: This is the first time I try flyspell and I noticed that
    it's unbearably slow.  Shouldn't the checking stuff be run by a timer?

I don't know, but would you like to give it a try?

Re: [bug]org-mode with flyspell-mode freezes emacs

[Michael Olson]

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

David Kastrup <dak@gnu.org> writes:

> The question is why the information of the link has to be in the
> buffer text.

The purpose of this program is for the user to keep track of various
kinds of data in a way that can be viewed and exported conveniently,
similar (to some extent) to a wiki engine and personal organizer.

For links, which are colorized for the sake of visual appeal, the user
provides both the link and (optionally) the link description using the
markup syntax that Carsten described.  So of course it has to be in
the buffer text -- how else could changes be meaningfully saved?

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Michael Olson <mwolson@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The question is why the information of the link has to be in the
>> buffer text.
>
> The purpose of this program is for the user to keep track of various
> kinds of data in a way that can be viewed and exported conveniently,
> similar (to some extent) to a wiki engine and personal organizer.
>
> For links, which are colorized for the sake of visual appeal, the
> user provides both the link and (optionally) the link description
> using the markup syntax that Carsten described.  So of course it has
> to be in the buffer text -- how else could changes be meaningfully
> saved?

By putting them into text properties and converting those using
format.el.  I think that is what enriched text mode does.

It's not exactly like this has not been already discussed in this
thread.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [bug]org-mode with flyspell-mode freezes emacs

[Michael Olson]

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

David Kastrup <dak@gnu.org> writes:

> Michael Olson <mwolson@gnu.org> writes:
>
>> For links, which are colorized for the sake of visual appeal, the
>> user provides both the link and (optionally) the link description
>> using the markup syntax that Carsten described.  So of course it
>> has to be in the buffer text -- how else could changes be
>> meaningfully saved?
>
> By putting them into text properties and converting those using
> format.el.  I think that is what enriched text mode does.

Thank you for pointing this out.

[Now speaking from the perspective of Emacs Muse, which I maintain,
and which uses the same syntax for links.]

format.el does not seem to be able to handle what needs to be done,
however.  For one thing, it can only do translations that involve one
property at a time.  Muse needs to be able to add the muse-link to the
entire link, a face to the description, and invisible to the link
destination.  Just using the display property isn't enough, because
(1) there is a helpful feature of jumping to the next link by hitting
TAB, which is fastest when using the muse-link property and (2) it
apparently inhibits the user from editing the link description in
place, which is a useful feature.

> It's not exactly like this has not been already discussed in this
> thread.

I don't see any mention of format.el on this thread, apart from the
message this one responds to.

If you are going to question the way something is done, please mention
an alternative at the same time, otherwise it is hard to take you
seriously.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [bug]org-mode with flyspell-mode freezes emacs

[Stefan Monnier]

> By putting them into text properties and converting those using
> format.el.  I think that is what enriched text mode does.

Invisible text in a buffer has its drawbacks, but so does format.el.


        Stefan

Re: [bug]org-mode with flyspell-mode freezes emacs

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> By putting them into text properties and converting those using
>> format.el.  I think that is what enriched text mode does.
>
> Invisible text in a buffer has its drawbacks, but so does format.el.

Certainly.  One wants to choose the way that best corresponds to the
users wishes, needs and expectations.

I don't think I ever suggested anything different.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [bug]org-mode with flyspell-mode freezes emacs

[Richard Stallman]

    format.el does not seem to be able to handle what needs to be done,
    however.  For one thing, it can only do translations that involve one
    property at a time.  Muse needs to be able to add the muse-link to the
    entire link, a face to the description, and invisible to the link
    destination.

format.el was meant for doing things like enriched.el, but it has not
been used very much.  It could well be that some redesign would make
it a lot more useful.  If you want to work, non-urgently, on that kind
of improvement in format.el, I'd appreciate it.

Re: [bug]org-mode with flyspell-mode freezes emacs

[Michael Olson]

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

Richard Stallman <rms@gnu.org> writes:

> format.el was meant for doing things like enriched.el, but it has not
> been used very much.  It could well be that some redesign would make
> it a lot more useful.  If you want to work, non-urgently, on that kind
> of improvement in format.el, I'd appreciate it.

I'll try to take a look at it sometime after I release the next
version of Muse.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel