Guaxinim - Literate Programming with Hyperlinked Source

Pinging @josevalim because of an old discussion (here: Access to some information not available in mix xref) regarding opening up parts of the Mix.Xref for external use. Currently, Guaxinim requires access to the runtime_dispatches and compile_dispatches to find the function calls in the source. I assume similar projects might be interested in this information too.

Making these fields accessible (properly encapsulated, of course) doesn’t seem o constrain Mix.Xref a lot.

Also, some parts of Guaxinim could be included in Mix.Xref. Currently, Mix.Xref doesn’t find intra-module function calls, which is very easy to do with access to the BEAM debug chunks.

Heh, this is really cool, a very nice source viewer! Definitely needs that dark theme though. ^.^
Perhaps some of the vertical whitespace in lines to be reduced too?

The whitespace before titles will certainly be reduced. The whitespace between paragraphs probably not. The text would become too cramped.

I was even referencing between the lines of source code too as well as that. But then again I have the same issue with ex_doc too, so eh… ^.^;

Well, I can give you a way of passing your custom CSS file. It’s easy.

And the pages use mostly bootstrap classes for layout, so if you know bootstrap you can make it work.

It’s all HTML and CSS now. The only JS is the one required by Makeup to match delimiters on mouseover. I don’t want to include more JS (I don’t like having a little JS - I prefer either no JS ot full-blown framework).

The issue is the API guarantees. For example, last week we changed runtime_dispatches and compile_dispatches to also include the file in some cases and that would have broken any code that relied on those functions to return only lines, as it did before. It has more information now but the change could be considered a breaking one.

The other downside of relying on runtime_dispatches and compile_dispatches is that then it is a tool specific to Mix? Could I for example have a foo.exs file that would just work with that?

This rocks. I’ve been wanting something like DXR to browse Elixir code. Thanks for making this.

Regarding API stability, couldn’t you provide s public function that returned maps isntead of tuples? That way even if you have new information you won’t break anything, even if the user uses pattern matching.

Yes, it depends on Mix. I use Mix to read the compile manifests from which I take the data I mentioned above. I don’t know if this can be made not to depend on Mix easily. On the other hand, it can be made independent of the mix.exs file itself. I ha e to try and decouple it as much as possible

You’re asking if this works on .exs files instead of .ex? Sadly it doesn’t. But if you have a way of including those files in the compile manifests and generate BEAM files from them it can work, of course.

Right, we know that now. But in general that’s why I don’t want to couple implementation details with the external API.

We could add a new command to xref though that shows all the calls in a file with the respective line. That seems to be all that you need?

Yes, that’s enough, but I’d prefer a normal Elixir function instead of a command that forced me to parse text. For each function, I need something like:

{{module, function, arity}, caller_module, file, line}

Or possibly a map instead of a tuple. The caller_module might be optional, I have to see if I can derive it from the line number alone.

Maybe I should file an issue asking for the minimum amount of information I can’t derive any other way?