Feature Request: Option to hide some fields

[jdevera]

The request

I would like to somehow be able to dissociate what is shown to what is returned. For example, the output of git --no-pager log --format=oneline --abbrev-commit -n 5 in this repository

6fd6fff [vim] Ignore 'dir' option if empty
d1387bf Use IO.console when possible
4c923a2 [uninstall] Remove both patterns of source command (#97)
4ee85f1 [install] Join line numbers when multiple matches found
829c7f9 Merge branch 'mjwhitta-master'

I'd like to be able to show only the commit messages, without the sha, but at the same time, when I choose one, I want the sha to be in the output. So fzf would show me this:

[vim] Ignore 'dir' option if empty
Use IO.console when possible
[uninstall] Remove both patterns of source command (#97)
[install] Join line numbers when multiple matches found
Merge branch 'mjwhitta-master'

And when I choose the last one, I get this, the full line:

829c7f9 Merge branch 'mjwhitta-master'

Possible interface

The interface could, for example, be similar to that for limiting the search scope. Only in this case we either choose what to hide, or what to show.

[junegunn]

Thanks, it's an interesting idea. I can imagine something like: --show-nth=2,1,4..

Implementing it, however, could be non-trivial as doing so will make match highlighting (bright green) much more complex, especially in extended-search mode where there can be more than one matched substrings for each item. Maybe we should consider disabling the highlighting when --show-nth option is used.

[junegunn]

Implementing the feature is not really hard if we simply decide not to highlight the matched substrings. However, I'm not really sure if I like the feature as it can be pretty confusing when the query matches the hidden parts of the string as shown above (especially without substring highlighting).

[jdevera]

At least in my use case, I didn't need to match in the fields that were not visible, I only needed them to appear in the output in the end. If this was the case, I guess it would not be so confusing any more.

[junegunn]

Okay, I see. So we transform the original string and match against it, but return the unmodified string. That makes sense.

[junegunn]

Pushed to add-with-nth branch. Please test it and let me know if it meets your expectation.
In your case, --with-nth=2.. should do.

[jdevera]

Hey, that was fast! Thanks.

I tried this --with-nth=2.. and it worked as expected. However, when I did --with-nth=1, I was shown only the first column, as expected, but then the output contained only this, rather than the full string.

[junegunn]

Hmm, are you sure? I can't reproduce:

> echo 'hello world' | fzf --with-nth 1 -x -q llo$ -1
hello world

[jdevera]

When I use that command, it also works for me:

 $ echo 'hello world' | fzf --with-nth 1 -x -q llo$ -1
 hello world

In fact, I have reduced it to this:

$ echo 'hello world' | fzf --with-nth 1 # Select manually
hello
$ echo 'hello world' | fzf --with-nth 1 -1 # Select automatically
hello world

However, it doesn't seem to be a problem in the manual selection in all cases, since:

$ echo 'hello world' | fzf --with-nth 1 -q llo # Manual selection
hello world

[jdevera]

Furthermore, in all the manual selection cases above, if I type nothing, just select the only one match, then it shows hello. But if I type something like an h, then it returns hello world

Also tried this:

$ echo -e 'hello world\nbye world' | fzf --with-nth 1

Again, if I don't type anything, but just use arrow keys to select one match, then I get only the visible part. If I filter by typing something, then I get the full string.

[junegunn]

Maybe it's a bug I already fixed in the branch, I force-pushed a couple of times.
The HEAD should be db37e67, if it isn't, please force-pull and check.

[jdevera]

$ git rev-parse HEAD
db37e675756ef51b623326d54c29a86e98781544

Could it be related to?:

$ ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

[junegunn]

Aha, yes, it looks like it's only reproducible on old Rubies, I'll take a look.

[junegunn]

Please pull again and test it. (I'm dealing with the dark side of Ruby :/)

[jdevera]

Works like a charm! Thank you so much!

[junegunn]

Alright, it's finally merged to master. I just needed to write test cases for the problems we ran into.
Thanks for your feedback!

[jdevera]

I just noticed that if I set the delimiter to something like ' | ' (one of my use cases) and do --with-nth=2.. I get lines starting with the delimiter. That was unexpected. I would expect this to eat up this initial delimiter. Shall I create a new issue for it?

[jdevera]

Sorry, my bad, I did not realise that I had to regex-escape the expression passed to -d.

[jdevera]

It's worth noting that the value of --nth is applied after the cutting from --with-nth has been applied.

[junegunn]

Ah yes, the help entry could use some clarification. But I felt that it's the only sane way to do it. Imagine the confusion when we do it the other way round, especially in extended-search mode.

[tagwint]

There's always someone who likes the opposite :)
I mean - to show N fields but only pass one (some) of them (specified by -nth ) to the output.
A kind of -xnth, which would not only specify the fields to make selection on, but also forced to only take those fields from selection.
Generalizing the idea, inside an item line i'd like to distinguish fields i can make filtering on from the fields that are accepted e.g.

John 23 single baseball
Bob 29 married guitar
Suzi 22 single cooking
Mary 30 single baseball
Dan 44 single guitar

I would like select all singles who like baseball but only printout their name and age.
Perhaps there's a way to achieve that w/o implementing a new -xntht option?
I could not manage that using --with-nth and -nth - they seem to contradict for use case like that

[junegunn]

@tagwint

Perhaps there's a way to achieve that w/o implementing a new -xntht option?

You can post-process the output. e.g. awk, sed.

[tagwint]

Sure I can, and I also can chain fzf calls. There's nearly always more than one way of doing things :)

[junegunn]

@tagwint Yes, and so there's no point of adding the option. It's not like --nth or --with-nth which cannot be done with pre or post processors.

[Bugswriter]

I have this file:
http://0x0.st/iCwK.pls
I want to cat this file into fzf and remove the last word (or last 11 characters) without altering the output. (idk if this is the correct place) but after so long still I am unable to find the solution. So that's an issue.
I can achieve this if there is any inverse of :
cat file.pls | fzf --with-nth -1 ?

[srsudar]

@Bugswriter, I think maybe you could do this?

file.pls:

a b c d

Demo:

cat file.pls | fzf --with-nth='1..-2'

That then shows a b c as the search, and selecting it outputs the whole line: a b c d.

Is that what you want?

[Bugswriter]

Oh I can do this. thank you so much for replying the solution.
I was looking for this so long.

[drewauff]

Im fighting with this fc -t '%a.%m﹒%I:%M:%S%p' -rl 100 | fzf --with-nth=2..

Works, just cant scroll or select anything, on the very rare occasion I do select something, it does not execute.

The basic premise of this is to change what the history widget displays then execute on selection.

[TamaMcGlinn]

@tagwint Yes, and so there's no point of adding the option. It's not like --nth or --with-nth which cannot be done with pre or post processors.

This usecase cannot be done with pre- or postprocessors, because we care about the display that fzf gives while selecting, not just the output of the command. In this example, we want to display the names and ages, while searching the other two fields. The output of fzf afterwards can be manipulated by other commands, but the display cannot.

Note this would be quite simple if fzf did what the manpage implies, and allows you to separately specify indexes to display and to search:

       -n, --nth=N[,..]
              Comma-separated list of field index expressions for limiting search scope.  See FIELD INDEX EXPRESSION for the details.

       --with-nth=N[,..]
              Transform the presentation of each line using field index expressions

Based on this, you would expect this to work:

echo -e 'John 23 single baseball\nBob 29 married guitar\nSuzi 22 single cooking\nSingle 44 married piano' | fzf --nth 3.. --with-nth 1,2

If we enter 'single' then we should see John and Suzi, if we enter 'married' we should see Bob and the person named Single.

We specify that we want to search from the third field onwards, but display the first and second field. However, fzf currently filters first on with-nth and then applies the indexes of nth onto the reordered fields - I can't think of any reason to do it that way, it is strictly less powerful than the intuitive reading of the manpage would suggest.

[junegunn]

@TamaMcGlinn

I can't think of any reason to do it that way

I answered to the question early on: #102 (comment)
I did not like fzf searching against non-visible parts of an item, and whether you like it or not, that ship has sailed long ago. I agree that the man page needs clarification.

[junegunn]

@TamaMcGlinn

Imagine the confusion when we do it the other way round

Suppose we're applying --nth against the original string.

echo foo bar baz qux foo | fzf --with-nth 3,2,4 --nth ..

• You see baz bar qux on the screen but ^b doesn't match the item.
• bazbar doesn't match either
• Likewise, no match on x$
• fofo matches the item. But it's really hard to see why it's matching.

[TamaMcGlinn]

I would contend that the ship has been standing in the harbour in quarantine for three years. I just applied PR1447 and it works exactly as I described above. No need to update documentation.

Your example is incorrect, I tried it and all 4 statements about what would match are wrong, presumably you meant to make the --nth actually be some subset, not all fields using '..'; nevertheless I understand where you are taking the point, and you could make the point using my example above.

You are saying that you can then pass parameters to fzf which make it behave 'strange' - but, the user put the parameters there, right? If the user explicitly says 'search on fields 3 and 4, but show fields 1 and 2', why do we care whether said user understands what he told fzf to do?

[TamaMcGlinn]

For what it's worth, my main reason for wanting this is that I have a large preview window which shows the context including the actual line matched and some coloring using grep, so displaying the full line also in the list of matches is duplicate information which just doesn't fit. I am trying to abbreviate that so that I can always see the first part. Currently it shows some part of the match with ellipses on either end of the line, which is not helpful at all.

[junegunn]

I would contend that the ship has been standing in the harbour in quarantine for three years.

You're underestimating the implication of breaking the backward compatibility. Many users of fzf have relied on the current behavior and have written many scripts and we don't want to break them all of a sudden after 7 years.

I can always see the first part

--no-hscroll