all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Francesco Potortì" <pot@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 30086@debbugs.gnu.org
Subject: bug#30086: Please add a flag to stop etags from falling back to Fortran and C
Date: Fri, 12 Jan 2018 14:09:40 +0100	[thread overview]
Message-ID: <E1eZz5Y-0006iV-S0@tucano.isti.cnr.it> (raw)
In-Reply-To: <441032b1-9e13-fefa-9b26-17d22899c2ec@yandex.ru>

>Previous discussion here: 
>http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html

I argue that fallbacks should be removed, or at least the default
reversed, i.e., not use fallback unless some --legacy-fallback option is
given.

Falbacks only make sense in an environment where Fortran and C are much
more prominently used than other languages AND where it is common to use
nonstandard suffixes for the source files.

Neither assumption is true nowadays, and I'd say it hasn't been true for
projects started in maybe the latest 20 years, while it may have been
true for legacy projects at the time when Etags was written.

Those legacy projects are the only reason why Etags should keep using a
default.  I assume that if people need to support Fortran or C
environments 20 years old without even changing the file name suffixes,
they are probably forced to use old tools, among which old Etag
versions, and we should not worry about such strict compatibility.

So, I'd say, just remove fallbacks, or use them only if a
--legacy-fallback option is used.





  reply	other threads:[~2018-01-12 13:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 12:06 bug#30086: Please add a flag to stop etags from falling back to Fortran and C Dmitry Gutov
2018-01-12 13:09 ` Francesco Potortì [this message]
2018-01-12 14:00   ` Eli Zaretskii

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=E1eZz5Y-0006iV-S0@tucano.isti.cnr.it \
    --to=pot@gnu.org \
    --cc=30086@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /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.