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".
[I thought I had isolated myself from this department by setting `slime-highlight-suppressed-forms' to nil. Could all buffer fontification code please be moved to an optional contrib? including the complexities involved in department]
-- Madhu
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.
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'.
-T.
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
* Madhu m3ljoqd9jh.fsf@meer.net Wrote on Thu, 21 May 2009 16:09:46 +0530:
| 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 don't think this was directly related to my other crib in this thread, But there is a bug in `slime-goto-location-position':
diff --git a/slime.el b/slime.el index 058458b..a6c718a 100644 --- a/slime.el +++ b/slime.el @@ -3330,14 +3330,15 @@ you should check twice before modifying.") ((:function-name name) (let ((case-fold-search t) (name (regexp-quote name))) - (or - (re-search-forward - (format "\s *(def\(\s_\|\sw\)*\s +%s\S_" name) nil t) - (re-search-forward - (format "\s *(def\(\s_\|\sw\)*\s +(*%s\S_" name) nil t) - (re-search-forward - (format "[( \t]%s\>\(\s \|$\)" name) nil t))) - (goto-char (match-beginning 0))) + (and + (or + (re-search-forward + (format "\s *(def\(\s_\|\sw\)*\s +%s\S_" name) nil t) + (re-search-forward + (format "\s *(def\(\s_\|\sw\)*\s +(*%s\S_" name) nil t) + (re-search-forward + (format "[( \t]%s\>\(\s \|$\)" name) nil t)) + (goto-char (match-beginning 0)))) ((:method name specializers &rest qualifiers) (slime-search-method-location name specializers qualifiers)) ((:source-path source-path start-position)
Madhu enometh@meer.net writes:
- Madhu m3ljoqd9jh.fsf@meer.net Wrote on Thu, 21 May 2009 16:09:46 +0530:
| 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 don't think this was directly related to my other crib in this thread, But there is a bug in `slime-goto-location-position':
Thanks, applied. (replaced `and' with `when')
-T.
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.
-
Madhu -
Tobias C. Rittweiler