bug#6439: `bkqt` <- eval-last-sexp return value => bkqt

bug#6439: `bkqt` <- eval-last-sexp return value => bkqt

[MON KEY]

With point after the following:

 `bkqt`

`eval-last-sexp' returns => bkqt

e.g.

(progn
  (insert "`bkqt`")
  (apply 'eval-last-sexp '(nil)))

Likewise, there is this weird behavior:

(progn
  (insert
   "\n\(progn\n"
   "  \(insert \"`bkqt`\"\)\n"
   "  \(apply 'eval-last-sexp '\(nil\)\)\)\n`\n")
  (apply 'eval-last-sexp '(nil)))

Why does evaluating the grave char evaluate the sexp preceding it but also does
something like this:

 (with-temp-buffer (insert "`````") (apply 'eval-last-sexp '(nil)))

Which signals an EOF?

Whereas this something like this doesn't:

 (with-temp-buffer (insert "`,(quote nil)`````") (apply 'eval-last-sexp '(nil)))


--
/s_p\

bug#6439: `bkqt` <- eval-last-sexp return value => bkqt

[Lars Magne Ingebrigtsen]

MON KEY <monkey@sandpframing.com> writes:

> With point after the following:
>
>  `bkqt`
>
> `eval-last-sexp' returns => bkqt
>
> e.g.
>
> (progn
>   (insert "`bkqt`")
>   (apply 'eval-last-sexp '(nil)))

I don't think recursive calls to `eval-last-sexp' are particularly
useful.

The command does some minor Do What I Mean to make it more useful, and
that means that you can make it return odd values if you're doing
something Nobody Could Possibly Mean.

So I don't think this is a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/