[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDE
From: |
Eric Ludlam |
Subject: |
Re: IDE |
Date: |
Sat, 17 Oct 2015 08:45:23 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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
- Re: IDE, (continued)
- Re: IDE, Eric Ludlam, 2015/10/15
- Re: IDE, Dmitry Gutov, 2015/10/12
- Re: IDE, Eric Ludlam, 2015/10/13
- Re: IDE, Dmitry Gutov, 2015/10/14
- Re: IDE, Eric Ludlam, 2015/10/15
- Re: IDE, Przemysław Wojnowski, 2015/10/16
- Re: IDE, Dmitry Gutov, 2015/10/16
- Re: IDE, Dmitry Gutov, 2015/10/16
- Re: IDE, Eric Ludlam, 2015/10/16
- Re: IDE, Dmitry Gutov, 2015/10/16
- Re: IDE,
Eric Ludlam <=
- Re: IDE, Stephen Leake, 2015/10/17
- Re: IDE, Dmitry Gutov, 2015/10/17
- Re: IDE, David Engster, 2015/10/17
- Re: IDE, Dmitry Gutov, 2015/10/17
- Re: IDE, Eric Ludlam, 2015/10/19
- Re: IDE, Dmitry Gutov, 2015/10/19
- Re: IDE, Eric Ludlam, 2015/10/20
- Re: IDE, Lluís, 2015/10/13
- Re: IDE, John Wiegley, 2015/10/13
- Re: IDE, David Kastrup, 2015/10/13