[slime-devel] parser state bugs

[Madhu]

I do not want you to turn slime into a structured editor which accepts
only what you think is right

* "Tobias C. Rittweiler" <87k54aokll.fsf at freebits.de> :
Wrote on Thu, 21 May 2009 11:45:26 +0200:

| Madhu <enometh at meer.net> writes:
|
|> Consider the following content in a slime buffer with the cursor at the
|> point indicated by the caret
|>
|> |#
|> (defun foo ()
|>   (getf 
|>        ^
|> (slime-symbol-at-point) returns nil.  It should return "getf".
|
| Technically the behaviour is correct. The vertical bar initiates a
| symbol which is not terminated. If you add a | at the cursor position,
| `slime-symbol-at-point' will correctly return the whole thing.

I expected this sort of weasel reply, which is why I am reluctant to
spend more time on more detailed test cases.  The parser gets confused
even when it is other cases where there is perfectly legal code for
example

#|
|#

Its harder to get into these situations, but theyre happening.  I really
think this is an issue with your code quality and not thinking issues
out and not testing things out enough

I'm also running into problems where C-c C-c (slime-compile-defun) and a
subsequent M-n M-p gets the line numbers wrong and takes you to the top
of the file depending on whether the cursor is at column 0 or elsewhere.

| It's probably rather surprising, though. I committed to fallback to
| not look at the surrounding context.
|
| If you want to overwrite this, you can redefine
| `slime-beginning-of-symbol' and `slime-end-of-symbol'.

I'd rather not use faulty logic at all and just use elisp's
symbol-at-point.  

To reiterate the request you snipped out, I think it would be better if
one had a way to isolate themselves from these sort of changes: Could
all buffer fontification code please be moved to an optional contrib?
including the complexities you are introducing in this department]

--
Madhu