unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sven Utcke <utcke@kogs1.informatik.uni-hamburg.de>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Bug Report (Feature request?) etags (GNU Emacs 21.1)
Date: Fri, 22 Feb 2002 16:02:34 +0100 (CET)	[thread overview]
Message-ID: <200202221502.g1MF2Ye03793@kogs46.informatik.uni-hamburg.de> (raw)
In-Reply-To: <E16eGP9-0005ck-00@pot.cnuce.cnr.it> from "Francesco Potorti`" at Feb 22, 2002 03:10:31 PM

>    That is backwards.  It should only tag zz.y, not zz.c.
> 
>    The reason is that zz.y may have tags that are not reflected in zz.c.
> 
> Argh.  Right.   
>    						  It will also be possible
>           to use `etags xx.web xx.c' and etags will only tag xx.c with tags
>           pointing to xx.web.
> 
>    That is reasonable in this case because xx.web is in a format that
>    can't be processed by etags.
> 
> So etags should distinguish the two cases.  I'd like to find a more
> linear logic, however.

Personally, I do not think we should burden ourselves with this at
all.  I certainly would not give a .web file to etags, and _not_
giving .web files to etags is easily automated :-) So I _believe_ that
the right thing to do would be to create references for all files
given to etags, and to obey #line.  So if someone gives a .y and .c
file to etags, it _should_ create duplicate references to the .y file.

Of course one could optionally have etags remove duplicate entries, or
(maybe even better), if both the .y and .c file are given than etags
could take this as a hint to not obey #line for this particular .c
file, but I believe the best approach for now might be to simply
generate the duplicate references and be done...

Sven
-- 
 _  __                     The Cognitive Systems Group
| |/ /___  __ _ ___                                       University of Hamburg
| ' </ _ \/ _` (_-<  phone:    +49 (0)40 42883-2576      Vogt-Koelln-Strasse 30
|_|\_\___/\__, /__/  fax  :    +49 (0)40 42883-2572             D-22527 Hamburg
          |___/ http://kogs-www.informatik.uni-hamburg.de/~utcke/home.html

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


  reply	other threads:[~2002-02-22 15:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200202211303.g1LD3ar29903@kogs46.informatik.uni-hamburg.de>
2002-02-21 14:43 ` Bug Report (Feature request?) etags (GNU Emacs 21.1) Francesco Potorti`
2002-02-21 15:51   ` Kim F. Storm
2002-02-21 16:21     ` Sven Utcke
2002-02-22 14:08       ` Francesco Potorti`
     [not found]     ` <200202220433.g1M4XAt14047@aztec.santafe.edu>
2002-02-22 11:48       ` Sven Utcke
2002-02-22 14:29       ` Francesco Potorti`
2002-02-22 14:56         ` Sven Utcke
2002-02-23 20:19         ` Richard Stallman
     [not found]   ` <200202220433.g1M4X3f14032@aztec.santafe.edu>
2002-02-22 14:10     ` Francesco Potorti`
2002-02-22 15:02       ` Sven Utcke [this message]
2002-02-22 16:27         ` Stefan Monnier
     [not found] <200202220433.g1M4XCj14050@aztec.santafe.edu>
2002-02-22 11:37 ` Sven Utcke
2002-02-23 20:19   ` Richard Stallman
     [not found] <200202141816.g1EIGWQ19766@kogs12.informatik.uni-hamburg.de>
     [not found] ` <871yfjhgk7.fsf@pot.cnuce.cnr.it>
     [not found]   ` <5xg03zg0hc.fsf@kfs2.cua.dk>
     [not found]     ` <vd0bsenf432.fsf@kogs12.informatik.uni-hamburg.de>
     [not found]       ` <5xu1sfq8t9.fsf@kfs2.cua.dk>
     [not found]         ` <Pine.SUN.3.91.1020218153612.5449D-100000@is>
     [not found]           ` <87n0y6emxz.fsf@pot.cnuce.cnr.it>
     [not found]             ` <uofimd4mp.fsf@synopsys.com>
     [not found]               ` <87lmdq7cwm.fsf@creche.redhat.com>
     [not found]                 ` <87eljie7ty.fsf@pot.cnuce.cnr.it>
     [not found]                   ` <200202192131.g1JLVp413268@aztec.santafe.edu>
2002-03-05 12:15                     ` Francesco Potorti`
2002-03-05 13:11                       ` Sven Utcke
2002-03-06  5:57                         ` 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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=200202221502.g1MF2Ye03793@kogs46.informatik.uni-hamburg.de \
    --to=utcke@kogs1.informatik.uni-hamburg.de \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).