From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16893 invoked from network); 25 May 2001 20:47:44 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 May 2001 20:47:44 -0000 Received: (qmail 23847 invoked by alias); 25 May 2001 20:47:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14485 Received: (qmail 23835 invoked from network); 25 May 2001 20:47:37 -0000 Date: Fri, 25 May 2001 13:47:09 -0700 (PDT) From: Wayne Davison X-X-Sender: To: Bart Schaefer Cc: Subject: Re: accept-and-infer-next-history is broken? In-Reply-To: <1010524080447.ZM12576@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463796991-1471301942-990823629=:18391" 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-1471301942-990823629=:18391 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 24 May 2001, Bart Schaefer wrote: > infer-next-history is OK: > But accept-and is not: Actually they both appear to share the same bug, but it gets tickled by where you are in the history. Since accept-and-infer-next-history leaves you up in the history list while just infer-next-history + CR does not, you don't usually notice the bug with just infer-next-history (unless you try to use it multiple times in a row). So, I think that the proper solution is to modify the algorithm like this: if (we have a line in the history below us && the current line is unchanged from the history version) { use the next line; else search from the bottom of the history for a match and infer; This means that a-a-i-n-h works just like accept-line-and-down-history after the first inferred line. An alternate approach would be to just always start the search from the bottom of the history. Thoughts? The attached patch implements my pseudo-code above. It also unifies the infer algorithm in a single support function. Another change I made was to have the code ignore the transient edits in the history list when it is searching for and storing the inferred line (also affecting accept-line-and-down-history). I've been bitten by this before: I've searched for a line I need, I decide to put a line I encountered on the way into the kill ring with Ctrl-U, continued on to find the real command I wanted to run, and then pressed Ctrl-O to use accept-line-and-down-history. If the line I deleted was actually next in the history, I get an empty line as the inferred next history line, not the actual next history line. 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. ..wayne.. ---1463796991-1471301942-990823629=:18391 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="infer.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Fix infer-next-history problems Content-Disposition: attachment; filename="infer.patch" SW5kZXg6IFNyYy9abGUvemxlX2hpc3QuYw0KLS0tIFNyYy9abGUvemxlX2hp c3QuYwkyMDAwLzAyLzIzIDE1OjE4OjQ5CTEuMS4xLjE0DQorKysgU3JjL1ps ZS96bGVfaGlzdC5jCTIwMDEvMDUvMjUgMjA6NDI6MzYNCkBAIC0yNTIsNyAr MjUyLDcgQEANCiANCiAgICAgaWYgKCEoaGUgPSBtb3ZlaGlzdGVudChxdWll dGdldGhpc3QoaGlzdGxpbmUpLCAxLCBISVNUX0ZPUkVJR04pKSkNCiAJcmV0 dXJuIDE7DQotICAgIHpwdXNobm9kZShidWZzdGFjaywgenRyZHVwKFpMRVRF WFQoaGUpKSk7DQorICAgIHpwdXNobm9kZShidWZzdGFjaywgenRyZHVwKGhl LT50ZXh0KSk7DQogICAgIGRvbmUgPSAxOw0KICAgICBzdGFja2hpc3QgPSBo ZS0+aGlzdG51bTsNCiAgICAgcmV0dXJuIDA7DQpAQCAtODkxLDIzICs4OTEs MzYgQEANCiAJa3VuZ2V0Y3QgPSBzYXZla2V5czsNCiB9DQogDQorc3RhdGlj IEhpc3RlbnQNCitpbmZlcm5leHRoaXN0KGNoYXIgKiphcmdzKQ0KK3sNCisg ICAgSGlzdGVudCBoZTsNCisNCisgICAgaWYgKCEoaGUgPSBxdWlldGdldGhp c3QoaGlzdGxpbmUpKSkNCisJcmV0dXJuIE5VTEw7DQorICAgIGlmICghbWV0 YWRpZmZlcihoZS0+dGV4dCwgKGNoYXIgKilsaW5lLCBsbCkNCisgICAgICYm IChoZSA9IG1vdmVoaXN0ZW50KGhlLCAxLCBISVNUX0ZPUkVJR04pKSAhPSBO VUxMKQ0KKwlyZXR1cm4gaGU7DQorICAgIGZvciAoaGUgPSBtb3ZlaGlzdGVu dChoaXN0X3JpbmcsIC0yLCBISVNUX0ZPUkVJR04pOw0KKwkgaGU7IGhlID0g bW92ZWhpc3RlbnQoaGUsIC0xLCBISVNUX0ZPUkVJR04pKSB7DQorCWlmICgh bWV0YWRpZmZlcihoZS0+dGV4dCwgKGNoYXIgKikgbGluZSwgbGwpKQ0KKwkg ICAgcmV0dXJuIG1vdmVoaXN0ZW50KGhlLCAxLCBISVNUX0ZPUkVJR04pOw0K KyAgICB9DQorICAgIHJldHVybiBOVUxMOw0KK30NCisNCiAvKiovDQogaW50 DQogYWNjZXB0YW5kaW5mZXJuZXh0aGlzdG9yeShjaGFyICoqYXJncykNCiB7 DQogICAgIEhpc3RlbnQgaGU7DQogDQorICAgIGlmICghKGhlID0gaW5mZXJu ZXh0aGlzdChhcmdzKSkpDQorCXJldHVybiAxOw0KKyAgICB6cHVzaG5vZGUo YnVmc3RhY2ssIHp0cmR1cChoZS0+dGV4dCkpOw0KICAgICBkb25lID0gMTsN Ci0gICAgZm9yIChoZSA9IG1vdmVoaXN0ZW50KHF1aWV0Z2V0aGlzdChoaXN0 bGluZSksIC0yLCBISVNUX0ZPUkVJR04pOw0KLQkgaGU7IGhlID0gbW92ZWhp c3RlbnQoaGUsIC0xLCBISVNUX0ZPUkVJR04pKSB7DQotCWlmICghbWV0YWRp ZmZlcihaTEVURVhUKGhlKSwgKGNoYXIgKikgbGluZSwgbGwpKSB7DQotCSAg ICBoZSA9IG1vdmVoaXN0ZW50KGhlLCAxLCBISVNUX0ZPUkVJR04pOw0KLQkg ICAgenB1c2hub2RlKGJ1ZnN0YWNrLCB6dHJkdXAoWkxFVEVYVChoZSkpKTsN Ci0JICAgIHN0YWNraGlzdCA9IGhlLT5oaXN0bnVtOw0KLQkgICAgcmV0dXJu IDA7DQotCX0NCi0gICAgfQ0KLSAgICByZXR1cm4gMTsNCisgICAgc3RhY2to aXN0ID0gaGUtPmhpc3RudW07DQorICAgIHJldHVybiAwOw0KIH0NCiANCiAv KiovDQpAQCAtOTE2LDE1ICs5MjksMTEgQEANCiB7DQogICAgIEhpc3RlbnQg aGU7DQogDQotICAgIGZvciAoaGUgPSBtb3ZlaGlzdGVudChxdWlldGdldGhp c3QoaGlzdGxpbmUpLCAtMiwgSElTVF9GT1JFSUdOKTsNCi0JIGhlOyBoZSA9 IG1vdmVoaXN0ZW50KGhlLCAtMSwgSElTVF9GT1JFSUdOKSkgew0KLQlpZiAo IW1ldGFkaWZmZXIoWkxFVEVYVChoZSksIChjaGFyICopIGxpbmUsIGxsKSkg ew0KLQkgICAgaGUgPSBtb3ZlaGlzdGVudChoZSwgMSwgSElTVF9GT1JFSUdO KTsNCi0JICAgIHpsZV9zZXRsaW5lKGhlKTsNCi0JICAgIHJldHVybiAwOw0K LQl9DQotICAgIH0NCi0gICAgcmV0dXJuIDE7DQorICAgIGlmICghKGhlID0g aW5mZXJuZXh0aGlzdChhcmdzKSkpDQorCXJldHVybiAxOw0KKw0KKyAgICB6 bGVfc2V0bGluZShoZSk7DQorICAgIHJldHVybiAwOw0KIH0NCiANCiAvKiov DQo= ---1463796991-1471301942-990823629=:18391--