which-function => DEFUN?

which-function => DEFUN?

[Lennart Borgman]

It is a bit annoying to see DEFUN as the function shown by which-function-mode.

I am sure someone here has written an
imenu-extract-index-name-function for use in Emacs C sources... ;-)

Where is it? How do you set it up?

Re: which-function => DEFUN?

[Juanma Barranquero]

On Mon, May 10, 2010 at 15:58, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> It is a bit annoying to see DEFUN as the function shown by which-function-mode.
>
> I am sure someone here has written an
> imenu-extract-index-name-function for use in Emacs C sources... ;-)

(defun which-func-identify-DEFUN ()
  (save-excursion
    (save-match-data
      (beginning-of-defun)
      (and (looking-at "DEFUN +(\"[^\"]+\",[ \n]+\\(F[^,]+\\),")
           (match-string-no-properties 1)))))

Likely the `save-match-data' is not required, but I tend to err on the
side of saving it on my code.

> Where is it? How do you set it up?

  (add-hook 'which-func-functions 'which-func-identify-DEFUN nil t)

on the required buffers (I set it through `c-mode-hook').

    Juanma

Re: which-function => DEFUN?

[Lennart Borgman]

On Mon, May 10, 2010 at 4:22 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Mon, May 10, 2010 at 15:58, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> It is a bit annoying to see DEFUN as the function shown by which-function-mode.
>>
>> I am sure someone here has written an
>> imenu-extract-index-name-function for use in Emacs C sources... ;-)
>
> (defun which-func-identify-DEFUN ()
>  (save-excursion
>    (save-match-data
>      (beginning-of-defun)
>      (and (looking-at "DEFUN +(\"[^\"]+\",[ \n]+\\(F[^,]+\\),")
>           (match-string-no-properties 1)))))
>
> Likely the `save-match-data' is not required, but I tend to err on the
> side of saving it on my code.
>
>> Where is it? How do you set it up?
>
>  (add-hook 'which-func-functions 'which-func-identify-DEFUN nil t)
>
> on the required buffers (I set it through `c-mode-hook').

Thanks Juanma, here is my slightly modified version built from your version:

  (defun my-which-func-identify-DEFUN ()
    (let ((here (point)))
      (save-match-data
        ;; Check if we are at the beginning of the function already
        (unless (eobp) (forward-char))
        (beginning-of-defun)
        (when (< here (point)) (beginning-of-defun))
        (prog1
            (and (looking-at "DEFUN +(\"[^\"]+\",[ \n]+\\(F[^,]+\\),")
                 (match-string-no-properties 1))
          (goto-char here)))))

  (defun my-add-DEFUN ()
    (add-hook 'which-func-functions 'my-which-func-identify-DEFUN nil t))
  (add-hook 'c-mode-hook 'my-add-DEFUN)

Re: which-function => DEFUN?

[Juanma Barranquero]

On Mon, May 10, 2010 at 16:39, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

>        ;; Check if we are at the beginning of the function already
>        (unless (eobp) (forward-char))

Yes, nice catch. Thanks.

>        (beginning-of-defun)
>        (when (< here (point)) (beginning-of-defun))

What does this protect against?

And, why did you go for (let ((here (point))) ...) instead of
`save-excursion'? Efficiency?

    Juanma

Re: which-function => DEFUN?

[Stefan Monnier]

> (defun which-func-identify-DEFUN ()
>   (save-excursion
>     (save-match-data
>       (beginning-of-defun)
>       (and (looking-at "DEFUN +(\"[^\"]+\",[ \n]+\\(F[^,]+\\),")
>            (match-string-no-properties 1)))))

> Likely the `save-match-data' is not required, but I tend to err on the
> side of saving it on my code.

The rule for where to place a save-match-data is:

  around the code run between "looking-at" and
  "match-string-no-properties".

In this case (as in 99% of the cases) this code is empty, so the
save-match-data can be dropped.

> (add-hook 'which-func-functions 'which-func-identify-DEFUN nil t)

If your save-match-data were needed, which-func-functions should say
so explicitly.


        Stefan

Re: which-function => DEFUN?

[Lennart Borgman]

On Mon, May 10, 2010 at 5:09 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Mon, May 10, 2010 at 16:39, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>>        ;; Check if we are at the beginning of the function already
>>        (unless (eobp) (forward-char))
>
> Yes, nice catch. Thanks.
>
>>        (beginning-of-defun)
>>        (when (< here (point)) (beginning-of-defun))
>
> What does this protect against?

We might have stepped into the next function.

> And, why did you go for (let ((here (point))) ...) instead of
> `save-excursion'? Efficiency?

Efficiency. And actually readability.

>    Juanma
>

Re: which-function => DEFUN?

[Lennart Borgman]

On Mon, May 10, 2010 at 5:42 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> The rule for where to place a save-match-data is:
>
>  around the code run between "looking-at" and
>  "match-string-no-properties".
>
> In this case (as in 99% of the cases) this code is empty, so the
> save-match-data can be dropped.
>
>> (add-hook 'which-func-functions 'which-func-identify-DEFUN nil t)
>
> If your save-match-data were needed, which-func-functions should say
> so explicitly.


Yes, but what is the rule for WHEN to use save-match-data. I just
looked in the elisp manual and could not find anything.

Re: which-function => DEFUN?

[Juanma Barranquero]

On Mon, May 10, 2010 at 17:56, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> We might have stepped into the next function.

In the case of DEFUN, which is only used in the Emacs sources, that's
unlikely unless you have

DEFUN (...)
{
}DEFUN (...)

which I don't think happens even once in the source (I doesn't, I just checked).

> Efficiency.

I have never noticed any slowness, but YMMV.

> And actually readability.

Let's agree to disagree on this one.

    Juanma

Re: which-function => DEFUN?

[Juanma Barranquero]

On Mon, May 10, 2010 at 17:42, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The rule for where to place a save-match-data is:
>
>  around the code run between "looking-at" and
>  "match-string-no-properties".
>
> In this case (as in 99% of the cases) this code is empty, so the
> save-match-data can be dropped.

The save-match-data is not there to protect the code between
`looking-at' and `match-string-no-properties', because as you point
out, that is an empty set. It is there to protect the caller of
which-func-identify-DEFUN.

> If your save-match-data were needed, which-func-functions should say
> so explicitly.

Yes, I know. As I said, in code for my own use I tend to err on the
side of caution.

    Juanma

Re: which-function => DEFUN?

[Stefan Monnier]

>> The rule for where to place a save-match-data is:
>> 
>>  around the code run between "looking-at" and
>>  "match-string-no-properties".
>> 
>> In this case (as in 99% of the cases) this code is empty, so the
>> save-match-data can be dropped.
>> 
>>> (add-hook 'which-func-functions 'which-func-identify-DEFUN nil t)
>> 
>> If your save-match-data were needed, which-func-functions should say
>> so explicitly.


> Yes, but what is the rule for WHEN to use save-match-data. I just
> looked in the elisp manual and could not find anything.

The "where":

   around the code run between "looking-at" and
   "match-string-no-properties".

also tells you "when": just look at the code around which to place
save-match-data and if it's clear that the save-match-data is not needed
(as in your case), then don't bother putting it there.


        Stefan

Global match data considered harmful

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The rule for where to place a save-match-data is:
 > 
 >   around the code run between "looking-at" and
 >   "match-string-no-properties".

*snort*  I'm with Juanma.

This is just so wrong, you know.  Not returning the match data, instead
storing it in a global object, is arguably the worst design decision
in all of Emacs.

Re: Global match data considered harmful

[Stefan Monnier]

>> The rule for where to place a save-match-data is:
>> around the code run between "looking-at" and "match-string-no-properties".
> *snort*  I'm with Juanma.

I'm not sure what that means.

> This is just so wrong, you know.  Not returning the match data, instead
> storing it in a global object, is arguably the worst design decision
> in all of Emacs.

Preaching to the choir, eh?
[ Well "the worst" I don't know: it's not like there's a shortage of
  global-abuse in Emacs. ]


        Stefan

Re: Global match data considered harmful

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> The rule for where to place a save-match-data is:
 > >> around the code run between "looking-at" and "match-string-no-properties".
 > > *snort*  I'm with Juanma.
 > 
 > I'm not sure what that means.

Most of the code I write is (ab)usable by .emacs; so I put
save-match-data in the functions I write to protect naive callers from
having their match-data tromped on by my using of matching code.  If
somebody complains about slow I defun a foo-internal without using
save-match-data, and call that from foo.

Why?  I'm pretty sure there's at least one match-data-munching bug in
XEmacs's minibuffer code at the moment (or it might be setcdr abuse),
but I don't have time for a full audit and it's sufficiently
intermittent that I don't have a strong incentive to do that
anyway....  Missing save-match-data is about as hard to debug as
missing GCPRO.  :-(  Better to put in too many than too few.

 > > This is just so wrong, you know.  Not returning the match data, instead
 > > storing it in a global object, is arguably the worst design decision
 > > in all of Emacs.
 > 
 > Preaching to the choir, eh?
 > [ Well "the worst" I don't know: it's not like there's a shortage of
 >   global-abuse in Emacs. ]

No shortage, for sure, but this one is like attaching an 'invisible
property to a low-hanging rope in a narrow hallway.

Re: Global match data considered harmful

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 12, 2010 at 11:01:10AM +0900, Stephen J. Turnbull wrote:

[...]

> No shortage, for sure, but this one is like attaching an 'invisible
> property to a low-hanging rope in a narrow hallway.

Ouch. Coffee. Keyboard. May I quote that?

(you made my day :-)

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFL6jgfBcgs9XrR2kYRAlcgAJ9xivynoJrH0zkmkqtf+mHST1649wCffLoV
PUK3hBw1G9pR7aDM3n3JMuE=
=GsxQ
-----END PGP SIGNATURE-----