From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: PATCH: parse from even deeper in hell
Date: Mon, 23 Feb 2015 14:46:55 +0100 [thread overview]
Message-ID: <CAHYJk3RuZiWpi-_ZnEfdS9HHww1OvFj1AegZBiXeMDH0zceieg@mail.gmail.com> (raw)
In-Reply-To: <CAHYJk3S3ECr_JuBOH8q7HPL-aZkaJaXDEJdiura6jmUnqN_R3g@mail.gmail.com>
On Mon, Feb 23, 2015 at 2:38 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On Mon, Feb 23, 2015 at 1:57 PM, Peter Stephenson
> <p.stephenson@samsung.com> wrote:
>> On Mon, 23 Feb 2015 12:36:07 +0000
>> Peter Stephenson <p.stephenson@samsung.com> wrote:
>>> On Mon, 23 Feb 2015 12:35:51 +0100
>>> Mikael Magnusson <mikachu@gmail.com> wrote:
>>> > I figured out that when we assign lineptr after fiddling with it, we
>>> > also need to update start, it records the location of *lineptr on
>>> > entry to the function, and is used to calculate things later on. With
>>> > that addition, the unmetafy + metafy mostly works. insert-last-word
>>> > still gets "stuck" on words that came from the old metafication and
>>> > starts over from the end of history, leaving the old word in place.
>>>
>>> What's the line this happens with? Is it the same as the one that
>>> originally failed?
>>
>> Yes, I see it is.
>
> If you start dev-0 and run
> echo た
> then you'll end up with a trouble-causing entry in your history file.
> Simply holding down alt-. in a new dev-1 shell then just inserts a
> bunch of た forever for me.
>
>>> I wonder if it's getting information by some other path, though it seems
>>> strange the last word wouldn't come from the bit we've apparently fixed
>>> up.
>
> At least the function calling this function seems to store the raw
> string in lasthist.text, but that's outside the while loop, so I think
> only for the final history entry? I get my problem even when the bad
> string is in an earlier line.
>
> Oh, there's also this line,
> he->node.nam = ztrdup(pt);
> (pt is the history line)
>
> Do we want to move the whole thing before that? I didn't look too
> closely at this function yet.
Doing so fixes the issue for me.
gmail-mangled patch follows, I also deleted the paragraph about
non-uselex since it's now outside that function.
diff --git i/Src/hist.c w/Src/hist.c
index ee55431..ae255d6 100644
--- i/Src/hist.c
+++ w/Src/hist.c
@@ -2502,11 +2502,42 @@ readhistfile(char *fn, int err, int readflags)
newflags |= HIST_MAKEUNIQUE;
while (fpos = ftell(in), (l = readhistline(0, &buf, &bufsiz, in))) {
char *pt = buf;
+ char *ptr;
+ int remeta;
if (l < 0) {
zerr("corrupt history file %s", fn);
break;
}
+
+ /*
+ * Handle the special case that we're reading from an
+ * old shell with fewer meta characters, so we need to
+ * metafy some more. (It's not clear why the history
+ * file is metafied at all; some would say this is plain
+ * stupid. But we're stuck with it now without some
+ * hairy workarounds for compatibility).
+ *
+ * This is rare so doesn't need to be that efficient; just
+ * allocate space off the heap.
+ */
+ for (ptr = pt; *ptr; ptr++) {
+ if (*ptr == Meta && ptr[1])
+ ptr++;
+ else if (imeta(*ptr)) {
+ remeta = 1;
+ break;
+ }
+ }
+ if (remeta) {
+ unmetafy(pt, &remeta);
+ pt = metafy(pt, remeta, META_USEHEAP);
+ }
+
if (*pt == ':') {
pt++;
stim = zstrtol(pt, NULL, 0);
@@ -3375,37 +3406,7 @@ histsplitwords(char *lineptr, short
{
int nwords = *nwordsp, nwordpos = 0, remeta = 0;
short *words = *wordsp;
- char *start, *ptr;
-
- /*
- * Handle the special case that we're reading from an
- * old shell with fewer meta characters, so we need to
- * metafy some more. (It's not clear why the history
- * file is metafied at all; some would say this is plain
- * stupid. But we're stuck with it now without some
- * hairy workarounds for compatibility).
- *
- * This is rare so doesn't need to be that efficient; just
- * allocate space off the heap.
- *
- * Note that our it's currently believed this all comes out in
- * the wash in the non-uselex case owing to where unmetafication
- * and metafication happen.
- */
- for (ptr = lineptr; *ptr; ptr++) {
- if (*ptr == Meta && ptr[1])
- ptr++;
- else if (imeta(*ptr)) {
- remeta = 1;
- break;
- }
- }
- if (remeta) {
- unmetafy(lineptr, &remeta);
- lineptr = metafy(lineptr, remeta, META_USEHEAP);
- }
-
- start = lineptr;
+ char *start = lineptr;
if (uselex) {
LinkList wordlist;
--
Mikael Magnusson
next prev parent reply other threads:[~2015-02-23 13:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 10:13 Peter Stephenson
2015-02-19 21:47 ` Mikael Magnusson
2015-02-19 22:03 ` Peter Stephenson
2015-02-20 3:16 ` Mikael Magnusson
2015-02-20 3:22 ` Mikael Magnusson
2015-02-20 3:33 ` Mikael Magnusson
2015-02-20 3:43 ` Mikael Magnusson
2015-02-20 4:19 ` Ray Andrews
2015-02-20 9:54 ` Peter Stephenson
2015-02-20 10:00 ` Peter Stephenson
2015-02-20 10:12 ` Mikael Magnusson
2015-02-22 18:26 ` Peter Stephenson
2015-02-23 9:54 ` Peter Stephenson
2015-02-23 10:11 ` Peter Stephenson
2015-02-23 11:35 ` Mikael Magnusson
2015-02-23 12:36 ` Peter Stephenson
2015-02-23 12:57 ` Peter Stephenson
2015-02-23 13:38 ` Mikael Magnusson
2015-02-23 13:46 ` Mikael Magnusson [this message]
2015-02-23 13:51 ` PATCH: Remeta one frame earlier Mikael Magnusson
2015-02-23 13:58 ` Peter Stephenson
2015-02-23 14:05 ` Peter Stephenson
2015-02-23 14:32 ` Mikael Magnusson
2015-02-23 17:32 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHYJk3RuZiWpi-_ZnEfdS9HHww1OvFj1AegZBiXeMDH0zceieg@mail.gmail.com \
--to=mikachu@gmail.com \
--cc=p.stephenson@samsung.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).