[slime-devel] backward-sexp and slime-pprint-eval-last-expression
I've been using slime-pprint-eval-last-expression on some expressions in .files in slime and came across the following: #(0) works fine, but #2A((0)) doesn't, as slime relies on emacs' backward-sexp to compute the sexp to eval. Would it be desirable to extend this to be reader-macro aware? thanks, Cyrus
On 7 May 2012 05:37, Cyrus Harmon <ch-slime@bobobeach.com> wrote:
doesn't, as slime relies on emacs' backward-sexp to compute the sexp to eval. Would it be desirable to extend this to be reader-macro aware?
I've been contemplating about the same thing re. indentation. There's a hook that could be used for the purpose -- so it doesn't have to even depend on font-lock. Cheers, -- nikodemus
* Cyrus Harmon [2012-05-07 02:37] writes:
I've been using slime-pprint-eval-last-expression on some expressions in .files in slime and came across the following:
#(0)
works fine, but
#2A((0))
doesn't, as slime relies on emacs' backward-sexp to compute the sexp to eval. Would it be desirable to extend this to be reader-macro aware?
backward-sexp is under the jurisdiction of lisp-mode and not of slime-mode. So if you think that backward-sexp should handle this case differently, then you should file a bug report to the Emacs developers. I personally have no desire to add special support for reader macros. IMO, reader macros aren't worth the trouble. Helmut
On May 6, 2012, at 10:37 PM, Helmut Eller wrote:
backward-sexp is under the jurisdiction of lisp-mode and not of slime-mode. So if you think that backward-sexp should handle this case differently, then you should file a bug report to the Emacs developers.
Sure, but SLIME is under no obligation to use backward-sexp. I think SLIME, for common lisp code, should be a bit more intelligent about how it finds the previous sexp. This may not be a bug for emacs lisp, but it, as demonstrated by the #2A example I gave above, is clearly suboptimal for common lisp code.
I personally have no desire to add special support for reader macros. IMO, reader macros aren't worth the trouble.
If some who consider it worth the trouble were to make this work, would you accept a patch? thanks, Cyrus
* Cyrus Harmon [2012-05-07 06:00] writes:
I personally have no desire to add special support for reader macros. IMO, reader macros aren't worth the trouble.
If some who consider it worth the trouble were to make this work, would you accept a patch?
If the patch is shorter than 20 lines. Helmut
participants (3)
-
Cyrus Harmon -
Helmut Eller -
Nikodemus Siivola