> On Nov 16, 2019, at 10:45 AM, Michael Albinus <[email protected]> wrote:
>
> JD Smith <[email protected]> writes:
>
>> `ido-everywhere` is the culprit. If I disable it, things work as
>> expected. Most ido users have it enabled I’d guess.
>>
>> I can also work to get ido patched so that it respects
>> `ido-read-file-name-non-ido` even for directory reads, which failure
>> seems like an obvious bug. Then perhaps tramp can add its rename
>> commands to that list. I’m not sure how Ivy or Helm (or fido!) deals
>> with these prompts, btw, but might be worth testing.
>
> I'll dive into ido debugging next week. Rather not this weekend; my
> daughter has her birthday tomorrow.
Of course! Priorities!
> If you find something for ido config, pls let me know. Or if you have an
> ido patch, I could commit it to Emacs in your name. (Don't know, whether
> you have an account on savannah.)
>
> Is this the only problem which is left?
I sent a bug report to bug-gnu-emacs with a suggested simple patch. I can
commit but it’s been quite a while so prefer others to do so.
BTW, I’ve already used rename-files to good effect today. One of my favorite
features of tramp is it serializes remote file access over an arbitrary history
of network (non-)availability. The file is always there, waiting to be written
over the network when available. I can safely edit a remote file on an
airplane or otherwise off-grid, then later cleanup the connection and continue
as if nothing changed. This is one of those emacs super-powers that people
cannot believe when I show them. There is simply no equivalent. And this new
functionality makes this superpower even more robust. Thanks for all your
efforts.
JD
