Stop logging common path to stderr

[ghost]

So I've taken a closer look at #107. The cause of the issue is actually that if there's a common path it's logged to stderr (see the block I've removed). This seems like a bit of a mismatch for stderr, from the fish docs stderr is meant to be used for:

Standard error (stderr) for writing errors and warnings. Defaults to writing to the screen.

and I don't think the common path really counts as either. Removing it fixes the prompt messing up when completing.

Behaviour before this change:

Behaviour after this change:

As you can see the prompt is now no longer messed up when there's a common path prefix.

Now I'm not really that familiar with awk or this plugin, so I'm not sure if we need to do some further cleanup after this change. Or if this change would break anything (other than removing the common path logging via stderr from z -l). See these lines for something that I think we could clean up: https://github.com/jethrokuan/z/blob/master/functions/__z.fish#L140-L143. We could also do that after this PR.

Let me know what you think.

[krobelus]

The fact that z -l query prints the common prefix looks like a nice feature. How about we keep it and use this alternative fix:

diff --git a/functions/__z_complete.fish b/functions/__z_complete.fish
index 51ec5f8..fe4f641 100644
--- a/functions/__z_complete.fish
+++ b/functions/__z_complete.fish
@@ -3,8 +3,8 @@ function __z_complete -d "add completions"
         printf "%s\n" (string replace -r '\|.*' '' < $Z_DATA)
     end
 
-    complete -c $Z_CMD -a "(__z -l | string replace -r '^\\S*\\s*' '')" -f -k
-    complete -c $ZO_CMD -a "(__z -l | string replace -r '^\\S*\\s*' '')" -f -k
+    complete -c $Z_CMD -a "(__z -l 2>/dev/null | string replace -r '^\\S*\\s*' '')" -f -k
+    complete -c $ZO_CMD -a "(__z -l 2>/dev/null | string replace -r '^\\S*\\s*' '')" -f -k
 
     complete -c $Z_CMD -s c -l clean -d "Cleans out $Z_DATA"
     complete -c $Z_CMD -s e -l echo -d "Prints best match, no cd"

[ghost]

Yeah the thing is, this still retains the pattern of outputting the common path to stderr for list. Which is the core of the problem. Stderr is for errors or warnings.

If you take the list, you could extract the common path from that separately. For example

If finding a common prefix is a very common usecase and you want to make it simpler for your users, I would provide it under a separate flag, say --common. That way if a user wants the common prefix, they can have it, if they want the list, that's possible as well. And if they want to retain the old behaviour, they could create an alias alias that calls --common and --list in sequence.

Everything would then be possible without messing up the prompt.

[ghost]

I think the core of my point is, it seems more in line with the unix philosophy to have list output a list. And if finding a common prefix is useful, having that as a separate command seems like the most composable solution. That would allow choice and composability without sacrificing us following the standards (i.e. using stderr vs stdout). What do you think?