patch: add-log.el: changelog find file under poin

patch: add-log.el: changelog find file under poin

[Jan Nieuwenhuizen]

Hi,

I found this function missing after applying a patch that had minor
conflicts in almost every file.

Greetings,
Jan.

ChangeLog
2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>

	* add-log.el (change-log-search-file-name, change-log-find-file):
	New function.
	(change-log-mode-map): New binding C-c C-f to change-log-find-file.

--- lisp/add-log.el~	2007-11-04 22:12:20.000000000 +0100
+++ lisp/add-log.el	2007-11-04 22:12:31.000000000 +0100
@@ -240,8 +240,10 @@
 ;; backward-compatibility alias
 (put 'change-log-acknowledgement-face 'face-alias 'change-log-acknowledgement)
 
+(defvar change-log-file-names-re "^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)")
+
 (defvar change-log-font-lock-keywords
-  '(;;
+  `(;;
     ;; Date lines, new (2000-01-01) and old (Sat Jan  1 00:00:00 2000) styles.
     ;; Fixme: this regepx is just an approximate one and may match
     ;; wrongly with a non-date line existing as a random note.  In
@@ -255,7 +257,7 @@
       (2 'change-log-email)))
     ;;
     ;; File names.
-    ("^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)"
+    (,change-log-file-names-re
      (2 'change-log-file)
      ;; Possibly further names in a list:
      ("\\=, \\([^ ,:([\n]+\\)" nil nil (1 'change-log-file))
@@ -287,10 +289,27 @@
      3 'change-log-acknowledgement))
   "Additional expressions to highlight in Change Log mode.")
 
+(defun change-log-search-file-name (where)
+  "Return the file-name for the change under point."
+  (save-excursion
+    (goto-char where)
+    (beginning-of-line 1)
+    (re-search-forward change-log-file-names-re)
+    (match-string 2)))
+
+(defun change-log-find-file ()
+  "Visit the file for the change under point."
+  (interactive)
+  (let ((file (change-log-search-file-name (point))))
+    (if (and file (file-exists-p file))
+	(find-file file)
+      (message "No such file or directory: ~s" file))))
+
 (defvar change-log-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
     (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
+    (define-key map [?\C-c ?\C-f] 'change-log-find-file)
     map)
   "Keymap for Change Log major mode.")
 


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

> I found this function missing after applying a patch that had minor
> conflicts in almost every file.
>
> Greetings,
> Jan.
>
> ChangeLog
> 2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>
>
> 	* add-log.el (change-log-search-file-name, change-log-find-file):
> 	New function.
> 	(change-log-mode-map): New binding C-c C-f to change-log-find-file.

Is this the same as what ffap does?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Jan Nieuwenhuizen]

Juri Linkov writes:

> > 	(change-log-mode-map): New binding C-c C-f to change-log-find-file.
> 
> Is this the same as what ffap does?

Thanks, never heard of that, should read the manual better.  

They do almost the same.  change-log-find-file is one keystroke less: it
visits the file directly, and it also works if point is in the
description of the change, so after the actual file.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

  > Hi,
  > 
  > I found this function missing after applying a patch that had minor
  > conflicts in almost every file.
  > 
  > Greetings,
  > Jan.
  > 
  > ChangeLog
  > 2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>
  > 
  > 	* add-log.el (change-log-search-file-name, change-log-find-file):
  > 	New function.
  > 	(change-log-mode-map): New binding C-c C-f to change-log-find-file.

May I suggest adding another (even more useful) binding: open the file
and search for the function mentioned in the change log entry?

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

>   > ChangeLog
>   > 2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>
>   >
>   > 	* add-log.el (change-log-search-file-name, change-log-find-file):
>   > 	New function.
>   > 	(change-log-mode-map): New binding C-c C-f to change-log-find-file.
>
> May I suggest adding another (even more useful) binding: open the file
> and search for the function mentioned in the change log entry?

That would be very useful.  Sometimes I have a thought that ChangeLog
could support the next-error interface, so every next-error or
next-error-follow-minor-mode will visit the next function from the
ChangeLog file.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

Would someone please install this, and update NEWS?
(Please add a doc string for the new variable.)

From: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
To: emacs-devel@gnu.org
Content-Type: text/plain
Organization: lilypond-design.org
Date: Sun, 04 Nov 2007 22:18:12 +0100
Mime-Version: 1.0
Subject: patch: add-log.el: changelog find file under poin

Hi,

I found this function missing after applying a patch that had minor
conflicts in almost every file.

Greetings,
Jan.

ChangeLog
2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>

	* add-log.el (change-log-search-file-name, change-log-find-file):
	New function.
	(change-log-mode-map): New binding C-c C-f to change-log-find-file.

--- lisp/add-log.el~	2007-11-04 22:12:20.000000000 +0100
+++ lisp/add-log.el	2007-11-04 22:12:31.000000000 +0100
@@ -240,8 +240,10 @@
 ;; backward-compatibility alias
 (put 'change-log-acknowledgement-face 'face-alias 'change-log-acknowledgement)
 
+(defvar change-log-file-names-re "^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)")
+
 (defvar change-log-font-lock-keywords
-  '(;;
+  `(;;
     ;; Date lines, new (2000-01-01) and old (Sat Jan  1 00:00:00 2000) styles.
     ;; Fixme: this regepx is just an approximate one and may match
     ;; wrongly with a non-date line existing as a random note.  In
@@ -255,7 +257,7 @@
       (2 'change-log-email)))
     ;;
     ;; File names.
-    ("^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)"
+    (,change-log-file-names-re
      (2 'change-log-file)
      ;; Possibly further names in a list:
      ("\\=, \\([^ ,:([\n]+\\)" nil nil (1 'change-log-file))
@@ -287,10 +289,27 @@
      3 'change-log-acknowledgement))
   "Additional expressions to highlight in Change Log mode.")
 
+(defun change-log-search-file-name (where)
+  "Return the file-name for the change under point."
+  (save-excursion
+    (goto-char where)
+    (beginning-of-line 1)
+    (re-search-forward change-log-file-names-re)
+    (match-string 2)))
+
+(defun change-log-find-file ()
+  "Visit the file for the change under point."
+  (interactive)
+  (let ((file (change-log-search-file-name (point))))
+    (if (and file (file-exists-p file))
+	(find-file file)
+      (message "No such file or directory: ~s" file))))
+
 (defvar change-log-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
     (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
+    (define-key map [?\C-c ?\C-f] 'change-log-find-file)
     map)
   "Keymap for Change Log major mode.")
 


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org



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

Re: patch: add-log.el: changelog find file under poin

[Glenn Morris]

Richard Stallman wrote:

> Would someone please install this, and update NEWS?

Really? As was pointed out when this was first submitted two months
ago, ffap essentially does this already.

The only difference is, ffap requires point to be over the file name,
this new stuff searches forward from the beginning of the current line.

Doesn't seem worth it to me.


> (Please add a doc string for the new variable.)
>
> From: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
> To: emacs-devel@gnu.org
> Content-Type: text/plain
> Organization: lilypond-design.org
> Date: Sun, 04 Nov 2007 22:18:12 +0100
> Mime-Version: 1.0
> Subject: patch: add-log.el: changelog find file under poin

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

    > Would someone please install this, and update NEWS?

    Really? As was pointed out when this was first submitted two months
    ago, ffap essentially does this already.

Yes, really.  ffap is a global mode which not everyone wants.
(I don't use it.)  This feature makes sense in Change Log mode.

Re: patch: add-log.el: changelog find file under poin

[Glenn Morris]

Richard Stallman wrote:

>     Really? As was pointed out when this was first submitted two months
>     ago, ffap essentially does this already.
>
> Yes, really.  ffap is a global mode which not everyone wants.

ffap is just a function, not a mode of any kind.

Perhaps you are saying you don't want people to have to load ffap.el?

> (I don't use it.)  This feature makes sense in Change Log mode.

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

>     > Would someone please install this, and update NEWS?
>
>     Really? As was pointed out when this was first submitted two months
>     ago, ffap essentially does this already.
>
> Yes, really.  ffap is a global mode which not everyone wants.
> (I don't use it.)  This feature makes sense in Change Log mode.

Actually this feature makes sense not only in Change Log mode,
but in any buffer that contains a file name.  For everyone who
doesn't want using ffap, I think it would be good to implement
a feature that will always add a file name under point to the
list of minibuffer's default values for C-x C-f.  So C-x C-f
will keep its current behavior, and additionally will provide
a file name under point available via M-n.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: patch: add-log.el: changelog find file under poin

[Drew Adams]

> > Yes, really.  ffap is a global mode which not everyone wants.
> > (I don't use it.)  This feature makes sense in Change Log mode.
>
> Actually this feature makes sense not only in Change Log mode,
> but in any buffer that contains a file name.  For everyone who
> doesn't want using ffap, I think it would be good to implement
> a feature that will always add a file name under point to the
> list of minibuffer's default values for C-x C-f.  So C-x C-f
> will keep its current behavior, and additionally will provide
> a file name under point available via M-n.

We went through this discusion at least once. See the thread "key to yank
text at point into minibuffer" of late Feb 2006.

* This post is the last one on-topic, and it reviews the arguments and use
cases:
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01074.html

* This mid-thread post is specifically about your argument to use `M-n' for
this vs my proposal to use another key:
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00664.html.

There are various ways to interpret the thingie at point - it could be a
file name or URL, but it could be other things also.

I would reserve `M-n' for things that the particular command deems would
make appropriate default values. That could include, in some cases,
something from the text at point - but it is the command that decides. That
is very different from always including a file name under point "in any
buffer".

I would prefer something like what we discussed in that 2006 thread, a
minibuffer key (I use `M-.') that is specifically for yanking text from the
buffer into the minibuffer.

That doesn't prohibit a particular command from also putting the file or URL
at point onto the future history list (`M-n'), but it separates the two:
general purpose yanking vs command-specific defaults. It doesn't always make
sense, for all commands in all buffers, for `M-n' to contain the file name
at point as one of its default values.

A general mechanism to yank buffer text to the minibuffer is useful. It
would be available for all commands in all buffers, and it would be
available at any time during minibuffer input. But it shouldn't be
confounded with minibuffer history/defaults.

You even agreed in the previous thread that we should separate the two:

 D> I'd prefer to keep the default-value list separate
 D> from this text-grabbing feature.

 J> Yes, they are separate features.

In the mechanism we discussed earlier, `M-.' has two possible modes (choice
via option): it either (1) cycles among alternative interpretations of the
thingie at point or (2) accumulates successive thingies (e.g. words) at
point, in either or both directions. In #1, each alternative replaces the
minibuffer input; in #2, the successive thingies are added to the input.

This approach, with option choice #1, provides the same cycling that you are
proposing via `M-n', but it doesn't mess up the set of default values
(`M-n'), which should be command-specific. A general mechanism to yank
buffer text should be on a different key.

I've been using this approach for a couple of years. It complements the
`M-n' history/defaults.

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Would someone please install this, and update NEWS?
  > (Please add a doc string for the new variable.)

I think this code needs a bit of bug fixing before it is ready to be
applied.  For example given this ChangeLog:

	* progmodes/hideif.el (hide-ifdef-initially, hide-ifdef-read-only)
	(hide-ifdef-lines, hide-ifdef-shadow, hide-ifdef-shadow):
	Remove autoload cookies.
	
	* vc.el (vc-diff-sentinel): Do not write a footer if there were
	differences.

If the point is on the hide-ifdef-shadow line, C-c C-f will find vc.el,
not progmodes/hideif.el, which sounds like a bug.

An improvement that would make this even more useful would be that after
finding the file, it should do a search for the item the point is
on. That won't always find the correct function/variable/etc. the log
entry refers to, but it will help the user a lot when it does.


  > From: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
  > To: emacs-devel@gnu.org
  > Content-Type: text/plain
  > Organization: lilypond-design.org
  > Date: Sun, 04 Nov 2007 22:18:12 +0100
  > Mime-Version: 1.0
  > Subject: patch: add-log.el: changelog find file under poin
  > 
  > Hi,
  > 
  > I found this function missing after applying a patch that had minor
  > conflicts in almost every file.
  > 
  > Greetings,
  > Jan.
  > 
  > ChangeLog
  > 2007-11-04  Jan Nieuwenhuizen  <janneke@gnu.org>
  > 
  > 	* add-log.el (change-log-search-file-name, change-log-find-file):
  > 	New function.
  > 	(change-log-mode-map): New binding C-c C-f to change-log-find-file.
  > 
  > --- lisp/add-log.el~	2007-11-04 22:12:20.000000000 +0100
  > +++ lisp/add-log.el	2007-11-04 22:12:31.000000000 +0100
  > @@ -240,8 +240,10 @@
  >  ;; backward-compatibility alias
  >  (put 'change-log-acknowledgement-face 'face-alias 'change-log-acknowledgement)
  >  
  > +(defvar change-log-file-names-re "^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)")
  > +
  >  (defvar change-log-font-lock-keywords
  > -  '(;;
  > +  `(;;
  >      ;; Date lines, new (2000-01-01) and old (Sat Jan  1 00:00:00 2000) styles.
  >      ;; Fixme: this regepx is just an approximate one and may match
  >      ;; wrongly with a non-date line existing as a random note.  In
  > @@ -255,7 +257,7 @@
  >        (2 'change-log-email)))
  >      ;;
  >      ;; File names.
  > -    ("^\\( +\\|\t\\)\\* \\([^ ,:([\n]+\\)"
  > +    (,change-log-file-names-re
  >       (2 'change-log-file)
  >       ;; Possibly further names in a list:
  >       ("\\=, \\([^ ,:([\n]+\\)" nil nil (1 'change-log-file))
  > @@ -287,10 +289,27 @@
  >       3 'change-log-acknowledgement))
  >    "Additional expressions to highlight in Change Log mode.")
  >  
  > +(defun change-log-search-file-name (where)
  > +  "Return the file-name for the change under point."
  > +  (save-excursion
  > +    (goto-char where)
  > +    (beginning-of-line 1)
  > +    (re-search-forward change-log-file-names-re)
  > +    (match-string 2)))
  > +
  > +(defun change-log-find-file ()
  > +  "Visit the file for the change under point."
  > +  (interactive)
  > +  (let ((file (change-log-search-file-name (point))))
  > +    (if (and file (file-exists-p file))
  > +	(find-file file)
  > +      (message "No such file or directory: ~s" file))))
  > +
  >  (defvar change-log-mode-map
  >    (let ((map (make-sparse-keymap)))
  >      (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
  >      (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
  > +    (define-key map [?\C-c ?\C-f] 'change-log-find-file)
  >      map)
  >    "Keymap for Change Log major mode.")
  >  
  > 
  > 
  > -- 
  > Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
  > http://www.xs4all.nl/~jantien       | http://www.lilypond.org
  > 
  > 
  > 
  > _______________________________________________
  > Emacs-devel mailing list
  > Emacs-devel@gnu.org
  > http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

> I would prefer something like what we discussed in that 2006 thread, a
> minibuffer key (I use `M-.') that is specifically for yanking text from the
> buffer into the minibuffer.
>
> That doesn't prohibit a particular command from also putting the file or URL
> at point onto the future history list (`M-n'), but it separates the two:
> general purpose yanking vs command-specific defaults. It doesn't always make
> sense, for all commands in all buffers, for `M-n' to contain the file name
> at point as one of its default values.

As I see, there is no disagreement: `M-n' could provide the file name at
point as a default value for the `C-x C-f' command, and a more general
command `M-.' is for yanking text (including file names and URLs) from the
buffer into the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

> An improvement that would make this even more useful would be that after
> finding the file, it should do a search for the item the point is
> on. That won't always find the correct function/variable/etc. the log
> entry refers to, but it will help the user a lot when it does.

Using the logic from `add-log-current-defun' might be unreliable, but
maybe it is better to rely on imenu to find the item in the source file.
What other package could do this?  (find-func is only for Emacs Lisp,
and etags requires the TAGS file.)

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: patch: add-log.el: changelog find file under poin

[Drew Adams]

> > I would prefer something like what we discussed in that 2006 thread, a
> > minibuffer key (I use `M-.') that is specifically for yanking
> > text from the buffer into the minibuffer.
> >
> > That doesn't prohibit a particular command from also putting
> > the file or URL at point onto the future history list (`M-n'),
> > but it separates the two: general purpose yanking vs
> > command-specific defaults. It doesn't always make
> > sense, for all commands in all buffers, for `M-n' to contain
> > the file name at point as one of its default values.
>
> As I see, there is no disagreement: `M-n' could provide the file name at
> point as a default value for the `C-x C-f' command, and a more general
> command `M-.' is for yanking text (including file names and URLs) from the
> buffer into the minibuffer.

Yes.

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

    ffap is just a function, not a mode of any kind.

    Perhaps you are saying you don't want people to have to load ffap.el?

Here's the file's documentation:

    ;; For the default installation, add this line to your .emacs file:
    ;;
    ;; (ffap-bindings)                      ; do default key bindings
    ;;
    ;; ffap-bindings makes the following global key bindings:
    ;;
    ;; C-x C-f		find-file-at-point (abbreviated as ffap)
    ;; C-x C-r		ffap-read-only
    ;; C-x C-v		ffap-alternate-file

This is not, strictly speaking, a minor mode (though perhaps we should
make it one), but it acts like a mode.  Some people use it, some
don't.

So the question is, should Change Log mode have this feature,
or should we say "globally use ffap if you want this"?

Or, perhaps Change Log mode could bind find-file-at-point
to a C-c command.

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

      For everyone who
    doesn't want using ffap, I think it would be good to implement
    a feature that will always add a file name under point to the
    list of minibuffer's default values for C-x C-f.

That might be a good feature, if it can work reliably.
The problem is, almost anything COULD be a file name.

In a change log, it is possible to find the file names
reliably, so such a feature can work reliably.

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

    If the point is on the hide-ifdef-shadow line, C-c C-f will find vc.el,
    not progmodes/hideif.el, which sounds like a bug.

Yes, it is.

Re: patch: add-log.el: changelog find file under poin

[Glenn Morris]

Richard Stallman wrote:

>     ;; For the default installation, add this line to your .emacs file:
>     ;;
>     ;; (ffap-bindings)                      ; do default key bindings
>     ;;
>     ;; ffap-bindings makes the following global key bindings:
>     ;;
>     ;; C-x C-f		find-file-at-point (abbreviated as ffap)
>     ;; C-x C-r		ffap-read-only
>     ;; C-x C-v		ffap-alternate-file
>
> This is not, strictly speaking, a minor mode (though perhaps we
> should make it one), but it acts like a mode.

The key binding stuff is optional; you don't have to bind those
commands to keys. If you don't want to do this, you can just use M-x
ffap, which is not a lot of typing.

> Or, perhaps Change Log mode could bind find-file-at-point to a C-c
> command.

Sounds better than re-inventing a wheel to me.

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     ffap is just a function, not a mode of any kind.
  > 
  >     Perhaps you are saying you don't want people to have to load ffap.el?
  > 
  > Here's the file's documentation:
  > 
  >     ;; For the default installation, add this line to your .emacs file:
  >     ;;
  >     ;; (ffap-bindings)                      ; do default key bindings
  >     ;;
  >     ;; ffap-bindings makes the following global key bindings:
  >     ;;
  >     ;; C-x C-f		find-file-at-point (abbreviated as ffap)
  >     ;; C-x C-r		ffap-read-only
  >     ;; C-x C-v		ffap-alternate-file
  > 
  > This is not, strictly speaking, a minor mode (though perhaps we should
  > make it one), but it acts like a mode.  Some people use it, some
  > don't.
  > 
  > So the question is, should Change Log mode have this feature,
  > or should we say "globally use ffap if you want this"?
  > 
  > Or, perhaps Change Log mode could bind find-file-at-point
  > to a C-c command.

That would be FAR less useful than the current proposal.

The point is that the file might not be at point. :-)

If you looking at a log entry with 50 changes, the file name can be very
far away from the point.

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > An improvement that would make this even more useful would be that after
  > > finding the file, it should do a search for the item the point is
  > > on. That won't always find the correct function/variable/etc. the log
  > > entry refers to, but it will help the user a lot when it does.
  > 
  > Using the logic from `add-log-current-defun' might be unreliable, but
  > maybe it is better to rely on imenu to find the item in the source file.
  > What other package could do this?  (find-func is only for Emacs Lisp,
  > and etags requires the TAGS file.)

The problem with those is that the user might not have imenu turned on,
so it would take a while to index the file, and might not have TAGS.
Another problem is if the entry is about something that has been deleted
or renamed.

IMHO it would be better to first go the easy way and to a simple string
search, and maybe later try to implement something more fancy.

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

>     For everyone who doesn't want using ffap, I think it would be good
>     to implement a feature that will always add a file name under
>     point to the list of minibuffer's default values for C-x C-f.
>
> That might be a good feature, if it can work reliably.
> The problem is, almost anything COULD be a file name.

I think this is not a problem.  ffap recognizes the correct file names
in most cases, and skips the text that is not a file name.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

>   > So the question is, should Change Log mode have this feature,
>   > or should we say "globally use ffap if you want this"?
>   >
>   > Or, perhaps Change Log mode could bind find-file-at-point
>   > to a C-c command.
>
> That would be FAR less useful than the current proposal.
>
> The point is that the file might not be at point. :-)
>
> If you looking at a log entry with 50 changes, the file name can be very
> far away from the point.

This looks like a request for a new function `find-file-before-point' in ffap
that searches backwards for a file name.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >   > So the question is, should Change Log mode have this feature,
  > >   > or should we say "globally use ffap if you want this"?
  > >   >
  > >   > Or, perhaps Change Log mode could bind find-file-at-point
  > >   > to a C-c command.
  > >
  > > That would be FAR less useful than the current proposal.
  > >
  > > The point is that the file might not be at point. :-)
  > >
  > > If you looking at a log entry with 50 changes, the file name can be very
  > > far away from the point.
  > 
  > This looks like a request for a new function `find-file-before-point' in ffap
  > that searches backwards for a file name.

It's not, if the point is before the file name but still on the same
entry it should look forward. Or at point if the point is on the file
name. 
Not relation to ffap here.

Re: patch: add-log.el: changelog find file under poin

[Juri Linkov]

>   > >   > So the question is, should Change Log mode have this feature,
>   > >   > or should we say "globally use ffap if you want this"?
>   > >   >
>   > >   > Or, perhaps Change Log mode could bind find-file-at-point
>   > >   > to a C-c command.
>   > >
>   > > That would be FAR less useful than the current proposal.
>   > >
>   > > The point is that the file might not be at point. :-)
>   > >
>   > > If you looking at a log entry with 50 changes, the file name can be very
>   > > far away from the point.
>   >
>   > This looks like a request for a new function `find-file-before-point' in ffap
>   > that searches backwards for a file name.
>
> It's not, if the point is before the file name but still on the same
> entry it should look forward.

How this is possible if ChangeLog entries always start with a file name?

> Or at point if the point is on the file name.

This is naturally to expect from such a function to first look at point
(including the leading star in case of ChangeLog entries).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

    It's not, if the point is before the file name but still on the same
    entry it should look forward. Or at point if the point is on the file
    name. 
    Not relation to ffap here.

It does seem that a command that is specifically for Change Log mode
would work better than any general-purpose command.

Re: patch: add-log.el: changelog find file under poin

[Richard Stallman]

    >     For everyone who doesn't want using ffap, I think it would be good
    >     to implement a feature that will always add a file name under
    >     point to the list of minibuffer's default values for C-x C-f.
    >
    > That might be a good feature, if it can work reliably.
    > The problem is, almost anything COULD be a file name.

    I think this is not a problem.  ffap recognizes the correct file names
    in most cases, and skips the text that is not a file name.

In that case, how about setting up an extra default for file names
using the same code used for ffap?

Re: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     It's not, if the point is before the file name but still on the same
  >     entry it should look forward. Or at point if the point is on the file
  >     name. 
  >     Not relation to ffap here.
  > 
  > It does seem that a command that is specifically for Change Log mode
  > would work better than any general-purpose command.

Based on that I checked this original patch in (Thanks Jan!).
And I made it a bit more robust in finding the correct file name.
If someone can figure out a way to use ffap that is at least as
reliable, then we can replace the current code.

Re: patch: add-log.el: changelog find file under poin

[Jan Nieuwenhuizen]

Juri Linkov writes:

> I think this is not a problem.  ffap recognizes the correct file names
> in most cases, and skips the text that is not a file name.

I've been using ffap for a while and found it abou as often big a pain
as it is handy.  Esp. suggesting that /*********************** etc.
are file names is not helpful when browsing projects.  How do others
cope with this, anyone using ffap?

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: patch: add-log.el: changelog find file under poin

[Johan Bockgård]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> I've been using ffap for a while and found it abou as often big a pain
> as it is handy.  Esp. suggesting that /*********************** etc.
> are file names is not helpful when browsing projects.  How do others
> cope with this, anyone using ffap?

I use

    (ffap-bindings)
    (setq ffap-require-prefix t
          dired-at-point-require-prefix t)

This means that `C-x C-f' and `C-x d' behave normally, and a `C-u'
prefix is used for ffap magic.

-- 
Johan Bockgård

Re: patch: add-log.el: changelog find file under poin

[martin rudalics]

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

> Based on that I checked this original patch in (Thanks Jan!).
> And I made it a bit more robust in finding the correct file name.
> If someone can figure out a way to use ffap that is at least as
> reliable, then we can replace the current code.

Based on what you wrote and Imenu I added support to find the "tag"
within the file with C-c C-t.  Rudimentary and largely untested!
If anyone is interested I can refine that though.

[-- Attachment #2: add-log.patch --]
[-- Type: text/plain, Size: 4947 bytes --]

*** add-log.el	Sun Jan 27 22:30:56 2008
--- add-log.el	Mon Jan 28 11:16:12 2008
***************
*** 328,338 ****
--- 328,456 ----
  	(find-file file)
        (message "No such file or directory: %s" file))))
  
+ (defconst change-log-tag-re "(\\(\\(?:\\sw\\|\\s_\\)+\\(?:,[ \t]+\\(?:\\sw\\|\\s_\\)+\\)*\\))")
+ 
+ (defun change-log-search-tag (&optional at)
+   "Search for something qualifying as tag."
+   (save-excursion
+     (goto-char (setq at (or at (point))))
+     (save-restriction
+       (widen)
+       (or (condition-case nil
+ 	      ;; Test for AT within list containing tags.
+ 	      (save-excursion
+ 		(backward-up-list)
+ 		(when (looking-at change-log-tag-re)
+ 		  (goto-char at)
+ 		  (save-restriction
+ 		    (narrow-to-region (match-beginning 1) (match-end 1))
+ 		    (find-tag-default))))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Test for AT before list containing tags.
+ 	      (save-excursion
+ 		(when (and (skip-chars-forward " \t") ; syntax goes to far
+ 			   (looking-at change-log-tag-re))
+ 		  (save-restriction
+ 		    (narrow-to-region (match-beginning 1) (match-end 1))
+ 		    (goto-char (point-min))
+ 		    (find-tag-default))))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Test for AT near filename.
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (save-restriction
+ 		    (narrow-to-region (match-beginning 1) (match-end 1))
+ 		    (goto-char (point-min))
+ 		    (find-tag-default))))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Test for AT before filename.
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (skip-syntax-backward " ")
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (save-restriction
+ 		    (narrow-to-region (match-beginning 1) (match-end 1))
+ 		    (goto-char (point-min))
+ 		    (find-tag-default))))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Test for AT near start entry.
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-start-entry-re))
+ 			   (forward-line) ; Won't work for multiple
+ 					  ; names, etc.
+ 			   (skip-syntax-forward " ")
+ 			   (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (re-search-forward change-log-tag-re))
+ 		  (save-restriction
+ 		    (narrow-to-region (match-beginning 1) (match-end 1))
+ 		    (goto-char (point-min))
+ 		    (find-tag-default))))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Test for AT after tag list.
+ 	      (when (re-search-backward change-log-tag-re)
+ 		(save-restriction
+ 		  (narrow-to-region (match-beginning 1) (match-end 1))
+ 		  (goto-char (point-max))
+ 		  (find-tag-default)))
+ 	    (error nil))))))
+ 
+ (defun change-log-find-tag ()
+   "Find tag using Imenu."
+   (interactive)
+   (let ((file (change-log-search-file-name (point)))
+ 	(tag (change-log-search-tag (point))))
+     (cond
+      ((and tag file (file-exists-p file))
+       (let ((buffer (find-file-noselect file))
+ 	    position)
+ 	(if buffer
+ 	    (with-current-buffer buffer
+ 	      (require 'imenu)
+ 	      (save-excursion
+ 		(save-restriction
+ 		  (widen)
+ 		  (condition-case nil
+ 		      (let* (imenu-use-markers element ; don't use markers.
+ 			     (tags (funcall imenu-create-index-function)))
+ 			;; TODO: Handle case of more than one
+ 			;; association for tag.
+ 			(if (setq element (assoc tag tags))
+ 			    (setq position (cdr element))
+ 			  (message "Not found tag: %s" tag)))
+ 		    (error nil))))
+ 	      (when position
+ 		(goto-char position)
+ 		(display-buffer buffer)))
+ 	  (message "Cannot find file: %s" file))))
+      ((not tag) (message "No such tag: %s" tag))
+      (t (message "No such file or directory: %s" file)))))
+ 
+ 
  (defvar change-log-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
      (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
      (define-key map [?\C-c ?\C-f] 'change-log-find-file)
+     (define-key map [?\C-c ?\C-t] 'change-log-find-tag)
      map)
    "Keymap for Change Log major mode.")
  
***************
*** 938,944 ****
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 		     
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))
--- 1056,1062 ----
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))

[-- 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: patch: add-log.el: changelog find file under poin

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > > Based on that I checked this original patch in (Thanks Jan!).
  > > And I made it a bit more robust in finding the correct file name.
  > > If someone can figure out a way to use ffap that is at least as
  > > reliable, then we can replace the current code.
  > 
  > Based on what you wrote and Imenu I added support to find the "tag"
  > within the file with C-c C-t.  Rudimentary and largely untested!
  > If anyone is interested I can refine that though.

IMO, it would be nice to have something like this.  (I haven't looked a
your code, nor tested it though)

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

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

I've now designed two approaches to handle this.  The user interface is
the same: Move to some `change-log-list' item and type C-c C-t.  The
corresponding part of the source should be displayed in another window.


The simple approach is based on searching and comparing the result with
that of `add-log-current-defun'.  It works pretty well most of the time
but may exhibit the nasty behavior described in

http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg00443.html

On my 1 GHz machine this means that I have to wait some 40 secs until
I'm told that there are no matches.  I can think of two ways to handle
this: (1) Convince Alan that the behavior of `c-beginning-of-defun' is
intolerable - AFAICT this has been tried before.  (2) Fix this within
`add-log-current-defun' to not use `c-beginning-of-defun' - I'm unable
to do this myself because I completely fail to understand that part of
the function.

I've attached the simple approach as add-log-simple.patch.


The more complicated approach is based on a combination of imenu, etags,
and regexp searching.  I've put most of this in a separate file called
local-tags.el merely because it would allow me to fix `which-func-mode'
and `imenu' as well (both are currently not really useful for c-mode).
This approach is more reliable and works faster for c-mode files.  It
requires, however, to have etags installed and working in order to get
reasonable behavior for c-mode change logs.

The second approach is attached as add-log-tags.patch and local-tags.el.
Note that add-log.el has (require 'local-tags) here, hence you have to
make sure that the latter is found.


[-- Attachment #2: add-log-simple.patch --]
[-- Type: text/plain, Size: 9686 bytes --]

*** add-log.el.~1.205.~	Sun Jan 27 20:52:46 2008
--- add-log.el	Mon Feb 18 20:00:22 2008
***************
*** 300,309 ****
  	;; name.
  	(progn
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string 2))
        (if (looking-at change-log-file-names-re)
  	  ;; We found a file name.
! 	  (match-string 2)
  	;; Look backwards for either a file name or the log entry start.
  	(if (re-search-backward
  	     (concat "\\(" change-log-start-entry-re 
--- 300,309 ----
  	;; name.
  	(progn
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string-no-properties 2))
        (if (looking-at change-log-file-names-re)
  	  ;; We found a file name.
! 	  (match-string-no-properties 2)
  	;; Look backwards for either a file name or the log entry start.
  	(if (re-search-backward
  	     (concat "\\(" change-log-start-entry-re 
***************
*** 314,324 ****
  		;; file name.
  		(progn
  		  (re-search-forward change-log-file-names-re nil t)
! 		  (match-string 2))
! 	      (match-string 4))
  	  ;; We must be before any file name, look forward.
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string 2))))))
  
  (defun change-log-find-file ()
    "Visit the file for the change under point."
--- 314,324 ----
  		;; file name.
  		(progn
  		  (re-search-forward change-log-file-names-re nil t)
! 		  (match-string-no-properties 2))
! 	      (match-string-no-properties 4))
  	  ;; We must be before any file name, look forward.
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string-no-properties 2))))))
  
  (defun change-log-find-file ()
    "Visit the file for the change under point."
***************
*** 328,338 ****
--- 328,523 ----
  	(find-file file)
        (message "No such file or directory: %s" file))))
  
+ (defun change-log-search-tag-name-1 (&optional from)
+   "Search for a tag name within subexpression 1 of last match.
+ Optional argument FROM specifies a buffer position where the tag
+ name should be located.  Return value is a cons whose car is the
+ string representing the tag and whose cdr is the position where
+ the tag was found."
+   (save-restriction
+     (narrow-to-region (match-beginning 1) (match-end 1))
+     (when from (goto-char from))
+     ;; The regexp below skips any symbol near `point' (FROM) followed by
+     ;; whitespace and another symbol.  This should skip, for example,
+     ;; "struct" in a specification like "(struct buffer)" and move to
+     ;; "buffer".  A leading paren is ignored.
+     (when (looking-at
+ 	   "[(]?\\(?:\\(?:\\sw\\|\\s_\\)+\\(?:[ \t]+\\(\\sw\\|\\s_\\)+\\)\\)")
+       (goto-char (match-beginning 1)))
+     (cons (find-tag-default) (point))))
+ 
+ (defconst change-log-tag-re
+   "(\\(\\(?:\\sw\\|\\s_\\)+\\(?:[, \t]+\\(?:\\sw\\|\\s_\\)+\\)*\\))"
+   "Regexp matching a tag name in change log entries.")
+ 
+ (defun change-log-search-tag-name (&optional at)
+   "Search for a tag name near `point'.
+ Optional argument AT non-nil means search near buffer position
+ AT.  Return value is a cons whose car is the string representing
+ the tag and whose cdr is the position where the tag was found."
+   (save-excursion
+     (goto-char (setq at (or at (point))))
+     (save-restriction
+       (widen)
+       (or (condition-case nil
+ 	      ;; Within parenthesized list?
+ 	      (save-excursion
+ 		(backward-up-list)
+ 		(when (looking-at change-log-tag-re)
+ 		  (change-log-search-tag-name-1 at)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Before parenthesized list?
+ 	      (save-excursion
+ 		(when (and (skip-chars-forward " \t")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Near filename?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Before filename?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (skip-syntax-backward " ")
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Near start entry?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-start-entry-re))
+ 			   (forward-line) ; Won't work for multiple
+ 					  ; names, etc.
+ 			   (skip-syntax-forward " ")
+ 			   (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (re-search-forward change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; After parenthesized list?.
+ 	      (when (re-search-backward change-log-tag-re)
+ 		(save-restriction
+ 		  (narrow-to-region (match-beginning 1) (match-end 1))
+ 		  (goto-char (point-max))
+ 		  (cons (find-tag-default) (point-max))))
+ 	    (error nil))))))
+ 
+ (defvar change-log-find-head nil)
+ (defvar change-log-find-tail nil)
+ 
+ (defun change-log-find-tag-1 (tag regexp file buffer
+ 				  &optional window first last)
+   "Search for tag TAG in buffer BUFFER visiting file FILE.
+ REGEXP is a regular expression for TAG.  The remaining arguments
+ are optional: WINDOW denotes the window to display the results of
+ the search.  FIRST is a position in BUFFER denoting the first
+ match from previous searches for TAG.  LAST is the position in
+ BUFFER denoting the last match for TAG in the last search."
+   (with-current-buffer buffer
+     (save-excursion
+       (save-restriction
+ 	(widen)
+ 	(if last
+ 	    (progn
+ 	      ;; When LAST is set make sure we continue from the next
+ 	      ;; line end to not find the same tag again.
+ 	      (goto-char last)
+ 	      (end-of-line)
+ 	      (condition-case nil
+ 		  ;; Try to go to the end of the current defun to avoid
+ 		  ;; false positives within the current defun's body
+ 		  ;; since these would match `add-log-current-defun'.
+ 		  (end-of-defun)
+ 		;; Don't fall behind when `end-of-defun' fails.
+ 		(error (progn (goto-char last) (end-of-line))))
+ 	      (setq last nil))
+ 	  ;; When LAST was not set start at beginning of BUFFER.
+ 	  (goto-char (point-min)))
+ 	(let (current-defun)
+ 	  (while (and (not last) (re-search-forward regexp nil t))
+ 	      ;; Verify that `add-log-current-defun' invoked at the end
+ 	      ;; of the match returns TAG.  This heuristic works well
+ 	      ;; whenever the name of the defun occurs within the first
+ 	      ;; line of the defun.
+ 	      (setq current-defun (add-log-current-defun))
+ 	      (when (and current-defun (string-equal current-defun tag))
+ 		;; Record this as last match.
+ 		(setq last (line-beginning-position))
+ 		;; Record this as first match when there's none.
+ 		(unless first (setq first last)))))))
+     (if (or last first)
+ 	(with-selected-window (or window (display-buffer buffer))
+ 	  (if last
+ 	      (progn
+ 		(when (or (< last (point-min)) (> last (point-max)))
+ 		  ;; Widen to show TAG.
+ 		  (widen))
+ 		(push-mark)
+ 		(goto-char last))
+ 	    ;; When there are no more matches go (back) to FIRST.
+ 	    (message "No more matches for `%s' in %s" tag file)
+ 	    (setq last first)
+ 	    (goto-char first))
+ 	  ;; Return new "tail".
+ 	  (list (selected-window) first last))
+       (message "Not found `%s' in %s" tag file)
+       nil)))
+ 
+ (defun change-log-find-tag ()
+   "Find source code for change log tag near `point'.
+ A tag is a symbol within a parenthesized, comma-separated list."
+   (interactive)
+   (if (and (eq last-command 'change-log-find-tag)
+ 	   change-log-find-tail)
+       (setq change-log-find-tail
+ 	    (condition-case nil
+ 		(apply 'change-log-find-tag-1
+ 		       (append change-log-find-head change-log-find-tail))
+ 	      (error
+ 	       (format "Cannot find more matches for `%s' in %s"
+ 		       (car change-log-find-head)
+ 		       (nth 2 change-log-find-head)))))
+     (save-excursion
+       (let* ((tag-at (change-log-search-tag-name))
+ 	     (tag (car tag-at))
+ 	     (file (when tag-at
+ 		     (change-log-search-file-name (cdr tag-at)))))
+ 	(if (not tag)
+ 	    (error "No suitable tag near `point'")
+ 	  (setq change-log-find-head
+ 		(list tag (concat "\\_<" (regexp-quote tag) "\\_>")
+ 		      file (find-file-noselect file)))
+ 	  (condition-case nil
+ 	      (setq change-log-find-tail
+ 		    (apply 'change-log-find-tag-1 change-log-find-head))
+ 	    (error (format "Cannot find matches for `%s' in %s"
+ 			   tag file))))))))
+ 
  (defvar change-log-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
      (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
      (define-key map [?\C-c ?\C-f] 'change-log-find-file)
+     (define-key map [?\C-c ?\C-t] 'change-log-find-tag)
      map)
    "Keymap for Change Log major mode.")
  
***************
*** 938,944 ****
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 		     
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))
--- 1123,1129 ----
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))


[-- Attachment #3: add-log-tags.patch --]
[-- Type: text/plain, Size: 8406 bytes --]

*** add-log.el.~1.205.~	Sun Jan 27 20:52:46 2008
--- add-log.el	Mon Feb 18 18:45:28 2008
***************
*** 300,309 ****
  	;; name.
  	(progn
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string 2))
        (if (looking-at change-log-file-names-re)
  	  ;; We found a file name.
! 	  (match-string 2)
  	;; Look backwards for either a file name or the log entry start.
  	(if (re-search-backward
  	     (concat "\\(" change-log-start-entry-re 
--- 300,309 ----
  	;; name.
  	(progn
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string-no-properties 2))
        (if (looking-at change-log-file-names-re)
  	  ;; We found a file name.
! 	  (match-string-no-properties 2)
  	;; Look backwards for either a file name or the log entry start.
  	(if (re-search-backward
  	     (concat "\\(" change-log-start-entry-re 
***************
*** 314,324 ****
  		;; file name.
  		(progn
  		  (re-search-forward change-log-file-names-re nil t)
! 		  (match-string 2))
! 	      (match-string 4))
  	  ;; We must be before any file name, look forward.
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string 2))))))
  
  (defun change-log-find-file ()
    "Visit the file for the change under point."
--- 314,324 ----
  		;; file name.
  		(progn
  		  (re-search-forward change-log-file-names-re nil t)
! 		  (match-string-no-properties 2))
! 	      (match-string-no-properties 4))
  	  ;; We must be before any file name, look forward.
  	  (re-search-forward change-log-file-names-re nil t)
! 	  (match-string-no-properties 2))))))
  
  (defun change-log-find-file ()
    "Visit the file for the change under point."
***************
*** 328,338 ****
--- 328,487 ----
  	(find-file file)
        (message "No such file or directory: %s" file))))
  
+ (defun change-log-search-tag-name-1 (&optional from)
+   "Search for a tag name within subexpression 1 of last match.
+ Optional argument FROM specifies a buffer position where the tag
+ name should be located.  Return value is a cons whose car is the
+ string representing the tag and whose cdr is the position where
+ the tag was found."
+   (save-restriction
+     (narrow-to-region (match-beginning 1) (match-end 1))
+     (when from (goto-char from))
+     ;; The regexp below skips any symbol near `point' (FROM) followed by
+     ;; whitespace and another symbol.  This should skip, for example,
+     ;; "struct" in a specification like "(struct buffer)" and move to
+     ;; "buffer".  A leading paren is ignored.
+     (when (looking-at
+ 	   "[(]?\\(?:\\(?:\\sw\\|\\s_\\)+\\(?:[ \t]+\\(\\sw\\|\\s_\\)+\\)\\)")
+       (goto-char (match-beginning 1)))
+     (cons (find-tag-default) (point))))
+ 
+ (defconst change-log-tag-re
+   "(\\(\\(?:\\sw\\|\\s_\\)+\\(?:[, \t]+\\(?:\\sw\\|\\s_\\)+\\)*\\))"
+   "Regexp matching a tag name in change log entries.")
+ 
+ (defun change-log-search-tag-name (&optional at)
+   "Search for a tag name near `point'.
+ Optional argument AT non-nil means search near buffer position
+ AT.  Return value is a cons whose car is the string representing
+ the tag and whose cdr is the position where the tag was found."
+   (save-excursion
+     (goto-char (setq at (or at (point))))
+     (save-restriction
+       (widen)
+       (or (condition-case nil
+ 	      ;; Within parenthesized list?
+ 	      (save-excursion
+ 		(backward-up-list)
+ 		(when (looking-at change-log-tag-re)
+ 		  (change-log-search-tag-name-1 at)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Before parenthesized list?
+ 	      (save-excursion
+ 		(when (and (skip-chars-forward " \t")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Near filename?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Before filename?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (skip-syntax-backward " ")
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (skip-syntax-forward " ")
+ 			   (looking-at change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; Near start entry?
+ 	      (save-excursion
+ 		(when (and (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-start-entry-re))
+ 			   (forward-line) ; Won't work for multiple
+ 					  ; names, etc.
+ 			   (skip-syntax-forward " ")
+ 			   (progn
+ 			     (beginning-of-line)
+ 			     (looking-at change-log-file-names-re))
+ 			   (goto-char (match-end 0))
+ 			   (re-search-forward change-log-tag-re))
+ 		  (change-log-search-tag-name-1)))
+ 	    (error nil))
+ 	  (condition-case nil
+ 	      ;; After parenthesized list?.
+ 	      (when (re-search-backward change-log-tag-re)
+ 		(save-restriction
+ 		  (narrow-to-region (match-beginning 1) (match-end 1))
+ 		  (goto-char (point-max))
+ 		  (cons (find-tag-default) (point-max))))
+ 	    (error nil))))))
+ 
+ (defvar change-log-tag-buffer nil
+   "Buffer visiting source file for last call of `change-log-find-tag'.")
+ 
+ (defvar change-log-tag-list nil
+   "List of matches found by last call of `change-log-find-tag'.
+ When matches exist a cons cell whose caar denotes the function to
+ call for going to a matching location and whose cdr is the list
+ of locations.")
+ 
+ (defvar change-log-tag-arg nil
+   "Index used for rotating `change-log-tag-list'.")
+ 
+ (defun change-log-find-tag ()
+   "Display source code matching change log entry near `point'.
+ Invoking this repeatedly will rotate through matches found."
+   (interactive)
+   (save-excursion
+     (if (equal last-command 'change-log-find-tag)
+ 	;; Rotate hits.
+ 	(if (or (not change-log-tag-buffer) (null change-log-tag-list))
+ 	    (message "No matches to display")
+ 	  (setq change-log-tag-arg (1+ change-log-tag-arg))
+ 	  (when (= change-log-tag-arg (length (cdr change-log-tag-list)))
+ 	    (when (> (length (cdr change-log-tag-list)) 1)
+ 	      (message "Wrapping to first match")) ; Inform user.
+ 	    (setq change-log-tag-arg 0))
+ 	  (let ((fun (caar change-log-tag-list))
+ 		(hit (nth change-log-tag-arg (cdr change-log-tag-list))))
+ 	    (with-selected-window (display-buffer change-log-tag-buffer)
+ 	      (push-mark nil t)
+ 	      (funcall fun hit))))
+       ;; Get new hits.
+       (let* ((tag-at (change-log-search-tag-name))
+ 	     (tag (car tag-at))
+ 	     (file (when tag-at
+ 		     (change-log-search-file-name (cdr tag-at)))))
+ 	(if (not tag)
+ 	    (error "No suitable tag name near `point'")
+ 	  (set (make-local-variable 'change-log-tag-buffer)
+ 	       (find-file-noselect file))
+ 	  (require 'local-tags)
+ 	  (set (make-local-variable 'change-log-tag-list)
+ 	       (with-current-buffer change-log-tag-buffer
+ 		 (local-tags-find tag)))
+ 	  (if (null change-log-tag-list)
+ 	      (message "No matches for `%s' in %s" tag file)
+ 	    (when (> (length (cdr change-log-tag-list)) 1)
+ 	      (message "Repeat this command to display more matches"))
+ 	    (set (make-local-variable 'change-log-tag-arg) 0)
+ 	    (let ((fun (caar change-log-tag-list))
+ 		  (hit (cadr change-log-tag-list)))
+ 	      (with-selected-window (display-buffer change-log-tag-buffer)
+ 		(push-mark nil t)
+ 		(funcall fun hit)))))))))
+ 
  (defvar change-log-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [?\C-c ?\C-p] 'add-log-edit-prev-comment)
      (define-key map [?\C-c ?\C-n] 'add-log-edit-next-comment)
      (define-key map [?\C-c ?\C-f] 'change-log-find-file)
+     (define-key map [?\C-c ?\C-t] 'change-log-find-tag)
      map)
    "Keymap for Change Log major mode.")
  
***************
*** 938,944 ****
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 		     
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))
--- 1087,1093 ----
  		       having-next-defun
  		       previous-defun-end
  		       next-defun-beginning)
! 
  		   (save-excursion
  		     (setq having-previous-defun
  			   (c-beginning-of-defun))


[-- Attachment #4: local-tags.el --]
[-- Type: text/plain, Size: 14043 bytes --]

;;; local-tags.el --- buffer-local tags

;; Copyright (C) 2008 Martin Rudalics

;; Time-stamp: "2008-02-18 20:41:11 martin"
;; Author: Martin Rudalics <rudalics@gmx.at>
;; Keywords: tags, imenu, etags

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

(defgroup local-tags nil
  "Buffer-local tags."
  :version "23.1"
  :group 'convenience)

(defcustom local-tags-methods '(imenu etags syntax plain)
  "List of methods for extracting tags of current buffer.
Possible members are:

 `imenu': Apply the method used by imenu for creating this buffer's
          index (`imenu--index-alist').

 `etags': Run the `etags' program on the contents of this buffer.

 `plain': Plain search (ignored when listing tags).

 `syntax': Like plain search but do not report matches within
           comments or strings (ignored when listing tags).

The methods in this list are run until one of them reports a
result.  This variable can be set in a hook, as

 (add-hook 'c-mode-hook
	   (set (make-local-variable 'local-tags-methods)
	        '(etags imenu syntax plain)))"
  :type '(repeat (choice (const :tag "imenu" imenu)
			 (const :tag "etags" etags)
			 (const :tag "syntactic search" syntax)
			 (const :tag "plain search" plain)))
  :group 'local-tags)

(defcustom local-tags-revert-buffer nil
  "Non-nil means revert buffer when visited file chenged on disk."
  :type 'boolean
  :group 'local-tags)

(defcustom local-tags-etags-program "etags"
  "Name of etags program."
  :type 'string
  :group 'local-tags)

(defcustom local-tags-etags-options '("--no-members")
  "List of options passed to etags program.
Possible options are \"--declarations\", \"-D\", \"-I\",
\"--no-globals\", and \"--no-members\".

Do not specify \"-o\", \"--output\", or \"--parse-stdin\" here,
they are passed to etags automatically."
  :type '(repeat (string :tag "Option"))
  :group 'local-tags)

(defcustom local-tags-etags-charpos nil
  "Non-nil means etags based functions report character positions.
The default has etags based functions report line numbers which
is slower when actually going to the tag but more reliable
because the etags program reports file position which might not
always translate correctly to buffer positions."
  :type 'boolean
  :group 'local-tags)

;; imenu specific part.
(defvar local-tags-imenu-tag-list nil
  "Tags created by `local-tags-imenu-list'.")
(make-variable-buffer-local 'local-tags-imenu-tag-list)

(defun local-tags-imenu-list ()
  "Retrieve tags for current buffer using imenu.
Return nil or a cons cell whose car is a list built of the symbol
`goto-char' and the `buffer-chars-modified-tick' value at the
time this list was created.  The cdr of the cons is the list of
tags created by `imenu-create-index-function' for this buffer."
  (if (and (local-variable-p 'local-tags-imenu-tag-list)
	   (= (nth 1 (car local-tags-imenu-tag-list))
	      (buffer-chars-modified-tick)))
      ;; We have a valid `local-tags-imenu-tag-list', return it.
      local-tags-imenu-tag-list
    ;; `local-tags-imenu-tag-list' either doesn't exist yet or the
    ;; buffer has been modified since it was created; (re-)build it.
    (require 'imenu)
    ;; Don't use markers for our purposes.
    (let (imenu-use-markers)
      (save-excursion
	(save-restriction
	  (widen)
	  (let ((tags (condition-case nil
			  ;; Calculate the tags.
			  (funcall imenu-create-index-function)
			(error nil))))
	    ;; Prepend `goto-char' and `buffer-chars-modified-tick' and
	    ;; save the result in `local-tags-imenu-tag-list'.
	    (setq local-tags-imenu-tag-list
		  (when tags
		    (cons (list 'goto-char (buffer-chars-modified-tick))
			  tags)))))))))

(defun local-tags-imenu-find-1 (tags tag)
  "Return list of all matches for TAG in tag-list TAGS.
TAGS is assumed to be an object created by calling
`imenu-create-index-function'."
  (let (hits)
    (dolist (item tags)
      (cond
       ((number-or-marker-p (cdr item))
	;; A useful item, return as is.
	(when (equal (car item) tag)
	  (setq hits (cons (cdr item) hits))))
       ((listp (cdr item))
	;; Recurse.
	(setq hits (nconc (local-tags-imenu-find-1 (cdr item) tag)
			  hits)))))
    hits))

(defun local-tags-imenu-find (tag)
  "Return matches for tag TAG in current buffer using imenu.
Return nil or a cons cell whose car is a list built of the symbol
`goto-char' and the `buffer-chars-modified-tick' value at the
time a list of tags was created for this buffer.  The cdr of the
cons is a list of locations matching TAG."
  (condition-case nil
      ;; Update `local-tags-imenu-tag-list' if necessary.
      (let ((tags (local-tags-imenu-list)))
	(when tags
	  (let ((hits (local-tags-imenu-find-1 (cdr tags) tag)))
	    (when hits
	      (cons (car tags)
		    ;; `local-tags-imenu-find-1' returns hits in descending
		    ;; order, reverse them.
		    (nreverse hits))))))
    (error nil)))


;; etags specific part.
(defvar local-tags-etags-buffer nil
  "Buffer used for storing etags output.")

(defvar local-tags-etags-tag-list nil
  "Tags created by `local-tags-etags-list'.")
(make-variable-buffer-local 'local-tags-etags-tag-list)

;; We use an adaption of the regexp from Roland McGrath's
;; `etags-tags-completion-table', where
;;   1 is the "guessed" tag name,
;;   2 the "explicitly specified" tag name,
;;   3 the number of the line where the tag appears, and
;;   4 (usually) the tag's line beginning position (minus 1).
(defconst local-tags-etags-regexp
  "^\\(?:\\(?:[^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(?:\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
  "Regexp to search for tags in etags generated buffers.")

;; Note: Maybe we should consider customizing which matches may be
;; reported for etags regexp (only guessed, only explicitly specified,
;; currently it's either of them when they differ).

(defun local-tags-etags-list ()
  "Retrieve tags for current buffer using etags.
Return nil or a cons cell whose car is a list built of the
function to go to the tag, the `buffer-chars-modified-tick' value
at the time this list was created, and the values of
`local-tags-etags-options' and `local-tags-etags-charpos' used
for running etags.  The cdr of the cons is the list of tags
obtained by running `local-tags-etags-program' on this buffer."
  (if (and (local-variable-p 'local-tags-etags-tag-list)
	   (= (nth 1 (car local-tags-etags-tag-list))
	      (buffer-chars-modified-tick))
	   (equal (nth 2 (car local-tags-etags-tag-list))
		  local-tags-etags-options)
	   (equal (nth 3 (car local-tags-etags-tag-list))
		  local-tags-etags-charpos))
      ;; We have a valid `local-tags-etags-tag-list', return it.
      local-tags-etags-tag-list
    ;; `local-tags-etags-tag-list' either doesn't exist yet, or the
    ;; buffer has been modified since it was created, or some options
    ;; for running etags have changed; (re-)build it.
    (unless local-tags-etags-buffer
      ;; There's no buffer for etags output, create one.
      (setq local-tags-etags-buffer
	    ;; FIXME: Prepend space to make this buffer invisible.
	    (generate-new-buffer "*local-tags*")))
    ;; Clean the buffer for etags output.
    (with-current-buffer local-tags-etags-buffer
      (erase-buffer))
    ;; Run etags on entire buffer.
    (save-restriction
      (widen)
      (apply 'call-process-region (point-min) (point-max)
	     local-tags-etags-program nil local-tags-etags-buffer nil
	     (append
	      (list
	       "--output=-" (concat "--parse-stdin=" (buffer-name)))
	      local-tags-etags-options)))
    ;; Build the tags-list.  Make sure to apply the correct value of
    ;; `local-tags-etags-charpos' in case this has been made local in
    ;; the current buffer.
    (let ((position local-tags-etags-charpos)
	  tags ms1 ms2 location)
      (with-current-buffer local-tags-etags-buffer
	(goto-char (point-min))
	(while (re-search-forward local-tags-etags-regexp nil t)
	  ;; When we record character positions add one to the value
	  ;; returned by etags since the latter counts file positions
	  ;; from zero.
	  (setq location
		(if position
		    (1+ (string-to-number
			 (match-string-no-properties 4)))
		  (string-to-number
		   (match-string-no-properties 3))))
	  (when (setq ms1 (match-string-no-properties 1))
	    ;; We have a match for the "guessed" tag, record it.
	    (setq tags (cons (cons ms1 location) tags)))
	  (when (and (setq ms2 (match-string-no-properties 2))
		     (or (not ms1) (not (string-equal ms1 ms2))))
	    ;; We have a match for the "explicitly specified" tag and
	    ;; its name does not coincide with that of the "guessed"
	    ;; tag, record it.
	    (setq tags (cons (cons ms2 location) tags)))))
      ;; Prepend the goto function, `buffer-chars-modified-tick', and
      ;; the relevant options for running etags, and save the result in
      ;; `local-tags-etags-tag-list'.
      (setq local-tags-etags-tag-list
	    (when tags
	      (cons
	       (list
		(if local-tags-etags-charpos 'goto-char 'goto-line)
		(buffer-chars-modified-tick)
		local-tags-etags-options local-tags-etags-charpos)
	       ;; List tags in ascending buffer positions.
	       (nreverse tags)))))))

(defun local-tags-etags-find (tag)
  "Return matches for tag TAG in current buffer using etags.
Return nil or a cons cell whose car is a list built of the
function to go to tag locations, the `buffer-chars-modified-tick'
value at the time this list was created, and the values of
`local-tags-etags-options' and `local-tags-etags-charpos' used
for running etags.  The cdr of the cons is a list of locations of
tags matching TAG."
  (condition-case nil
      ;; Update `local-tags-etags-tag-list' if necessary.
      (let ((tags (local-tags-etags-list)))
	(when tags
	  (let (hits)
	    (dolist (item (cdr tags))
	      (when (string-equal (car item) tag)
		(setq hits (cons (cdr item) hits))))
	    (when hits
	      (cons (car tags) (nreverse hits))))))
    (error nil)))


;; Regexp search.
(defun local-tags-regexp-find (tag &optional syntax)
  "Return matches for tag TAG in current buffer by searching.
Return nil or a cons cell whose car is a list built of the symbol
`goto-char'.  The cdr of the cons is a list of beginning
positions for each buffer line containing a symbol matching TAG.

Optional argument SYNTAX non-nil means don't report matches
within comments or strings."
  ;; TAG must be a symbol according to the current symbol table.
  (let ((regexp (concat "\\_<" (regexp-quote tag) "\\_>"))
	hit hits end state)
    (save-excursion
      (save-restriction
	(widen)
	(goto-char (point-min))
	(while (re-search-forward regexp nil t)
	  ;; Save `match-end' since `syntax-ppss' may clobber it.
	  (setq end (match-end 0))
	  (unless (and syntax
		       (setq state (syntax-ppss end))
		       (or (nth 3 state) (nth 4 state)))
	    (setq hit (line-beginning-position))
	    (unless (and hits (= hit (car hits)))
	      ;; Don't record a hit if we have already recorded its
	      ;; `line-beginning-position'.
	      (setq hits (cons (line-beginning-position) hits))))
	  (goto-char end))))
    (when hits
      ;; Prepend `goto-char' and reverse hits.
      (cons (list 'goto-char) (nreverse hits)))))


;; List tags for current buffer.
(defun local-tags-list (&optional overriding-methods)
  "Return tags for current buffer.
The list of methods tried to find tags is specified by the
variable `local-tags-methods'.  Alternatively, optional argument
`overriding-methods' can be used to specify the list of methods.
Return nil when no tags have been found.  Otherwise, return a
cons whose caar denotes the function to call for going to a tag
and whose cdr is the list of tags returned by the respective
method.  Each entry of that list is a cons cell whose car is the
name of the tag and whose cdr is the location of the tag."
  (interactive)
  ;; Maybe revert buffer.
  (when (and local-tags-revert-buffer
	     (file-exists-p (buffer-file-name))
	     (not (verify-visited-file-modtime (current-buffer))))
    (revert-buffer)) ; Maybe we should preserve modes here?
  (let (tags)
    (catch 'tags
      ;; Run methods until one of them gets us a result.
      (dolist (method local-tags-methods)
	(if tags
	    (throw 'tags t)
	  (setq tags
		(cond
		 ((eq method 'etags)
		  (local-tags-etags-list))
		 ((eq method 'imenu)
		  (local-tags-imenu-list)))))))
    tags))

;; Find matches for a tag in current buffer.
(defun local-tags-find (tag &optional overriding-methods)
  "Return matches for tag TAG in current buffer.
The list of methods tried to find tags is specified by the
variable `local-tags-methods'.  Alternatively, optional argument
`overriding-methods' can be used to speify the list of methods.
Return nil when no matches have been found.  Otherwise, return a
cons whose caar denotes the function to call for going to a
matching location and whose cdr is the list of locations."
  (interactive)
  (let (hits)
    (catch 'hits
      ;; Run methods until one of them gets us a result.
      (dolist (method (or overriding-methods local-tags-methods))
	(if hits
	    (throw 'hits t)
	  (setq hits
		(cond
		 ((eq method 'etags)
		  (local-tags-etags-find tag))
		 ((eq method 'imenu)
		  (local-tags-imenu-find tag))
		 ((eq method 'syntax)
		  (local-tags-regexp-find tag t))
		 ((eq method 'plain)
		  (local-tags-regexp-find tag)))))))
    hits))

(provide 'local-tags)

Unbearably slow editing in .h files (was: patch: add-log.el: changelog find file under point)

[Stefan Monnier]

> The simple approach is based on searching and comparing the result with
> that of `add-log-current-defun'.  It works pretty well most of the time
> but may exhibit the nasty behavior described in

> http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg00443.html

> On my 1 GHz machine this means that I have to wait some 40 secs until
> I'm told that there are no matches.  I can think of two ways to handle
> this: (1) Convince Alan that the behavior of `c-beginning-of-defun' is
> intolerable - AFAICT this has been tried before.  (2) Fix this within
> `add-log-current-defun' to not use `c-beginning-of-defun' - I'm unable
> to do this myself because I completely fail to understand that part of
> the function.

Nowadays, I find myself regularly using M-x fundamental-mode in .h files
in order to be able to edit them sanely.  We have to do something to
fix it.  Alan?


        Stefan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: patch: add-log.el: changelog find file under point

[Juri Linkov]

> The more complicated approach is based on a combination of imenu, etags,
> and regexp searching.  I've put most of this in a separate file called
> local-tags.el merely because it would allow me to fix `which-func-mode'
> and `imenu' as well (both are currently not really useful for c-mode).
> This approach is more reliable and works faster for c-mode files.  It
> requires, however, to have etags installed and working in order to get
> reasonable behavior for c-mode change logs.

The etags approach doesn't seem to me too promising, because
its implementation is unreliable.  But imenu would be useful.
If it doesn't support yet some mode we could improve it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 > The etags approach doesn't seem to me too promising, because
 > its implementation is unreliable.  But imenu would be useful.
 > If it doesn't support yet some mode we could improve it.

Imenu support for c-mode is a pain, have yo ever tried it?  etags is far
superior in this regard.  Anyway, the basic idea of `local-tags' was to
make tags creation customizable on a per-buffer (per-mode) base.  Hence
people should be able to write the appropriate plugins for `cscope' and
`gnu-globals' (neither of them work here) as well.

Re: patch: add-log.el: changelog find file under point

[Juri Linkov]

>> The etags approach doesn't seem to me too promising, because
>> its implementation is unreliable.  But imenu would be useful.
>> If it doesn't support yet some mode we could improve it.
>
> Imenu support for c-mode is a pain, have yo ever tried it?  etags is far
> superior in this regard.  Anyway, the basic idea of `local-tags' was to
> make tags creation customizable on a per-buffer (per-mode) base.  Hence
> people should be able to write the appropriate plugins for `cscope' and
> `gnu-globals' (neither of them work here) as well.

If etags is superior to imenu for parsing C code, maybe we should
provide an option to use etags in imenu too?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 > If etags is superior to imenu for parsing C code, maybe we should
 > provide an option to use etags in imenu too?

That was my idea when I wrote local-tags.el - presently imenu is useless
for C.  It seems, however, that hardly anyone uses imenu (which-func,
speedbar tags, ...) together with C mode - at least on this list.  Hence
we can probably leave things as they are ;-)

Re: patch: add-log.el: changelog find file under point

[Richard Stallman]

    That was my idea when I wrote local-tags.el - presently imenu is useless
    for C.

That is surprising, because it worked in the past.
Can you describe the problem more specifically?
Post a test case?

      It seems, however, that hardly anyone uses imenu (which-func,
    speedbar tags, ...) together with C mode - at least on this list.  Hence
    we can probably leave things as they are ;-)

We don't abandon a combination of features just because it has
a bug.  We fix it!

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 >     That was my idea when I wrote local-tags.el - presently imenu is useless
 >     for C.
 >
 > That is surprising, because it worked in the past.
 > Can you describe the problem more specifically?
 > Post a test case?

Consider the Emacs src directory.  data.c gets me some 100 entries
called "DEFUN", nine called "usage:" and things like "GLOBAL" "in" "nil"
"therefore" "or" (from the ...or (at your option)... header)) "pair"
"zero" in addition to say 20 "useful" entries.  buffer.c gets me some 30
"as" three "element" seven "entry", ...  For these files one out of
three entries created by `imenu-create-index-function' makes sense.
Moreover, I don't know how to make imenu list global variables in a
consistent way or macro definitions but maybe I'm missing something
here.

 >       It seems, however, that hardly anyone uses imenu (which-func,
 >     speedbar tags, ...) together with C mode - at least on this list.  Hence
 >     we can probably leave things as they are ;-)
 >
 > We don't abandon a combination of features just because it has
 > a bug.  We fix it!

We'd have to make imenu aware of Emacs' special "DEFUN" semantics -
probably simple.  We'd have to parse the buffer's syntax in order to
skip matches in comments and strings.  Simple as well, but will slow
down menu generation and additionally hardened by the fact that
`imenu--generic-function' scans the buffer backwards.  Finally, we
should fix variable, macro, enum, union definitions ...

Since no one complained until now I'm not sure whether this should be
done the hard way - `cc-imenu-c++-generic-expression' seems a quite
fragile regexp - so we'll hardly get much feedback when we change this.
It would be far simpler to get tags frome etags and have imenu use them.

Re: patch: add-log.el: changelog find file under point

[Richard Stallman]

    Consider the Emacs src directory.  data.c gets me some 100 entries
    called "DEFUN", nine called "usage:" and things like "GLOBAL" "in" "nil"
    "therefore" "or" (from the ...or (at your option)... header)) "pair"
    "zero" in addition to say 20 "useful" entries.  buffer.c gets me some 30
    "as" three "element" seven "entry", ... 

Thank you for being more specific.  Now the problem is clear:
Imenu for C does not understand the special macros used in Emacs sources.

I am sure this can be fixed with a certain amount of special programming.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 > Now the problem is clear:
 > Imenu for C does not understand the special macros used in Emacs sources.

The fact that imenu doesn't understand special macros is one out of
three aspects I listed (BTW, etags also handles SYSCALL, ENTRY, PSEUDO).
Why did you ignore the remaining ones?

 > I am sure this can be fixed with a certain amount of special programming.

Probably.  But the problem of matches within comments and strings is
more difficult to handle and much more annoying for other sources.  The
most serious problem with using imenu for change-log entries, on the
other hand, is its inability to cleanly report variable and macro
definitions.  With other words: What `add-log-current-defun' gets me is
usually a subset of what etags finds.  It considerably differs from what
imenu reports.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unbearably slow editing in .h files (was: patch: add-log.el: changelog find file under point)

[Alan Mackenzie]

Hello, Stefan and Martin.

On Mon, Feb 18, 2008 at 03:09:42PM -0500, Stefan Monnier wrote:
> > The simple approach is based on searching and comparing the result with
> > that of `add-log-current-defun'.  It works pretty well most of the time
> > but may exhibit the nasty behavior described in

> > http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg00443.html

, whose content is thus:

:Try the following:
:
:  emacs -Q src/lisp.h
:  C-s Fplist_put RET
:  C-x 4 a
:
:you should see Emacs get stuck in an infinite loop (not a bad, one: C-g
:stops it just fine).
:
:
:Stefan
:
:PS: BTW, am I the only one who experiences odd slowdowns when editing
:src/lisp.h, apparently due to font-lock occasionally taking a lot of time
:(like a second or two) to do its job.  Not easy to reproduce, sadly.

It does a lot of cacheing of things; that second or two is filling up
caches, which prevents it from being "reproduced" immediately.  ;-)

> > On my 1 GHz machine this means that I have to wait some 40 secs until
> > I'm told that there are no matches.  I can think of two ways to handle
> > this: (1) Convince Alan that the behavior of `c-beginning-of-defun' is
> > intolerable - AFAICT this has been tried before.

;-)  I think that lisp.h is an ill-conditioned file, in some way.  Or
are you telling me that the slowness happens in a lot of files.h?  The
intolerability could be due to searching for an unnested brace instead
of one at column zero.

(2) Fix this within
> > `add-log-current-defun' to not use `c-beginning-of-defun' - I'm unable
> > to do this myself because I completely fail to understand that part of
> > the function.

What is add-log-current-defun using c-beginning-of-defun for?  How many
times does it call c-b-o-d?  If it's calling it lots of times, why.  OK,
cancel that, I've just had a look at the function (in Emacs-22).  It's
using several sledgehammers to crack some tiny nuts, presumably dating
from the era in which the sledgehammer was the only available tool.  The
bit in add-log-current-defun dealing with C files could usefully use
`c-beginning-of-macro' and, in particular,
`c-where-wrt-to-brace-construct'.

The latter function painstakingly analyses where, in a defun, point is,
returning a value such as 'in-header or 'outwith-function.  It's a
somewhat slow function, is called at the start of every
c-{beginning,end}-of-defun call, and its result is not currently cached.
Using it directly, instead of the five explicit calls to
c-\(beginning\|end\)-of-defun would give a speed up of 5 or 2.5 in C-x 4
a.

> Nowadays, I find myself regularly using M-x fundamental-mode in .h files
> in order to be able to edit them sanely.  We have to do something to
> fix it.  Alan?

Which files.h are you talking about, Stefan?  CC Mode seems to work well
enough for me in my day job (maintaining typical old
"proprietary-quality" C code).  Maybe .../src/lisp.h and one or two
others are somewhat extreme in their use of macros, or something.  A
solution might be to set open-paren-in-column-0-is-defun-start in the
file local variables list, but I can't remember offhand if CC Mode
handles it properly (I suspect it doesn't).
 
>         Stefan

-- 
Alan.

Re: Unbearably slow editing in .h files

[martin rudalics]

Evening Alan,

 > What is add-log-current-defun using c-beginning-of-defun for?

Visit lisp.h, go to the end of the buffer, and do

M-x RET c-beginning-of-defun RET

Convincing?

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

'n Abend, Martin!

On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
> Evening Alan,

> > What is add-log-current-defun using c-beginning-of-defun for?

> Visit lisp.h, go to the end of the buffer, and do

> M-x RET c-beginning-of-defun RET

> Convincing?

Yes, very.  Sadly.  It takes about 18 seconds for me (1.2 GHz Athlon).
However, it is having to analyze over 54kBytes of C source between EOB
and EO-last-defun.  This time is taken up almost fully by the call to
c-where-wrt-to-brace-construct.  Maybe this could be optimised.  Maybe,
on the other hand, it's not reasonable to expect anything faster in this
pathological case.

By comparison, if you do the same in lread.c, it takes much less than a
second.  It may be that the plethora of macros in lisp.h is causing the
delay.

However, there are two problems conflated in this thread.  There's the
slowness in certain C files, and there's the way C-x 4 a calls
c-\(beginning\|end\)-of-defun five times.  Lets separate them!

5 x 18s = 1.5 minutes.  This is the other thing that is slugging C-x 4 a.
add-log-current-defun is _emulating_ c-where-wrt-to-brace-construct, and
emulations tend to be slow.  ;-)

-- 
Alan.

Re: Unbearably slow editing in .h files

[Stefan Monnier]

> ;-)  I think that lisp.h is an ill-conditioned file, in some way.  Or
> are you telling me that the slowness happens in a lot of files.h?

Basically, all .h files, tho clearly the slowdown is proportional to the
distance between point-min and point.

> The intolerability could be due to searching for an unnested brace
> instead of one at column zero.

Could be.  Tho I don't see why it should be so slow, and if it is, then
I'm convinced there's got to be some heuristic we could use to eliminate
the O(N) complexity in practice.
E.g. (re-search-backward "[;}][ \n\t]*\n[^ \t]") combined with
a syntax-ppss check to make sure we're not inside a string/comment/parens.

> Which files.h are you talking about, Stefan?  CC Mode seems to work well
> enough for me in my day job (maintaining typical old
> "proprietary-quality" C code).  Maybe .../src/lisp.h and one or two
> others are somewhat extreme in their use of macros, or something.  A

My machine is not slow, but my Emacs is compiled with a fair bit of
extra debugging checks, so it's equivalent to running on a slow machine.
Still, the slowness is usually unnoticeable.


        Stefan


PS: One other problem with add-log-current-defun is that it does not
recognize function declarations any more (i.e. hitting C-x 4 a
on a line like

  void foo (int);

will fail to find the "foo" to put it in the ChangeLog).  Not sure if
it's related.

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Morning, Stefan!

On Sat, Feb 23, 2008 at 07:37:17PM -0500, Stefan Monnier wrote:
> > ;-)  I think that lisp.h is an ill-conditioned file, in some way.  Or
> > are you telling me that the slowness happens in a lot of files.h?

> Basically, all .h files, tho clearly the slowdown is proportional to
> the distance between point-min and point.

It's not quite as simple as that.  Try loading a large file.c, say
.../src/w32fns.c, then do M-> and C-M-a.  This is instantaneous enough.
But yes, further C-M-a's do become a bit sluggish.  globals_of_w32fns is
spectacularly bad.  OK, there's stuff to fix here.

[ .... ]

> One other problem with add-log-current-defun is that it does not
> recognize function declarations any more (i.e. hitting C-x 4 a on a
> line like

>   void foo (int);

> will fail to find the "foo" to put it in the ChangeLog).  Not sure if
> it's related.

C-x 4 a uses c-\(beginning\|end\)-of-defun.  @dfn{defuns} in CC Mode are
currently top-level structures containing a brace block.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Unbearably slow editing in .h files

[martin rudalics]

 > Yes, very.  Sadly.  It takes about 18 seconds for me (1.2 GHz Athlon).
 > However, it is having to analyze over 54kBytes of C source between EOB
 > and EO-last-defun.  This time is taken up almost fully by the call to
 > c-where-wrt-to-brace-construct.  Maybe this could be optimised.  Maybe,
 > on the other hand, it's not reasonable to expect anything faster in this
 > pathological case.

I think `c-beginning-of-defun' should also report an error within
reasonable time when defuns are malformed.  How about providing some
`c-fast-beginning-of-defun' mechanism which might not be able to cater
with all possible ways to write a defun but is reasonably fast for
well-written ones?

 > By comparison, if you do the same in lread.c, it takes much less than a
 > second.  It may be that the plethora of macros in lisp.h is causing the
 > delay.

The plain idea of potentially scanning the entire buffer backwards is
tantalizing.  There should be some way to avoid that.

 > However, there are two problems conflated in this thread.  There's the
 > slowness in certain C files, and there's the way C-x 4 a calls
 > c-\(beginning\|end\)-of-defun five times.  Lets separate them!
 >
 > 5 x 18s = 1.5 minutes.  This is the other thing that is slugging C-x 4 a.
 > add-log-current-defun is _emulating_ c-where-wrt-to-brace-construct, and
 > emulations tend to be slow.  ;-)

Sure.  I already mentioned in this thread that I fail to understand how
`add-log-current-defun' is organized.  The problem is: Changing that
function may implicitly alter the way change logs entries get written.
This could go on - for some time - unnoticed and lead to considerable
confusions afterwards.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unbearably slow editing in .h files

[Andreas Schwab]

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

> PS: One other problem with add-log-current-defun is that it does not
> recognize function declarations any more (i.e. hitting C-x 4 a
> on a line like
>
>   void foo (int);
>
> will fail to find the "foo" to put it in the ChangeLog).

Did it ever do that?  I don't think add-log-current-defun is supposed to
refer to declarations in the first place.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unbearably slow editing in .h files

[Stefan Monnier]

>> PS: One other problem with add-log-current-defun is that it does not
>> recognize function declarations any more (i.e. hitting C-x 4 a
>> on a line like
>> 
>> void foo (int);
>> 
>> will fail to find the "foo" to put it in the ChangeLog).

> Did it ever do that?

Indeed, it seems it didn't do it in Emacs-21 either.  For some reason
this has started to bother me only recently.

> I don't think add-log-current-defun is supposed to
> refer to declarations in the first place.

Why not.  When we make a change to (or add/remove) a declaration, we
usually mention it in the ChangeLog, so C-x 4 a should ideally pick
it up.


        Stefan

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Hi, Stefan!

On Sun, Feb 24, 2008 at 08:49:26AM -0500, Stefan Monnier wrote:
> >> PS: One other problem with add-log-current-defun is that it does not
> >> recognize function declarations any more (i.e. hitting C-x 4 a on a
> >> line like

> >> void foo (int);

> >> will fail to find the "foo" to put it in the ChangeLog).

> > Did it ever do that?

> Indeed, it seems it didn't do it in Emacs-21 either.  For some reason
> this has started to bother me only recently.

> > I don't think add-log-current-defun is supposed to refer to
> > declarations in the first place.

> Why not.  When we make a change to (or add/remove) a declaration, we
> usually mention it in the ChangeLog, so C-x 4 a should ideally pick it
> up.

No reason why not; it just needs Somebody (tm) to write it.  Stefan?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Unbearably slow editing in .h files

[Jason Rumney]

Alan Mackenzie wrote:
> It's not quite as simple as that.  Try loading a large file.c, say
> .../src/w32fns.c, then do M-> and C-M-a.  This is instantaneous enough.
> But yes, further C-M-a's do become a bit sluggish.  globals_of_w32fns is
> spectacularly bad.  OK, there's stuff to fix here.
>   
There is something weird with globals_of_w32fns though, it used to be 
the case that add-change-log-entry within that function would not pick 
up the function name. I haven't tried it lately, so it may have changed.

Re: patch: add-log.el: changelog find file under point

[Richard Stallman]

    The fact that imenu doesn't understand special macros is one out of
    three aspects I listed (BTW, etags also handles SYSCALL, ENTRY, PSEUDO).
    Why did you ignore the remaining ones?

That is the only one I understood.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: patch: add-log.el: changelog find file under point

[Richard Stallman]

    The fact that imenu doesn't understand special macros is one out of
    three aspects I listed (BTW, etags also handles SYSCALL, ENTRY, PSEUDO).
    Why did you ignore the remaining ones?

That is the only one I clearly understood.  I don't entirely
understand the issue of strings and comments, but it strikes me that
maybe those comments are part of the DEFUN contruct.  Comments don't
usually cause a problem because the text is inside them is indented at
least a little.  The exception is the comment in a DEFUN that really
specifies the doc string.

If that's the case where comments cause a problem, handling DEFUN
properly would solve that problem too.

I have no idea what the other issue is.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unbearably slow editing in .h files

[Stefan Monnier]

> It just needs Somebody (tm) to write it.  Stefan?

Yeah, right, and next thing you know I get sued for
trademark infringement?  No thanks,


        Stefan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unbearably slow editing in .h files

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 14:46:00 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: bug-cc-mode@gnu.org, martin rudalics <rudalics@gmx.at>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> There is something weird with globals_of_w32fns though, it used to be 
> the case that add-change-log-entry within that function would not pick 
> up the function name. I haven't tried it lately, so it may have changed.

"C-x 4 a" in that function does TRT now.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unbearably slow editing in .h files

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 08:39:50 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: bug-cc-mode@gnu.org, martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
> 
> Try loading a large file.c, say
> .../src/w32fns.c, then do M-> and C-M-a.  This is instantaneous enough.
> But yes, further C-M-a's do become a bit sluggish.  globals_of_w32fns is
> spectacularly bad.

I don't see any particular sluggishness in that file or that function.
In what version of Emacs do you see this?

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

On Sun, Feb 24, 2008 at 10:42:58AM -0500, Stefan Monnier wrote:
> > It just needs Somebody (tm) to write it.  Stefan?

> Yeah, right, and next thing you know I get sued for
> trademark infringement?  No thanks,

:-).  Maybe I'll have a look at it myself, sometime.

>         Stefan

-- 
Alan.

Re: Unbearably slow editing in .h files

[Richard Stallman]

    > I don't think add-log-current-defun is supposed to
    > refer to declarations in the first place.

    Why not.  When we make a change to (or add/remove) a declaration, we
    usually mention it in the ChangeLog, so C-x 4 a should ideally pick
    it up.

All else being equal, this feature would be good.  But I suspect it
may be hard, and I think it is not worth a lot of work.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 > That is the only one I clearly understood.  I don't entirely
 > understand the issue of strings and comments, but it strikes me that
 > maybe those comments are part of the DEFUN contruct.  Comments don't
 > usually cause a problem because the text is inside them is indented at
 > least a little.  The exception is the comment in a DEFUN that really
 > specifies the doc string.

Many of them are, indeed.

 > If that's the case where comments cause a problem, handling DEFUN
 > properly would solve that problem too.

We can hardly skip the associated comment with the help of a regexp.

 > I have no idea what the other issue is.

Take the following line:

static int foo; /* bar (silly) */

The tag imenu gets me is `bar' not `foo'.

Re: Unbearably slow editing in .h files

[Stefan Monnier]

>> I don't think add-log-current-defun is supposed to
>> refer to declarations in the first place.

>     Why not.  When we make a change to (or add/remove) a declaration, we
>     usually mention it in the ChangeLog, so C-x 4 a should ideally pick
>     it up.

> All else being equal, this feature would be good.  But I suspect it
> may be hard, and I think it is not worth a lot of work.

Agreed.


        Stefan

Re: patch: add-log.el: changelog find file under point

[Richard Stallman]

     > If that's the case where comments cause a problem, handling DEFUN
     > properly would solve that problem too.

    We can hardly skip the associated comment with the help of a regexp.

Using a regexp is just one of the methods Imenu supports.
This would need special-purpose Lisp code, but it isn't very hard.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: patch: add-log.el: changelog find file under point

[martin rudalics]

 > Using a regexp is just one of the methods Imenu supports.
 > This would need special-purpose Lisp code, but it isn't very hard.

Using a function would be much better but require a complete redesign of
imenu support for c-mode.  Also note that currently
`cc-imenu-objc-generic-expression' depends on
`cc-imenu-c++-generic-expression', hence we would have to decide about
the former as well.

So far I added the following to `cc-imenu-c++-generic-expression':

     (nil
      ,(concat
        "DEFUN[ \t]*(\"[" c-alnum "-]+\",[ \t]*"
        "\\([" c-alnum "_]+\\),[ \t]*[" c-alnum "_]+,[ \t\n]+"
        "\\(?:[ \t]*[0-9]+,\\)*\n"
        "[ \t]*doc:[ \t]*/\\*"
        "\\(?:[^*]+\\|\\*[^/]+\\)\\*/"
        "[ \t]*)") 1)

This gets me a list of all Fcons, Flist, ... names provided they have
been written well.  It does _not_ remove the DEFUN entries and it does
_not_ remove the entries in comments.  A major cuplrit is the

        "[^()\n]*"                             ; no parentheses before

line in `cc-imenu-c++-generic-expression' which is supposed to avoid
leading parens.  Obviously, this expression matches anything on a line
if only the remainder of the line matches something like a function
definition.  Removing this line helps to redeem the problem.


It doesn't help in the following cases:

(1) Commented-out code.

(2) Comments starting at bol.  Even if an item is in a doc-string of a
DEFUN it will be listed since the very nature of imenu regexp
specifications means the DEFUN scan and that for normal functions are
separate (with DEFUNs imenu will scan C-mode buffers up to six times).
The latter scan _will_ report any function definition found on the bol
of a doc-string handled by the former.

(3) Strings starting at bol (you can see some nasty implications of this
by running imenu on lib-src/etags.c).

(4) An expression at bol like "while (0)" (you can find one in buffer.h,
lisp.h, search.c, a couple in ccl.c).

Using a function for Imenu + `syntax-ppss' could help us get rid of
problems (1)-(3).  It could also help to not list defs with leading
parens.  Things like (4) can then be either considered bad style or
could be handled by applying certain heuristics.

Writing a function obviously doesn't get me

- macros like #define ...

- type definitions like typedef union Lisp_Object

- enumerations like enum Lisp_Type

and many more automatically.  All these are used in change-log entries
and not finding them via imenu makes it hardly worth the effort to run
imenu in the first place.  (Please recall: This thread started out as
finding a definiton from a corresponding change log entry.)

Adding these would mostly require to reinvent things that have been
written and validated in etags before.

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Hi, Martin and Stefan,

On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
> Evening Alan,

> > What is add-log-current-defun using c-beginning-of-defun for?

> Visit lisp.h, go to the end of the buffer, and do

> M-x RET c-beginning-of-defun RET

> Convincing?

I have just fixed this problem (I hope!) in both the Emacs-22 branch and
the trunk.  Basically, the contorted functionality in add-log.el has
been superseded by optimised routines in cc-cmds.el.

On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4 seconds at the
end of lisp.h, in the trunk.  It's somewhat faster in the Emacs-22
branch, but I don't know why.

I think this is fast enough.

-- 
Alan Mackenzie (Nuremberg, Germany).
 

Re: Unbearably slow editing in .h files

[Dan Nicolaescu]

Alan Mackenzie <acm@muc.de> writes:

  > Hi, Martin and Stefan,
  > 
  > On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
  > > Evening Alan,
  > 
  > > > What is add-log-current-defun using c-beginning-of-defun for?
  > 
  > > Visit lisp.h, go to the end of the buffer, and do
  > 
  > > M-x RET c-beginning-of-defun RET
  > 
  > > Convincing?
  > 
  > I have just fixed this problem (I hope!) in both the Emacs-22 branch and
  > the trunk.  Basically, the contorted functionality in add-log.el has
  > been superseded by optimised routines in cc-cmds.el.
  > 
  > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4 seconds at the
  > end of lisp.h, in the trunk.  It's somewhat faster in the Emacs-22
  > branch, but I don't know why.
  > 
  > I think this is fast enough.

Can it be faster?  Might sound like a joke, but it's a serious question.

`diff-add-change-log-entries-other-window' uses this (calls it once per
diff hunk), and it is nice to let it run on largish diff buffers to
quickly produce a skeleton for a ChangeLog .
Is the slowdown still caused by the fact that is hard to distinguish a
K&R functions from variable declarations? 

Thanks

        --dan

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Hi, Dan!

On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:
> Alan Mackenzie <acm@muc.de> writes:

>   > Hi, Martin and Stefan,

>   > On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
>   > > Evening Alan,

>   > > > What is add-log-current-defun using c-beginning-of-defun for?

>   > > Visit lisp.h, go to the end of the buffer, and do

>   > > M-x RET c-beginning-of-defun RET

>   > > Convincing?

>   > I have just fixed this problem (I hope!) in both the Emacs-22
>   > branch and the trunk.  Basically, the contorted functionality in
>   > add-log.el has been superseded by optimised routines in cc-cmds.el.

>   > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4 seconds at
>   > the end of lisp.h, in the trunk.  It's somewhat faster in the
>   > Emacs-22 branch, but I don't know why.

>   > I think this is fast enough.

> Can it be faster?  Might sound like a joke, but it's a serious
> question.

Just to clarify, that 4 seconds is in the extreme case (lisp.h) that
brought the problem to light.  In a typical case, the action is
"instantaneous".  When finding (or failing to find) a function name, the
new implementation is more than an order of magnitude faster than the
old.  For a macro name, it takes about as long as the old.

> `diff-add-change-log-entries-other-window' uses this (calls it once per
> diff hunk), and it is nice to let it run on largish diff buffers to
> quickly produce a skeleton for a ChangeLog .

Hey, I didn't know you could do this.  Thanks for telling me!  :-)
(Actually, until I looked at this bug report, I didn't realise you could
do C-x 4 a in an elisp or C file - I thought it would only work when done
in ChangeLog itself.)

> Is the slowdown still caused by the fact that is hard to distinguish a
> K&R functions from variable declarations? 

Again, it's a massive speedup, not a slowdown.  Isn't it?  To the extent
that it's still slower than it might be, yes it's the K&R stuff making it
slow.  The function which takes time is c-in-knr-argdecl (cc-engine.el,
~L6317).  Actually, this function gets called twice.  It would take a lot
of refactoring to make it get called only once.

> Thanks

>         --dan

-- 
Alan.

Re: Unbearably slow editing in .h files

[Dan Nicolaescu]

Alan Mackenzie <acm@muc.de> writes:

  > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:
  > > Alan Mackenzie <acm@muc.de> writes:
  > 
  > >   > Hi, Martin and Stefan,
  > 
  > >   > On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
  > >   > > Evening Alan,
  > 
  > >   > > > What is add-log-current-defun using c-beginning-of-defun for?
  > 
  > >   > > Visit lisp.h, go to the end of the buffer, and do
  > 
  > >   > > M-x RET c-beginning-of-defun RET
  > 
  > >   > > Convincing?
  > 
  > >   > I have just fixed this problem (I hope!) in both the Emacs-22
  > >   > branch and the trunk.  Basically, the contorted functionality in
  > >   > add-log.el has been superseded by optimised routines in cc-cmds.el.
  > 
  > >   > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4 seconds at
  > >   > the end of lisp.h, in the trunk.  It's somewhat faster in the
  > >   > Emacs-22 branch, but I don't know why.
  > 
  > >   > I think this is fast enough.
  > 
  > > Can it be faster?  Might sound like a joke, but it's a serious
  > > question.
  > 
  > Just to clarify, that 4 seconds is in the extreme case (lisp.h) that
  > brought the problem to light.  In a typical case, the action is
  > "instantaneous".  When finding (or failing to find) a function name, the
  > new implementation is more than an order of magnitude faster than the
  > old.  For a macro name, it takes about as long as the old.
  > 
  > > `diff-add-change-log-entries-other-window' uses this (calls it once per
  > > diff hunk), and it is nice to let it run on largish diff buffers to
  > > quickly produce a skeleton for a ChangeLog .
  > 
  > Hey, I didn't know you could do this.  Thanks for telling me!  :-)
  > (Actually, until I looked at this bug report, I didn't realise you could
  > do C-x 4 a in an elisp or C file - I thought it would only work when done
  > in ChangeLog itself.)

Note that `diff-add-change-log-entries-other-window'  is C-x 4 A not C-x 4 a, 
it is the equivalent of:
FOR each hunk in a diff DO
    C-x 4 a

When used on a diff buffer with thousands of lines, it is a bit slow.

  > > Is the slowdown still caused by the fact that is hard to distinguish a
  > > K&R functions from variable declarations? 
  > 
  > Again, it's a massive speedup, not a slowdown.  Isn't it?  

Sorry, I was referring to the fact slowdown cause by K&R checks, not your patch.

  > To the extent that it's still slower than it might be, yes it's the
  > K&R stuff making it slow.  The function which takes time is
  > c-in-knr-argdecl (cc-engine.el, ~L6317).  Actually, this function
  > gets called twice.  It would take a lot of refactoring to make it
  > get called only once.

What if it's not called at all?  After all, the vast majority of the
users never edit K&R.  Just a thought...

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Hi, Dan!

On Thu, Apr 03, 2008 at 06:10:40AM -0700, Dan Nicolaescu wrote:
> Alan Mackenzie <acm@muc.de> writes:

>   > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:

>   > > Alan Mackenzie <acm@muc.de> writes:
>   > >   > I have just fixed this problem (I hope!) in both the Emacs-22
>   > >   > branch and the trunk.  Basically, the contorted functionality
>   > >   > in add-log.el has been superseded by optimised routines in
>   > >   > cc-cmds.el.

>   > >   > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4
>   > >   > seconds at the end of lisp.h, in the trunk.  It's somewhat
>   > >   > faster in the Emacs-22 branch, but I don't know why.

>   > >   > I think this is fast enough.

>   > > Can it be faster?  Might sound like a joke, but it's a serious
>   > > question.

>   > Just to clarify, that 4 seconds is in the extreme case (lisp.h)
>   > that brought the problem to light.  In a typical case, the action
>   > is "instantaneous".  When finding (or failing to find) a function
>   > name, the new implementation is more than an order of magnitude
>   > faster than the old.  For a macro name, it takes about as long as
>   > the old.

>   > > `diff-add-change-log-entries-other-window' uses this (calls it
>   > > once per diff hunk), and it is nice to let it run on largish diff
>   > > buffers to quickly produce a skeleton for a ChangeLog .

>   > Hey, I didn't know you could do this.  Thanks for telling me!  :-)
>   > (Actually, until I looked at this bug report, I didn't realise you
>   > could do C-x 4 a in an elisp or C file - I thought it would only
>   > work when done in ChangeLog itself.)

> Note that `diff-add-change-log-entries-other-window'  is C-x 4 A not
> C-x 4 a, it is the equivalent of:
> FOR each hunk in a diff DO
>     C-x 4 a

Wow!  I've just tried this.  It's amazing!  There are one or two things
in it which aren't quite right, though.

> When used on a diff buffer with thousands of lines, it is a bit slow.

Hmmm.  I've only tried it on diffs with elisp files.  That was a little
slow.  Do you mean it's _very_ slow with C file diffs?  Can you give some
numbers here?  Processor speed, size of diff file, time it takes.  But
then again, people are only going to be using it once or twice per patch
(and then having to fill out the result by hand), so it is surely not
that critical.  But if it were taking 20 minutes rather than 45 seconds,
that would be too slow, I agree.

>   > > Is the slowdown still caused by the fact that is hard to distinguish a
>   > > K&R functions from variable declarations? 

>   > Again, it's a massive speedup, not a slowdown.  Isn't it?  

> Sorry, I was referring to the fact slowdown cause by K&R checks, not
> your patch.

I'd be very interested to here how much faster C-x 4 A has become as a
result of this patch and my patch on Friday 2008-03-07 to cc-engine.el.

>   > To the extent that it's still slower than it might be, yes it's the
>   > K&R stuff making it slow.  The function which takes time is
>   > c-in-knr-argdecl (cc-engine.el, ~L6317).  Actually, this function
>   > gets called twice.  It would take a lot of refactoring to make it
>   > get called only once.

> What if it's not called at all?  After all, the vast majority of the
> users never edit K&R.  Just a thought...

Well, one set of users who still use K&R is the Emacs development team.
;-)  It would be possible, and very easy, to make K&R a user option.  But
I don't think that's the right thing to do.

The overhead that K&R imposes on C-M-a and C-x 4 a is not _that_ high,
and it will diminish as processors continue to get faster.  I recently
put in a hard-coded limit to the number of parameter declarations in a
K&R section.  That limit is currently 20. 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Unbearably slow editing in .h files

[Dan Nicolaescu]

Alan Mackenzie <acm@muc.de> writes:

  > On Thu, Apr 03, 2008 at 06:10:40AM -0700, Dan Nicolaescu wrote:
  > > Alan Mackenzie <acm@muc.de> writes:
  > 
  > >   > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:
  > 
  > >   > > Alan Mackenzie <acm@muc.de> writes:
  > >   > >   > I have just fixed this problem (I hope!) in both the Emacs-22
  > >   > >   > branch and the trunk.  Basically, the contorted functionality
  > >   > >   > in add-log.el has been superseded by optimised routines in
  > >   > >   > cc-cmds.el.
  > 
  > >   > >   > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4
  > >   > >   > seconds at the end of lisp.h, in the trunk.  It's somewhat
  > >   > >   > faster in the Emacs-22 branch, but I don't know why.
  > 
  > >   > >   > I think this is fast enough.
  > 
  > >   > > Can it be faster?  Might sound like a joke, but it's a serious
  > >   > > question.
  > 
  > >   > Just to clarify, that 4 seconds is in the extreme case (lisp.h)
  > >   > that brought the problem to light.  In a typical case, the action
  > >   > is "instantaneous".  When finding (or failing to find) a function
  > >   > name, the new implementation is more than an order of magnitude
  > >   > faster than the old.  For a macro name, it takes about as long as
  > >   > the old.
  > 
  > >   > > `diff-add-change-log-entries-other-window' uses this (calls it
  > >   > > once per diff hunk), and it is nice to let it run on largish diff
  > >   > > buffers to quickly produce a skeleton for a ChangeLog .
  > 
  > >   > Hey, I didn't know you could do this.  Thanks for telling me!  :-)
  > >   > (Actually, until I looked at this bug report, I didn't realise you
  > >   > could do C-x 4 a in an elisp or C file - I thought it would only
  > >   > work when done in ChangeLog itself.)
  > 
  > > Note that `diff-add-change-log-entries-other-window'  is C-x 4 A not
  > > C-x 4 a, it is the equivalent of:
  > > FOR each hunk in a diff DO
  > >     C-x 4 a
  > 
  > Wow!  I've just tried this.  It's amazing!  There are one or two things
  > in it which aren't quite right, though.

Yep, it should not generate duplicate entries.
One possible improvement is that it should iterate at a lower
granularity than a hunk, some hunks have changes ! + and - changes.
(but that's still not enough, a + hunk could be adding 5 functions...)

  > > When used on a diff buffer with thousands of lines, it is a bit slow.
  > 
  > Hmmm.  I've only tried it on diffs with elisp files.  That was a little
  > slow.  Do you mean it's _very_ slow with C file diffs?  Can you give some
  > numbers here?  Processor speed, size of diff file, time it takes.  

Unfortunately I don't have any massive patches handy, so I can't test
now how much things have improved for exactly the things that had
problems before.  But some quick tests with the diff for lisp.h revision
1.606 (i.e. something that had a long ChangeLog entry, 625 lines
unidiff) showed that things have improved quite a lot today vs a > 1
month old emacs (a few seconds vs > 2 minutes).
Which is great. Thanks!

Trying C-x 4 A on a 4-5000 lines patch would be more interesting...

  > But then again, people are only going to be using it once or twice
  > per patch (and then having to fill out the result by hand), so it is
  > surely not that critical.  But if it were taking 20 minutes rather
  > than 45 seconds, that would be too slow, I agree.

Ideally in the future C-x 4 A should be done automatically when doing a
checkin, that why it is important to be as fast as possible.


  > >   > > Is the slowdown still caused by the fact that is hard to distinguish a
  > >   > > K&R functions from variable declarations? 
  > 
  > >   > Again, it's a massive speedup, not a slowdown.  Isn't it?  
  > 
  > > Sorry, I was referring to the fact slowdown cause by K&R checks, not
  > > your patch.
  > 
  > I'd be very interested to here how much faster C-x 4 A has become as a
  > result of this patch and my patch on Friday 2008-03-07 to cc-engine.el.

See above.

  > >   > To the extent that it's still slower than it might be, yes it's the
  > >   > K&R stuff making it slow.  The function which takes time is
  > >   > c-in-knr-argdecl (cc-engine.el, ~L6317).  Actually, this function
  > >   > gets called twice.  It would take a lot of refactoring to make it
  > >   > get called only once.
  > 
  > > What if it's not called at all?  After all, the vast majority of the
  > > users never edit K&R.  Just a thought...
  > 
  > Well, one set of users who still use K&R is the Emacs development team.
  > ;-)  

Yeah, and many people wish that would change at some point.  But that a
separate discussion that we should get into now.

  > It would be possible, and very easy, to make K&R a user option.  But
  > I don't think that's the right thing to do.
  >
  > The overhead that K&R imposes on C-M-a and C-x 4 a is not _that_ high,
  > and it will diminish as processors continue to get faster.  I recently
  > put in a hard-coded limit to the number of parameter declarations in a
  > K&R section.  That limit is currently 20. 

Just exploring options here...
Would simply ignoring K&R for the purpose or running C-x 4 a  work?
Yes, it might generate the wrong name in the ChangeLog entry in some
very limited cases (is that true?), but that's not very critical.

Re: Unbearably slow editing in .h files

[Alan Mackenzie]

Hi, again!

On Thu, Apr 03, 2008 at 08:22:10AM -0700, Dan Nicolaescu wrote:
> Alan Mackenzie <acm@muc.de> writes:

>   > On Thu, Apr 03, 2008 at 06:10:40AM -0700, Dan Nicolaescu wrote:
>   > > Alan Mackenzie <acm@muc.de> writes:

>   > >   > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:

>   > > Note that `diff-add-change-log-entries-other-window'  is C-x 4 A not
>   > > C-x 4 a, it is the equivalent of:
>   > > FOR each hunk in a diff DO
>   > >     C-x 4 a

>   > Wow!  I've just tried this.  It's amazing!  There are one or two
>   > things in it which aren't quite right, though.

> Yep, it should not generate duplicate entries.  One possible
> improvement is that it should iterate at a lower granularity than a
> hunk, some hunks have changes ! + and - changes.  (but that's still not
> enough, a + hunk could be adding 5 functions...)

I tried it (with a window configuration I can't remember exactly) and
ChangeLog ended up in both the upper and lower windows.  But that's for
another thread.  ;-)

>   > > When used on a diff buffer with thousands of lines, it is a bit
>   > > slow.

>   > Hmmm.  I've only tried it on diffs with elisp files.  That was a
>   > little slow.  Do you mean it's _very_ slow with C file diffs?  Can
>   > you give some numbers here?  Processor speed, size of diff file,
>   > time it takes.  

> Unfortunately I don't have any massive patches handy, so I can't test
> now how much things have improved for exactly the things that had
> problems before.  But some quick tests with the diff for lisp.h
> revision 1.606 (i.e. something that had a long ChangeLog entry, 625
> lines unidiff) showed that things have improved quite a lot today vs a
> > 1 month old emacs (a few seconds vs > 2 minutes).  Which is great.
> Thanks!

:-)

> Trying C-x 4 A on a 4-5000 lines patch would be more interesting...

Yes.

>   > But then again, people are only going to be using it once or twice
>   > per patch (and then having to fill out the result by hand), so it
>   > is surely not that critical.  But if it were taking 20 minutes
>   > rather than 45 seconds, that would be too slow, I agree.

> Ideally in the future C-x 4 A should be done automatically when doing a
> checkin, that why it is important to be as fast as possible.

I'm not sure I agree, here.  That might make it far too easy for people
to forget (or even to "forget") to write commit comments.

>   > >   > To the extent that it's still slower than it might be, yes
>   > >   > it's the K&R stuff making it slow.  The function which takes
>   > >   > time is c-in-knr-argdecl (cc-engine.el, ~L6317).  Actually,
>   > >   > this function gets called twice.  It would take a lot of
>   > >   > refactoring to make it get called only once.

>   > > What if it's not called at all?  After all, the vast majority of
>   > > the users never edit K&R.  Just a thought...

>   > Well, one set of users who still use K&R is the Emacs development
>   > team.  ;-)  

> Yeah, and many people wish that would change at some point.  But that a
> separate discussion that we should get into now.

I'm not sure why we don't just change all the K&R declarations to ANSI
ones.  It could probably be done simply enough with a script (awk, perl,
python, Emacs Lisp, or anything else).

>   > It would be possible, and very easy, to make K&R a user option.
>   > But I don't think that's the right thing to do.

>   > The overhead that K&R imposes on C-M-a and C-x 4 a is not _that_
>   > high, and it will diminish as processors continue to get faster.  I
>   > recently put in a hard-coded limit to the number of parameter
>   > declarations in a K&R section.  That limit is currently 20. 

> Just exploring options here...
> Would simply ignoring K&R for the purpose of running C-x 4 a  work?

No.  You're at the opening brace of a C function/typedef/struct; you've
got, somehow, to get from there to the function name.  That involves
jumping backwards over the K&R region, should it be present.  Or, point
starts out _outside_ a brace block.  You've got to decide whether it's
inside a function/typedef/struct header, and this might be the K&R
region.

> Yes, it might generate the wrong name in the ChangeLog entry in some
> very limited cases (is that true?), .....

I doubt it.  I think it would foul up with _every_ K&R function
declaration.  To try it out, set the major mode to C++ mode, then try
C-M-a or C-x 4 a.  In fact, in xdisp.c, I've just done this, gone to EOB
and typed C-M-a 25 times.  It got BOD OK 8 times, failed 17 times.

> ...., but that's not very critical.

I think it would be.  It would only need to happen to a hacker once, and
he would lose all confidence in it.  He would then feel obliged to check
every entry by hand - and the complaints would find their way to
bug-cc-mode@gnu.org.  ;-(

-- 
Alan Mackenzie (Nuremberg, Germany).