The Erlang programming language promotes the handling of functions deconstructing the arguments in different clauses. Its the natural way of the language. Its so common.
Most modules end-up with functions like these:
handle_call({hora, Persona}, _, State=#{persona_oper:=PersonaOper, schedule:=Schedule}) -> ... handle_call({head, Operador}, _, State=#{oper_persona:=OperPersona, schedule:=Schedule}) -> ... handle_call(active_heads, _, State=#{oper_persona:=OperPersona, schedule:=Schedule}) -> ...
That whole pattern is just one function and each clause looks like any other function definition. Sometimes these functions tend to get big, as in any language depending of the problem they solve...
The SYMBOLS panel displays this clauses as: https://imgur.com/S4gy2sc.png
As you can see the panel lists the clauses but then it doesnt give any lights about the function anymore. Thats a hole of information right there, whenever I'm analyzing these clause functions I just begin to strugle with exploring the code
Is there a way to tune the panel to list the complete line or maybe cut it but list them in raw so now they can present the information transparently?
For example handle_call({hora, Persona}, _, State=#{pe... [203] handle_call({head, Operador}, _, State=#{.... [212] handle_call(active_heads, _, State=#{oper_... [219]
Most functional languages' function definitions tend to promote this pattern of development so their syntax in this aspect are quite refined. There is no need for cute visuals when the syntax is expressive enough, which is the case here.
Geany doesn't handle overloaded functions very well, the same problem happens in languages like C++. Overloaded functions are not immediately distinguishable, but if the language parser parses the argument list, when the cursor is on the symbols sidebar the tooltip shows the argument list for the symbol under the cursor, which allows you to distinguish the overload you want to click on to go to it.
This does not work for Erlang, presumably because the Erlang parser doesn't parse the argument list, also supported by the the fact that no calltips are shown. The parsers come from the [Universal Ctags](https://github.com/universal-ctags/ctags) project and the change needs to happen there first.
Showing the argument list in the symbol list is the way other IDEs handle distinguishing overloads, so its probably a reasonable improvement, but "somebody" has to do it.
A check of the latest Erlang parser in Uctags shows it does not parse the function arguments.
A check of the latest Erlang parser in Uctags shows it does not parse the function arguments.
I have never read ctags codebase. Can you point me a parser which does distinguish overloads?
Technically none of them do AFAIK, but some parse the parameters and save that as extra information on the tag. That will allow a human to distinguish the overload they want when they use the tags.
The ctags parsers are in the parsers directory of the project I linked above.
github-comments@lists.geany.org