Improve ivy TRAMP support

[ghost]

Modifications for better ivy/TRAMP support
for /protocol: syntax as well as /path/to//protocol:.

[ghost]

Sorry for the noise -- turns out I have no idea how to comment my PR on GitHub.

The commit is available with annotations:
d7328ec

[abo-abo]

Thanks, it looks like a lot of changes. Since Ivy is in GNU ELPA, you can contribute only up to 15 lines without an Emacs Copyright Assignment. Do you have one?

[ghost]

Will shoot assign@gnu.org a message for the CA. I'll let you know once I've gotten it in order.

[abo-abo]

Great! If you're in USA, it can be done faster electronically. I had to go through snail mail since I was in Germany back then, so it took around 1 month.

[PythonNut]

I did mine electronically, but it took about a month anyway (no idea why).

Hope it gets done in short order! :)

[ghost]

Received confirmation of my Emacs assignment.

I noticed that there was a bug in my previous patch (6666cf8) when checking against the expanded filename (fixed in b39e20c). I expand them in the above PR in some places as well, so I will take some time to investigate if there are any related issues a bit later this week and update against the latest master.

In the meantime, if there is any commentary on the patch, especially related to the (= ivy--length 1) case that I'm proposing removing, it would be appreciated.

[abo-abo]

Could you update the PR? I only see a version of code from 2 weeks ago. Is that still current?

[ghost]

Still current as of now; I'll have time tomorrow to update against master and check to make sure it isn't affected by the expanded path problem. Updated PR will be available at that time.

The part I was wondering though was the purpose of this line in master.

It seems like removing that condition ((= ivy--length 1)) results in better behavior in all cases, but I wanted to check to make sure that would not break an edge case that I'm not thinking about.

It could also be removed separately from my PR, if that's the case.

[abo-abo]

The part I was wondering though was the purpose of this line in master.

It seems like removing that condition ((= ivy--length 1)) results in better behavior in all cases, but I wanted to check to make sure that would not break an edge case that I'm not thinking about.

It could also be removed separately from my PR, if that's the case.

I think it can be removed. It carried over from the general logic of trying to partial-complete on the first TAB and exit on the second TAB. But if the input is a perfect directory name, might as well exit on the first TAB.

[ghost]

PR is now updated against master.

[abo-abo]

Thanks, the change looks good to me. Could you maybe give some examples of the new things that work now and didn't work before? Should be useful for the manual.

[ghost]

Sure. In most cases it gives /protocol: matching behavior to /path/to//protocol::

Hostname completion:

Completions:

Prior: /path/to//protocol: TAB
Additional: /protocol: TAB

ivy:

Prior: /path/to//protocol: C-j
Additional: /protocol: C-j

Find file (continue in ivy):

Prior: /path/to//protocol:host: TAB <-- better behavior, continues in ivy rather than Completions
Additional: /protocol:host: TAB

Prior: /path/to//protocol:host: C-j
Additional: /protocol:host: C-j

File open (if path is a valid directory, it continues in ivy):

Prior: /path/to//protocol:host:/some/path C-j
Additional: /protocol:host:/some/path C-j

Quick jump to same directory as sudo:

Prior: /path/to//sudo:: C-j
Additional: No analogous, user probably wants ~root rather than / here.