Re: [code] Updated proposal for better ctags support

From: Mitchell <>
Date: Wed, 2 Jul 2014 17:50:58 -0400 (EDT)

Hi Carlos,

On Wed, 2 Jul 2014, Carlos Pita wrote:

> Hi all,
> a couple of months ago I proposed a couple of changes to adeptsense in
> order to better cope with completions and code navigation. Shortly
> after that there was the textadept overhaul that removed adeptsense
> from the core. So now, things a bit settled down, I would like to ask
> if there are plans to factor out some ctags basic functionality in
> order to provide:

First of all, I don't have any plans to do this because I don't use ctags.
However, I recognize the utility of ctags and am certainly open to
patches. For now I recommend going the route of an external module.

> 1) Generic go-to-definition functionality.

This would be a good first start and the result would likely be added to
Textadept builds.

> 2) Common routines for language modules that implement autocompletion
> on top of ctags.
> 3) Language agnostic autocompletion based on ctags, as a complement to
> the autocompletion based on symbols in current buffers.
> I think that all of the above could be implemented using two simple
> building blocks:
> a) Base routines to load, cache, filter (by language, scope, type,
> prefix, pattern) and iterate ctags files that would be used by both
> language modules and ...
> b) ... a generic symbol list dialog offering the ability to (i) filter
> the symbol list and (ii) execute a final action based on the selected
> symbol: go-to-definition or autocomplete the word under cursor.

Adeptsense was an experiment for this functionality, but the generic
routines I came up with had too many holes in them. Perhaps you can do
better, but I'm not terribly optimistic. That's why some of the language
modules that utilize ctags in the new autocompleter functions (e.g. ANSI
C, Python) have their own separate implementations.

> This dialog could by taylored to a number of typical use cases by
> instantiating it with different default settings:
> - A language module could provide a scope filter to get
> context-sensitive autocompletion (and also context-sensitive
> go-to-definition -kinda poor man's outline-).
> - Generic go-to-definition would preset the final action to
> go-to-definition and (optionally) the prefix filter to the word under
> cursor (in this last case, a language filter for the current buffer
> language could be a sensible default, also, since the prefix belongs
> to the buffer).
> - Generic ctags-based autocompletion would preset the final action
> to autocomplete and the prefix filter to the word under cursor (again,
> a language filter for the current buffer language would be a sensible
> default, IMO).
> A nice thing is that the user would be able to further refine the
> filtering if she wished to do so but that the defaults are appropriate
> to support the typical use cases.

This sounds good in principle, but again, it would be difficult to get
working in a generic sense. Adeptsense tried a few of these things and
fell short.

> I know I'm glossing over a lot of details here (there's a lot to be
> discussed about the right filters, the right defaults, etc.) but all
> in all I think the proposal is both simple and general.
> Despite some of this stuff was already part of adeptsense I don't see
> this as a retreat to adeptsense but as a recognition that ctags is a
> versatile tool very useful as common denominator for a large number of
> situations in which real parsers and code analyzers aren't there to be
> integrated, or are difficult to integrate, or integration is
> undesirable from an economic (in the more general sense of the word)
> perspective.
> If LOCs are a concern an external module could be a good place to
> implement ctags support as an extension.
> What do you think?

I would be very interested in seeing what you come up with as an external
module for the time being. Feel free to ping the list with more ideas or


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Wed 02 Jul 2014 - 17:50:58 EDT

This archive was generated by hypermail 2.2.0 : Thu 03 Jul 2014 - 06:35:56 EDT