[Unison-hackers] UI patches, build script

[Benjamin C. Pierce]

I did try applying the patch, but I had trouble getting it to work.  (This is not a big surprise: it was the first time I’d tried patching with git.)

git am --signoff < temp1.patch

Applying: Test fix for confusing 'stop reconciling' UI bug
error: patch failed: src/uitext.ml:607
error: src/uitext.ml: patch does not apply

Unless there’s something obvious I’m doing wrong, a PR (or two, since your other fixes also seem useful) would probably be smoother.

    - B

> On Jan 31, 2020, at 11:31 PM, frederik at ofb.net wrote:
> 
> Thank you Benjamin. I'm not sure why a PR would make it easier, is
> that like a digital signature or something? There are presumably
> comments and other things that you would want to clean up by hand. I
> can do it, but I'm guessing you want only the first patch.
> 
> The comment in the second patch describes it as a "work in progress".
> It tries to fix some behavior that was added recently with all the
> "matching" predicates, in particular "%", but other commands need to
> be changed to make them consistent. The current behavior is confusing
> to me because the predicates don't apply to the current file, only the
> ones after. So if you want to do something for every file, you have to
> treat the first one differently from 2..n:
> 
>    $ unison a ssh://thutmose/a
>    Unison 2.51.2 (ocaml 4.08.1): Contacting server...
>    Connected [//ptolemy//home/frederik/a -> //thutmose//home/frederik/a]
>    Looking for changes
>      Waiting for changes from server
>    Reconciling changes
> 
>    local          thutmose
>    new file ---->            baz  [f] L   # list all changes
>      new file ---->            baz
>      new file ---->            foo
>    new file ---->            baz  [f] 1   # match all changes propagating ->
>      Enabling matching condition
>    new file ---->            baz  [f] /   # skip matching files
>    new file ---->            baz  [f] L   # foo is skipped, but not baz
>      new file ---->            baz
> 
> I just verified that I can apparently fix this by changing "rest" to
> "ril" in "actOnMatching", but you might want to check with whoever
> wrote that code (G.raud?) to make sure this is the right thing to do.
> The new patch is number 3 here
> https://github.com/navarum/tweaks/tree/master/unison/patches
> 
> Thanks,
> 
> Frederick
> 
> On Fri, Jan 31, 2020 at 08:44:30PM -0500, Benjamin C. Pierce wrote:
>> This does look like an improvement.  Would you mind packaging it as a pull request?
>> 
>> Thank you!
>> 
>>   - Benjamin
>> 
>>> On Jan 29, 2020, at 8:22 PM, frederik at ofb.net wrote:
>>> 
>>> I'm not sure if my emails are getting through here, but I created some patches to attempt to correct the UI behavior which I found confusing. I thought maybe I should share them in case they are useful:
>>> 
>>> https://github.com/navarum/tweaks/tree/master/unison/patches
>>> 
>>> The same repo contains a build script which I use to deploy Unison across different platforms. It builds a fixed version of Unison against a fixed version of OCaml. This makes it easier for me to run Unison between (say) Raspbian and Arch. Comments welcome.
>>> 
>>> Best wishes,
>>> 
>>> Frederick
>>> 
>>> On Mon, Dec 16, 2019 at 02:15:34PM -0800, frederik at ofb.net wrote:
>>>> Dear Unison hackers,
>>>> 
>>>> I think I've mentioned this before, but often when using Unison I want to take a break from answering questions and just reconcile the changes that I've selected. For example in the following interaction
>>>> 
>>>>  new file <==== new file   R/Makeconf  [f] <
>>>>  new file <-?-> new file   asound.conf  [] s
>>>> 
>>>>  Proceed with propagating updates? [] y
>>>> 
>>>> I selected that R/Makeconf should be propagated in one direction. Then I perused the increasingly longer list of commands and found one that looks appropriate:
>>>> 
>>>>  s                     stop reconciling and go to the proceed menu
>>>> 
>>>> I'm not sure what the "proceed menu" is, but since I selected only one update I'm pretty sure that only one thing is going to happen when I "stop reconciling" and allow Unison to "proceed". However, when I hit "s" and "y" then Unison proceeds to copy a whole bunch of stuff that I didn't ask for, and I have to Ctrl-C, which doesn't even do anything, so then I have to Ctrl-Z Ctrl-C, but meanwhile a lot of files have been copied, generally making a mess that I have to spend time cleaning up. Here's a fuller summary: http://ix.io/24Dn
>>>> 
>>>> By contrast, if I hit "/" at every prompt, to skip to the next item, then nothing is propagated.
>>>> 
>>>> My questions: Is my use case somehow unusual? Where did I go wrong? Or is it OK for all users to have an experience like this when learning how to use your program?
>>>> 
>>>> And what exactly does 's' do, and why doesn't it have a more accurate description in the UI?
>>>> 
>>>> Thanks,
>>>> 
>>>> Frederick
>>>> 
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at LISTS.SEAS.UPENN.EDU
>>> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>> 
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at LISTS.SEAS.UPENN.EDU
>> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>> 
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at LISTS.SEAS.UPENN.EDU
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20200201/42788290/attachment.html>