all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: font-locking and open parens in column 0
@ 2006-11-03 16:19 Mackenzie, Alan
  2006-11-03 19:29 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Mackenzie, Alan @ 2006-11-03 16:19 UTC (permalink / raw)
  Cc: Alan Mackenzie, Richard Stallman, emacs-devel

Hi, Martin! 

>-----Ursprüngliche Nachricht-----
>Von: martin rudalics [mailto:rudalics@gmx.at] 
>Gesendet: Freitag, 3. November 2006 15:03
>An: Mackenzie, Alan
>Cc: Richard Stallman; emacs-devel@gnu.org; Alan Mackenzie
>Betreff: Re: AW: font-locking and open parens in column 0
>
>Good afternoon, Alan
>

[ .... ]

> > Are you saying that
> > open-paren-in-column-0-is-defun-start shouldn't exist at all?  When
> > it is nil, a paren in column 0 may not, of itself, be regarded as a
> > defun start.

>I fail to understand the present state of things.  On the one hand,
>`open-paren-in-column-0-is-defun-start' is customizable which means a
>user should be able to set it and a major mode should respect that.  On
>the other hand, c-mode deliberately sets this to nil.  I think users
>should be free to express their choice here if they consider their
>machine inapt for scanning from bob.

As far as I can see, the purpose of open-p-i-c-0-i-d-start wasn't
clearly recorded in the ChangeLog.  The value t is clear; I can't think
of any meaning for nil other than the one I've given it.  Certainly,
Martin Stjernholm assumed that meaning (goto a brace at top level) when
he coded up c-beginning-of-defun.  If this meaning is not given to it,
there doesn't seem to be any point in having the variable.

I think it was made customizable so that a user could set it for
"efficiency" (when his perl files' functions all have { at column 0) or
"rigour" (when he uses "k&r" placement of braces in his files.pl).  It
doesn't seem to have worked very well, so far.

CC Mode always sets o-p-i-c-0-i-d-start to nil, and caches the brace
structure to prevent excessive scanning from BOB.  After all, opic0id
being nil will always find BO-defun.  Setting it to t was an optimisation
for when computers were much less powerful than they are now - and this
causes quite a bit of inconvenience.

> > I would say, rather, that font-locking should not use b-o-defun-raw
> > when o-p-i-c-0-i-d-s is nil, except in exceptional circumstances.

>Font-lock uses `syntax-ppss' which may call `syntax-begin-function'
>which may be defined as `beginning-of-defun' which usually calls
>`beginning-of-defun-raw'.  When I open a C file and jump to a position
>before stealth fontification gets there, that's the way things behave.

OK

> > The case
> > you spotted in syntax.c (and I've really no idea how you did ;-), is
> > such an exceptional case.

>I spotted that incidentally when scrolling backwards through syntax.c.
>Anyway, it *is* exceptional and thus should not warrant any major
>change.  Richard's patch just comes in handy.

I confess I'm not familiar with this.  I've been without net access for
several weeks.  I'm currently at the mercy of Deutsche Telekom, who have
promised to get my new DSL connection working real soon now.  :-(

> > CC Mode caches parenthesis structures.

>... which parallels the work of `syntax-ppss', hence we currently end up
>with two caches for the same structures - I know c-mode has to work hard
>to handle all sorts of older (X)Emacsen ...

Not only that, CC Mode uses its cache for things other than font-locking.

> > My patch did fix the bug (a whole screenful of misfontified string in
> > syntax.c), though, didn't it?

>It does fix it, and it's even pretty fast ;-).  But I still think the
>"bug" is with the author who put the left paren in column zero of that
>comment.  That author should be warned just as in emacs-lisp-mode.

Should _HAVE_ been warned.  Martin Stjernholm has worked very hard to
remove that restriction from C Mode without sacrificing (much) speed.  It
would be a shame now to leave the restriction in Emacs 22.

[ .... ]

-- 
Alan.



*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

^ permalink raw reply	[flat|nested] 8+ messages in thread
* AW: font-locking and open parens in column 0
@ 2006-11-03  8:44 Mackenzie, Alan
  2006-11-03 14:14 ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Mackenzie, Alan @ 2006-11-03  8:44 UTC (permalink / raw)
  Cc: Richard Stallman, emacs-devel

Hi, Martin! 

>-----Ursprüngliche Nachricht-----
>Von: martin rudalics [mailto:rudalics@gmx.at] 
>Gesendet: Donnerstag, 2. November 2006 19:32
>An: Mackenzie, Alan
>Cc: emacs-devel@gnu.org; Richard Stallman; Alan Mackenzie
>Betreff: Re: font-locking and open parens in column 0

>Good evening, Alan

> > The cause of this (as Martin (almost) discerned) is that the handling of
> > (eq open-paren-in-column-0-is-defun-start nil) in begining-of-defun-raw
> > hasn't been implemented.  The function just looks for a "(" in C0
> > regardless of that variable.
> >
> > "Clearly", when that variable is nil, a defun can begin at no place other
> > than a paren at the outermost level.  Therefore, the function must scan
> > the entire source file from BOB, as in the earliest days.

>No!  That would be a serious regression.  Font-locking should never be
>forced to scan from BOB.

         1         2         3         4         5         6         7  3
I agree with you.  :-)  However, my patch is to do with
beginning-of-defun-raw, not font-locking.  Are you saying that
open-paren-in-column-0-is-defun-start shouldn't exist at all?  When it is
nil, a paren in column 0 may not, of itself, be regarded as a defun
start.

Richard, please say what you think about this.

I would say, rather, that font-locking should not use b-o-defun-raw when
o-p-i-c-0-i-d-s is nil, except in exceptional circumstances.  The case
you spotted in syntax.c (and I've really no idea how you did ;-), is
such an exceptional case.  CC Mode caches parenthesis structures.

My patch did fix the bug (a whole screenful of misfontified string in
syntax.c), though, didn't it?

>Observe that this would only serve to handle
>the rare case where a user puts a paren in column zero of a C comment.
>I think warning about such parens as in emacs-lisp-mode is sufficient.
>Please try to make use of Richard's `font-lock-syntax-paren-check' from
>this thread as with

>     (put font-lock-beginning-of-syntax-function
>	 'font-lock-syntax-paren-check t)

>Moreover, any such code as yours should ....

You're talking about my patch to beginning-of-defun-raw, here, not the
stuff in CC Mode.  I don't have the source files to hand at the moment.

>(1) Consult `syntax-ppss' first.
>
>(2) Try to use the 9th field of the return value of 
>`parse-partial-sexp'
>to find the outermost paren instead of up-/forward-/backward-listing.
>
>(3) Crowd the cache of `syntax-ppss' in order to avoid further scans.

OK, thanks!  I'll need to learn about these optimisations.
begining-of-defun-raw, when used in font locking, could be distressingly
slow without them.

-- 
Alan Mackenzie (Ittersbach, Germany)



*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: font-locking and open parens in column 0
@ 2006-11-02  8:49 Mackenzie, Alan
  2006-11-02 18:31 ` martin rudalics
  0 siblings, 1 reply; 8+ messages in thread
From: Mackenzie, Alan @ 2006-11-02  8:49 UTC (permalink / raw)
  Cc: Martin Rudalics, Richard Stallman

Hi, Emacs!

[Apologies for not being able to reply with proper headers, since I'm
still without a network connection at home.  Please send any CCs to
acm@muc.de as well as my work address.]

Martin Rudalics wrote on Monday 11th September 2006, 15:05:55 +0200:

> (1) With emacs -Q open ~/src/syntax.c

> (2) Execute

>(defun foo ()
>  (interactive)
>  (re-search-forward "string-to-syntax")
>  (forward-line 6)
>  (recenter 0))

>This will fontify the entire body of `string_to_syntax' as a C string
>due to the left paren in column zero of the doc-string.

The cause of this (as Martin (almost) discerned) is that the handling of
(eq open-paren-in-column-0-is-defun-start nil) in begining-of-defun-raw
hasn't been implemented.  The function just looks for a "(" in C0
regardless of that variable.

"Clearly", when that variable is nil, a defun can begin at no place
other
than a paren at the outermost level.  Therefore, the function must scan
the entire source file from BOB, as in the earliest days.

The patch below implements this.  When applied (don't forget to rebuild
Emacs or M-x load-file lisp.elc, since lisp.elc is a preloaded file),
Emacs fontifies string-to-syntax properly after jumping there with M-x
foo.


2006-11-01  Alan Mackenzie  <acm@muc.de>

	* emacs-lisp/lisp.el (beginning-of-defun-raw): Code up the case
	(eq open-paren-in-column-0-is-defun-start nil) by searching for
	least nested open-paren.


*** lisp-1.74.el	2006-02-19 12:51:43.000000000 +0000
--- lisp.el	2006-11-01 22:03:56.313088952 +0000
***************
*** 208,229 ****
  
  If variable `beginning-of-defun-function' is non-nil, its value
  is called as a function to find the defun's beginning."
!   (interactive "p")
!   (if beginning-of-defun-function
!       (if (> (setq arg (or arg 1)) 0)
! 	  (dotimes (i arg)
! 	    (funcall beginning-of-defun-function))
! 	;; Better not call end-of-defun-function directly, in case
! 	;; it's not defined.
! 	(end-of-defun (- arg)))
!     (and arg (< arg 0) (not (eobp)) (forward-char 1))
      (and (re-search-backward (if defun-prompt-regexp
  				 (concat (if
open-paren-in-column-0-is-defun-start
  					     "^\\s(\\|" "")
  					 "\\(?:" defun-prompt-regexp
"\\)\\s(")
  			       "^\\s(")
! 			     nil 'move (or arg 1))
! 	 (progn (goto-char (1- (match-end 0)))) t)))
  
  (defvar end-of-defun-function nil
    "If non-nil, function for function `end-of-defun' to call.
--- 208,270 ----
  
  If variable `beginning-of-defun-function' is non-nil, its value
  is called as a function to find the defun's beginning."
!   (interactive "p") ; change this to "P", maybe, if we ever come to
pass ARG
! 		    ; to beginning-of-defun-function.
!   (unless arg (setq arg 1))		; The call might not be
interactive.
!   (cond
!    (beginning-of-defun-function
!     (if (> arg 0)
! 	(dotimes (i arg)
! 	  (funcall beginning-of-defun-function))
!       ;; Better not call end-of-defun-function directly, in case
!       ;; it's not defined.
!       (end-of-defun (- arg))))
! 
!    ((or defun-prompt-regexp open-paren-in-column-0-is-defun-start)
!     (and (< arg 0) (not (eobp)) (forward-char 1))
      (and (re-search-backward (if defun-prompt-regexp
  				 (concat (if
open-paren-in-column-0-is-defun-start
  					     "^\\s(\\|" "")
  					 "\\(?:" defun-prompt-regexp
"\\)\\s(")
  			       "^\\s(")
! 			     nil 'move arg)
! 	 (progn (goto-char (1- (match-end 0)))) t))
! 
!    (t
!     ;; Column 0 has no significance - so scan forward from BOB to see
how
!     ;; nested point is, then carry on from there.
!     (let ((floor (point-min))
! 	  (ceiling (point-max))
! 	  pps-state nesting-depth)
!       (save-restriction
! 	(widen)
! 	(setq pps-state (parse-partial-sexp (point-min) (point))
! 	      nesting-depth (nth 0 pps-state))
! 	;; Get outside of any string or comment.
! 	(if (nth 8 pps-state)
! 	    (goto-char (nth 8 pps-state)))
! 
! 	(cond
! 	 ((> arg 0)
! 	  (when (> nesting-depth 0)
! 	    (up-list (- nesting-depth))
! 	    (setq arg (1- arg)))
! 	  ;; We're now outside of any defun.
! 	  (backward-list arg)
! 	  (if (< (point) floor) (goto-char floor)))
! 
! 	 ((< arg 0)
! 	  (cond
! 	   ((> nesting-depth 0)
! 	    (up-list nesting-depth)
! 	    (setq arg (1+ arg)))
! 	   ((not (looking-at "\\s("))
! 	    ;; We're between defuns, and not at the start of one.
! 	    (setq arg (1+ arg))))
! 	  (forward-list (- arg))
! 	  (down-list)
! 	  (backward-char)
! 	  (if (> (point) ceiling) (goto-char ceiling)))))))))
  
  (defvar end-of-defun-function nil
    "If non-nil, function for function `end-of-defun' to call.


-- 
Alan Mackenzie (Ittersbach, Germany).



*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-11-05  7:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-03 16:19 font-locking and open parens in column 0 Mackenzie, Alan
2006-11-03 19:29 ` Stefan Monnier
2006-11-04 11:35   ` martin rudalics
2006-11-04  9:30 ` martin rudalics
2006-11-05  7:08 ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2006-11-03  8:44 AW: " Mackenzie, Alan
2006-11-03 14:14 ` Stefan Monnier
2006-11-02  8:49 Mackenzie, Alan
2006-11-02 18:31 ` martin rudalics

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.