Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related problem in latest CVS]

Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related problem in latest CVS]

[Martin Stjernholm]

> From: "Zoltan Kemenczy" <kemenczy@rogers.com>
> Subject: cc-engine:c-guess-basic-syntax  related problem in latest CVS
> To: <emacs-devel@gnu.org>
> Date: Tue Jul  8 04:11:46 2003 +0200
>
> Try S-M-;  (c-guess-basic-syntax)  at different points within a buffer
> visiting a C source file that is *write-protected*... - I get a "Buffer is
> read-only: #<buffer foo.c>" message in many places.  If the buffer is made
> writeable, the syntactic information is returned...

This has to do with functions that make "hidden buffer changes", i.e.
change text properties for internal purposes. See the blurb on that
near the top of cc-engine.el. c-guess-basic-syntax is a function that
could do such hidden buffer changes, but I've now wrapped it so that
it can be called in read only mode again.

> A related question (that started all this) is that the point value of the
> syntactic information is now returned as '(syntax-symbol point-integer) list
> (it used to be a cons cell: '(symbol . point-integer)).  This breaks my
> gud-find-class function inside gud.el. I fixed that function (to use more
> maintainable predicate functions on the syntactic info as opposed to the
> (car (cdr...)), but before I submit the patch, I'd like to ask if this
> change to the '(syntax-symbol point-integer) is there to stay...

It is. I had to do that change to be able to extend syntactic
information. There's a note about it in NEWS (which I've extended a
bit now).

I think such predicate functions belong in CC Mode. How did you design
them?

Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related problem in latest CVS]

[Zoltan Kemenczy]

Getting syntax information on write-protected C++ buffers does work now...
(however, visiting a .java file now doesn't load java-mode?? :-( . (don't
have time to look into the cc-mode autoloads)  But after loading java-mode,
the syntactic information is returned correctly).

Regarding syntactic info 'predicates':

In gud-find-class certain lookups are performed a couple of times per
syntactic context as the information is parsed backward in the file looking
for any nested classes ('inclass syntactic elements).  Two "predicates"
(there must be a better term for "getAttribute" type methods?)  I found
useful to define (inside gud-find-class as local symbols) are:

(fset 'syntax-symbol (lambda (x) (car (car x))))      ; symbol of first
syntactic element
(fset 'syntax-point (lambda (x) (car (cdr (car x))))) ; point (integer) of
first syntactic element

If feeling pedantic, one could also define an iterator:
(fset 'syntax-remaining (lambda (x) (cdr x)))
to make reading code easier (a bit).

I did look through cc-engine to see if anything like the above existed...
It's just
common sense to have such predicates with the "objects", so if you agree,
redesign/name them for cc-engine, and I'll patch gud-jdb accordingly...

Regards, Zoltan

----- Original Message -----
From: "Martin Stjernholm" <mast@lysator.liu.se>
To: "Zoltan Kemenczy" <kemenczy@rogers.com>
Cc: <bug-cc-mode@gnu.org>; <emacs-devel@gnu.org>; <monnier@cs.yale.edu>;
<rms@gnu.org>
Sent: Tuesday, July 08, 2003 7:31 PM
Subject: Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related
problem in latest CVS]


> > From: "Zoltan Kemenczy" <kemenczy@rogers.com>
> > Subject: cc-engine:c-guess-basic-syntax  related problem in latest CVS
> > To: <emacs-devel@gnu.org>
> > Date: Tue Jul  8 04:11:46 2003 +0200
> >
> > Try S-M-;  (c-guess-basic-syntax)  at different points within a buffer
> > visiting a C source file that is *write-protected*... - I get a "Buffer
is
> > read-only: #<buffer foo.c>" message in many places.  If the buffer is
made
> > writeable, the syntactic information is returned...
>
> This has to do with functions that make "hidden buffer changes", i.e.
> change text properties for internal purposes. See the blurb on that
> near the top of cc-engine.el. c-guess-basic-syntax is a function that
> could do such hidden buffer changes, but I've now wrapped it so that
> it can be called in read only mode again.
>
> > A related question (that started all this) is that the point value of
the
> > syntactic information is now returned as '(syntax-symbol point-integer)
list
> > (it used to be a cons cell: '(symbol . point-integer)).  This breaks my
> > gud-find-class function inside gud.el. I fixed that function (to use
more
> > maintainable predicate functions on the syntactic info as opposed to the
> > (car (cdr...)), but before I submit the patch, I'd like to ask if this
> > change to the '(syntax-symbol point-integer) is there to stay...
>
> It is. I had to do that change to be able to extend syntactic
> information. There's a note about it in NEWS (which I've extended a
> bit now).
>
> I think such predicate functions belong in CC Mode. How did you design
> them?

Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related problem in latest CVS]

[Martin Stjernholm]

"Zoltan Kemenczy" <kemenczy@rogers.com> wrote:

> Getting syntax information on write-protected C++ buffers does work now...
> (however, visiting a .java file now doesn't load java-mode?? :-( .

Perhaps you haven't updated your loaddefs.el file lately?

> Two "predicates" (there must be a better term for "getAttribute"
> type methods?)

I call them accessor functions.

> I found useful to define (inside gud-find-class as local symbols)
> are:
>
> (fset 'syntax-symbol (lambda (x) (car (car x))))      ; symbol of first
> syntactic element
> (fset 'syntax-point (lambda (x) (car (cdr (car x))))) ; point (integer) of
> first syntactic element

I find it more generic to make accessor functions for a single
syntactic element and then treat the syntactic context as a normal
list of them (i.e. no use defining accessors for the list itself).
There are many cases where single elements are handled.

/.../
> It's just common sense to have such predicates with the "objects",
> so if you agree, redesign/name them for cc-engine, and I'll patch
> gud-jdb accordingly...

I've now added c-langelem-sym, c-langelem-pos, and c-langelem-2nd-pos
(which makes use of the new extended information in some syntactic
elements). (The naming scheme stems from the already existing
c-langelem-col.)

gud.el - jdb support update to work with updated cc-mode

[Zoltan Kemenczy]

This patch is required to make gud-jdb work again since cc-mode changed the
syntactic information...
Regards,
Zoltan Kemenczy

diff -u ~/b/emacs/emacs/lisp/progmodes/gud.el ~/local/lisp-cvs/gud.el
--- /zoltan/b/emacs/emacs/lisp/progmodes/gud.el Mon Sep  1 11:45:35 2003
+++ /zoltan/local/lisp-cvs/gud.el Sat Sep 13 19:48:53 2003
@@ -2536,11 +2536,11 @@
        (setq pos (point))
        (setq overlay-arrow-string "=>")
        (or overlay-arrow-position
-    (setq overlay-arrow-position (make-marker)))
+       (setq overlay-arrow-position (make-marker)))
        (set-marker overlay-arrow-position (point) (current-buffer)))
      (cond ((or (< pos (point-min)) (> pos (point-max)))
-     (widen)
-     (goto-char pos))))
+     (widen)
+     (goto-char pos))))
    (if window (set-window-point window overlay-arrow-position))))))

 ;; The gud-call function must do the right thing whether its invoking
@@ -2817,8 +2817,13 @@
       (save-match-data
         (let ((cplist (append gud-jdb-sourcepath gud-jdb-classpath))
               (fbuffer (get-file-buffer f))
-              class-found)
+              syntax-symbol syntax-point class-found)
           (setq f (file-name-sans-extension (file-truename f)))
+          ;; Syntax-symbol returns the symbol of the *first* element
+          ;; in the syntactical analysis result list, syntax-point
+          ;; returns the buffer position of same
+          (fset 'syntax-symbol (lambda (x) (c-langelem-sym (car x))))
+          (fset 'syntax-point (lambda (x) (c-langelem-pos (car x))))
           ;; Search through classpath list for an entry that is
           ;; contained in f
           (while (and cplist (not class-found))
@@ -2841,17 +2846,17 @@
                   ;; with the 'topmost-intro symbol, there may be
                   ;; nested classes...
                   (while (not (eq 'topmost-intro
-                                  (car (car (c-guess-basic-syntax)))))
+                                  (syntax-symbol (c-guess-basic-syntax))))
                     ;; Check if the current position c-syntactic
                     ;; analysis has 'inclass
                     (setq syntax (c-guess-basic-syntax))
                     (while
-                        (and (not (eq 'inclass (car (car syntax))))
+                        (and (not (eq 'inclass (syntax-symbol syntax)))
                              (cdr syntax))
                       (setq syntax (cdr syntax)))
-                    (if (eq 'inclass (car (car syntax)))
+                    (if (eq 'inclass (syntax-symbol syntax))
                         (progn
-                          (goto-char (cdr (car syntax)))
+                          (goto-char (syntax-point syntax))
                           ;; Now we're at the beginning of a class
                           ;; definition.  Find class name
                           (looking-at
@@ -2860,9 +2865,9 @@
                                 (append (list (match-string-no-properties
1))
                                         nclass)))
                       (setq syntax (c-guess-basic-syntax))
-                      (while (and (not (cdr (car syntax))) (cdr syntax))
+                      (while (and (not (syntax-point syntax)) (cdr syntax))
                         (setq syntax (cdr syntax)))
-                      (goto-char (cdr (car syntax)))
+                      (goto-char (syntax-point syntax))
                       ))
                   (string-match (concat (car nclass) "$") class-found)
                   (setq class-found

----- Original Message ----- 
From: "Martin Stjernholm" <mast@lysator.liu.se>
To: "Zoltan Kemenczy" <zoltan@ieee.org>
Cc: <bug-cc-mode@gnu.org>; <emacs-devel@gnu.org>; <monnier@cs.yale.edu>;
<rms@gnu.org>
Sent: Wednesday, July 16, 2003 5:13 PM
Subject: Re: [kemenczy@rogers.com: cc-engine:c-guess-basic-syntax related
problem in latest CVS]


> "Zoltan Kemenczy" <kemenczy@rogers.com> wrote:
>
> > Getting syntax information on write-protected C++ buffers does work
now...
> > (however, visiting a .java file now doesn't load java-mode?? :-( .
>
> Perhaps you haven't updated your loaddefs.el file lately?
>
> > Two "predicates" (there must be a better term for "getAttribute"
> > type methods?)
>
> I call them accessor functions.
>
> > I found useful to define (inside gud-find-class as local symbols)
> > are:
> >
> > (fset 'syntax-symbol (lambda (x) (car (car x))))      ; symbol of first
> > syntactic element
> > (fset 'syntax-point (lambda (x) (car (cdr (car x))))) ; point (integer)
of
> > first syntactic element
>
> I find it more generic to make accessor functions for a single
> syntactic element and then treat the syntactic context as a normal
> list of them (i.e. no use defining accessors for the list itself).
> There are many cases where single elements are handled.
>
> /.../
> > It's just common sense to have such predicates with the "objects",
> > so if you agree, redesign/name them for cc-engine, and I'll patch
> > gud-jdb accordingly...
>
> I've now added c-langelem-sym, c-langelem-pos, and c-langelem-2nd-pos
> (which makes use of the new extended information in some syntactic
> elements). (The naming scheme stems from the already existing
> c-langelem-col.)