new output goes to the front of slime presentations about slime

[joaotavora]

Could not reproduce this. Closing until convinced otherwise.

[joaotavora]

Hmm, actually, reopening. The issuer should define "in front". The output I get goes before the presentation. Should it go after it? It's questionable... IELM can't be a good comparison in this case since it doesn't use the same REPL for results and output.

[csrhodes]

João Távora [email protected] writes:

Hmm, actually, reopening. The issuer should define "in front". The
output I get goes before the presentation. Should it go after it?
It's questionable... IELM can't be a good comparison in this case
since it doesn't use the same REPL for results and output.

Not the issuer, but I agree that output from a subsequent command should
go after the presentation from a prior command.

If more rationale is needed, consider doing some work at the repl, then
compiling a file. The compiler output will go to the slime repl, but
all behind the last output from the last form evaluated at the repl,
which will then be vastly disconnected from the form that produced it.

Christophe

[joaotavora]

@csrhodes yes that use case sounds reasonable, in fact, it happens to me quite often. Will have a look, but slime-repl.el's marker handling is a bit contorted. There are unit tests, but they are not too stable either, especially when both slime-repl.el and slime-presentations.el are enabled.