[code] Updated proposal for better ctags support

From: Carlos Pita <carlosjosepita.att.gmail.com>
Date: Wed, 2 Jul 2014 12:52:25 -0300

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:

1) Generic go-to-definition functionality.

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.

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.

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?

Best regards

--
Carlos
-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Wed 02 Jul 2014 - 11:52:25 EDT

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