From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20463 invoked from network); 26 May 2001 06:45:52 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 May 2001 06:45:52 -0000 Received: (qmail 18277 invoked by alias); 26 May 2001 06:45:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14488 Received: (qmail 18266 invoked from network); 26 May 2001 06:45:43 -0000 Date: Fri, 25 May 2001 23:45:14 -0700 (PDT) From: Wayne Davison X-X-Sender: To: Bart Schaefer Cc: Subject: PATCH: accept-and-infer-next-history is broken? In-Reply-To: <1010526012125.ZM18237@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463796991-730172578-990859514=:26275" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463796991-730172578-990859514=:26275 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 26 May 2001, Bart Schaefer wrote: > I DON'T want inferences to skip over the expired history slots and use > what follows ... I'd rather have it feep at me. Sounds like a nice idea. I can even think of a fairly easy way to do this, which I can implement after 4.0.1 gets released. > So whether the algorithm needs to always search from the bottom > depends on what "we have a line in the history below us" means. I've been reflecting on this some more, and, I think I may like my alternate approach better (i.e. always search from the bottom, at least in the case of accept-and-infer-n-h). The main reason for this is that it gives the user the choice of how to pick the next history item. If you want to proceed in exactly the same sequence as before, use accept-line-and-down-history. If you want to make a new inference from the current line, use accept-and-infer-next-history (which does a new search). It would even be logically equivalent to pressing CR + up-arrow + infer-next-history, so that even argues in its favor, IMO. > } Finally, I changed the function to be like a-l-a-down-history in > } that it does not set "done = 1" if the infer fails. > > What practical effect does that have, exactly? Translation: if it can't infer a new line, it feeps and doesn't accept the line either. This is how accept-line-and-down-history works, and I thought that it was a good idea for accept-and-infer-next-history to work this way too. OK, so here's an alternate patch to my first one. This version does not change the way infer-next-history works. This allows the user to press up-arrow and infer-next-history to try to find a match further back in the history after each infer-next-history. One way that this is useful is that if you're using accept-and-infer-next-history over and over again and you end up in the wrong sequence, using up-arrow + infer-next-history should get you back on track. ..wayne.. ---1463796991-730172578-990859514=:26275 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="infer.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: New infer-next-history patch Content-Disposition: attachment; filename="infer.patch" SW5kZXg6IFNyYy9abGUvemxlX2hpc3QuYw0KLS0tIFNyYy9abGUvemxlX2hp c3QuYwkyMDAwLzAyLzIzIDE1OjE4OjQ5CTEuMS4xLjE0DQorKysgU3JjL1ps ZS96bGVfaGlzdC5jCTIwMDEvMDUvMjYgMDY6MzY6MDINCkBAIC0yNTIsNyAr MjUyLDcgQEANCiANCiAgICAgaWYgKCEoaGUgPSBtb3ZlaGlzdGVudChxdWll dGdldGhpc3QoaGlzdGxpbmUpLCAxLCBISVNUX0ZPUkVJR04pKSkNCiAJcmV0 dXJuIDE7DQotICAgIHpwdXNobm9kZShidWZzdGFjaywgenRyZHVwKFpMRVRF WFQoaGUpKSk7DQorICAgIHpwdXNobm9kZShidWZzdGFjaywgenRyZHVwKGhl LT50ZXh0KSk7DQogICAgIGRvbmUgPSAxOw0KICAgICBzdGFja2hpc3QgPSBo ZS0+aGlzdG51bTsNCiAgICAgcmV0dXJuIDA7DQpAQCAtODkxLDIzICs4OTEs MjkgQEANCiAJa3VuZ2V0Y3QgPSBzYXZla2V5czsNCiB9DQogDQorc3RhdGlj IEhpc3RlbnQNCitpbmZlcm5leHRoaXN0KEhpc3RlbnQgaGUsIGNoYXIgKiph cmdzKQ0KK3sNCisgICAgZm9yIChoZSA9IG1vdmVoaXN0ZW50KGhlLCAtMiwg SElTVF9GT1JFSUdOKTsNCisJIGhlOyBoZSA9IG1vdmVoaXN0ZW50KGhlLCAt MSwgSElTVF9GT1JFSUdOKSkgew0KKwlpZiAoIW1ldGFkaWZmZXIoaGUtPnRl eHQsIChjaGFyICopIGxpbmUsIGxsKSkNCisJICAgIHJldHVybiBtb3ZlaGlz dGVudChoZSwgMSwgSElTVF9GT1JFSUdOKTsNCisgICAgfQ0KKyAgICByZXR1 cm4gTlVMTDsNCit9DQorDQogLyoqLw0KIGludA0KIGFjY2VwdGFuZGluZmVy bmV4dGhpc3RvcnkoY2hhciAqKmFyZ3MpDQogew0KICAgICBIaXN0ZW50IGhl Ow0KIA0KKyAgICBpZiAoIShoZSA9IGluZmVybmV4dGhpc3QoaGlzdF9yaW5n LCBhcmdzKSkpDQorCXJldHVybiAxOw0KKyAgICB6cHVzaG5vZGUoYnVmc3Rh Y2ssIHp0cmR1cChoZS0+dGV4dCkpOw0KICAgICBkb25lID0gMTsNCi0gICAg Zm9yIChoZSA9IG1vdmVoaXN0ZW50KHF1aWV0Z2V0aGlzdChoaXN0bGluZSks IC0yLCBISVNUX0ZPUkVJR04pOw0KLQkgaGU7IGhlID0gbW92ZWhpc3RlbnQo aGUsIC0xLCBISVNUX0ZPUkVJR04pKSB7DQotCWlmICghbWV0YWRpZmZlciha TEVURVhUKGhlKSwgKGNoYXIgKikgbGluZSwgbGwpKSB7DQotCSAgICBoZSA9 IG1vdmVoaXN0ZW50KGhlLCAxLCBISVNUX0ZPUkVJR04pOw0KLQkgICAgenB1 c2hub2RlKGJ1ZnN0YWNrLCB6dHJkdXAoWkxFVEVYVChoZSkpKTsNCi0JICAg IHN0YWNraGlzdCA9IGhlLT5oaXN0bnVtOw0KLQkgICAgcmV0dXJuIDA7DQot CX0NCi0gICAgfQ0KLSAgICByZXR1cm4gMTsNCisgICAgc3RhY2toaXN0ID0g aGUtPmhpc3RudW07DQorICAgIHJldHVybiAwOw0KIH0NCiANCiAvKiovDQpA QCAtOTE2LDE1ICs5MjIsMTAgQEANCiB7DQogICAgIEhpc3RlbnQgaGU7DQog DQotICAgIGZvciAoaGUgPSBtb3ZlaGlzdGVudChxdWlldGdldGhpc3QoaGlz dGxpbmUpLCAtMiwgSElTVF9GT1JFSUdOKTsNCi0JIGhlOyBoZSA9IG1vdmVo aXN0ZW50KGhlLCAtMSwgSElTVF9GT1JFSUdOKSkgew0KLQlpZiAoIW1ldGFk aWZmZXIoWkxFVEVYVChoZSksIChjaGFyICopIGxpbmUsIGxsKSkgew0KLQkg ICAgaGUgPSBtb3ZlaGlzdGVudChoZSwgMSwgSElTVF9GT1JFSUdOKTsNCi0J ICAgIHpsZV9zZXRsaW5lKGhlKTsNCi0JICAgIHJldHVybiAwOw0KLQl9DQot ICAgIH0NCi0gICAgcmV0dXJuIDE7DQorICAgIGlmICghKGhlID0gaW5mZXJu ZXh0aGlzdChxdWlldGdldGhpc3QoaGlzdGxpbmUpLCBhcmdzKSkpDQorCXJl dHVybiAxOw0KKyAgICB6bGVfc2V0bGluZShoZSk7DQorICAgIHJldHVybiAw Ow0KIH0NCiANCiAvKiovDQo= ---1463796991-730172578-990859514=:26275--