Thread: [Distel-hackers] erl-complete ...
Status: Beta
Brought to you by:
lukeg
Menu
▾
▴
distel-hackers
|
From: Pierre R. <pra...@ya...> - 2007-09-12 17:37:12
|
I am wondering why some completions do not seem to work. For instance "math:" only gives pi(). None of the functions in the erlang module seems to complete(list_to, is_, ...) The way completion works is really weak (the *Completion buffer do not close automatically). Is there someone interested in improving the feature ? I will try to compare the el completion code with Slime if nobody else out is willing to do it (I have no knowledge of el). Are there obvious reasons why it is difficult to backport ? Thanks for your help. |
|
From: Matthias R. <mat...@so...> - 2007-09-12 21:01:25
|
Pierre Radermecker wrote:
> I am wondering why some completions do not seem to work. For instance "math:"
> only gives pi(). None of the functions in the erlang module seems to
> complete(list_to, is_, ...)
This is not distel's fault. There is something odd about these modules;
xref cannot see much in them either:
(x@h)2> xref:start(foo, {xref_mode, modules}).
{ok,<0.158.0>}
(x@h)3> xref:add_release(foo, code:lib_dir(), {name, otp}).
ok
(x@h)4> xref:q(foo, 'X * math:_/_').
{ok,[{math,pi,0}]}
(x@h)6> xref:q(foo, 'X * erlang:"list_to.*"/_').
{ok,[{erlang,list_to_integer,2}]}
(x@h)7> xref:q(foo, 'X * erlang:"is_.*"/_').
{ok,[]}
Matthias.
|
|
From: Bill C. <bil...@gm...> - 2007-09-12 21:30:21
|
Matthias Radestock <mat...@so...> writes:
> Pierre Radermecker wrote:
>> I am wondering why some completions do not seem to work. For instance "math:"
>> only gives pi(). None of the functions in the erlang module seems to
>> complete(list_to, is_, ...)
>
> This is not distel's fault. There is something odd about these modules;
> xref cannot see much in them either:
>
> (x@h)2> xref:start(foo, {xref_mode, modules}).
> {ok,<0.158.0>}
> (x@h)3> xref:add_release(foo, code:lib_dir(), {name, otp}).
> ok
> (x@h)4> xref:q(foo, 'X * math:_/_').
> {ok,[{math,pi,0}]}
> (x@h)6> xref:q(foo, 'X * erlang:"list_to.*"/_').
> {ok,[{erlang,list_to_integer,2}]}
> (x@h)7> xref:q(foo, 'X * erlang:"is_.*"/_').
> {ok,[]}
Probably because they're BIF's that are implemented in C rather than
Erlang:
(emacs@bc)7> erl_bifs:is_bif(math, pi, 0).
false
(emacs@bc)8> erl_bifs:is_bif(math, sin, 1).
true
Do a "M-." on "math:pi()" and you'll see that it's the only function
in the source file.
- Bill
|
|
From: Bill C. <bil...@gm...> - 2007-09-14 20:06:55
|
Hi Matthias, Matthias Radestock <mat...@so...> writes: > Bill Clementson wrote: >> Matthias Radestock <mat...@so...> writes: >>> This is not distel's fault. There is something odd about these >>> modules; xref cannot see much in them either: > >> Probably because they're BIF's that are implemented in C rather than >> Erlang: >> >> (emacs@bc)7> erl_bifs:is_bif(math, pi, 0). >> false >> (emacs@bc)8> erl_bifs:is_bif(math, sin, 1). >> true >> >> Do a "M-." on "math:pi()" and you'll see that it's the only function >> in the source file. > > In which case I know how to fix this: [snip examples] Great - will you be preparing a patch to the Call Graph code so that who_calls will also return info on BIF's? > (except distel's completion currently isn't using xref, but it should) I guess the main problem with using xref for completion is speed. The xref who_calls build process is fairly slow and (if a lot of new functions are being added) could result in lengthy wait times when you want to get a completion. I guess you could use a separate (different from the who_calls server) xref server that always rebuilds and only gets functions for the specified module though. Was that what you had in mind? - Bill |
|
From: Matthias R. <mat...@so...> - 2007-09-14 20:34:10
|
Bill, Bill Clementson wrote: > Matthias Radestock <mat...@so...> writes: > >> Bill Clementson wrote: >>> Do a "M-." on "math:pi()" and you'll see that it's the only function >>> in the source file. >> In which case I know how to fix this: > [snip examples] > > Great - will you be preparing a patch to the Call Graph code so that > who_calls will also return info on BIF's? Changing the completion code to use xref, and include BIFs, is on my todo list. Don't know when I will get round to doing it though. The code I posted, together with the existing who_calls code and the explanation below should be enough for anybody to be able implement it. >> (except distel's completion currently isn't using xref, but it should) > > I guess the main problem with using xref for completion is speed. The > xref who_calls build process is fairly slow and (if a lot of new > functions are being added) could result in lengthy wait times when you > want to get a completion. I guess you could use a separate (different > from the who_calls server) xref server that always rebuilds and only > gets functions for the specified module though. Was that what you had > in mind? The current_who calls only builds the graph the first time you invoke it - which takes a while but is faster than what we had before - and then updates it incrementally for every subsequent invocation, which is very quick. For completion I would use a different xref instance, configured to operate in "modules" mode, which is sufficient in this case. See the code I posted in my previous email. The modules mode of xref is *much* faster to initialise - less than 2 seconds on my machine, so even the first invocation of completion will work at tolerable speed. As with who_calls, subsequent invocations will be set up to update the call graph with any changed modules. Matthias |
|
From: Matthias R. <mat...@so...> - 2007-09-12 21:45:15
|
Bill Clementson wrote:
> Matthias Radestock <mat...@so...> writes:
>> This is not distel's fault. There is something odd about these modules;
>> xref cannot see much in them either:
> Probably because they're BIF's that are implemented in C rather than
> Erlang:
>
> (emacs@bc)7> erl_bifs:is_bif(math, pi, 0).
> false
> (emacs@bc)8> erl_bifs:is_bif(math, sin, 1).
> true
>
> Do a "M-." on "math:pi()" and you'll see that it's the only function
> in the source file.
In which case I know how to fix this:
(x@h)30> xref:start(foo, {xref_mode, modules}).
{ok,<0.7716.0>}
(x@h)31> xref:set_default(foo, builtins, true).
{ok,false}
(x@h)32> xref:add_release(foo, code:lib_dir(), {name, otp}).
{ok,otp}
(x@h)39> xref:q(foo, '(X+B) * math:_/_').
{ok,[{math,exp,1},{math,log,1},{math,pi,0},{math,pow,2},{math,sqrt,1}]}
(x@h)40> xref:q(foo, '(X+B) * erlang:"is_.*"/_').
{ok,[{erlang,is_alive,0},
{erlang,is_atom,1},
{erlang,is_binary,1},
{erlang,is_boolean,1},
{erlang,is_builtin,3},
{erlang,is_constant,1},
{erlang,is_float,1},
{erlang,is_function,1},
{erlang,is_function,2},
{erlang,is_integer,1},
{erlang,is_list,1},
{erlang,is_number,1},
{erlang,is_pid,1},
{erlang,is_process_alive,1},
{erlang,is_reference,1},
{erlang,is_tuple,1}]}
(except distel's completion currently isn't using xref, but it should)
Matthias.
|
|
From: <mat...@so...> - 2007-09-15 04:49:55
Attachments:
distel_xref_complete.patch
|
Bill,
Bill Clementson <bil...@gm...> writes:
> I was asking about a patch for the Call Graph code that you wrote
> previously. At the moment, the "who calls" support doesn't work for
> BIF's.
Oh I see. Is it really that useful to have that? I don't often find
myself wondering who calls a particular BIF.
I added builtins to the call graph xref server - see attached patch -
but it doesn't seem to make a difference. I suspect BIFs are only added
as unconnected vertices.
>>>> (except distel's completion currently isn't using xref, but it should)
> Does the attached patch do what you wanted?
Thanks for the patch. I've made the following changes:
- don't add otp release - the otp modules are part of the code path and
hence get loaded anyway
- filter duplicates (due to different arity) from function completion
- avoid duplication of code between who_calls and completion
- add rebuild_{completions, call_graph} functions - there is nothing on
the emacs side that calls them, but you can call them manually
- minor cosmetic changes
See attachment for the revised patch.
One remaining problem with this code is that it doesn't automatically
handle the addition/removal of modules or changes to the code load
path - you have to invoke the aforementioned rebuild functions manually
for this.
Matthias.
|
|
From: Matthias R. <mat...@so...> - 2007-09-15 05:00:05
|
mat...@so... wrote:
> I've made the following changes: [...]
There is one other thing you may want to change.
Currently the functions completion code doesn't actually use the
function name prefix. Yet it works, presumably because the filtering
happens on the emacs side (though I still have to figure out how).
Anyway, I reckon it would be cleaner to do the filtering on the erlang
side. For that just change
case xref_q(?COMPLETION_SERVER, ?COMPLETION_SERVER_OPTS,
"(X+B) * ~p:_/_", [Mod]) of
to
case xref_q(?COMPLETION_SERVER, ?COMPLETION_SERVER_OPTS,
'(X+B) * ~p:"~s.*"/_', [Mod, Prefix]) of
Matthias
|
|
From: Bill C. <bil...@gm...> - 2007-09-15 06:11:21
|
Hi Matthias,
mat...@so... writes:
> Bill Clementson <bil...@gm...> writes:
>
>> I was asking about a patch for the Call Graph code that you wrote
>> previously. At the moment, the "who calls" support doesn't work for
>> BIF's.
>
> Oh I see. Is it really that useful to have that? I don't often find
> myself wondering who calls a particular BIF.
I would imagine that it might be useful if one were refactoring code
and wanted to eliminate/replace/change calls to specific BIF's.
> I added builtins to the call graph xref server - see attached patch -
> but it doesn't seem to make a difference. I suspect BIFs are only added
> as unconnected vertices.
Perhaps.
>>>>> (except distel's completion currently isn't using xref, but it should)
>> Does the attached patch do what you wanted?
>
> Thanks for the patch. I've made the following changes:
>
> - don't add otp release - the otp modules are part of the code path and
> hence get loaded anyway
>
> - filter duplicates (due to different arity) from function completion
>
> - avoid duplication of code between who_calls and completion
>
> - add rebuild_{completions, call_graph} functions - there is nothing on
> the emacs side that calls them, but you can call them manually
>
> - minor cosmetic changes
>
> See attachment for the revised patch.
Much tidier than my patch.
> One remaining problem with this code is that it doesn't automatically
> handle the addition/removal of modules or changes to the code load
> path - you have to invoke the aforementioned rebuild functions manually
> for this.
I don't think that's much of a problem. At least it's consistent for
both the completions and the call graph servers and it's easy enough
to invoke the rebuilds.
I've applied your patch (as well as the mod you sent in your later
message) and have committed the changes.
Thanks,
Bill
|
|
From: Pierre R. <pra...@ya...> - 2007-09-22 00:05:34
|
> > I've applied your patch (as well as the mod you sent in your later > message) and have committed the changes. > Thanks for the fix ! Would be nice to have completion for the erlang BIF that don't require the module prefix (like is_tuple(Term)) Is it in the to-do list ;-) |
|
From: Bill C. <bil...@gm...> - 2007-09-25 20:58:45
|
Hi Pierre, Pierre Radermecker <pra...@ya...> writes: >> I've applied your patch (as well as the mod you sent in your later >> message) and have committed the changes. >> > > Thanks for the fix ! > > Would be nice to have completion for the erlang BIF that don't require the > module prefix (like is_tuple(Term)) > > Is it in the to-do list ;-) It wasn't in my to-do list - is it in yours? ;-) I'm not sure if there's any way of determining what all of the available BIF's are at runtime. Do you know of any way to do this? - Bill |
Thanks for helping keep SourceForge clean.
X