| swisspol | |
| Jul 20 2015, 10:22 PM |
| F643137: pasted_file | |
| Jul 20 2015, 11:06 PM |
| F643033: pasted_file | |
| Jul 20 2015, 10:24 PM |
| F643021: pasted_file | |
| Jul 20 2015, 10:22 PM |
Observed on lastest Mac Chrome running an instance on Phacility: select some text in a Phriction document side-by-side diff like this:
Copy text with Cmd-C but what gets on the clipboard is this:
= Release Manager Role = Hotfix Branches (bunch of empty lines)
In unified diff, it works better but still not correctly:
= Release Manager Role 55 Releases can take many forms, so the specific role for your team should be worke 56 d out with your manager and documented on your team's page. In general, however, 57 the release manager's job is make sure the main repo is clean and keeps an accu 58 rate history. 59 When it is time for a release, the release manager starts the release branch. Th 60 is takes two parts: 61 # Creating the release branch 62 # Bumping any versioning you have 63 For example 64 `` 65 git checkout -b release-1.2 master 66 ./bump-version.sh 1.2 67 git commit -a -m "Bumped version number to 1.2" 68 `` 69
Actually works really well in Chrome (43 and earlier) on Windows:
its event and scheduling features.
- {T7924}
Harbormaster
=====
We plan to unprototype Harbormaster and provide basic external build support.
- {T8089}
No newline at end of fileIn 1-up, there's no ambiguity and we can improve this behavior.
In 2-up, when you select a range, we can't tell (in the general case) whether you want the right-hand side or the left-hand side. We assume you want the right-hand side, because this is more often the case, especially in Differential. In the original report, what's being copied is likely a clean version of the right-hand side of the selection.
Because the event is a copy, I believe we also need to react to the event inline (without returning to the event loop), so we can't pop a dialog asking the user which side they meant. We could possibly use a confirm(), although this would be fairly kludgy ("Press 'ok', or your browser's similar confirm button, to take the right-hand side [this button will be on the left on Windows, but it takes the right-hand side!]. Press 'cancel', or your browser's similar cancel button, to take the left-hand side.").
We could also copy both sides with some explanatory text, like this:
(You copied some text from a 2-up diff, and we can't tell if you wanted the left or right side, so we're giving you both.) <Left Side> blah blah <Right Side> blah blah
This is always bad (i.e., never what the user wanted), but more clear and always a superset of what they wanted, at least.
When copying from Phriction and transaction diffs (for example, the diff shown in "Show Details" on a transaction like "alincoln edited the description for this task."), you're also copying out of a diff which we've inserted artificial linebreaks into. These linebreaks are inserted prior to diffing, and these diffs are generally of very low quality. There's some discussion in T3353 of improving these diffs to be word-based instead of character-based, which is likely to substantially mitigate issues around linebreaks and the generally low quality of these diffs.
@swisspol / @chad, in this case, is the root issue here the lack of per-section revert in Phriction? That is, are you copying the left side of a Phriction diff specifically in order to revert it to an earlier version? If so, something in the vein of T6610 may be a better solution to the root problem.
I copy/paste code, i don't know how to write it myself.
If it's a left/right issue, we could cheat and see where you started the click (left or right).
Right now my workflow is to use View Options -> View Right File Raw
Do you have an example where copying the right side of a diff currently does not work like you expect/want it to?
Oh, I can copy and paste fine in Differential. Guess... Chrome fixed that at some point, or I'm forgetful.
I wasn't trying to revert, I was just trying to copy-paste some of the markup of an old version of a wiki doc. Since I was copying from a previously deleted section, I understand why the result was empty: it was copying from the right side of the diff which was empty. That said, that was very non-intuitive.
In any case, is it expected that line numbers are being copied in the unified diff case?
In any case, is it expected that line numbers are being copied in the unified diff case?
No:
In 1-up, there's no ambiguity and we can improve this behavior.