Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

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?

> 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.

>> If we were able to easily substitute in SMIE-based "current tag"
>> implementation instead of using Wisent, that would be a plus.
>
> The problem is the same (ie - go write a parser to find tags), except
> the SMIE tagger isn't implemented yet.

That's less work than writing a grammar, and it could be reusable (at 
least partially) across languages.

> 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.

> The difference is switching from "fairly" to "very", and mode authors
> would not need to go and write all those beginning-of-defun type overrides.

True enough.

>> I wonder if it's ideal: in IntellijIDEA, say, you can click on any of
>> the method's uses and to list the other references. With your scheme,
>> however, one has to jump to its definition first.
>
> There is always a desire to go two ways "where is the symbol under
> cursor", and "who uses the function I'm in".  I was describing the
> later.  The former is important, and not solved by my suggestion above.

I was also describing the latter. Although, I suppose, my way could be 
implemented on top of what Semantic does now, as long as it can "jump to 
the definition" accurately.

> 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).

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.

>> So, that's a problem. If we could, using semantic-symref could be made
>> more natural.
>
> Yes.  There is a spot in symref waiting with a comment for that nugget
> of code to be written.  My primary concern is that of performance since
> that data is derived, not cached.

Not sure what you mean here (which part you believe to have to be 
written yet, or which data we're talking about).

But in any case, symref can afford to be a little slow when prompting 
for a symbol name, just as long the slowness is not proportional to the 
size of the repository (or the multiplier is small, at least).