dobkeratops / rustfind Goto Github PK

scan comments for URLs, and make those clickable in the generated HTML view..

very handy with deep expressions and type inference .. the ideal would be if in the html view there was a popup showing type info.

a first step would be to have some way of querying type , not just 'jump to definition'.

This project really needs a license to define what everyone's rights are when working with the source and output.

use the jump-to-def info to generate call graphs,
maybe generate dotfiles for graphviz to render these out,
some sort of static linked html callgraph which links back into the sourcecode would be nice..
perhaps generate views of static callgraphs for each module ? (collapse functions to modules to make the amount of information in each page manageable?)

info from wiki
<mark_edward> there was a recent PR merged, that meant that chars could no longer be used as integral types
<mark_edward> lemme find it...
<doomlord__> oh does that break ioutil.rs by any chance :)
<mark_edward> it breaks.. this: https://github.com/dobkeratops/rustfind/blob/master/htmlwriter.rs#L81
<doomlord__> ok, yikes.
<mark_edward> also something seems to have changed about .unwrap_or_default
<doomlord__> i vaguely remermber talk about that but can't remember what changed..
<doomlord__> it might just be renamed to .unwrap_or() ?
<doomlord__> i seem to remember some discussion about wanting symetry between or's /elses
<mark_edward> right, right, lemme check
<doomlord__> hopefully the char thing is just something changing to u8s perhaps..
<mark_edward> hopefully... maybe there is still a way to get chars to ints, lol
<doomlord__> in the name of safety it's sometimes surprising what you cant do ... but in that instance i think i'm ultimately just transfrering charcters from one buffer to another.. ither might even be a more direct function
<mark_edward> doomlord__: do you think this will do it: http://seld.be/rustdoc/master/std/char/fn.to_digit.html
<doomlord__> ah - i had to translate soemthing ,
<doomlord__> oh yeah now i remember - its translating various things for html .. "<" -> "<" etc etc
<doomlord__> so its not a straight copy
<mark_edward> hmmm...
<doomlord__> perhaps that could be a key:value map if they really dont want chars indexable.
<doomlord__> ^or if they really dont want to use chars as ints (indices)
<doomlord__> self.doc.push_str(self.xlat[x]); <<<< sorry for the crytpic ASM inspired name, ".xlat" is a translation table holding all that.
<doomlord__> so xlat:[str] could be changed to xlat:hashmap<char,str>
<mark_edward> you think that approach won't break too much else? and do hashmaps have [x] indexing?
<doomlord__> it would be changed to "self.doc.push_str(self.xlat.find(x).unwrap_or(""))" i think
<doomlord__> similarly building xlat would be .insert(...)
<mark_edward> okay..
<doomlord__> https://github.com/dobkeratops/rustfind/blob/master/htmlwriter.rs <<< mk_xlat_table

would be nice to have links to rustdoc entries, and make it easy for those to link back to this source..

currently calls to methods on trait objects aren't handled;

in jumptodefmap.rs: fn lookup_def_node_of_node(../) , the match case for typeck::method_object(mp) is incomplete.. it probably needs to resolve these methods using its' method-index.. is there helper code in rust already for this ?

As a temporary fix It might be sufficient to just show the definition of the objects' trait - of course the exact impl' isn't inferable from a trait call... that would be better than nothing.

need version info in .rfx 'crosscratemap' to avoid using out of date info

commandline functions or indexed html pages to search all the traits implemented for a particular type
this could look like generating similar information to a C++ header.. type { all the methods supported , listed in one place..}
beyond that listing all the functoins that take a particular type as a parameter would also be useful..

would generating lots of static HTML for navigation this way get out of hand?

check what rustdoc_ng does first, stick to features that complement what that already does.

show the timestamp of the source file and/or other versioning info at the top of the file.

The HTML output of rustfind includes many different tags which are not valid html5, e.g. <ln>, <maintext>, <bg15>, <c..> for many cs, etc.

These should all be cleaned up so that the source uses semantic html5 tags instead.

straightforward index of symbol definitions might be nice

Currently the html always looks for a .css file in the same directory as the html output.
it would be better if they all referenced this from the same place,

it doesn't even copy this .css file into the output directories yet.. i'd been doing that manually for testing. the fact it uses a .css at all is a bit of an afterthought

I am working on this now. I am a relative novice in this area of programming, so feel free to do it yourself if I'm taking too long or not being to competent.

From a cursory examination, i should be able to make the port however