Re: IDE

[Eric Ludlam]

On 10/16/2015 11:06 PM, Dmitry Gutov wrote:
> On 10/17/2015 05:39 AM, Eric Ludlam wrote:
>
> > The magic of overlays is that the overlays keep the bounds of the tag up
> > to date for you.  Once you stop editing, and incremental parser fixes up
> > any weird things you might have done, such as hacking a tag in half,
> > adding new tags, etc.  Because it is incremental, is typically
> > instantaneous.
>
> Is that still true if you're editing at the beginning of the file?

Yes.

> > I am not familiar with SMIE as an acronym, but a google search makes it
> > look like someone made a parser generator, in which case there is no
> > real difference except that SMIE is tuned for indentation, and wisent is
> > tuned for parsing tags.
>
> My point is, Semantic grammars don't help with writing indentation 
> code (could they?), and we already have SMIE grammars for several 
> languages. It would make sense to be able to make do only with one or 
> the other, not have them both for the same language.

Ah, I think I see what you are poking at.

There is nothing about semantic the framework that prevents using 
something like SMIE as a tagging engine.  It seems likely that if some 
language not supported by CEDET today has a good SMIE grammar, and if 
SMIE could be adapted to produce compatible tags (which isn't really 
that hard to do), and if SMIE has an entry point that allows parsing a 
tag set out of a region, then it would integrate into the semantic 
framework at the best level.

The difference is that the parser generators in Semantic today have 
optimizations for skipping parts of the buffer while tagging.  This lets 
it parse whole files more quickly, and more robustly.  Since it uses 
syntax tables to do that, I'll guess SMIE can do it, but I'm not that 
familiar with it.

Also, wisent type grammars could easily dump out data you need for 
indentation since actions can do anything you can write in lisp.  No one 
has tried to do it though.

> > If by "open all project files" you mean pull file contents into a buffer
> > and leave it open, then that is not what semantic does.  The data is
> > indeed resident in memory, but files stay closed unless the user asks to
> > jump there.  The first time you make a request that needs searching, it
> > will open files to parse them, but then it closes the file. Later, it
> > refers only the the cached data, not to the files.
>
> I mean that you have to use etags at some point anyway. Or gtags, or 
> id-utils, etc.

Have to, no.  Want to, probably. Those tools provide nice short-cuts 
when doing simple name lookup.

The mechanism in use is that there are detailed taggers, like those 
currently written for Semantic using wisent type parsers, and weak 
taggers, like GNU Global.

Once a buffer is open, the detailed tagger runs and is truth.  When a 
search occurs, a process of pulling all relevant databases together is 
started.  This includes tags from the detailed taggers already cached, 
and high level 'omniscient' taggers that are usually weak, but have 
scanned the whole project.  The output of the search includes a database 
table, and tags found in that table.  The tags are additionally refined 
based on whatever the layered criteria is, and when the code decides to 
work with a detailed tag from the search, it forces it to be real, and 
pulls it into a buffer if necessary, and any problems with the weak 
tagger is resolved.

The key here is that the detailed tagger is needed to do complex tasks, 
but weak taggers are great to integrate in due to the speed advantage.  
Having a mix gives you the best possible results.

> > CEDET/Semantic usually gets foo.bar() syntax correct, unless you are
> > saying something else.  Can you elaborate?
>
> In the few languages it properly supports now? Maybe it does, most of 
> the time (although not in the problem example I gave in this 
> discussion: https://gist.github.com/dgutov/19c45ef43d1c90b96483; no 
> matter the argument tee is called with, `C-c , J' jumps to the first 
> function with that name).

I missed that before.  The answer here is that:

C-c , J RET

has two results.  Since that is a prompt based query and only the string 
is available once it is up.  If instead you put the cursor on "tee" and do

M-x semantic-ia-fast-jump RET

it will go to the right spot.

For the keybinding you were using, the workflow is:

C-c , J tee TAB

shows you where it would jump, then

TAB

refines to the next possible target.  Hit RET when it shows you the 
place you do what to jump to.

It needs more typing since the default isn't on the prompt.  Perhaps 
that is a possible improvement.

Can all this be improved - sure.  I agree it would be nicer to mix the 
two workflows better.  Most of my time goes into the parsers etc.

> But what about duck typed languages? If a method foo calls bar on its 
> argument tee, we don't know the type of tee, all we know that it has a 
> method bar.

In the workflow above, you can just keep pressing TAB to pick the one 
you want.

Eric