all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Francesco Potortì" <pot@gnu.org>
To: Iustin Pop <iustin@google.com>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] etags: Add a small list of interpretors for Python
Date: Wed, 01 Sep 2010 15:09:14 +0200	[thread overview]
Message-ID: <E1Oqn3y-0008MG-P9@tucano.isti.cnr.it> (raw)
In-Reply-To: <20100819153606.GO4157@google.com>

>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 :)



  parent reply	other threads:[~2010-09-01 13:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-19 15:36 [PATCH] etags: Add a small list of interpretors for Python Iustin Pop
2010-09-01 11:53 ` Iustin Pop
2010-09-01 13:09 ` Francesco Potortì [this message]
2010-12-23 14:13   ` Iustin Pop
2011-01-12 16:43     ` Francesco Potortì

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Oqn3y-0008MG-P9@tucano.isti.cnr.it \
    --to=pot@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=iustin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.