Small patch for rng-valid.el

Small patch for rng-valid.el

[Lennart Borgman]

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

I just realized that I have a small patch for rng-valid.el that is
needed for it to work with nXhtml/MuMaMo. I would be glad if we could
apply it now and I do not believe it can break anything. I have
attached the patch.

Several people have had problems with this, see

   https://bugs.launchpad.net/nxhtml/+bug/354363

[-- Attachment #2: rng-valid.el.diff --]
[-- Type: application/octet-stream, Size: 7196 bytes --]

Index: rng-valid.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/nxml/rng-valid.el,v
retrieving revision 1.6
diff -c -b -r1.6 rng-valid.el
*** rng-valid.el	6 May 2008 04:25:58 -0000	1.6
--- rng-valid.el	27 May 2008 23:23:24 -0000
***************
*** 520,527 ****
  			    (t (rng-set-initial-state))))))))))
  
  
  (defun rng-do-some-validation-1 (&optional continue-p-function)
!   (let ((limit (+ rng-validate-up-to-date-end
  		  rng-validate-chunk-size))
  	(remove-start rng-validate-up-to-date-end)
  	(next-cache-point (+ (point) rng-state-cache-distance))
--- 520,558 ----
  			    (t (rng-set-initial-state))))))))))
  
  
+ (defvar rng-get-major-mode-chunk-function nil
+   "Function to use to get major mode chunk.
+ It should take one argument, the point where to get the major mode chunk.
+ 
+ This is to be set by multiple major mode frame works, like
+ mumamo.
+ 
+ See also `rng-valid-nxml-major-mode-chunk-function' and
+ `rng-end-major-mode-chunk-function'. Note that all three
+ variables must be set.")
+ (make-variable-buffer-local 'rng-get-major-mode-chunk-function)
+ (put 'rng-get-major-mode-chunk-function 'permanent-local t)
+ 
+ (defvar rng-valid-nxml-major-mode-chunk-function nil
+   "Function to use to check if nxml can parse major mode chunk.
+ It should take one argument, the chunk.
+ 
+ For more info see also `rng-get-major-mode-chunk-function'.")
+ (make-variable-buffer-local 'rng-valid-nxml-major-mode-chunk-function)
+ (put 'rng-valid-nxml-major-mode-chunk-function 'permanent-local t)
+ 
+ (defvar rng-end-major-mode-chunk-function nil
+   "Function to use to get the end of a major mode chunk.
+ It should take one argument, the chunk.
+ 
+ For more info see also `rng-get-major-mode-chunk-function'.")
+ (make-variable-buffer-local 'rng-end-major-mode-chunk-function)
+ (put 'rng-end-major-mode-chunk-function 'permanent-local t)
+ 
  (defun rng-do-some-validation-1 (&optional continue-p-function)
!   (let (major-mode-chunk
!         end-major-mode-chunk
!         (limit (+ rng-validate-up-to-date-end
  		  rng-validate-chunk-size))
  	(remove-start rng-validate-up-to-date-end)
  	(next-cache-point (+ (point) rng-state-cache-distance))
***************
*** 536,543 ****
  	xmltok-attributes
  	xmltok-namespace-attributes
  	xmltok-dependent-regions
! 	xmltok-errors)
!     (when (= (point) 1)
        (let ((regions (xmltok-forward-prolog)))
  	(rng-clear-overlays 1 (point))
  	(while regions
--- 567,576 ----
  	xmltok-attributes
  	xmltok-namespace-attributes
  	xmltok-dependent-regions
! 	xmltok-errors
!         )
!     ;;(message ">>>>>>>>> here -1, p=%s" (point)) ;;(sit-for 4)
!     (when (and continue (= (point) 1))
        (let ((regions (xmltok-forward-prolog)))
  	(rng-clear-overlays 1 (point))
  	(while regions
***************
*** 549,558 ****
  	(rng-clear-conditional-region))
        (setq rng-dtd xmltok-dtd))
      (while continue
!       (setq have-remaining-chars (rng-forward))
        (let ((pos (point)))
  	(setq continue
  	      (and have-remaining-chars
  		   (or (< pos limit)
  		       (and continue-p-function
  			    (funcall continue-p-function)
--- 582,631 ----
  	(rng-clear-conditional-region))
        (setq rng-dtd xmltok-dtd))
      (while continue
!       ;; If mumamo (or something similar) is used then jump over parts
!       ;; that can not be parsed by nxml-mode.
!       (when (and rng-get-major-mode-chunk-function
!                  rng-valid-nxml-major-mode-chunk-function
!                  rng-end-major-mode-chunk-function)
!         (let ((here (point))
!               next-non-space-pos)
!           (skip-chars-forward " \t\r\n")
!           (setq next-non-space-pos (point))
!           (goto-char here)
!           ;;(message "here when, p=%s emmc=%s non-space=%s" (point) end-major-mode-chunk next-non-space-pos) ;;(sit-for 4)
!           (unless (and end-major-mode-chunk
!                        ;; Remaining chars in this chunk?
!                        (< next-non-space-pos end-major-mode-chunk))
!             (setq end-major-mode-chunk nil)
!             (setq major-mode-chunk (funcall rng-get-major-mode-chunk-function next-non-space-pos))
!             (while (and major-mode-chunk
!                         (not (funcall rng-valid-nxml-major-mode-chunk-function major-mode-chunk))
!                         (< next-non-space-pos (point-max)))
!               (let ((end-pos (funcall rng-end-major-mode-chunk-function major-mode-chunk)))
!                 (goto-char (+ end-pos 0))
!                 (setq major-mode-chunk (funcall rng-get-major-mode-chunk-function (point)))
!                 ;;(message "---> here 3, point=%s, ep=%s, mm-chunk=%s" (point) end-pos major-mode-chunk)
!                 )
!               (setq next-non-space-pos (point))))
!           ;; Stop parsing if we do not have a chunk here yet.
!           (setq continue (and major-mode-chunk
!                               (funcall rng-valid-nxml-major-mode-chunk-function major-mode-chunk)))
!           (when continue
!             ;;(message "  continue=t")
!             (setq end-major-mode-chunk (funcall rng-end-major-mode-chunk-function major-mode-chunk)))))
! 
!       (when continue
!         ;;(message "*** here remain, p=%s" (point))
!         (setq have-remaining-chars (rng-forward end-major-mode-chunk))
!         ;;(message "*** here remain b, p=%s" (point))
          (let ((pos (point)))
+           (when end-major-mode-chunk
+             ;; Fix-me: Seems like we need a new initialization (or why
+             ;; do we otherwise hang without this?)
+             (and (> limit end-major-mode-chunk) (setq limit end-major-mode-chunk)))
            (setq continue
                  (and have-remaining-chars
+                      continue
                       (or (< pos limit)
                           (and continue-p-function
                                (funcall continue-p-function)
***************
*** 582,587 ****
--- 655,661 ----
                   (setq next-cache-point (+ pos rng-state-cache-distance))
                   (rng-clear-cached-state remove-start pos)
                   (when have-remaining-chars
+                    ;;(message "rng-cach-state (1- %s)" pos)
                     (rng-cache-state (1- pos)))
                   (setq remove-start pos)
                   (unless continue
***************
*** 603,609 ****
  			  (rng-clear-conditional-region))
  			 ((< rng-conditional-up-to-date-start pos)
  			  (set-marker rng-conditional-up-to-date-start
! 				      pos)))))))))
      have-remaining-chars))
      
  (defun rng-clear-conditional-region ()
--- 677,683 ----
                              (rng-clear-conditional-region))
                             ((< rng-conditional-up-to-date-start pos)
                              (set-marker rng-conditional-up-to-date-start
!                                         pos))))))))))
      have-remaining-chars))
  
  (defun rng-clear-conditional-region ()

Re: Small patch for rng-valid.el

[Stefan Monnier]

> I just realized that I have a small patch for rng-valid.el that is
> needed for it to work with nXhtml/MuMaMo.  I would be glad if we could
> apply it now and I do not believe it can break anything.  I have
> attached the patch.

Thank you, but it'll have to wait for 23.2.


        Stefan

Re: Small patch for rng-valid.el

[Lennart Borgman]

On Sat, May 2, 2009 at 3:37 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I just realized that I have a small patch for rng-valid.el that is
>> needed for it to work with nXhtml/MuMaMo.  I would be glad if we could
>> apply it now and I do not believe it can break anything.  I have
>> attached the patch.
>
> Thank you, but it'll have to wait for 23.2.

It is a bit unfortunate. It will mean that nXhtml only works well on
w32 with my patched version of Emacs ...

Re: Small patch for rng-valid.el

[Davi Leal]

Lennart Borgman wrote:
> > Thank you, but it'll have to wait for 23.2.
>
> It is a bit unfortunate. It will mean that nXhtml only works well on
> w32 with my patched version of Emacs ...

I use nXhtml and emacs 23 from CVS.


Is this patch needed and 100% verified?   If so, it would be cool if this 
patch were added?

Anyway, I understand the patch arrive maybe too much late.

Re: Small patch for rng-valid.el

[Lennart Borgman]

On Sat, May 2, 2009 at 1:46 PM, Davi Leal <davi@gnu.org> wrote:
> Lennart Borgman wrote:
>> > Thank you, but it'll have to wait for 23.2.
>>
>> It is a bit unfortunate. It will mean that nXhtml only works well on
>> w32 with my patched version of Emacs ...
>
> I use nXhtml and emacs 23 from CVS.
>
>
> Is this patch needed and 100% verified?

Yes.

> Anyway, I understand the patch arrive maybe too much late.

My bad, but this patch is safe.

Re: Small patch for rng-valid.el

[Lennart Borgman]

Ehum, my bad. I forgot that I had some other patches applied to
rng-valid.el too...

What I thought I sent was just a patch to surround the body of
rng-after-change-function with

  (when rng-valid-up-to-date-end
    ...
    )


On Sat, May 2, 2009 at 1:14 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> I just realized that I have a small patch for rng-valid.el that is
> needed for it to work with nXhtml/MuMaMo. I would be glad if we could
> apply it now and I do not believe it can break anything. I have
> attached the patch.
>
> Several people have had problems with this, see
>
>   https://bugs.launchpad.net/nxhtml/+bug/354363
>

Re: Small patch for rng-valid.el

[Lennart Borgman]

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

It seems like I just sent the wrong patch for rng-valid.el on 2 May.
Here is the patch I thought I sent. It contains only some error
checking and is very simple (the errors actually happens sometimes). I
would be glad if it could be installed now.


On Sun, May 10, 2009 at 4:02 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> Ehum, my bad. I forgot that I had some other patches applied to
> rng-valid.el too...
>
> What I thought I sent was just a patch to surround the body of
> rng-after-change-function with
>
>  (when rng-valid-up-to-date-end
>    ...
>    )
>
>
> On Sat, May 2, 2009 at 1:14 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> I just realized that I have a small patch for rng-valid.el that is
>> needed for it to work with nXhtml/MuMaMo. I would be glad if we could
>> apply it now and I do not believe it can break anything. I have
>> attached the patch.
>>
>> Several people have had problems with this, see
>>
>>   https://bugs.launchpad.net/nxhtml/+bug/354363
>>
>

[-- Attachment #2: rng-valid.el.diff --]
[-- Type: application/octet-stream, Size: 1745 bytes --]

Index: rng-valid.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/nxml/rng-valid.el,v
retrieving revision 1.9
diff -u -b -r1.9 rng-valid.el
--- rng-valid.el	5 Jan 2009 03:22:55 -0000	1.9
+++ rng-valid.el	1 May 2009 23:08:18 -0000
@@ -304,6 +304,7 @@
   (or rng-validate-mode (rng-validate-mode)))
 
 (defun rng-after-change-function (start end pre-change-len)
+  (when rng-validate-up-to-date-end
   ;; Work around bug in insert-file-contents.
   (when (> end (1+ (buffer-size)))
     (setq start 1)
@@ -343,7 +344,7 @@
   ;; Arrange to revalidate
   (rng-activate-timers)
   ;; Need to do this after activating the timer
-  (force-mode-line-update))
+    (force-mode-line-update)))
 
 (defun rng-compute-mode-line-string ()
   (cond (rng-validate-timer
@@ -443,6 +444,8 @@
 ;; validation process down.
 
 (defun rng-validate-while-idle (buffer)
+  (if (not (buffer-live-p buffer))
+      (rng-kill-timers)
   (with-current-buffer buffer
     (if rng-validate-mode
 	(if (let ((rng-validate-display-point (point))
@@ -451,16 +454,18 @@
 	    (force-mode-line-update)
 	  (rng-validate-done))
       ;; must have done kill-all-local-variables
-      (rng-kill-timers))))
+        (rng-kill-timers)))))
 
 (defun rng-validate-quick-while-idle (buffer)
+  (if (not (buffer-live-p buffer))
+      (rng-kill-timers)
   (with-current-buffer buffer
     (if rng-validate-mode
 	(if (rng-do-some-validation)
 	    (force-mode-line-update)
 	  (rng-validate-done))
       ;; must have done kill-all-local-variables
-      (rng-kill-timers))))
+        (rng-kill-timers)))))
 
 (defun rng-validate-done ()
   (when (or (not (current-message))

Re: Small patch for rng-valid.el

[Jason Rumney]

Lennart Borgman wrote:
> It seems like I just sent the wrong patch for rng-valid.el on 2 May.
> Here is the patch I thought I sent. It contains only some error
> checking and is very simple (the errors actually happens sometimes).

Under what circumstances does the error happen? There is no bug report 
as far as I can see that mentions this problem, and a quick look at the 
code suggests that if rng-validate-up-to-date-end were ever to become 
nil, there would be errors happening throughout the code, so fixing this 
one place would not be sufficient.

Re: Small patch for rng-valid.el

[Lennart Borgman]

On Wed, May 13, 2009 at 4:34 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> It seems like I just sent the wrong patch for rng-valid.el on 2 May.
>> Here is the patch I thought I sent. It contains only some error
>> checking and is very simple (the errors actually happens sometimes).
>
> Under what circumstances does the error happen? There is no bug report as
> far as I can see that mentions this problem, and a quick look at the code
> suggests that if rng-validate-up-to-date-end were ever to become nil, there
> would be errors happening throughout the code, so fixing this one place
> would not be sufficient.

There were two different situations that I tried to catch in this
patch. One was were the buffer is gone when a timer is about to run. I
guess there is no problem with that part of the patch.

The other situation is when rng-validate-upto-date-end is nil. And
yes, that is more problematic. I have seen it happen in
rng-after-change-function, but nowhere else. I believe it only has
happened to me when nxml-mode (or rather nxhtml-mode) is used together
with mumamo.el (but I am not sure of that). This might of course
depend on the way I handle this in mumamo. It takes me some time to
investigate this and I would prefer not to do it now since the
handling of parsing functions within a multi mode framework like
mumamo probably require some more general thoughts. (I believe that it
can has something to do with that I do not restart the parser
correctly when creating new chunks. The rng-after-change-function
seems to be set up to early, but fixing this can perhaps be
complicated.)

However the check for a non-nil rng-validate-up-to-date-end in
rng-after-change-function is very cheap so I see no good reason not to
add it there now. I have not looked at the other places where this
variable is used though.

Re: Small patch for rng-valid.el

[Jason Rumney]

Lennart Borgman wrote:
> However the check for a non-nil rng-validate-up-to-date-end in
> rng-after-change-function is very cheap so I see no good reason not to
> add it there now.
>   

The good reason is that Emacs is in a state of "regression bugfixes 
only" code freeze.  Checking in a change to workaround a bug in third 
party code that the developer would prefer not to bother fixing right 
now is not an option at this stage.

Re: Small patch for rng-valid.el

[Lennart Borgman]

On Thu, May 14, 2009 at 12:53 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> However the check for a non-nil rng-validate-up-to-date-end in
>> rng-after-change-function is very cheap so I see no good reason not to
>> add it there now.
>>
>
> The good reason is that Emacs is in a state of "regression bugfixes only"
> code freeze.  Checking in a change to workaround a bug in third party code
> that the developer would prefer not to bother fixing right now is not an
> option at this stage.

Was not nXml added after the Emacs 22 release?

As I said two of the fixes are just bug fixes. The third might not be
a bug fix for Emacs, but I am not sure. Are you?