Re: IDE

[Eric Ludlam <ericludlam@gmail.com>]

On 10/16/2015 09:05 AM, Dmitry Gutov wrote:
> On 10/15/2015 03:57 PM, Eric Ludlam wrote:
>
>> CEDET will store tags into a set of overlays in the buffer.  That means
>> figuring out what tag the cursor is in is as fast as asking for what
>> overlay the cursor is in.
>
> I see. But you have to keep that info up-to-date as well, and that 
> becomes less fast, because you implement it in Elisp. If we're 
> comparing to an external program.
>

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.

>> Imenu stores it's tags in a list, so you need to scan the list to figure
>> it out. Imenu's tags are also weak, so the elisp knows very little about
>> the tag, only where it is, and enough to queue the reader.
>
> All true. But we have other facilities as well. For instance, the 
> modes which use SMIE for indentation can implement extraction of 
> similar information, in a more accurate way.
>
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.

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

>> Yes.  There are other tools that do different pieces of what CEDET does.
>
> I mean that you can't *really* use Semantic for "jump to a tag in the 
> project", because one doesn't usually like to open all project files 
> at once. But if the "daemon" proposal sees any development, maybe...
>

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.

>> * It lets you 'copy' a tag, and 'yank' it somewhere else.
>> * It provides an accurate 'beginning of defun', 'end of defun',
>>    'narrow to defun'
>
> Emacs usually provides fairly accurate definitions of these as well.

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.

>
>> * Provides a starting symbol for some commands, such as symref.
>
> 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.

>> * You can parse the local context more quickly determining nesting
>>    context (ie - method in a class) for decoding symbols (like "this")
>
> Yes, you can usually resolve what 'this' is (and, consequently, 
> this.foo()). But not what foo.bar() is, in the general case. Not in a 
> duck-typed language anyway.
>

CEDET/Semantic usually gets foo.bar() syntax correct, unless you are 
saying something else.  Can you elaborate?

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

Eric