unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Gauthier Östervall" <gauthier@ostervall.se>
Cc: 31754@debbugs.gnu.org
Subject: bug#31754: 25.1; etags output lacks info for making xref more useful
Date: Tue, 12 Jun 2018 20:05:38 +0300	[thread overview]
Message-ID: <83r2lc3pgd.fsf@gnu.org> (raw)
In-Reply-To: <CAM8gEgiPcw_wxfGAjEEpkocQA_kPX=v6Nmn4=7OGGSkZykvO7g@mail.gmail.com> (message from Gauthier Östervall on Tue, 12 Jun 2018 16:49:44 +0200)

> From: Gauthier Östervall <gauthier@ostervall.se>
> Date: Tue, 12 Jun 2018 16:49:44 +0200
> Cc: 31754@debbugs.gnu.org
> 
> > So now I think that perhaps we should leave etags alone, and instead
> > add a feature to xref whereby the lines in the XREF buffer will show
> > in a tooltip the full signature of the function.
> 
> I am not a fan of tooltips, to be honest.

It's standard UI for these cases.  But we could, of course, have an
option whereby the XREF buffer itself would display enough of the
function's beginning to show the same info.

> In order to show the full signature, XREF would need to parse the
> source files.

Well, "parse" is really an exaggeration here.  More like "display the
first sexp", I'd say.  Every programming language mode already knows
how to do such limited "parsing".

> etags is already parsing files anyway, I can't see why not let it
> save whole signatures to TAGS?

Because it will bloat TAGS by a large factor.  Think about large
projects with hundreds of source files.  Even in Emacs, which is not
such a large package by modern standards, the combined TAGS table
weighs in at about 4MB.  The larger TAGS, the slower searches and
completion based on it.

It isn't TAGS' role, anyway.  TAGS is there to provide "links" to the
places in sources where functions are defined, it only shows the text
at that place for 2 purposes: (1) so that links won't break when the
source file changes in small ways, and the function moves to a
different line/byte offset; and (2) to show the identifier (the
function's name) itself, so as to allow Emacs to find in TAGS the
identifier the user requests.  Anything else is something Xref should
do when it finds the place where TAGS points, IMO.  Besides, this
feature will I think be valuable with Xref back-ends other than etags.





      reply	other threads:[~2018-06-12 17:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08  9:21 bug#31754: 25.1; etags output lacks info for making xref more useful Gauthier Östervall
2018-06-11 17:46 ` Eli Zaretskii
2018-06-12 14:49   ` Gauthier Östervall
2018-06-12 17:05     ` Eli Zaretskii [this message]

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=83r2lc3pgd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=31754@debbugs.gnu.org \
    --cc=gauthier@ostervall.se \
    /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).