zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: _history-complete-older problems with $(
Date: Wed, 13 Jan 2016 20:48:47 -0800	[thread overview]
Message-ID: <160113204847.ZM14158@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVBz1nNueRmEfyz3157kvJjEgHW3wmSXraKM+-9P-i5Atw@mail.gmail.com>

On Jan 13,  5:40pm, Sebastian Gniazdowski wrote:
}
} Zsh doesn't make following word active, i.e. "ls |/Users/user_na"
} with the cursor where "|" is will not complete the "user_name".

That's specific to complete_in_word -- if you have not set that, then
the cursor moves to the end of the word before attempting completion.
But if you HAVE set that, you are saying that the (empty) part of the
word to the left of the cursor is important, so zsh is correctly
responding that there isn't anything that can be completed there.

} I have chosen different approach, in such case I treat
} what's after "|" as right part of current shell word.

Zsh DOES treat what's to the right of the cursor as part of the
current word.

You can see what's going on more clearly if you complete (in the zsh
source tree, "|" indicates the cursor when TAB is pressed):

torch% setopt completeinword
torch% ls |c
Doc/  Etc/  Src/

Here "c" is part of the word and there IS something that can appear
to the left of it, so you get the completions.

If you want other behavior you use a matcher (matcher-list style).

} The same I do for zew-transpose-shell-words (former
} transpose-segments), block cursor on first letter of word makes the
} word active, selected for transposition.

That should be the way both the builtin transpose-words and the newly
patched transpose-words-match work as well, so I'm not sure 

} I have one problem. First compadd returns $found array
} populated with matches:
} 
} But nothing is displayed below the prompt, "en" replaces "wid" at
} prompt and that's all

Ah.  Another wrinkle I overlooked.  You need to store the original
values of $PREFIX and $SUFFIX somewhere, e.g.

    local origPREFIX=$PREFIX origSUFFIX=$SUFFIX

Then, after "compadd -O found" but before trimming PREFIX and SUFFIX
off of $found, you need

    PREFIX=${PREFIX#$origPREFIX}
    SUFFIX=${SUFFIX%$origSUFFIX}

This is because compadd will still try to replace the original word
prefix ("wid") with whatever you pass to that second compadd, so if
there was an original prefix/suffix you must NOT trim those off.  I
didn't test my original version with anything other than an empty
$PREFIX so didn't think of this.

} The same problem is with "ls" about which I wrote to you earlier. So
} it seems that the second compadd isn't fully working.

When _history returns nonzero, your debugging line

    echo >> /tmp/wfhistory

is clobbering that with its own zero return, so completion stops even
if no matches were found.  Move that last "echo" into the block that
is after "always" (right before "unfunction compadd").


  reply	other threads:[~2016-01-14  4:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-10 19:35 Sebastian Gniazdowski
2016-01-11 16:21 ` Sebastian Gniazdowski
2016-01-12  0:15   ` Bart Schaefer
2016-01-12 13:09     ` Sebastian Gniazdowski
2016-01-12 19:39       ` Bart Schaefer
2016-01-13  1:01         ` Daniel Shahaf
2016-01-13  2:01           ` Bart Schaefer
2016-01-13 16:40             ` Sebastian Gniazdowski
2016-01-14  4:48               ` Bart Schaefer [this message]
2016-01-14 11:30                 ` Sebastian Gniazdowski
2016-01-14 11:37                   ` Sebastian Gniazdowski
2016-01-14 11:59                     ` Sebastian Gniazdowski
2016-01-15  3:18                   ` Bart Schaefer
2016-01-15  5:07                     ` Sebastian Gniazdowski
2016-01-15  6:26                     ` Daniel Shahaf
2016-01-14 18:55                 ` Sebastian Gniazdowski
2016-01-14  9:52               ` Sebastian Gniazdowski
2016-01-14 10:14                 ` Sebastian Gniazdowski
2016-01-14 10:55                   ` Sebastian Gniazdowski
2016-01-15  3:05                     ` Bart Schaefer
2016-01-15  6:26                 ` Daniel Shahaf
2016-01-13  1:01       ` Daniel Shahaf
2016-01-13  1:59         ` Bart Schaefer
2016-01-12  7:57 ` Bart Schaefer

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=160113204847.ZM14158@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).