unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: John Yates <john@yates-sheets.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Edward Bishop <binutils@gmail.com>,
	Danil Orlov <zargener@gmail.com>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: From etags to ctags?
Date: Fri, 6 Jun 2014 15:01:25 -0400	[thread overview]
Message-ID: <CAJnXXoi_ThVqoozZbT3JZXL9c=wUtqtyOOjCeiFivSno6ftGrw@mail.gmail.com> (raw)
In-Reply-To: <jwv8upc31nw.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

On Wed, Jun 4, 2014 at 3:40 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > For instance Edward Bishop's vtags fork?
>
> I know nothing about it.  If we can get its copyright cleared, then it'd
> probably be a good starting point (we'd probably want to try and
> integrate it more with the current tags functionality).
>

My reason for using vtags has never been the additional annotations.  They
just turned out to be an unexpected extra.  The important thing about vtags
is that it assumes a binary searchable external tags file and offers other
UI improvements.  Definitely a source of idea.

/john

;; Added tags (as opposed to TAGS) functionality.
;; The code now has the ability to parse vi-style
;; tags tables generated by Exuberant Ctags.
;; By introduction of vtags-get-tagfile-header and struct tagfileinfo, we
have tried
;; to make the higher-level functions tag-type agnostic and
non-buffer-centric.
;; Many functions that used to assume that the TAGS file is in
;; the current buffer now take a tagfileinfo, or tfi, parameter.
;;
;; Changed the behavior of vtags-find for multiple matches. Previously the
user
;; could iterate through the matches one at a time. Now the user
;; is presented with all the matches at once in a buffer, similar
;; to the way that completions, list-tags, or tags-apropos are handled.
;; Removed next-p in vtags-find-internal, etc. Now vtags-find-internal
searches all tag files.
;;
;; Deprecated the tag ring in favor of placeholders.
;; Placeholders navigation is more natural, allowing forward and back,
;; similar to the way debuggers allow programmers to navigate up and down
;; a call stack, or to the way browsers allow history navigation.
;;
;; Ripped out cached completions, i.e. tags-completion-table.
;; These are not useful since they take forever to compute without a prefix
;; (and people almost never use completion without a prefix).
;;
;; Eliminated tags-file-name. Users should use vtags-table-list instead.
;; There were too many global variables tracking
;; the same or overlapping functionality.
;;
;; Eliminated select-tags-table and all other references to
tags-table-set-list.
;; There may be some merit to allowing the user to select a set of tags
tables
;; from a list of sets, but it seems to me that the previous implementation
;; was too complicated, too rigid, and too poorly documented, and too
implicitly
;; entangled with the rest of the tags functionality to be easily
salvageable.
;; See Design Notes below.
;;
;; Eliminated `tags-table-computed-list'. There is no evidence that
;; this optimization was needed.  Let Emacs and the OS cache file stats
;; if needed.
;;
;; Removed 'button and 'apropos dependency, using vtags-mode instead.
;; We don't need all the features of button and apropos, and removing
;; them makes the code more portable and independent.

[-- Attachment #2: Type: text/html, Size: 3809 bytes --]

  reply	other threads:[~2014-06-06 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 14:23 From etags to ctags? Danil Orlov
2014-06-04 18:00 ` Stefan Monnier
2014-06-04 18:44   ` John Yates
2014-06-04 19:40     ` Stefan Monnier
2014-06-06 19:01       ` John Yates [this message]
2014-06-05  1:11 ` Eric M. Ludlam

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='CAJnXXoi_ThVqoozZbT3JZXL9c=wUtqtyOOjCeiFivSno6ftGrw@mail.gmail.com' \
    --to=john@yates-sheets.org \
    --cc=binutils@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=zargener@gmail.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 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).