Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large macro expansions are truncated #253

Closed
kdavy opened this issue Feb 7, 2013 · 6 comments
Closed

Large macro expansions are truncated #253

kdavy opened this issue Feb 7, 2013 · 6 comments

Comments

@kdavy
Copy link

kdavy commented Feb 7, 2013

When I expand a macro (C-c C-m) and the output is more than "about a page" it is truncated.

I am running nrepl version 20130205.706
Thanks.

@kingtim
Copy link
Member

kingtim commented Feb 7, 2013

Thanks for reporting this. I see the problem and I am working on a fix.

@sundbp
Copy link

sundbp commented Mar 6, 2013

+1
I also ran into this problem. Would love to be able to use C-c C-m. I can't seem to work out how to use macroexpand-1 via the repl or otherwise to actually see a proper macro expansion once the expressions get a bit bigger.

@sundbp
Copy link

sundbp commented Mar 6, 2013

If I use (foo [1 2 3 4 5 6 7 8 9 10]) as my expansion form, then it's fine up to repeat 40, but at repeat 41 the output is just:
2 3 4 5 6 7 8 9 10])

Interestingly if I use nrepl-macroexpand-1-inplace instead I see this highly confusing output:
2 3 4 5 6 7 8 9 10])(clojure.core/list
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[1

That suggests to me it's getting the results in "chunks" and perform insert (from pos 0) each time, i.e. what happens is (pseudo-code):
handle-result(output1)
handle-result(output2)

For the inplace version handle-result will insert at point and hence it prints the 2 chunks in reverse orders, for the non-inplace it erases buffer in the handle-result and hence "overwrites" so you just see the 2nd chunk.

I can sort of see the macro expand buffer flash by with the first output and then get reinitialized with the 2nd batch so that adds up.

So the fix would be to either wait for all chunks before outputting, or to append to buffer. I'll experiment and see if I can work that out, but I'm no elisp expert. The trick for waiting is to buffer results and "when you're done", and for append to buffer to known when the first call is made so you can create new buffer only for the first call and not the subsequent. i.e. need to keep some state between handler receives chunks one way or another.

The 2 functions on the output side are:
nrepl-initialize-macroexpansion-buffer (for the non-inplace version)
nrepl-redraw-macroexpansion-buffer (for the inplace version)

@sundbp
Copy link

sundbp commented Mar 6, 2013

I managed to fix the non-inplace expansion, but struggling to work out the logic for the inplace expansion.

In this pull request: #295

kingtim added a commit that referenced this issue Mar 12, 2013
expansion before emitting into expansion buffer.
@kingtim
Copy link
Member

kingtim commented Mar 12, 2013

Thanks @sundpb for the PR.
I just published the branch 'fix-macroexpand' with a different fix that also addresses inplace expansion as well.
@kdavy @sundbp @bwo could you please check it out and let me know if it resolves the issue for you? Thanks much.

kingtim added a commit that referenced this issue Mar 13, 2013
@kingtim
Copy link
Member

kingtim commented Mar 13, 2013

Merged #303 to fix this issue. Please let me know if there are any other further issues. Thanks!

@kingtim kingtim closed this as completed Mar 13, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants