[slime-devel] propose changes to `slime-marcoexpand-again' with patch

[MON KEY]

On Mon, May 9, 2011 at 4:23 PM, Stas Boukarev <stassats at gmail.com> wrote:
> To reiterate what I said on launchpad.
> The aforementioned scenario doesn't come up in any normal usage.

It is AFAIK "normal usage" to use completion when invoking interactive commands.
Regardless, who are you to say what is a normal usage pattern for
others Slime/Emacs users?

If the intent is that `slime-macroexpand-again' _only_ be available as
a command in "*slime-macroexpansion*" then the correct thing would be
to remove the (interactive) form from `slime-macroexpand-again' and
bind "g" inside an anonymous function which is active only when
`slime-macroexansion-minor-mode' is in play e.g.:

(define-key slime-macroexpansion-minor-mode-map "g" #'(lambda ()
(interactive) (slime-macroexpand-again)))

> If you
> do this accidentally, learn your lesson and don't do that again.
The accident isn't mine --  w/r/t `slime-macroexpand-again' Slime is
not careful enough about which buffer is current before erasing the
buffer contents.

No doubt I do like many other Slime users and patch my Slime to work
correctly rather than rely on memory to prevent myself from using an
interactive Slime command which does things it should _never_ do.

Fortunately for me I'm capable of locating the bug in slime and
patching my local copy of slime to prevent it from occuring again in
the future.

What I find problematic is that there is an obvious error in
`slime-macroexpand-again' which is easily remedied by changing one
form from:
 (slime-rcurry #'slime-initialize-macroexpansion-buffer (current-buffer))

to:
 (slime-rcurry #'slime-initialize-macroexpansion-buffer
  (get-buffer-create (slime-buffer-name :macroexpansion)))

Why should other users also be forced to needlesly learn to avoid (or
fix) a bug when the bug can be so easily remedied?

> Doing M-x slime-thread-control-mode will discard undo history as well,
> but I don't see you complaining about it.
>

Are you going out of your way to miss the point?

Its not only the discarding of buffer-undo-list that is problematic as
I've already indicated slime-macroexpand again relies on other
functions which erase-buffer!

It is the combination of (setq buffer-undo-list nil) (erase-buffer)
which is the underlying problem...

> I don't feel that the goal of slime is to provide an idiot-proof
> interface.

It certainly shouldn't be a goal to _provide_ idiotic interfaces nor
should it be to promote the feelings of adherents to idiotic interface
design.

Neither should the goal of Slime be to force its users into
acquiescence idiotic opinions on reasonable UI design (esp. where
these radically differ from those of the host Emacs).

Independent of your "feelings" (which are irrelevant to whether there
is or isn't a bug) can you point to any core _interactive_ Emacs
command which so blithely destroys both the users buffer content and
her ability to recover the destroyed content in a manner similiar to
that of `slime-macroexpand-again'? If you can not perhaps you should
re-examine your "feelings" w/r/t Slime user's expectations in lieu of
Slime's goal to interface with Emacs.

>
> Considering this, I see no point in fixing what isn't broken.

Considering that, maybe you are not the best arbiter of such matters.

Patient: "Doctor, my elbow hurts when I do this..."
Doctor:  "So what, my elbow doesn't hurt when you do that."

--
/s_P\