`last-command' exposes implementation of the package

[fehmud]

Hello,

thanks for sharing this useful package.

There is a problem with the value of last-command after having executed any command from this package. The value of last-command will be the internal iy-go-to-char--command instead of iy-go-to-char or any other command from the interface of the package. This is a problem when writing a new command that builds on this package.

Thanks for your attention.

[doitian]

It is tricky to support multiple cursor. I'll check to see how to work around it.

[fehmud]

Thanks for your quick reply.

I am not an Emacs Lisp expert, but maybe you could set this-command before returning from each command. For instance, for iy-go-to-char we would have:

(defun iy-go-to-char (n char)
     ;; Implementation of `iy-go-to-char`
     (setq this-command 'iy-go-to-char))

[doitian]

Do you have any plan to build a command based on this package? I don't see any benefit of it. This package is intended to be used by end user, instead of used as a library.

What you suggest is just the default behaviour of emacs. The problem is that when multiple cursor is enabled, iy-go-to-char will prompt you the char to search in every cursors.

[fehmud]

Thanks for your assistance.

I have already adapted two custom commands to use this package, namely my own "smart" commands that I have bound to C-w and M-w. To accomplish this, I had already disabled the temporary map (before the version 3.2.2 of the package allowed it).

I have never used Multiple Cursor, so I don't know what to say regarding interactions with that package. Maybe this package could rely on a buffer-local variable instead of last-command?

Anyway, tampering with last-command seems wrong. Even a package that is intended to be used by end users shouldn't leak its implementation. You never know what users could decide to do with a package. At least, the README should mention this quirk.