[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6893: evaluating `'#'(lambda (b) b)8 ; => 8 with `eval-last-sexp' "C
From: |
MON KEY |
Subject: |
bug#6893: evaluating `'#'(lambda (b) b)8 ; => 8 with `eval-last-sexp' "C-x C-e" in `emacs-lisp-mode' |
Date: |
Tue, 24 Aug 2010 16:49:30 -0400 |
On Sun, Aug 22, 2010 at 6:49 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> So what about these?
>
>> `'#'8
>> ;=> (quote (function 8))
>
> What about it? C-M-b indeed shows that '#'8 is the sexp.
>
>> `#'?\x27?\x23
>> ;=> (function 39)
>
My point is that with these C M-b:
`'#'
`'
point is skipped back beyond the sexp at point to "M-b:".
Isn't there an implicit list after the last quote created by backquote?
It "feels" like there is with these:
`#1=#1#
;=> (nil)
`','#1=#1#
;=> (quote (nil))
`',#''#1=#1#
;=> (quote (quote (nil)))
`',#','#1=#1#
;=> (quote \,)
`,#','#1=#1#
;=> \,
`',#','nil
;=> (quote \,)
`',#',#1=#1#
;=> (quote \,)
>> Where did 35 go?
>
> That's a known shortcoming of syntax tables which aren't able to
> describe correctly the syntax of Elisp char constants.
Does that affect how the range of "last sexp" is allowed to extend beyond the
beginning-of-line only to find some arbitrary word barier a few lines up?
> But again C-M-b
> shows you correctly what C-x C-e considers as "the last sexp".
Yes well, even w/ C M-b hopping its still not a valid sexp for `eval':
`#'?\x27?\x23
=> (function 39)
(eval (function 39))
;=> 39
(eval `#'?\x27?\x23)
;=> Debugger entered--Lisp error: (wrong-number-of-arguments eval 2)
And besides, theres this anomaly too:
#&8"\377"
;=> "\377" (actually on Emacs 23.2 its => "ÿ")
`#&8"\377"
;=> "\377" (actually on Emacs 23.2 its => "ÿ")
`#&8"\x3fffff"
;=> "\377" (actually on Emacs 23.2 its => "ÿ")
Which would make sense except that _both_ of these manages to fail "correctly":
`'#s
`'#s" "
!string
=> Debugger entered--Lisp error: (invalid-read-syntax "#")
Despite the fact that C M-b for either of this forms:
`'#s(hash-table size 30 data (key1 val1 key2 300))
#s(hash-table size 30 data (key1 val1 key2 300))
puts point just after "#s".
I understand that the hash-table read syntax has a higher priority because its
newer but the cummulative effect of the various sharpsign quoting/evaluation
rules for the immediate sexp before point feels inconsistently biased when
viewed in the aggregate.
>
>
> Stefan
--
/s_P\