(Of course there are zillions of spurious changes to the rc
file, due to the fact that our Merge.rc file is so different
from how MSVC6 writes it out -- ignore the rc file -- the
only difference is, of course, adding the accelerator.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm. What happens when there is no selection in other side?
Text is copied to cursor pos, and that can be surprising
user. Because cursor and/or anchor might not be where user
expects it to be..
This would be very nice if it could be used to replace
selected line in another file. I mean, seleting line in
FileA, and this feature replaces matching line in another
file, instead of appending new text. That would be handy for
example merging rc files, no need to copy/paste new strings,
just select line in other side and use this.
Determining that 'matching line' in another file is usually
simple by view line number (not actual file linenumber). But
propably there are nasty special cases too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it pastes where the caret it, which is the invisible
selection area.
This was exactly what I want, when I'm in the middle of
doing the hundreds of times of this in the Chinese merge --
that happened when there was nothing on the right side. That
was fairly rare, actually, and I forget -- oh, it happened
with keyword changes.
I think maybe you're talking about a different functionality
-- about finding the matching line. I mean, that would be
different than this one.
I think this one is pretty simple to explain -- copy
selected area to selected area
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pasting to where cursor is doesn't make sense many times.
Cursor is usually in begin of line in other view. Unless you
specifically set cursor position in another view, and then
you propably select word(s) you want to replace also.
And after scrolling to diff cursor is at begin of first line
of diff. When do you want to copy from middle of (for
example) third line to begin of first line (of diff)?
This is fine to replace selection in another file. But its
pretty problematic when there is no selection. You cannot
suprise users with unpredictable paste location. And thats
the reason we don't have those line-by-line diff features,
correct behavior is hard to get right.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But, what I really want here, is exactly to paste where the
cursor is. That is the whole point. The reason is that I'm
not selecting where the cursor is, WinMerge is, because I'm
doing this right after doing either "shift-F4" or "F4,F4",
both of which set the cursor the appropriate place.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can we move the discussion about finding matching lines to
somewhere more appropriate? I have some thought about that,
but this doesn't seem to me to be a very good place for me
to put them.
(That--finding matching lines--could be pretty useful.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. We have couple of RFE items about that already.
Can you change this patch so it only replaces selection for
now. Like I mentioned, its confusing if copied selection
appears to seemingly random places (inactive view has no
cursor visible!).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, its not as useful if it doesn't handle the case that
the selection on the other side is empty.
I wrote it to work perfectly with both Shift-F4 and F4,F4.
If I understand, you want it only work when the matching
area on the other side is non-empty?
That will mostly impede this on the F4 operations -- the
ones where you are walking across the interior diffs in a
line, and some of them have empty matching spots on the
other, because you have an added word highlighted.
I suppose the workaround (if we make this patch not work for
those parts), is to hit F6 and then do it again, because it
will work the other way, but no -- that will merge the wrong
direction.
I think this functionality is actually less confusing that
the existing ctrl-alt-right arrow, because with this, you
can see what just happened -- with ctrl-alt-right, you
usually cannot see what just happened, because WinMerge
purposefully scrolls to somewhere else immediately.
But, even though ctrl-alt-right is somewhat dangerous and
possibly confusing, we want it, because it is so useful to
power users; I certainly want it -- the single keystroke
that it saves is very valuable because it is so common.
I think this patch is similar -- it only saves a few
keystrokes, but they are terribly repetitive when you're
using them.
This functionality, like ctrl-alt-right, is aimed at the
power user, not the novice. The novice is likely to start
out doing simple select, copy, select paste operations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm. I'm sure I can cripple this function to only work if the
other side has non-empty selection, but I'm not immediately
sure how to do so, so I'll have to investigate, and post a
revised, crippled version later. (In this code, I never had
to fetch the selection from the other side -- but it should
be analogous to fetching the active selection text, so it
should be easy.) Then I can apply that (new crippled) one
for now, right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CString text = pActiveView->GetCopyableText();
CString oldtext = pInactiveView->GetCopyableText();
if (oldtext.IsEmpty())
return; // we don't copy if there isn't a selection
on the other side
pInactiveView->ReplaceSelection(text, 0);
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ctrl-Alt-Left/Right behaves always like expected. It doesn't
copy random diffs to random places.
Hmm. Good point that F4 sets cursor position to inactive
side, and then this is useful as adding text. Now, this
starts to sound like we should have this as just
shortcut/helper for F4, not as general feature.
But still, user cannot see cursor position in inactive view,
so user has no clue where text is to be added. After F4 user
has clue and certain expectation, its safe and good behavior.
But real problem is when that text is pasted to totally
different place, it can even be begin of first line of view.
User may not even notice where text was pasted, especially
if its already inside another diff. So one scrolls view and
losts pasted text, saves file...
This scares me somewhat, making unexpected changes to files.
Hmm. Do we have a way to determine if current selection is
by word-diff? Then we could (at start) enable this only when
used with F4?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That revised method is ok for me. Don't get me wrong, I
certainly am happy user of this new feature, but we have to
handle all cases not just most obvious ones. Like shown with
multi-doc and per-doc-menu patches, both work nice for
general cases but then there are those ugly corner cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Ctrl-Alt-Left/Right behaves always like expected. It doesn't
copy random diffs to random places.
I don't understand -- are you saying that this patch copies
to random place? I wrote the patch, and didn't observe any
behavior like that. I admit I didn't test very much -- have
you tried it?
I don't understand what you mean by unexpected change either.
This is like ctrl-alt-right -- if you push it, that is what
you get. Except, this patch doesn't scroll away, so at least
it doesn't try to hide the results from you.
But, the crippled version will probably solve most of my
needs anyway, so I doubt I'll care :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about if I leave a comment in the code, saying to remove
those two lines to get the uncrippled version? Just to help
me find them and remove them, if I need the full version, in
my own IDE running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have not seen weird behavior since you are using it like
you expect it is to be used. Other case is simple (once again):
- scroll to diff with Alt-Down
Now, where is the cursor in another (inactive) file?
It is in begin of the first line of diff. Do we agree about
this?
Now, user selects text in active view, lets say from third
line in diff, and uses this feature. Where does text get
copied? To third line of diff in inactive view? Nope. To
begin of first line of diff. Does user expect that? I don't
think so.
What if cursor is somewhere else in file? User may have
edited that other file, then swiched to other side to select
text. Now user has no any idea where cursor is in inactive
file, and where text gets copied. And cursor can be outside
visible area of file. Just scroll view using scrollbars.
That certainly causes confusion.
I've spent many days with this selection and inactive file
cursor position code. Its hard to get right so it feels natural.
Full code in comments is OK. Propably best solution right
now so more people can easily experiment with this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like this idea and I have thought implementing something
like this myselft. But UI has serious problems.
Hmm. Just checking that we are replacing selecting in same
screen lines propably addresses all complaints I have.
So this could be done in two ways:
- only enable/allow this feature when cursor/selection is
in same lines in both sides
- enable/allow always, but show warning if cursor/selection
is in different lines
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1195173
(Of course there are zillions of spurious changes to the rc
file, due to the fact that our Merge.rc file is so different
from how MSVC6 writes it out -- ignore the rc file -- the
only difference is, of course, adding the accelerator.)
150Kb zip of 6 files changed & original
Logged In: YES
user_id=1195173
Oh, I also added a menu item to the bottom of the Edit menu
for this functionality - when I was struggling because F2
hotkeys don't work.
The new function, performed by this patch, is driven by
command symbol ID_COPYSELACROSS.
Logged In: YES
user_id=631874
Hmm. What happens when there is no selection in other side?
Text is copied to cursor pos, and that can be surprising
user. Because cursor and/or anchor might not be where user
expects it to be..
This would be very nice if it could be used to replace
selected line in another file. I mean, seleting line in
FileA, and this feature replaces matching line in another
file, instead of appending new text. That would be handy for
example merging rc files, no need to copy/paste new strings,
just select line in other side and use this.
Determining that 'matching line' in another file is usually
simple by view line number (not actual file linenumber). But
propably there are nasty special cases too.
Logged In: YES
user_id=1195173
re: when there is no selection in other side
Yes, it pastes where the caret it, which is the invisible
selection area.
This was exactly what I want, when I'm in the middle of
doing the hundreds of times of this in the Chinese merge --
that happened when there was nothing on the right side. That
was fairly rare, actually, and I forget -- oh, it happened
with keyword changes.
I think maybe you're talking about a different functionality
-- about finding the matching line. I mean, that would be
different than this one.
I think this one is pretty simple to explain -- copy
selected area to selected area
Logged In: YES
user_id=631874
Pasting to where cursor is doesn't make sense many times.
Cursor is usually in begin of line in other view. Unless you
specifically set cursor position in another view, and then
you propably select word(s) you want to replace also.
And after scrolling to diff cursor is at begin of first line
of diff. When do you want to copy from middle of (for
example) third line to begin of first line (of diff)?
This is fine to replace selection in another file. But its
pretty problematic when there is no selection. You cannot
suprise users with unpredictable paste location. And thats
the reason we don't have those line-by-line diff features,
correct behavior is hard to get right.
Logged In: YES
user_id=1195173
But, what I really want here, is exactly to paste where the
cursor is. That is the whole point. The reason is that I'm
not selecting where the cursor is, WinMerge is, because I'm
doing this right after doing either "shift-F4" or "F4,F4",
both of which set the cursor the appropriate place.
Logged In: YES
user_id=1195173
By the way
> And thats the reason we don't have those line-by-line diff
features, correct behavior is hard to get right.
What are these "line-by-line diff features" ?
If I knew, I've forgotten. :(
Logged In: YES
user_id=1195173
Can we move the discussion about finding matching lines to
somewhere more appropriate? I have some thought about that,
but this doesn't seem to me to be a very good place for me
to put them.
(That--finding matching lines--could be pretty useful.)
Logged In: YES
user_id=631874
Yes. We have couple of RFE items about that already.
Can you change this patch so it only replaces selection for
now. Like I mentioned, its confusing if copied selection
appears to seemingly random places (inactive view has no
cursor visible!).
Logged In: YES
user_id=1195173
Well, its not as useful if it doesn't handle the case that
the selection on the other side is empty.
I wrote it to work perfectly with both Shift-F4 and F4,F4.
If I understand, you want it only work when the matching
area on the other side is non-empty?
That will mostly impede this on the F4 operations -- the
ones where you are walking across the interior diffs in a
line, and some of them have empty matching spots on the
other, because you have an added word highlighted.
I suppose the workaround (if we make this patch not work for
those parts), is to hit F6 and then do it again, because it
will work the other way, but no -- that will merge the wrong
direction.
I think this functionality is actually less confusing that
the existing ctrl-alt-right arrow, because with this, you
can see what just happened -- with ctrl-alt-right, you
usually cannot see what just happened, because WinMerge
purposefully scrolls to somewhere else immediately.
But, even though ctrl-alt-right is somewhat dangerous and
possibly confusing, we want it, because it is so useful to
power users; I certainly want it -- the single keystroke
that it saves is very valuable because it is so common.
I think this patch is similar -- it only saves a few
keystrokes, but they are terribly repetitive when you're
using them.
This functionality, like ctrl-alt-right, is aimed at the
power user, not the novice. The novice is likely to start
out doing simple select, copy, select paste operations.
Logged In: YES
user_id=1195173
Hm. I'm sure I can cripple this function to only work if the
other side has non-empty selection, but I'm not immediately
sure how to do so, so I'll have to investigate, and post a
revised, crippled version later. (In this code, I never had
to fetch the selection from the other side -- but it should
be analogous to fetching the active selection text, so it
should be easy.) Then I can apply that (new crippled) one
for now, right?
Logged In: YES
user_id=1195173
Here is the revised method code for a crippled version, for
minimized possible confusion:
void CMergeDoc::CopySelToOtherView(CMergeEditView * pActiveView)
{
CMergeEditView * pInactiveView = GetOtherView(pActiveView);
CString text = pActiveView->GetCopyableText();
CString oldtext = pInactiveView->GetCopyableText();
if (oldtext.IsEmpty())
return; // we don't copy if there isn't a selection
on the other side
pInactiveView->ReplaceSelection(text, 0);
}
Logged In: YES
user_id=631874
Ctrl-Alt-Left/Right behaves always like expected. It doesn't
copy random diffs to random places.
Hmm. Good point that F4 sets cursor position to inactive
side, and then this is useful as adding text. Now, this
starts to sound like we should have this as just
shortcut/helper for F4, not as general feature.
But still, user cannot see cursor position in inactive view,
so user has no clue where text is to be added. After F4 user
has clue and certain expectation, its safe and good behavior.
But real problem is when that text is pasted to totally
different place, it can even be begin of first line of view.
User may not even notice where text was pasted, especially
if its already inside another diff. So one scrolls view and
losts pasted text, saves file...
This scares me somewhat, making unexpected changes to files.
Hmm. Do we have a way to determine if current selection is
by word-diff? Then we could (at start) enable this only when
used with F4?
Logged In: YES
user_id=631874
That revised method is ok for me. Don't get me wrong, I
certainly am happy user of this new feature, but we have to
handle all cases not just most obvious ones. Like shown with
multi-doc and per-doc-menu patches, both work nice for
general cases but then there are those ugly corner cases.
Logged In: YES
user_id=1195173
> Ctrl-Alt-Left/Right behaves always like expected. It doesn't
copy random diffs to random places.
I don't understand -- are you saying that this patch copies
to random place? I wrote the patch, and didn't observe any
behavior like that. I admit I didn't test very much -- have
you tried it?
I don't understand what you mean by unexpected change either.
This is like ctrl-alt-right -- if you push it, that is what
you get. Except, this patch doesn't scroll away, so at least
it doesn't try to hide the results from you.
But, the crippled version will probably solve most of my
needs anyway, so I doubt I'll care :)
Logged In: YES
user_id=1195173
How about if I leave a comment in the code, saying to remove
those two lines to get the uncrippled version? Just to help
me find them and remove them, if I need the full version, in
my own IDE running.
Logged In: YES
user_id=631874
You have not seen weird behavior since you are using it like
you expect it is to be used. Other case is simple (once again):
- scroll to diff with Alt-Down
Now, where is the cursor in another (inactive) file?
It is in begin of the first line of diff. Do we agree about
this?
Now, user selects text in active view, lets say from third
line in diff, and uses this feature. Where does text get
copied? To third line of diff in inactive view? Nope. To
begin of first line of diff. Does user expect that? I don't
think so.
What if cursor is somewhere else in file? User may have
edited that other file, then swiched to other side to select
text. Now user has no any idea where cursor is in inactive
file, and where text gets copied. And cursor can be outside
visible area of file. Just scroll view using scrollbars.
That certainly causes confusion.
I've spent many days with this selection and inactive file
cursor position code. Its hard to get right so it feels natural.
Full code in comments is OK. Propably best solution right
now so more people can easily experiment with this.
Logged In: YES
user_id=1195173
Another approach would be some type of UI so that I can make
this as a macro.
That might make more sense, as you're convinced that this is
too dangerous for users, right?
And I'm entirely convinced that this is what I need (after
doing hundreds of operations wishing I had it).
So, some type of interface like macros, where I can program
in this functionality, but it won't affect other users,
might be best.
Logged In: YES
user_id=631874
I like this idea and I have thought implementing something
like this myselft. But UI has serious problems.
Hmm. Just checking that we are replacing selecting in same
screen lines propably addresses all complaints I have.
So this could be done in two ways:
- only enable/allow this feature when cursor/selection is
in same lines in both sides
- enable/allow always, but show warning if cursor/selection
is in different lines
Logged In: YES
user_id=1195173
I thought about it some, but I am not ready to try to solve
the UI for macros -- that will be difficult.
So I'll go back to applying a reduced version of this patch.