-
Notifications
You must be signed in to change notification settings - Fork 332
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
Grabbing multiple outputs in swank:eval-and-grab-output #554
base: master
Are you sure you want to change the base?
Conversation
One question from @luismbo I left unanswered concerns |
c94ea67
to
fbd0679
Compare
b823dc3
to
a477508
Compare
3764e4e
to
8520569
Compare
8520569
to
05771e5
Compare
05771e5
to
36a4181
Compare
36a4181
to
c122076
Compare
859ff65
to
4a0e1cb
Compare
ceb6ba7
to
7264b1d
Compare
7264b1d
to
1e5bfe7
Compare
1e5bfe7
to
c147f2a
Compare
2186322
to
d2a5d41
Compare
Could we return to this please? Everything is backward-compatible now, and the feature needs to be merged into slime first, then into Org. |
@akater I have some refactoring suggestions, but before getting to that, I'm wondering to you think about my question regarding interleaving output in #551 (comment) |
Yes, it makes sense. However, it should not happen in `eval-and-grab-output`: it should be up to higher level interfaces how to combine the outputs. I guess elisp's `slime-eval-save` does count as such but I don't use it so I hold no opinions on what it should do. I only have a clear vision for the interface of `eval-and-grab-output`.
|
@akater but if |
Let's provide an additional combined stream with SLIME's custom tag, e.g. `slime:debug-and-trace-output`, — but keep the original ones. Having use cases from my practice in mind, I would not want to see anything irregular in trace output simply because it could break structural editing modes like paredit or lispy.
|
@akater can you give me an example where's you'd prefer to see output segregated by stream rather than interleaved? |
An example with trace-output:
https://gitlab.com/akater/cl-serere/-/blob/master/serere.org#L1506
A general (non-trace) example would be literally any block in that repository.
|
That example only has trace output, it doesn't show output from other streams does it? |
Exactly. Looks like you expected a more elaborate answer but I don't know what else to say — it only exemplifies my point. I evaluate that form to get the trace.
|
@akater What I mean is, given (defun foo (x)
(print x))
(trace foo) what output do you expect to grab with |
All of it.
It depends on
but it presumes some guessing by org-mode so I'm not certain. I'd rather discuss this in emacs-orgmode mailing list, and I'd rather do it when diverse multiple stream contents are actually available in org-mode to combine. |
d2a5d41
to
d8cfedf
Compare
d8cfedf
to
6f40775
Compare
6f40775
to
e9c51e5
Compare
ead2e2e
to
89831f5
Compare
89831f5
to
3a280ab
Compare
3a280ab
to
b30a2de
Compare
b30a2de
to
66685e1
Compare
e497165
to
abe1822
Compare
It is often desirable to get output from time and trace in Emacs, particularly in org-babel. This patch extends swank:eval-and-grab-output to support emitting *trace-output*; it also introduces *error-output*, for good measure. We check whether eval-and-grab-output caller presumes older interface to it and return a legacy list of two elements instead of alist in those cases. This check can very likely be dropped when either Emacs 27 or Org 9.4 become unsupported.
abe1822
to
ff23e4e
Compare
The suggestion had previously been discussed in PR #551 but I proposed an incompatible change then. Patches suggested here ensure everything is backwards-compatible.
swank:eval-and-grab-output
now returns alist with many possible outputs, if they were requested in the call. (Return values are provided in that alist too.) Outputs are requested in an optional argument. If optional argument is not supplied, we infer that caller uses old interface and return standard output and values as they are returned now. It thus doesn't break anything.The check for old interface can certainly be dropped when Emacs 27 is not supported anymore, and can very likely be dropped when Org-mode adopts new interface (Org-mode is likely the only user of
swank:eval-and-grab-output
in the present day Emacs; I did check). I have a corresponding patch ready for Org-mode but it's difficult to test until SLIME merges this.My main motivation was to make traces and errors accessible to Org-Babel. I use the feature very often (mostly traces).
My Org-mode patch also ensures backwards compatibility with stable SLIME releases. I presume this feature can be used since SLIME 2.25. Please correct me on this if needed.
The only Elisp functions affected are
slime-eval-print
andslime-eval-save
. They behave exactly as they do now.