Spyder: Duplicate line down has changed behavior with Duplicate line up

Created on 24 Mar 2020  路  9Comments  路  Source: spyder-ide/spyder

Previously when you duplicate line down the newly created line was also selected. This is imo prefered behaviour because you could immediately move the newly copied lines with move line down.

In Spyder 4.1.1 this has changed and the original lines stay selected, which is the old duplicate line up behaviour. Thus, one has to move the original lines through the newly copied ones and then to the location where you want them.

Maybe this is the wanted behaviour, so I'm not sure about reporting it, and there's an easy workaround - switch the current shortcuts between the two commands to retain the old behaviour :smile:

Question

Most helpful comment

Yes I think I inverted things by mistake. I can submit a PR that will switch this back to the original behaviour, this is very simple to achieve.

I just need to inverse the after_current_line argument in self.__duplicate_line_or_selection calls and update the tests probably.

All 9 comments

Thoughts on this @spyder-ide/core-developers ?

I'm unsure if we changed that behavior intentionally. Just in case, as far as I know, the last PR changing something regarding the duplicate lines functionality was PR #11122 (although I think that only changes the shortcuts names)

Yeah, I think this could have been changed by @jnsebgosselin in that PR.

If I'm thinking about this correctly there is no difference between copy line up or down except where the select line ends up after the completion of the task. This is a question like whether "natural" scrolling is more intuitive. I can make both ways make sense in my mind.

If a compare this operation to duplicating in graphics software(which is where I got the duplicate name idea) the duplicate is usually selected after the operation to allow editing on the duplicate not the origional. So we would have it backward in this case.

Yes I think I inverted things by mistake. I can submit a PR that will switch this back to the original behaviour, this is very simple to achieve.

I just need to inverse the after_current_line argument in self.__duplicate_line_or_selection calls and update the tests probably.

Thanks for your help with that @jnsebgosselin!

@bcolsen Yeah, but it's not really equivalent. Say you have the following code:

x = np.linspace(0, 4*np.pi, 100)
y = np.sin(x)
plt.figure()
plt.plot(x, y)
plt.grid()

And then you add:

x = np.arange(100)
y = np.sin(x)

and you wanna make a plot of the new data. The ergonomic way to do it would be to move up to the three plotting lines, select them and duplicate them downward, which results in a selected copy below the original three lines, which then you can move down to the end of the file. If in contrast the original lines remain selected, then you either have to select the newly copied lines, or move the selected original ones down through their copy to the end of the file.

Also using duplicate line up to get the selected original ones down doesn't make too much sense.

@gerazov All I was trying to say is that one could duplicate them upward and achieve the same effect that you wanted, which is how you made the gif I guess.

I do agree that I would want the duplicate to be selected(ie It's currently backwards)

Yeah I really wanted to make that gif :smile:

Was this page helpful?
0 / 5 - 0 ratings