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@freebits.de : Wrote on Thu, 21 May 2009 11:45:26 +0200:
| Madhu enometh@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