[PATCH] etags: Add a small list of interpretors for Python

[PATCH] etags: Add a small list of interpretors for Python

[Iustin Pop]

Currently, etags has no interpretors defined for Python, which prevents
it from recognising Python scripts that have no extension. This patch
adds a small list of interpretors for this language, which while not
perfect (e.g. it will fail on specific versions like python2.4), it is
better than the current situation where all scripts without an extension
will default to Fortran.

Note: I debated adding a more detailed list, but it would get outdated
quickly, so I left just these three versions. A regular expression for
the interpreter name would be much better here, would implementing that
make sense?

[please keep me CC-ed, I'm not subscribed to the list]

=== modified file 'lib-src/etags.c'
*** lib-src/etags.c	2010-08-11 08:20:34 +0000
--- lib-src/etags.c	2010-08-19 13:27:43 +0000
*************** line.";
*** 755,760 ****
--- 755,762 ----
  
  static const char *Python_suffixes [] =
    { "py", NULL };
+ static const char *Python_interpreters [] =
+   { "python", "python2", "python3", NULL };
  static const char Python_help [] =
  "In Python code, `def' or `class' at the beginning of a line\n\
  generate a tag.";
*************** static language lang_names [] =
*** 836,842 ****
    { "postscript",PS_help,        PS_functions,      PS_suffixes        },
    { "proc",      no_lang_help,   plain_C_entries,   plain_C_suffixes   },
    { "prolog",    Prolog_help,    Prolog_functions,  Prolog_suffixes    },
!   { "python",    Python_help,    Python_functions,  Python_suffixes    },
    { "scheme",    Scheme_help,    Scheme_functions,  Scheme_suffixes    },
    { "tex",       TeX_help,       TeX_commands,      TeX_suffixes       },
    { "texinfo",   Texinfo_help,   Texinfo_nodes,     Texinfo_suffixes   },
--- 838,844 ----
    { "postscript",PS_help,        PS_functions,      PS_suffixes        },
    { "proc",      no_lang_help,   plain_C_entries,   plain_C_suffixes   },
    { "prolog",    Prolog_help,    Prolog_functions,  Prolog_suffixes    },
!   { "python",Python_help,Python_functions,Python_suffixes,NULL,Python_interpreters},
    { "scheme",    Scheme_help,    Scheme_functions,  Scheme_suffixes    },
    { "tex",       TeX_help,       TeX_commands,      TeX_suffixes       },
    { "texinfo",   Texinfo_help,   Texinfo_nodes,     Texinfo_suffixes   },

Re: [PATCH] etags: Add a small list of interpretors for Python

[Iustin Pop]

On Thu, Aug 19, 2010 at 05:36:06PM +0200, Iustin Pop wrote:
> Currently, etags has no interpretors defined for Python, which prevents
> it from recognising Python scripts that have no extension. This patch
> adds a small list of interpretors for this language, which while not
> perfect (e.g. it will fail on specific versions like python2.4), it is
> better than the current situation where all scripts without an extension
> will default to Fortran.
> 
> Note: I debated adding a more detailed list, but it would get outdated
> quickly, so I left just these three versions. A regular expression for
> the interpreter name would be much better here, would implementing that
> make sense?
> 
> [please keep me CC-ed, I'm not subscribed to the list]

Ping? Is this the wrong list?

thanks!
iustin

Re: [PATCH] etags: Add a small list of interpretors for Python

[Francesco Potortì]

>Currently, etags has no interpretors defined for Python, which prevents
>it from recognising Python scripts that have no extension. This patch
>adds a small list of interpretors for this language, which while not
>perfect (e.g. it will fail on specific versions like python2.4), it is
>better than the current situation where all scripts without an extension
>will default to Fortran.

Sure.

>Note: I debated adding a more detailed list, but it would get outdated
>quickly, so I left just these three versions. A regular expression for
>the interpreter name would be much better here, would implementing that
>make sense?

It is simpler than that, see below.

>+ static const char *Python_interpreters [] =
>+   { "python", "python2", "python3", NULL };

You just add "python" here.

>!   { "python",Python_help,Python_functions,Python_suffixes,NULL,Python_interpreters},

This is allright.

Moreover, in get_language_from_interpreter you change this:

  for (lang = lang_names; lang->name != NULL; lang++)
    if (lang->interpreters != NULL)
      for (iname = lang->interpreters; *iname != NULL; iname++)
        if (streq (*iname, interpreter))
            return lang;

to something like this:

  for (lang = lang_names; lang->name != NULL; lang++)
    if (lang->interpreters != NULL)
      for (iname = lang->interpreters; *iname != NULL; iname++)
-->     if (strneq (*iname, interpreter, strlen(*iname)))     <--
            return lang;

This changes the semantics of get_language_from_interpreter so that the
list of interpreters is now a list of initial substrings that are
accepted as interpreters names: I think that this new semantic is more
useful than the previous one.

If this change is done, one should look through the etags builtin help,
the man page and the info manual and update them with the new semantics,
if necessary.

I should be the one to do that, as the etags' maintainer, but I am sure
that this work will proceed much more quickly if you do it :)

Re: [PATCH] etags: Add a small list of interpretors for Python

[Iustin Pop]

On Wed, Sep 01, 2010 at 03:09:14PM +0200, Francesco Potortì wrote:
> >Currently, etags has no interpretors defined for Python, which prevents
> >it from recognising Python scripts that have no extension. This patch
> >adds a small list of interpretors for this language, which while not
> >perfect (e.g. it will fail on specific versions like python2.4), it is
> >better than the current situation where all scripts without an extension
> >will default to Fortran.
> 
> Sure.
> 
> >Note: I debated adding a more detailed list, but it would get outdated
> >quickly, so I left just these three versions. A regular expression for
> >the interpreter name would be much better here, would implementing that
> >make sense?
> 
> It is simpler than that, see below.

Sorry for the very late response.

> >+ static const char *Python_interpreters [] =
> >+   { "python", "python2", "python3", NULL };
> 
> You just add "python" here.
> 
> >!   { "python",Python_help,Python_functions,Python_suffixes,NULL,Python_interpreters},
> 
> This is allright.
> 
> Moreover, in get_language_from_interpreter you change this:
> 
>   for (lang = lang_names; lang->name != NULL; lang++)
>     if (lang->interpreters != NULL)
>       for (iname = lang->interpreters; *iname != NULL; iname++)
>         if (streq (*iname, interpreter))
>             return lang;
> 
> to something like this:
> 
>   for (lang = lang_names; lang->name != NULL; lang++)
>     if (lang->interpreters != NULL)
>       for (iname = lang->interpreters; *iname != NULL; iname++)
> -->     if (strneq (*iname, interpreter, strlen(*iname)))     <--
>             return lang;

I did this, but then:

> This changes the semantics of get_language_from_interpreter so that the
> list of interpreters is now a list of initial substrings that are
> accepted as interpreters names: I think that this new semantic is more
> useful than the previous one.
> 
> If this change is done, one should look through the etags builtin help,
> the man page and the info manual and update them with the new semantics,
> if necessary.

I looked but didn't find any documentation about this; probably due the
fact that the interpretors are not user-customizable?

If you can point me to which docs needs to be changed, I'll be glad to.
Neither doc/man/etags.1 nor doc/emacs/maintaining.texi list anything
about it.

Interdiff from the previous patch:

=== modified file 'lib-src/etags.c'
--- lib-src/etags.c     2010-12-23 13:52:41 +0000
+++ lib-src/etags.c     2010-12-23 14:05:35 +0000
@@ -757,7 +757,7 @@
 static const char *Python_suffixes [] =
   { "py", NULL };
 static const char *Python_interpreters [] =
-  { "python", "python2", "python3", NULL };
+  { "python", NULL };
 static const char Python_help [] =
 "In Python code, `def' or `class' at the beginning of a line\n\
 generate a tag.";
@@ -1477,7 +1477,7 @@
   for (lang = lang_names; lang->name != NULL; lang++)
     if (lang->interpreters != NULL)
       for (iname = lang->interpreters; *iname != NULL; iname++)
-       if (streq (*iname, interpreter))
+       if (strneq (*iname, interpreter, strlen(*iname)))
            return lang;
 
   return NULL;

-- 
thanks,
iustin

Re: [PATCH] etags: Add a small list of interpretors for Python

[Francesco Potortì]

>
>On Wed, Sep 01, 2010 at 03:09:14PM +0200, Francesco Potortì wrote:
>> >Currently, etags has no interpretors defined for Python, which prevents
>> >it from recognising Python scripts that have no extension. This patch
>> >adds a small list of interpretors for this language, which while not
>> >perfect (e.g. it will fail on specific versions like python2.4), it is
>> >better than the current situation where all scripts without an extension
>> >will default to Fortran.
>> 
>> Sure.
>> 
>> >Note: I debated adding a more detailed list, but it would get outdated
>> >quickly, so I left just these three versions. A regular expression for
>> >the interpreter name would be much better here, would implementing that
>> >make sense?
>> 
>> It is simpler than that, see below.
>
>Sorry for the very late response.
>
>> >+ static const char *Python_interpreters [] =
>> >+   { "python", "python2", "python3", NULL };
>> 
>> You just add "python" here.
>> 
>> >!   { "python",Python_help,Python_functions,Python_suffixes,NULL,Python_interpreters},
>> 
>> This is allright.
>> 
>> Moreover, in get_language_from_interpreter you change this:
>> 
>>   for (lang = lang_names; lang->name != NULL; lang++)
>>     if (lang->interpreters != NULL)
>>       for (iname = lang->interpreters; *iname != NULL; iname++)
>>         if (streq (*iname, interpreter))
>>             return lang;
>> 
>> to something like this:
>> 
>>   for (lang = lang_names; lang->name != NULL; lang++)
>>     if (lang->interpreters != NULL)
>>       for (iname = lang->interpreters; *iname != NULL; iname++)
>> -->     if (strneq (*iname, interpreter, strlen(*iname)))     <--
>>             return lang;
>
>I did this, but then:
>
>> This changes the semantics of get_language_from_interpreter so that the
>> list of interpreters is now a list of initial substrings that are
>> accepted as interpreters names: I think that this new semantic is more
>> useful than the previous one.
>> 
>> If this change is done, one should look through the etags builtin help,
>> the man page and the info manual and update them with the new semantics,
>> if necessary.
>
>I looked but didn't find any documentation about this; probably due the
>fact that the interpretors are not user-customizable?
>
>If you can point me to which docs needs to be changed, I'll be glad to.
>Neither doc/man/etags.1 nor doc/emacs/maintaining.texi list anything
>about it.

I checked.

The builtin help does not mention any details, so no need to update it.

The man page does not mention the fact that etags looks for an
interpreter in the first line of the source files, so no need to update
it.  Same for the info help.  In short, nothing to do in the
documentation.

>Interdiff from the previous patch:
>
>=== modified file 'lib-src/etags.c'
>--- lib-src/etags.c     2010-12-23 13:52:41 +0000
>+++ lib-src/etags.c     2010-12-23 14:05:35 +0000
>@@ -757,7 +757,7 @@
> static const char *Python_suffixes [] =
>   { "py", NULL };
> static const char *Python_interpreters [] =
>-  { "python", "python2", "python3", NULL };
>+  { "python", NULL };
> static const char Python_help [] =
> "In Python code, `def' or `class' at the beginning of a line\n\
> generate a tag.";
>@@ -1477,7 +1477,7 @@
>   for (lang = lang_names; lang->name != NULL; lang++)
>     if (lang->interpreters != NULL)
>       for (iname = lang->interpreters; *iname != NULL; iname++)
>-       if (streq (*iname, interpreter))
>+       if (strneq (*iname, interpreter, strlen(*iname)))
>            return lang;
> 
>   return NULL;
>
>-- 
>thanks,
>iustin
>

Comments should be updated in the source:

  char **interpreters;		/* interpreters for this language */

This should probably read:

  char **interpreters;	/* initial substr of interpreters for this language */

-- 
Francesco Potortì (ricercatore)        Voice: +39 050 315 3058 (op.2111)
ISTI - Area della ricerca CNR          Fax:   +39 050 315 2040
via G. Moruzzi 1, I-56124 Pisa         Email: Potorti@isti.cnr.it
(entrance 20, 1st floor, room C71)     Web:   http://fly.isti.cnr.it/