* bug#39484: 26.3; try-completion bug @ 2020-02-07 15:44 Wanrong Lin 2020-10-27 18:42 ` Lars Ingebrigtsen 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-02-07 15:44 UTC (permalink / raw) To: 39484 try-completion does not work as expected when completion-ignore-case is t. Examples: (let ((completion-ignore-case t)) (try-completion "xy" '("XyzD" "XyzAbc")) ) ==> "Xyz" Expected. The return value has uppercase "X", since the return value should be the maximum substring among all the *candidates*. (let ((completion-ignore-case t)) (try-completion "xyz" '("XyzD" "XyzAbc")) ) ==> "xyz" *Unexpected*. Should be "Xyz". Thanks for looking into this. Wanrong ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-02-07 15:44 bug#39484: 26.3; try-completion bug Wanrong Lin @ 2020-10-27 18:42 ` Lars Ingebrigtsen 2020-10-27 19:08 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 18:42 UTC (permalink / raw) To: Wanrong Lin; +Cc: Stefan Monnier, 39484 Wanrong Lin <wrglin@gmail.com> writes: > (let ((completion-ignore-case t)) > (try-completion "xyz" '("XyzD" "XyzAbc")) > ) > ==> "xyz" > > *Unexpected*. Should be "Xyz". That is somewhat odd, especially considering: (let ((completion-ignore-case t)) (try-completion "xyz" '("XyzaD" "Xyzabc"))) => "Xyza" Stefan? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 18:42 ` Lars Ingebrigtsen @ 2020-10-27 19:08 ` Andreas Schwab 2020-10-27 19:17 ` Lars Ingebrigtsen 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-27 19:08 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Wanrong Lin, Stefan Monnier, 39484 On Okt 27 2020, Lars Ingebrigtsen wrote: > Wanrong Lin <wrglin@gmail.com> writes: > >> (let ((completion-ignore-case t)) >> (try-completion "xyz" '("XyzD" "XyzAbc")) >> ) >> ==> "xyz" >> >> *Unexpected*. Should be "Xyz". > > That is somewhat odd /* If we are ignoring case, and there is no exact match, and no additional text was supplied, don't change the case of what the user typed. */ Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 19:08 ` Andreas Schwab @ 2020-10-27 19:17 ` Lars Ingebrigtsen 2020-10-27 20:17 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 19:17 UTC (permalink / raw) To: Andreas Schwab; +Cc: Wanrong Lin, Stefan Monnier, 39484 Andreas Schwab <schwab@linux-m68k.org> writes: > /* If we are ignoring case, and there is no exact match, > and no additional text was supplied, > don't change the case of what the user typed. */ Should this be mentioned in the doc string? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 19:17 ` Lars Ingebrigtsen @ 2020-10-27 20:17 ` Wanrong Lin 2020-10-27 20:28 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-27 20:17 UTC (permalink / raw) To: Lars Ingebrigtsen, Andreas Schwab; +Cc: Stefan Monnier, 39484 I am curious what is the rationale behind this behavior? I remember this behavior gives me problem in "ido" trying to expand the user input to the max common matched text among all candidates, because as you can see, the "expansion" using this method may end up returning something that is not common at all for all the candidates. On 10/27/2020 3:17 PM, Lars Ingebrigtsen wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > >> /* If we are ignoring case, and there is no exact match, >> and no additional text was supplied, >> don't change the case of what the user typed. */ > Should this be mentioned in the doc string? > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 20:17 ` Wanrong Lin @ 2020-10-27 20:28 ` Andreas Schwab 2020-10-27 20:44 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-27 20:28 UTC (permalink / raw) To: Wanrong Lin; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 On Okt 27 2020, Wanrong Lin wrote: > I remember this behavior gives me problem in "ido" trying to expand the > user input to the max common matched text among all candidates, because > as you can see, the "expansion" using this method may end up returning > something that is not common at all for all the candidates. It isn't? "xyz" surely is a common prefix of "XyzD" and "XyzAbc", ignoring case. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 20:28 ` Andreas Schwab @ 2020-10-27 20:44 ` Wanrong Lin 2020-10-27 21:21 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-27 20:44 UTC (permalink / raw) To: Andreas Schwab; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 My understanding is: "ignoring case" here applies to the comparison part, not the returning part. What makes me think so: 1. That variable name is "completion-ignore-case", meaning, complete as much as possible ignoring case in comparison. But still, the action is to "complete", and "complete" should use the original candidate text when possible. 2. the first example did return the original text in the candidate instead of the user input. (let ((completion-ignore-case t)) (try-completion "xy" '("XyzD" "XyzAbc")) ) ==> "Xyz" I am not saying other behaviors are "wrong", but not ideal in my view, and there should be some rationale (performance?) behind it. Wanrong On 10/27/2020 4:28 PM, Andreas Schwab wrote: > On Okt 27 2020, Wanrong Lin wrote: > >> I remember this behavior gives me problem in "ido" trying to expand the >> user input to the max common matched text among all candidates, because >> as you can see, the "expansion" using this method may end up returning >> something that is not common at all for all the candidates. > It isn't? "xyz" surely is a common prefix of "XyzD" and "XyzAbc", > ignoring case. > > Andreas. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 20:44 ` Wanrong Lin @ 2020-10-27 21:21 ` Andreas Schwab 2020-10-28 0:44 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-27 21:21 UTC (permalink / raw) To: Wanrong Lin; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 So what should (try-completion "abc" '("Abcde" "aBcdf" "abCdg")) return? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-27 21:21 ` Andreas Schwab @ 2020-10-28 0:44 ` Wanrong Lin 2020-10-28 0:47 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-28 0:44 UTC (permalink / raw) To: Andreas Schwab; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 For this case, "abc" might be OK, unless you think there is another better answer. But in the example I gave, don't you think "Xyz" is obviously a better answer than "xyz"? The argument here is for some examples, the function does not return the best answer, and also, does not seem to be consistent to me (for those two examples I gave). There might be a reason behind this "compromise", or, it might be just an arbitrary decision as documented in the comments you gave. If it is the latter, can we improve on it? I think those are valid questions. Wanrong On 10/27/2020 5:21 PM, Andreas Schwab wrote: > So what should (try-completion "abc" '("Abcde" "aBcdf" "abCdg")) return? > > Andreas. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 0:44 ` Wanrong Lin @ 2020-10-28 0:47 ` Wanrong Lin 2020-10-28 0:57 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-28 0:47 UTC (permalink / raw) To: Andreas Schwab; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 Sorry, I meant "abcd" as the answer for your example. On 10/27/2020 8:44 PM, Wanrong Lin wrote: > For this case, "abc" might be OK, unless you think there is another > better answer. But in the example I gave, don't you think "Xyz" is > obviously a better answer than "xyz"? > > The argument here is for some examples, the function does not return > the best answer, and also, does not seem to be consistent to me (for > those two examples I gave). There might be a reason behind this > "compromise", or, it might be just an arbitrary decision as documented > in the comments you gave. If it is the latter, can we improve on it? I > think those are valid questions. > > Wanrong > > On 10/27/2020 5:21 PM, Andreas Schwab wrote: >> So what should (try-completion "abc" '("Abcde" "aBcdf" "abCdg")) return? >> >> Andreas. >> > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 0:47 ` Wanrong Lin @ 2020-10-28 0:57 ` Wanrong Lin 2020-10-28 7:51 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-28 0:57 UTC (permalink / raw) To: Andreas Schwab; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 I just tried this in Emacs 26.3: (let ((completion-ignore-case t)) (try-completion "abc" '("Abcde" "aBcdf" "abCdg"))) -> "Abcd" The answer is not bad, matching at least one of the candidates. That makes the answer to my original example even more odd: (let ((completion-ignore-case t)) (try-completion "xyz" '("XyzD" "XyzAbc")) ) ==> "xyz" Why does it matter whether any additional chars follow the user input in the match? Wanrong On 10/27/2020 8:47 PM, Wanrong Lin wrote: > Sorry, I meant "abcd" as the answer for your example. > > On 10/27/2020 8:44 PM, Wanrong Lin wrote: >> For this case, "abc" might be OK, unless you think there is another >> better answer. But in the example I gave, don't you think "Xyz" is >> obviously a better answer than "xyz"? >> >> The argument here is for some examples, the function does not return >> the best answer, and also, does not seem to be consistent to me (for >> those two examples I gave). There might be a reason behind this >> "compromise", or, it might be just an arbitrary decision as >> documented in the comments you gave. If it is the latter, can we >> improve on it? I think those are valid questions. >> >> Wanrong >> >> On 10/27/2020 5:21 PM, Andreas Schwab wrote: >>> So what should (try-completion "abc" '("Abcde" "aBcdf" "abCdg")) >>> return? >>> >>> Andreas. >>> >> > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 0:57 ` Wanrong Lin @ 2020-10-28 7:51 ` Andreas Schwab 2020-10-28 9:35 ` Lars Ingebrigtsen 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-28 7:51 UTC (permalink / raw) To: Wanrong Lin; +Cc: Lars Ingebrigtsen, Stefan Monnier, 39484 On Okt 27 2020, Wanrong Lin wrote: > The answer is not bad, matching at least one of the candidates. That makes > the answer to my original example even more odd: > (let ((completion-ignore-case t)) > (try-completion "xyz" '("XyzD" "XyzAbc")) > ) > ==> "xyz" That also matches one of the candidates (since case doesn't matter). Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 7:51 ` Andreas Schwab @ 2020-10-28 9:35 ` Lars Ingebrigtsen 2020-10-28 9:42 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Lars Ingebrigtsen @ 2020-10-28 9:35 UTC (permalink / raw) To: Andreas Schwab; +Cc: Wanrong Lin, Stefan Monnier, 39484 Andreas Schwab <schwab@linux-m68k.org> writes: > On Okt 27 2020, Wanrong Lin wrote: > >> The answer is not bad, matching at least one of the candidates. That makes >> the answer to my original example even more odd: >> (let ((completion-ignore-case t)) >> (try-completion "xyz" '("XyzD" "XyzAbc")) >> ) >> ==> "xyz" > > That also matches one of the candidates (since case doesn't matter). It does, but it's weird. I mean, this pair of return values don't make sense on any level: (let ((completion-ignore-case t)) (try-completion "xyz" '("XyzaD" "XyZabc"))) => "Xyza" (let ((completion-ignore-case t)) (try-completion "xyz" '("XyZbD" "XyZabc"))) => "xyz" -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 9:35 ` Lars Ingebrigtsen @ 2020-10-28 9:42 ` Andreas Schwab 2020-10-28 9:50 ` Lars Ingebrigtsen 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-28 9:42 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Wanrong Lin, Stefan Monnier, 39484 On Okt 28 2020, Lars Ingebrigtsen wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > >> On Okt 27 2020, Wanrong Lin wrote: >> >>> The answer is not bad, matching at least one of the candidates. That makes >>> the answer to my original example even more odd: >>> (let ((completion-ignore-case t)) >>> (try-completion "xyz" '("XyzD" "XyzAbc")) >>> ) >>> ==> "xyz" >> >> That also matches one of the candidates (since case doesn't matter). > > It does, but it's weird. I mean, this pair of return values don't make > sense on any level: > > (let ((completion-ignore-case t)) > (try-completion "xyz" '("XyzaD" "XyZabc"))) > => "Xyza" > > (let ((completion-ignore-case t)) > (try-completion "xyz" '("XyZbD" "XyZabc"))) > => "xyz" It makes a whole lot sense. If the candidate is not modified, it should not receive any case changes either. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 9:42 ` Andreas Schwab @ 2020-10-28 9:50 ` Lars Ingebrigtsen 2020-10-28 9:56 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Lars Ingebrigtsen @ 2020-10-28 9:50 UTC (permalink / raw) To: Andreas Schwab; +Cc: Wanrong Lin, Stefan Monnier, 39484 Andreas Schwab <schwab@linux-m68k.org> writes: >> It does, but it's weird. I mean, this pair of return values don't make >> sense on any level: >> >> (let ((completion-ignore-case t)) >> (try-completion "xyz" '("XyzaD" "XyZabc"))) >> => "Xyza" >> >> (let ((completion-ignore-case t)) >> (try-completion "xyz" '("XyZbD" "XyZabc"))) >> => "xyz" > > It makes a whole lot sense. If the candidate is not modified, it > should not receive any case changes either. But the case change in the modified case is essentially arbitrary, while the unmodified case has a unique, non-arbitrary match. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 9:50 ` Lars Ingebrigtsen @ 2020-10-28 9:56 ` Andreas Schwab 2020-10-28 11:16 ` Lars Ingebrigtsen 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-28 9:56 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Wanrong Lin, Stefan Monnier, 39484 On Okt 28 2020, Lars Ingebrigtsen wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > >>> It does, but it's weird. I mean, this pair of return values don't make >>> sense on any level: >>> >>> (let ((completion-ignore-case t)) >>> (try-completion "xyz" '("XyzaD" "XyZabc"))) >>> => "Xyza" >>> >>> (let ((completion-ignore-case t)) >>> (try-completion "xyz" '("XyZbD" "XyZabc"))) >>> => "xyz" >> >> It makes a whole lot sense. If the candidate is not modified, it >> should not receive any case changes either. > > But the case change in the modified case is essentially arbitrary, while > the unmodified case has a unique, non-arbitrary match. The case always matches one of the candidates. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 9:56 ` Andreas Schwab @ 2020-10-28 11:16 ` Lars Ingebrigtsen 2020-10-28 11:44 ` Andreas Schwab 0 siblings, 1 reply; 23+ messages in thread From: Lars Ingebrigtsen @ 2020-10-28 11:16 UTC (permalink / raw) To: Andreas Schwab; +Cc: Wanrong Lin, Stefan Monnier, 39484 Andreas Schwab <schwab@linux-m68k.org> writes: > The case always matches one of the candidates. Yes. An arbitrary candidate (well, the first one, but it's not documented, which means that it's arbitrary). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 11:16 ` Lars Ingebrigtsen @ 2020-10-28 11:44 ` Andreas Schwab 2020-10-28 12:59 ` Wanrong Lin 0 siblings, 1 reply; 23+ messages in thread From: Andreas Schwab @ 2020-10-28 11:44 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Wanrong Lin, Stefan Monnier, 39484 On Okt 28 2020, Lars Ingebrigtsen wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > >> The case always matches one of the candidates. > > Yes. An arbitrary candidate (well, the first one, but it's not > documented, which means that it's arbitrary). It is not nessesary to document each and every implementation detail. That makes it difficult to change the implementation later, and it also unduly restricts the way a collection function can handle that situation. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 11:44 ` Andreas Schwab @ 2020-10-28 12:59 ` Wanrong Lin 2020-10-28 14:45 ` Stefan Monnier 0 siblings, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-28 12:59 UTC (permalink / raw) To: Andreas Schwab, Lars Ingebrigtsen; +Cc: Stefan Monnier, 39484 This is not implementation detail. This is the interface of this function. User/caller should know exactly what are the rules for the return value. So in summary, my two points: 1. Return value is not ideal. You can argue it is still not wrong, but I think we can improve. 2. Even if we don't change anything here, we need to make this less-than-ideal behavior clear in the documentation (doc string). I hope I convinced at least some of you. Wanrong On 10/28/2020 7:44 AM, Andreas Schwab wrote: > On Okt 28 2020, Lars Ingebrigtsen wrote: > >> Andreas Schwab <schwab@linux-m68k.org> writes: >> >>> The case always matches one of the candidates. >> Yes. An arbitrary candidate (well, the first one, but it's not >> documented, which means that it's arbitrary). > It is not nessesary to document each and every implementation detail. > That makes it difficult to change the implementation later, and it also > unduly restricts the way a collection function can handle that > situation. > > Andreas. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 12:59 ` Wanrong Lin @ 2020-10-28 14:45 ` Stefan Monnier 2020-10-28 15:47 ` Wanrong Lin 2022-04-23 13:17 ` Lars Ingebrigtsen 0 siblings, 2 replies; 23+ messages in thread From: Stefan Monnier @ 2020-10-28 14:45 UTC (permalink / raw) To: Wanrong Lin; +Cc: Lars Ingebrigtsen, Andreas Schwab, 39484 > 1. Return value is not ideal. You can argue it is still not wrong, but > I think we can improve. Indeed, it can be improved, but we should not try to be too clever about it, because some choices might seem obvious in some circumstances but would result in rather poor answers in other cases. So rather than hypothetical cases like what we've seen here, I'm much more interested in real life situations. The current design is trying to be conservative, in the sense that it tries to avoid returning a poor result, at the cost of sometimes failing to return a better result. It does it by refraining from mix-and-match: either the whole result comes from the user input or the whole result comes from *one* of the candidates. There are cases where `completion-try-completion` (as opposed to `try-completion`) doesn't actually follow this rule correctly, and it's been a source of suboptimal results. Stefan ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 14:45 ` Stefan Monnier @ 2020-10-28 15:47 ` Wanrong Lin 2020-10-28 16:34 ` Stefan Monnier 2022-04-23 13:17 ` Lars Ingebrigtsen 1 sibling, 1 reply; 23+ messages in thread From: Wanrong Lin @ 2020-10-28 15:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Ingebrigtsen, Andreas Schwab, 39484 The examples I gave are real life situations. I discovered this issue from an unexpected behavior with ido. The "bug" has real negative consequences, at least for me. As for this: "It does it by refraining from mix-and-match: either the whole result comes from the user input or the whole result comes from *one* of the candidates." It still sounds quite arbitrary to me, as I failed to understand why it is bad if the whole result comes from *all* of the candidates if that happens to be possible. I will try to give a version which I think is better (up to debate, of course) For the user input x, return a string y (or nil if impossible) so that it satisfies all three conditions below: 1. x is a prefix of y, ignoring case. 2. y is the maximum common prefix, ignoring case, among all candidates 3. y is the *exact* (including case) prefix of at least one of the candidates Wanrong On 10/28/2020 10:45 AM, Stefan Monnier wrote: >> 1. Return value is not ideal. You can argue it is still not wrong, but >> I think we can improve. > Indeed, it can be improved, but we should not try to be too clever about > it, because some choices might seem obvious in some circumstances but > would result in rather poor answers in other cases. > > So rather than hypothetical cases like what we've seen here, I'm much > more interested in real life situations. > > The current design is trying to be conservative, in the sense that it > tries to avoid returning a poor result, at the cost of sometimes failing > to return a better result. It does it by refraining from mix-and-match: > either the whole result comes from the user input or the whole result > comes from *one* of the candidates. > > There are cases where `completion-try-completion` (as opposed to > `try-completion`) doesn't actually follow this rule correctly, and it's > been a source of suboptimal results. > > > Stefan > ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 15:47 ` Wanrong Lin @ 2020-10-28 16:34 ` Stefan Monnier 0 siblings, 0 replies; 23+ messages in thread From: Stefan Monnier @ 2020-10-28 16:34 UTC (permalink / raw) To: Wanrong Lin; +Cc: Lars Ingebrigtsen, Andreas Schwab, 39484 > The examples I gave are real life situations. All the examples I see are of the "abcd" or "xyz", i.e. made up examples. I understand they are meant to illustrate real-life examples, but they are not themselves real life. > 1. x is a prefix of y, ignoring case. > 2. y is the maximum common prefix, ignoring case, among all candidates That's what is guaranteed by the semantics, so our code already does that (barring bugs). > 3. y is the *exact* (including case) prefix of at least one of the > candidates We could try that, indeed. It still satisfies the constraint I described as "conservative", and it wouldn't cost extra efforts either. If someone wants to try that, feel free to do so, but I personally would prefer if we only do that when all the matching candidates agree on the capitalization. BTW, we currently have the following tests in test/src/minibuffer-tests.el: (ert-deftest test-try-completion-ignore-case () (let ((completion-ignore-case t)) (should (equal (try-completion "bar" '("bAr" "barfoo")) "bAr")) (should (equal (try-completion "bar" '("bArfoo" "barbaz")) "bar")) (should (equal (try-completion "bar" '("bArfoo" "barbaz")) (try-completion "bar" '("barbaz" "bArfoo")))) ;; bug#11339 (should (equal (try-completion "baz" '("baz" "bAz")) "baz")) ;And not `t'! (should (equal (try-completion "baz" '("bAz" "baz")) (try-completion "baz" '("baz" "bAz")))))) -- Stefan ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#39484: 26.3; try-completion bug 2020-10-28 14:45 ` Stefan Monnier 2020-10-28 15:47 ` Wanrong Lin @ 2022-04-23 13:17 ` Lars Ingebrigtsen 1 sibling, 0 replies; 23+ messages in thread From: Lars Ingebrigtsen @ 2022-04-23 13:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: Wanrong Lin, Andreas Schwab, 39484 Stefan Monnier <monnier@iro.umontreal.ca> writes: > The current design is trying to be conservative, in the sense that it > tries to avoid returning a poor result, at the cost of sometimes failing > to return a better result. It does it by refraining from mix-and-match: > either the whole result comes from the user input or the whole result > comes from *one* of the candidates. I've now mentioned something like this in the doc string of the function in Emacs 29. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-04-23 13:17 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-07 15:44 bug#39484: 26.3; try-completion bug Wanrong Lin 2020-10-27 18:42 ` Lars Ingebrigtsen 2020-10-27 19:08 ` Andreas Schwab 2020-10-27 19:17 ` Lars Ingebrigtsen 2020-10-27 20:17 ` Wanrong Lin 2020-10-27 20:28 ` Andreas Schwab 2020-10-27 20:44 ` Wanrong Lin 2020-10-27 21:21 ` Andreas Schwab 2020-10-28 0:44 ` Wanrong Lin 2020-10-28 0:47 ` Wanrong Lin 2020-10-28 0:57 ` Wanrong Lin 2020-10-28 7:51 ` Andreas Schwab 2020-10-28 9:35 ` Lars Ingebrigtsen 2020-10-28 9:42 ` Andreas Schwab 2020-10-28 9:50 ` Lars Ingebrigtsen 2020-10-28 9:56 ` Andreas Schwab 2020-10-28 11:16 ` Lars Ingebrigtsen 2020-10-28 11:44 ` Andreas Schwab 2020-10-28 12:59 ` Wanrong Lin 2020-10-28 14:45 ` Stefan Monnier 2020-10-28 15:47 ` Wanrong Lin 2020-10-28 16:34 ` Stefan Monnier 2022-04-23 13:17 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.