find-tag-default

find-tag-default

[Juri Linkov]

I noticed that grep.el has a copy of find-tag-default function from
etags.el, for the reason not to load etags.el at run-time.

The function find-tag-default is a quite general function, which is
used by other Emacs Lisp files, so it could be moved from etags.el to
simple.el (without renaming), thus allowing other files to use it
without loading etags.el.

find-tag-default could be used also as an additional attempt to find a
function or variable name around point in functions describe-function,
describe-variable.  This is useful when a function or variable name is
located in a buffer not in Emacs Lisp mode, such as message or article
mode, where it is not quoted and has trailing punctuation.
(For example, try to type C-h f on function names in this paragraph.)

Index: emacs/lisp/help.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help.el,v
retrieving revision 1.264
diff -u -w -b -r1.264 help.el
--- emacs/lisp/help.el	27 Apr 2004 06:35:25 -0000	1.264
+++ emacs/lisp/help.el	13 May 2004 06:11:20 -0000
@@ -237,7 +237,7 @@
 (defun function-called-at-point ()
   "Return a function around point or else called by the list containing point.
 If that doesn't give a function, return nil."
-  (with-syntax-table emacs-lisp-mode-syntax-table
+  (or (with-syntax-table emacs-lisp-mode-syntax-table
     (or (condition-case ()
 	    (save-excursion
 	      (or (not (zerop (skip-syntax-backward "_w")))
@@ -262,7 +262,10 @@
 		    (error "Probably not a Lisp function call"))
 		(let ((obj (read (current-buffer))))
 		  (and (symbolp obj) (fboundp obj) obj))))
-	  (error nil)))))
+              (error nil))))
+      (let* ((str (find-tag-default))
+             (obj (if str (intern str))))
+        (and (symbolp obj) (fboundp obj) obj))))
 
 \f
 ;;; `User' help functions

Index: emacs/lisp/help-fns.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help-fns.el,v
retrieving revision 1.48
diff -u -w -b -r1.48 help-fns.el
--- emacs/lisp/help-fns.el	11 May 2004 23:50:25 -0000	1.48
+++ emacs/lisp/help-fns.el	13 May 2004 06:11:21 -0000
@@ -456,7 +456,7 @@
 (defun variable-at-point ()
   "Return the bound variable symbol found around point.
 Return 0 if there is no such symbol."
-  (condition-case ()
+  (or (condition-case ()
       (with-syntax-table emacs-lisp-mode-syntax-table
 	(save-excursion
 	  (or (not (zerop (skip-syntax-backward "_w")))
@@ -465,9 +465,12 @@
 	      (forward-sexp -1))
 	  (skip-chars-forward "'")
 	  (let ((obj (read (current-buffer))))
-	    (or (and (symbolp obj) (boundp obj) obj)
-		0))))
-    (error 0)))
+                (and (symbolp obj) (boundp obj) obj))))
+        (error nil))
+      (let* ((str (find-tag-default))
+             (obj (if str (intern str))))
+        (and (symbolp obj) (boundp obj) obj))
+      0))
 
 ;;;###autoload
 (defun describe-variable (variable &optional buffer)

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

Re: find-tag-default

[Richard Stallman]

It might make sense to move find-tag-default, but if we think it
is no longer specifically about tags, we should change its name.
Suggestions for the new name?

Re: find-tag-default

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> It might make sense to move find-tag-default, but if we think it
> is no longer specifically about tags, we should change its name.
> Suggestions for the new name?

It seems it can't be renamed because usually it is used in conjunction
with the variable `find-tag-default-function' which is already used
for purposes not related to the tags functionality.

A typical example is:

        (funcall (or find-tag-default-function
                     (get major-mode 'find-tag-default-function)
                     'find-tag-default))

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

Re: find-tag-default

[Kevin Rodgers]

Juri Linkov wrote:
 > Richard Stallman <rms@gnu.org> writes:
 >>It might make sense to move find-tag-default, but if we think it
 >>is no longer specifically about tags, we should change its name.
 >>Suggestions for the new name?
 >
 > It seems it can't be renamed because usually it is used in conjunction
 > with the variable `find-tag-default-function' which is already used
 > for purposes not related to the tags functionality.
 >
 > A typical example is:
 >
 >         (funcall (or find-tag-default-function
 >                      (get major-mode 'find-tag-default-function)
 >                      'find-tag-default))

(defalias 'find-tag-default 'the-new-name)

-- 
Kevin Rodgers

Re: find-tag-default

[Richard Stallman]

    > It might make sense to move find-tag-default, but if we think it
    > is no longer specifically about tags, we should change its name.
    > Suggestions for the new name?

    It seems it can't be renamed because usually it is used in conjunction
    with the variable `find-tag-default-function' which is already used
    for purposes not related to the tags functionality.

This doesn't mean we cannot rename it.  At most we need to keep
the old name as an alias.  But maybe we can change the name in
the places that use it.

Re: find-tag-default

[Juri Linkov]

I have a better idea: to left the function `find-tag-default'
alone in its etags.el, and to add a new function (which is
slightly extended version of `find-tag-default') to simple.el:

(defun identifier-at-point ()
  "Return a default identifier based on the text at point."
  (or (and (boundp 'find-tag-default-function)
           find-tag-default-function
           (funcall find-tag-default-function))
      (and (get major-mode 'find-tag-default-function)
           (funcall (get major-mode 'find-tag-default-function)))
      (save-excursion
        (while (looking-at "\\sw\\|\\s_")
          (forward-char 1))
        (when (or (re-search-backward "\\sw\\|\\s_"
                                      (save-excursion (beginning-of-line) (point))
                                      t)
                  (re-search-forward "\\(\\sw\\|\\s_\\)+"
                                     (save-excursion (end-of-line) (point))
                                     t))
          (goto-char (match-end 0))
          (buffer-substring-no-properties
           (point)
           (progn (forward-sexp -1)
                  (while (looking-at "\\s'")
                    (forward-char 1))
                  (point)))))))

There are several benefits:

1. no need to load etags.el;

2. a complicated construct

(funcall (or find-tag-default-function
         (get major-mode 'find-tag-default-function)
         'find-tag-default))

is replaced by a simple function call `(identifier-at-point)'.

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

Re: find-tag-default

[Juri Linkov]

Juri Linkov <juri@jurta.org> writes:
> I have a better idea: to left the function `find-tag-default'
> alone in its etags.el, and to add a new function (which is

I meant to _leave_ it alone in etags.el and create a new extended function.

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

Re: find-tag-default

[Richard Stallman]

If identifier-at-point is useful in a number of places,
let's install that and use it.

Is this function exactly the right thing?

Re: find-tag-default

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> If identifier-at-point is useful in a number of places,
> let's install that and use it.
>
> Is this function exactly the right thing?

The function name is right, but its contents is not too right.

Currently there are different methods for obtaining an identifier
at point:

- `find-tag-default' and `find-tag-default-function' from etags.el

- `symbol-at-point' from thingatpt.el

- info-look.el which has the most advanced implementation since
  it defines regular expressions and parsing rules for guessing
  the default identifier for 20 major modes (and one special
  function `info-lookup-guess-c-symbol' for C mode).

So to create right contents of `identifier-at-point' these packages
could be generalized.

Anyway, we could install this function now as a general method
to get an identifier at point, with the identifier guessing method
from etags.el, and improve its contents later.

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

Re: find-tag-default

[Richard Stallman]

    Currently there are different methods for obtaining an identifier
    at point:

    - `find-tag-default' and `find-tag-default-function' from etags.el

    - `symbol-at-point' from thingatpt.el

    - info-look.el which has the most advanced implementation since
      it defines regular expressions and parsing rules for guessing
      the default identifier for 20 major modes (and one special
      function `info-lookup-guess-c-symbol' for C mode).

    So to create right contents of `identifier-at-point' these packages
    could be generalized.

Is it clear that using the info-look code would be best for everything
that uses the other two functions?

If so, let's do that.

RE: find-tag-default

[Drew Adams]

Belated, and possibly irrelevant, but FYI -

Library thingatpt+.el provides additions and enhancements to thingatpt.el:

1) An optional syntax-table argument is used to determine the bounds.

2) New functions (e.g. symbol-nearest-point) don't require point to be on
the name you want. Here's how "nearest" is defined:

    The nearest symbol on the same line is returned, if there is any.
        Between two symbols equidistant from point on the same line, the
        leftmost is considered nearer.
    Otherwise, neighboring lines are tried in sequence:
        previous, next, 2nd previous, 2nd next, 3rd previous, 3rd next, etc.
        This means that between two symbols equidistant from point in
        lines above and below it, the symbol in the line above point
        (previous Nth) is considered nearer to it.

The code is here: http://www.emacswiki.org/elisp/thingatpt-plus.el.

You might consider using a similar "nearest" functionality in Emacs. In my
own code, I use it in commands like describe-variable. I prefer to have a
default value in the minibuffer for such commands (I use backward-kill-sexp,
bound to C-M-backspace, to remove it if it's inappropriate). I find that
"nearest" usually DTRT.

 - Drew

-----Original Message-----
From: Richard Stallman

    Currently there are different methods for obtaining an identifier
    at point:
    - `find-tag-default' and `find-tag-default-function' from etags.el
    - `symbol-at-point' from thingatpt.el
    - info-look.el which has the most advanced implementation since
      it defines regular expressions and parsing rules for guessing
      the default identifier for 20 major modes (and one special
      function `info-lookup-guess-c-symbol' for C mode).

    So to create right contents of `identifier-at-point' these packages
    could be generalized.

Is it clear that using the info-look code would be best for everything
that uses the other two functions?

If so, let's do that.

Re: find-tag-default

[Richard Stallman]

    Library thingatpt+.el provides additions and enhancements to thingatpt.el:

    1) An optional syntax-table argument is used to determine the bounds.

When have you found that useful?

    2) New functions (e.g. symbol-nearest-point) don't require point to be on
    the name you want. Here's how "nearest" is defined:

Some kind of extension in this direction could be useful, I guess.
However, I think this looks too far away from point:

	The nearest symbol on the same line is returned, if there is any.
	    Between two symbols equidistant from point on the same line, the
	    leftmost is considered nearer.
	Otherwise, neighboring lines are tried in sequence:
	    previous, next, 2nd previous, 2nd next, 3rd previous, 3rd next, etc.
	    This means that between two symbols equidistant from point in
	    lines above and below it, the symbol in the line above point
	    (previous Nth) is considered nearer to it.

I think it would be a mistake to use a symbol very far away from point.
The user would think, "Where in the world did that come from?"
It's better to say "there's no default" than grasp at straws to
find one.

So I would recommend a new function along these lines but with
some limits.

RE: find-tag-default

[Drew Adams]

    D>     Library thingatpt+.el provides additions and enhancements to
thingatpt.el:
    D>
    D>     1) An optional syntax-table argument is used to determine the
bounds.

  RMS> When have you found that useful?

To be honest, I don't remember well. I wrote this a decade ago.

I believe it was in order to take into account different modes with
different syntax; that is, so that the different "things" would have an
appropriate syntax definition. The syntax-table is used to determine the
bounds of the thing searched for.

You can, for instance, look for the "word" nearest point, where you define
"word" in a special way by passing in an explicit syntax-table arg.
Likewise, with other kinds of things (defuns, whitespace, pages, ...).

The syntax table will affect the exact definition of what constitutes a
"word" etc. What makes such an entity usable as a "thing" here is of course
that it has corresponding forward-THING (or beginning-of-THING) and
end-of-THING operations. The two (syntax table and boundary-defining
operations) work hand in hand.

Remember that the "thing" functions are completely general: you can define
your own forward-whazit and end-whazit commands and one or more
syntax-tables that incorporate whazit syntax(es). Your forward-whazit
function could behave differently with different syntax tables. This then
gives you functions to pick whazits out of a buffer easily in different
(syntax) situations.

Consider, for instance, forward-symbol, which uses this regexp:
"\\(\\sw\\|\\s_\\)+" to determine what a "symbol" is. This in turn depends
on what \sw and \s  mean. That is, forward-symbol depends on the syntax
table: give it a different syntax table and you get different behavior.

BTW, I note that I removed the syntax-table arg from the symbol-* functions
because the mode of use (for me) was always emacs-lisp-mode; I just passed
emacs-lisp-mode-syntax-table in as the syntax-table arg when defining the
symbol-* functions. I kept the syntax-table arg for the other functions
(form-*, thing-*, word-*, sentence-*, sexp-*, number-*, list-*), however.

If used for other (e.g. other programming) modes, it might be good to
reinstate the syntax-table arg for the symbol-* functions too.

The syntax-table arg is in any case optional.

    D>     2) New functions (e.g. symbol-nearest-point) don't require point
to be on
    D>     the name you want. Here's how "nearest" is defined:

  RMS> Some kind of extension in this direction could be useful, I guess.
  RMS> However, I think this looks too far away from point:

    D>         The nearest symbol on the same line is returned, if there is
any.
    D>             Between two symbols equidistant from point on the same
line, the
    D>             leftmost is considered nearer.
    D>         Otherwise, neighboring lines are tried in sequence:
    D>             previous, next, 2nd previous, 2nd next, 3rd previous, 3rd
next, etc.
    D>             This means that between two symbols equidistant from
point in
    D>             lines above and below it, the symbol in the line above
point
    D>             (previous Nth) is considered nearer to it.

  RMS> I think it would be a mistake to use a symbol very far away from
point.
  RMS> The user would think, "Where in the world did that come from?"
  RMS> It's better to say "there's no default" than grasp at straws to
  RMS> find one.

  RMS> So I would recommend a new function along these lines but with
  RMS> some limits.

It only picks up a thing (symbol, list, number, whatever) far from point if
there is none closer. That is, it just picks the closest one. If there is a
lot of blank space, for instance, this will ignore that.

Or, if there is other stuff that should be ignored, then that is ignored.
That is, if the type of "thing" searched for is surrounded by non-things,
the non-things are ignored and the nearest thing is picked up. For instance,
if the type is a number, then this ignores anything that is not a number.

I think that an arbitrary limit would *not* be useful. In practice, there is
something useful nearby. If there is none, nil is returned. If the only
appropriate thing is pretty far away, it is still probably appropriate to
return it. The notion of "nearby" is relative, in any case: it can be
different for different situations. Only the calling code really knows what
"nearby" means.

Besides, a calling function can always choose to ignore something beyond a
certain limit. The *-with-bounds functions all return the bounds of the
found thing, and the bounds-of-* functions extract those bounds. The bounds
can be tested to filter things too far away, if necessary.

Of course it's possible that if this were executed on a humongous file,
performance would suffer. For this reason, it might be good to limit the
search beforehand, instead of waiting to filter out a result that is too far
away. This is easily done by narrowing: these functions stop at the limits
of the buffer - or of the narrowing restriction. Again, the calling function
knows best whether such narrowing (and how much) is appropriate.

You may be right that a user might think "whazzat?!" in some situations - I
dunno. My personal preference is to always have Emacs serve me such a
default value; if I don't like it I toss it from the minibuffer with a
simple backward-kill-sexp (bound to C-M-backspace). In my own code, I use
symbol-nearest-point in completing-read everywhere.

Anyway, whether or not such functions (or similar) are used directly in
interactive specs, I think they can serve as useful elisp building blocks.

 - Drew

For reference, here's the code:
http://www.emacswiki.org/elisp/thingatpt-plus.el

Re: find-tag-default

[Richard Stallman]

    It only picks up a thing (symbol, list, number, whatever) far from point if
    there is none closer. That is, it just picks the closest one. If there is a
    lot of blank space, for instance, this will ignore that.

What I'm saying is that ignoring too much whitespace would give
a confusing result--it would be a mistake.

    If the only
    appropriate thing is pretty far away, it is still probably appropriate to
    return it. The notion of "nearby" is relative, in any case:

I disagree with both of those points.  10 lines away is not nearby.