change-log-goto-source: recognising . within tag names

change-log-goto-source: recognising . within tag names

[Stephen Eglen]

change-log-goto-source is a great function for finding the definition of
a function mentioned in a changelog.  I'm looking for some help though
getting it to work recognising tags in the language R (a popular
statistics environment).  In R, function names are often include the
period character, e.g. t.test().  When using change-log-goto-source on
these kinds of tags, the correct tag is not found because . is of the
syntax class 'punctuation', and it looks to me like the tags must be made
of  elements of syntax class 'word'.

This is also a problem in lisp, as it seems . can be used within lisp
defuns (but not used in practice I think):

(defun test1 (x)
  "Test version 1."
  t)

(defun test.2 (x)
  "Test version 2."
  nil)

(defun test3 (x)
  "Test version 3."
  t)

with the corresponding Changelog

2009-03-20  Stephen Eglen  <stephen@gnu.org>

	* simple.el (test1): New function.
	(test.2): new function.
	(test3): new function.


C-c C-c works when point is on test1 and test3, but not test2.

How to fix this?  I tried changing the regexp, but this didn't work:

(defconst change-log-tag-re
  "(\\(\\(?:\\sw\\|\\s_\\|\\.\\)+\\(?:[, \t]+\\(?:\\sw\\|\\s_\\|\\.\\)+\\)*\\))"
  "Regexp matching a tag name in change log entries.")

Apart from lisp and R, I'm not sure which other languages use . in
function names.

best wishes, Stephen

Re: change-log-goto-source: recognising . within tag names

[martin rudalics]

 > change-log-goto-source is a great function for finding the definition of
 > a function mentioned in a changelog.  I'm looking for some help though
 > getting it to work recognising tags in the language R (a popular
 > statistics environment).  In R, function names are often include the
 > period character, e.g. t.test().  When using change-log-goto-source on
 > these kinds of tags, the correct tag is not found because . is of the
 > syntax class 'punctuation', and it looks to me like the tags must be made
 > of  elements of syntax class 'word'.

`word' or `symbol'.

 > How to fix this?  I tried changing the regexp, but this didn't work:
 >
 > (defconst change-log-tag-re
 >   "(\\(\\(?:\\sw\\|\\s_\\|\\.\\)+\\(?:[, \t]+\\(?:\\sw\\|\\s_\\|\\.\\)+\\)*\\))"
 >   "Regexp matching a tag name in change log entries.")

This won't be sufficient because `find-tag-default' (which is called by
`change-log-search-tag-name-1') also works on symbols only and
`change-log-mode' is derived from `text-mode' :-(

I'm afraid `change-log-search-tag-name' is too clever when trying to
find a suitable tag.  Usually, it seems sufficient to search for the
previous and next property change of the `change-log-list' text property
near `point' and return the corresponding string.  Maybe we should
provide a `change-log-search-tag-name-function' people could set to do
the job.  Or, simply set the `syntax-table' text property to `symbol'
for periods preceded _and_ followed by word/symbol characters.

martin

change-log-goto-source: recognising . within tag names

[Bob Rogers]

   From: martin rudalics <rudalics@gmx.at>
   Date: Fri, 20 Mar 2009 20:48:47 +0100

   . . .

   I'm afraid `change-log-search-tag-name' is too clever when trying to
   find a suitable tag.  Usually, it seems sufficient to search for the
   previous and next property change of the `change-log-list' text property
   near `point' and return the corresponding string.  Maybe we should
   provide a `change-log-search-tag-name-function' people could set to do
   the job.  Or, simply set the `syntax-table' text property to `symbol'
   for periods preceded _and_ followed by word/symbol characters.

   martin

A simple fix would be to find the file name first, read it into a buffer
(since we'll need it anyway), and then use its syntax table to parse the
tag name.  The code below is a start at this; it seems to work.  But it
would have to be integrated with the change-log-goto-source logic that
finds both the file at point and the file near the tag and then picks
the best one.  The logic seems rather obscure; I suspect I would break
it if I tried to change it.  ;-}

   ================
   From: Stephen Eglen <S.J.Eglen@damtp.cam.ac.uk>
   Date: Fri, 20 Mar 2009 10:22:42 +0000

   . . .

   This is also a problem in lisp, as it seems . can be used within lisp
   defuns (but not used in practice I think) . . .

As a matter of fact, lisp/ChangeLog.12 (and probably others) contain
elisp names with dots such as newsticker--parse-rss-1.0, which is why I
used this particular change log for testing.

   For Lisp in particular, the problem is actually fairly broad, as
people often use "+", "*", "$", "%", etc., to distinguish certain
definition names.  A better solution might be to ask the language mode
itself to do the name parsing, in order to handle such things as name
quoting conventions.  But, of course, that's a much bigger job.

					-- Bob Rogers
					   http://www.rgrjr.com/

------------------------------------------------------------------------
(defun change-log-file-and-tag ()
  ;; Find the nearest file first, then use that file's syntax table to
  ;; find the tag.
  (interactive)
  (let ((file (change-log-search-file-name (point))))
    (if file
	(let* ((buffer (find-file-noselect file))
	       (tag (with-syntax-table (with-current-buffer buffer
					 (syntax-table))
		      (change-log-search-tag-name))))
	  (message "file %S tag %S" file tag)
	  (list file tag)))))

Re: change-log-goto-source: recognising . within tag names

[martin rudalics]

 > A simple fix would be to find the file name first, read it into a buffer
 > (since we'll need it anyway), and then use its syntax table to parse the
 > tag name.  The code below is a start at this; it seems to work.  But it
 > would have to be integrated with the change-log-goto-source logic that
 > finds both the file at point and the file near the tag and then picks
 > the best one.  The logic seems rather obscure; I suspect I would break
 > it if I tried to change it.  ;-}

Because I look for the nearest tag first and "the file matching the tag"
afterwards.  The idea behind that logic was to do something reasonable
regardless of the current position of `point' within a ChangeLog entry.
As mentioned earlier that's far too clever.  Users _should_ care a bit
about from where they want to invoke that function.  I think it would be
better to make `change-log-list' entries mousable and and provide the
goto-source facility iff `point' is on such an entry.  In that case your
"use the syntax-table of the source file approach" would fit perfectly.

 >    For Lisp in particular, the problem is actually fairly broad, as
 > people often use "+", "*", "$", "%", etc., to distinguish certain
 > definition names.  A better solution might be to ask the language mode
 > itself to do the name parsing, in order to handle such things as name
 > quoting conventions.  But, of course, that's a much bigger job.

It's less the question of a "bigger job" but that of providing some
standard interface for language modes.  That is, I pass you a string (or
a narrowed buffer region) and you tell me all identifier names you can
find in it.

martin