Make 'Paste Above' the default paste behavior.

[dwf]

Destructive paste mapped to Ctrl-M V is a surprising choice given that there was no drag-to-select on the area being replaced (there is a weaker notion of "selected cell" but this does not map to will-be-replaced-
by-paste in the minds of participants in an unscientific poll at PyConCA).

Destructive paste is still available as the last paste option in the Edit menu, qualified as "Paste Cell Replace".

[fperez]

maybe say Paste Cell & Replace?

[dwf]

Fixed.

[fperez]

I'm on board with this idea, I've been bitten by the destructiveness of the default paste behavior of paste enough that I'm now convinced it's really not the best UI.

Let's leave this one here for a bit longer to give other people a chance to look at it too and comment.

[dwf]

One justification for paste-above vs. paste-below: pasting at a cursor position in a text editor displaces content forward.

Also this is how vim does full-line pastes via 'p' (if you e.g. yank via "-v y")

[Carreau]

+1 . I'm sure this discussion is also somewhere else, but I don't find it.
Above or below, as long as it is not configurable, SO will complain.

[Carreau]

@ellisonbg no objection on making past above the default ?

[ivanov]

Hi David!

Slightly OT, I'm fine with either default behavior, but you wrote:

Also this is how vim does full-line pastes via 'p'

That's not the behaviour of 'p'

                            *p* *put* 
["x]p       Put the text [from register x] after the cursor
            [count] times.  {Vi: no count}

                            *P*
["x]P       Put the text [from register x] before the cursor
            [count] times.  {Vi: no count}

and this remains true for linewise changes (if you do a yy to yank a line, then edit that line to be something else, and press p, you'll see the original line pasted below)

[dwf]

Hmm, you're right. I guess I imagined that.

On Tue, Nov 13, 2012 at 6:30 PM, Paul Ivanov notifications@github.comwrote:

Hi David!

Slightly OT, I'm fine with either default behavior, but you wrote:

Also this is how vim does full-line pastes via 'p'

That's not the behaviour of 'p'

                        *p* *put*

["x]p Put the text [from register x] after the cursor
[count] times. {Vi: no count}

                        *P*

["x]P Put the text [from register x] before the cursor
[count] times. {Vi: no count}

and this remains true for linewise changes (if you do a yy to yank a
line, then edit that line to be something else, and press p, you'll see
the original line pasted below)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2572#issuecomment-10348751.

[image: Web Bug from
https://github.com/notifications/beacon/V4WeLnGyQaVRVkc2bSJLzmSyzDafggi5JdoKbHu6EwvEirCrhqjHVYw6cqo9sG1j.gif]

[ellisonbg]

I agree that the destructive paste is not a good default, but my initial intuition would be to have paste below as the default.

[dwf]

I'm not terribly picky. I tried out paste-above and it felt kinda natural,
so I ran with it. Anyone have an objection to changing it around to
paste-below?

On Tue, Nov 13, 2012 at 7:19 PM, Brian E. Granger
notifications@github.comwrote:

I agree that the destructive paste is not a good default, but my initial
intuition would be to have paste below as the default.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2572#issuecomment-10350094.

[image: Web Bug from
https://github.com/notifications/beacon/V4WeLnGyQaVRVkc2bSJLzmSyzDafggi5JdoKbHu6EwvEirCrhqjHVYw6cqo9sG1j.gif]

[Carreau]

I've no objection, it seems that nobody have. I'll let you change and I'll merge.

[Carreau]

@dwf, I send you a pr that change default to past below.
After that I think we can merge.

[dwf]

Done. Sorry I didn't see it.

On Thu, Nov 22, 2012 at 7:42 AM, Bussonnier Matthias <
notifications@github.com> wrote:

@dwf https://github.com/dwf, I send you a pr that change default to
past below.
After that I think we can merge.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2572#issuecomment-10633287.

[image: Web Bug from
https://github.com/notifications/beacon/J6T91GIPIyhU-8ti4GCGPyC60RZ_08dBF1RFh49nH6DtHVH7YmGgIfwvHJw3mRPK.gif]

[Carreau]

no problem.

Seeing that travis failure are du to timeout of 0min (??) and that we don't test the js yet. I'll go forward and merge.

Thanks !