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 --]
next prev parent 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).