I know I said I didn't mind if this change was revered, but in the interest of correctness, I think the code Edi checked in again is plain wrong. Details below.
---------------------------- Original Message ---------------------------- Subject: Re: [slime-devel] Re: slime.el `slime-expand-abbreviations-and-complete' From: "Edi Weitz" edi@agharta.de Date: Sat, January 20, 2007 2:43 To: enometh@meer.net --------------------------------------------------------------------------
On 20 Jan 2007 10:34:55 -0000, Madhu enometh@meer.net wrote:
|However, I regularly use slime-complete-symbol* as my completion
|function (but with other pop-up settings) and my text never got |garbled. And I liked the behaviour where point was directly
|after the shortest unambiguous prefix.
With slime-complete-symbol* and a vanilla checkout, text gets garbled again on emacs21. Perhaps the property setting shennanigans dont
work on this emacs?
I think you are have not considered all use cases and are also ignoring the fact that if you are using emacs' `choose-completion'
facility, you are not allowed to shift the point to an earlier
position during the completion operation.
If you do wish to move the point, you should perhaps automatically
invoke the completion command programatically again. I am not sure how this can be done.
Even if it WFM, and provides a shiny feature, it should be clear that
the existing code is wrong?
I'd rather have this discussion on slime-devel if it's really necessary.
On Sat, 20 Jan 2007 17:34:51 -0800 (PST), enometh@meer.net wrote:
Even if it WFM, and provides a shiny feature, it should be clear that the existing code is wrong?
I don't know, I haven't checked. I just noted that you seem to be the only one who reported problems with it so far while it works fine for me (and not only for me as I positively know that other people also use slime-complete-symbol*).
My completely egoistic preference is that the behaviour where point ends up directly after the shortest unambiguous prefix is kept as is. If you insist on modifying this function, I'd suggest that you send a patch which a) works around your problems without changing what the function does or b) adds a customization option so that one can optionally force the function to work the way you want it. I know that Helmut doesn't like customizations, but for me they're fine - most of them I simply ignore hoping that the default is fine... :)
edi@agharta.de wrote:
On Sat, 20 Jan 2007 17:34:51 -0800 (PST), enometh@meer.net wrote:
Even if it WFM, and provides a shiny feature, it should be clear that the existing code is wrong?
I don't know, I haven't checked. I just noted that you seem to be the only one who reported problems with it so far while it works fine for me (and not only for me as I positively know that other people also use slime-complete-symbol*).
I'm rather confused. The behaviour of moving the point to the end of the word, rather than to the end of the unambiguous prefix, has been driving me up the wall, and I was just about to reopen the previous thread on the subject.
These messages seem to be implying that Edi has already checked in a fix for this bug, but I don't see any mention of it in the ChangeLog, and it's still broken for me with Slime 2007-01-20. Am I missing something?
* Juho Snellman slrner8166.fcm.jsnell@localhost.localdomain :
| I'm rather confused. The behaviour of moving the point to the end of | the word, rather than to the end of the unambiguous prefix, has been | driving me up the wall, and I was just about to reopen the previous | thread on the subject.
This surprises me. How do people use this function? if you type a minimum number of characters and try to complete, the bug in the original unambiguous prefix code that I tried to demonstrate in that thread exposes itself rather clearly.
Also, who is responsible for that original code?
| These messages seem to be implying that Edi has already checked in a | fix for this bug, but I don't see any mention of it in the ChangeLog, | and it's still broken for me with Slime 2007-01-20. Am I missing | something?
From a checkout of a few weeks ago, the "bug" was put back, there was no Changelog entry, but I noticed the original buggy behaviour was back. . You can grep for "unambiguous" in slime.el to find if your sources are upto date
-- Regards Madhu
enometh@meer.net wrote:
- Juho Snellman slrner8166.fcm.jsnell@localhost.localdomain :
| I'm rather confused. The behaviour of moving the point to the end of | the word, rather than to the end of the unambiguous prefix, has been | driving me up the wall, and I was just about to reopen the previous | thread on the subject.
This surprises me. How do people use this function? if you type a minimum number of characters and try to complete, the bug in the original unambiguous prefix code that I tried to demonstrate in that thread exposes itself rather clearly.
I've never seen any bugs with this before the changes last month. What I do is:
1. Type some characters 2. Complete 3. If ambiguous, go to step 1
Well, actually that's what I *would* do if this wasn't broken in CVS right now. As it is, the workflow is more like:
1. Type some characters 2. Complete 3. If ambiguous try to type some characters. Find that it's useless, since there are no ambiguities at the point 4. Switch to the *Completions* window that was opened 5. Arrow-key or C-s to the symbol that I want 6. Press enter 7. Press C-x 0 to close the now useless window that was opened 8. Curse
The latter workflow seems rather suboptimal, even if I could teach myself to avoid steps 3 and 8. So I would love to have the first one work again.
| These messages seem to be implying that Edi has already checked in a | fix for this bug, but I don't see any mention of it in the ChangeLog, | and it's still broken for me with Slime 2007-01-20. Am I missing | something?
From a checkout of a few weeks ago, the "bug" was put back, there was no Changelog entry, but I noticed the original buggy behaviour was back. . You can grep for "unambiguous" in slime.el to find if your sources are upto date
I'm still confused! :-)
% cvs update -p -r HEAD slime.el | grep unambig | wc -l 0
[SEE APOLOGIES AT THE BOTTOM!]
* Juho Snellman slrner8828.fcm.jsnell@localhost.localdomain : | I've never seen any bugs with this before the changes last month. What | I do is: | | 1. Type some characters | 2. Complete | 3. If ambiguous, go to step 1
OK I see the difference. After Step 2, When a *Completions* buffer pops up, I try to "Choose a completion" by clicking on it (or hitting RET) in that buffer.
This is how I understand emacs completion works. From a UI standpoint, the choices are already displayed, and the user ought to be able to select one WITHOUT typing additional characters
With the original unambiguous completion code this is not possible when the point has been moved to an earlier location. This is a bug as far as I can see. I believe you haven't seen it because you do not used Emacs' choose-completion facility
| Well, actually that's what I *would* do if this wasn't broken in CVS | right now. As it is, the workflow is more like: | | 1. Type some characters | 2. Complete | 3. If ambiguous try to type some characters. Find that it's useless, | since there are no ambiguities at the point | 4. Switch to the *Completions* window that was opened | 5. Arrow-key or C-s to the symbol that I want | 6. Press enter | 7. Press C-x 0 to close the now useless window that was opened
Ah but this is my normal workflow! If ambiguous, and the completion is available at hand, I wish to use emacs to complete it by coosing it. This is not possible with the original unambigous prefix code.
Personally I dont like typing extra characters where fewer characters would suffice, but my issue was that Emacs completion facility does not work with the original behaviour
[...]
|> From a checkout of a few weeks ago, the "bug" was put back, there was |> no Changelog entry, but I noticed the original buggy behaviour was |> back. . You can grep for "unambiguous" in slime.el to find if your |> sources are upto date
^^^ This is incorrect.
| I'm still confused! :-) | | % cvs update -p -r HEAD slime.el | grep unambig | wc -l | 0
You are right and I am at fault. I should not have restarted this thread. I think Edi did not check in the changes as I assumed he did, and I was misled by a sticky version of slime.el.
Sorry!
-- Madhu
[SEE APOLOGIES AT THE BOTTOM!]
* Juho Snellman slrner8828.fcm.jsnell@localhost.localdomain : | I've never seen any bugs with this before the changes last month. What | I do is: | | 1. Type some characters | 2. Complete | 3. If ambiguous, go to step 1
OK I see the difference. After Step 2, When a *Completions* buffer pops up, I try to "Choose a completion" by clicking on it (or hitting RET) in that buffer.
This is how I understand emacs completion works. From a UI standpoint, the choices are already displayed, and the user ought to be able to select one WITHOUT typing additional characters
With the original unambiguous completion code this is not possible when the point has been moved to an earlier location. This is a bug as far as I can see. I believe you haven't seen it because you do not used Emacs' choose-completion facility
| Well, actually that's what I *would* do if this wasn't broken in CVS | right now. As it is, the workflow is more like: | | 1. Type some characters | 2. Complete | 3. If ambiguous try to type some characters. Find that it's useless, | since there are no ambiguities at the point | 4. Switch to the *Completions* window that was opened | 5. Arrow-key or C-s to the symbol that I want | 6. Press enter | 7. Press C-x 0 to close the now useless window that was opened
Ah but this is my normal workflow! If ambiguous, and the completion is available at hand, I wish to use emacs to complete it by coosing it. This is not possible with the original unambigous prefix code.
Personally I dont like typing extra characters where fewer characters would suffice, but my issue was that Emacs completion facility does not work with the original behaviour
[...]
|> From a checkout of a few weeks ago, the "bug" was put back, there was |> no Changelog entry, but I noticed the original buggy behaviour was |> back. . You can grep for "unambiguous" in slime.el to find if your |> sources are upto date
^^^ This is incorrect.
| I'm still confused! :-) | | % cvs update -p -r HEAD slime.el | grep unambig | wc -l | 0
You are right and I am at fault. I should not have restarted this thread. I think Edi did not check in the changes as I assumed he did, and I was misled by a sticky version of slime.el.
Sorry!
-- Madhu
* Edi Weitz ups98ossi.fsf@agharta.de : | My completely egoistic preference is that the behaviour where point | ends up directly after the shortest unambiguous prefix is kept as is. | If you insist on modifying this function, I'd suggest that you send a | patch which a) works around your problems without changing what the | function does or b) adds a customization option so that one can | optionally force the function to work the way you want it. I know | that Helmut doesn't like customizations, but for me they're fine - | most of them I simply ignore hoping that the default is fine... :)
[I don't insist. But given the dichotomy in interactions styles, I submit the following. (Hopefully this should stop Juho Snellman from cursing, while encouraging Helmut to start :)]
-
Edi Weitz -
enometh＠meer.net -
Juho Snellman -
Madhu