On Fri, Mar 4, 2011 at 3:13 PM, Stas Boukarev <stassats@gmail.com> wrote:

I'm actually quite surprised what could've prompted to conclude that there is any kind of a conflict.

B/c `slime-eval-print-last-expression' and `slime-eval-last-expression' (wrapper around `slime-interactive-eval') provide essentially the same functionality and the return value of each should be consistently transparent: ,---- (documentation 'slime-eval-print-last-expression) | Evaluate sexp before point; print value into the current buffer `---- ,---- (documentation 'slime-interactive-eval) | | Read and evaluate STRING and print value in minibuffer. | | Note: If a prefix argument is in effect then the result will be | inserted in the current buffer. | `---- B/c `slime-eval-print-last-expression' should not be seeing the dynamic binding that happens around *standard-output* per SWANK:EVAL-AND-GRAB-OUTPUT `slime-eval-print-last-expression' `-> slime-eval-print `--> slime-eval-print `---> SWANK:EVAL-AND-GRAB-OUTPUT (defun slime-eval-print-last-expression (string) (interactive (list (slime-last-expression))) (insert "\n") (slime-eval-print string)) (defun slime-eval-print (string) "Eval STRING in Lisp; insert any output and the result at point." (slime-eval-async `(swank:eval-and-grab-output ,string) (lambda (result) (destructuring-bind (output value) result (push-mark) (insert output value))))) ;; swank.lisp around the form: (*standard-output* s) (defslimefun eval-and-grab-output (string) (with-buffer-syntax () (with-retry-restart (:msg "Retry SLIME evaluation request.") (let* ((s (make-string-output-stream)) (*standard-output* s) (values (multiple-value-list (eval (from-string string))))) (list (get-output-stream-string s) (format nil "~{~S~^~%~}" values)))))) ;;; ============================== `slime-eval-last-expression' `-> `slime-eval-last-expression' `--> `slime-interactive-eval' `---> `SWANK:INTERACTIVE-EVAL' (defun slime-eval-last-expression () "Evaluate the expression preceding point." (interactive) (slime-interactive-eval (slime-last-expression))) (defun slime-interactive-eval (string) "Read and evaluate STRING and print value in minibuffer. Note: If a prefix argument is in effect then the result will be inserted in the current buffer." (interactive (list (slime-read-from-minibuffer "Slime Eval: "))) (case current-prefix-arg ((nil) (slime-eval-with-transcript `(swank:interactive-eval ,string))) ((-) (slime-eval-save string)) (t (slime-eval-print string)))) (defslimefun interactive-eval (string) (with-buffer-syntax () (with-retry-restart (:msg "Retry SLIME interactive evaluation request.") (let ((values (multiple-value-list (eval (from-string string))))) (finish-output) (format-values-for-echo-area values))))) -- /s_P\

On Fri, Mar 4, 2011 at 3:39 PM, Stas Boukarev <stassats@gmail.com> wrote:

...

B/c `slime-eval-print-last-expression' and `slime-eval-last-expression' (wrapper around `slime-interactive-eval') provide essentially the same functionality and the return value of each  should be consistently transparent: Please, don't cross-post. It's really inconvenient.

There are AFAIK two separate issues. a) Whehter there is a bug Launchpad has the bug report marked invalid even though there was a pending question from TCR as to what the nature of the bug may be. b) Whether the existing API is understood by _others_ to be in conflict. That the conflict is an invalid bug does not mean that the scope of the issue shouldn't be recorded to the mailing list for future reference. If you had waited for a response on launchpad prior to marking the bug invalid then I could understand your admonition that it is "really inconvenient". However, without a chance for others (not just the set of one whose sole member is Stas) to consider the issue at hand it seems "inconvenient" that you would squash my reasoned attempt to present what I believe is a problem. Maybe someone sometime in the future will find reference to the problem description in this thread useful. FWIW Slime is descended from ilisp... -- /s_P\