Very very nice. But it should really be an action in clangd instead of its own tool, for simple integration with LSP.<p>Also instead of always replacing the text, it could also be an overlay, where the function call is temporarily expanded in your IDE while in some special mode.
rust-analyzer has this as well. I've never actually used it though. In most cases where I would have found it useful the function was so simple that I just did it manually without thinking. This also seems to do a better job cleaning up the resulting code than rust-analyzer does for example.<p><pre><code> let cell = self.cell_mut(pos);
</code></pre>
Becomes:<p><pre><code> let cell = {
let ref mut this = self;
&mut this.board[usize::from(pos)]
};
</code></pre>
Instead of:<p><pre><code> let cell = &mut self.board[usize::from(pos)];
</code></pre>
It did manage to simplify the argument (maybe because it was the same name?) but had to rename `self`.
wow seriously cool idea here, i think it could be expanded on.<p>currently my only tool is "jump to definition" & docstr tooltips, but if i could expand those definitions in place... i'd imagine i could grok the code much faster, because i could expand multiple functions and even nested functions, and read the code in one linear flow.
Makes me think of these two emails by John Carmack.<p><a href="http://number-none.com/blow/john_carmack_on_inlined_code.html" rel="nofollow noreferrer">http://number-none.com/blow/john_carmack_on_inlined_code.htm...</a><p>> The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).
I sincerely don't understand when is this useful. It basically removes all the existing abstractions in the code, and replaces with inline code. Those abstractions were created by someone for some reasons. Blindly destroying them in the name of "refactoring" is just wrong. Refactoring should be process that involves intellectual creativity, involves deeply understanding the intricacy of dependencies and references, not mechanically expanding functions and call it done.<p>Of course, just like rust-analyzer's "Expand macro recursively" command, this could be used as an analysis utility, even better if it works not only on functions but also C/C++ macros.
Thank you! It's a tool I dreamed of having for years, but couldn't arse myself to try and write.<p>The output seems nice enough it should be possible to integrate it with Emacs to show as overlay, vs. actually replacing code - though in practice, I'd probably want a mix of both.