Madhu enometh@meer.net writes:
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
If you're referring to the recent fontification issues, I can understand that impression. Please notice that that there were bugs before I touched the code, but an `ignore-errors' around the code were sweeping bugs under the carpet. I deliberately removed that so bugs can be found and be fixed. The net result is that shadowing suppressed forms works more reliably now.
Writing test cases for this particular code is sadly pretty difficult. It depends on the buffer content, the buffer length, the position of the cursor, and where you were before in the buffer.
If you're referring to `slime-symbol-at-point', I did add a fairly comprehensive test case at the time I wrote the current implementation. It apparantly was not comprehensive enough, and I committed additionally cases involving #|...|# style comments which currently fail. So thank you for raising the issue.
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.
I haven't yet encountered such behaviour. If you happen to discover a reproducible case, I'd like to hear about it.
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?
Fontification code is in the contrib slime-fontify-fu.el.
including the complexities you are introducing in this department]
I think the only changes to code that is not in the above file is that I added `slime-bug', changed `slime-current-parser-state' from saving match data, renamed `slime-eval-feature-conditional' and made it signal a condition. What are the complextities you're talking of?
-T.