This has been an issue for me for a while:
When copy a block of code, and paste, I get an extra indent level added. Only after I’ve removed the indent, and then copied that block, does the following pasted code work as expected.
Any tips on where to look to fix this?
I’ve tried turning on/off “Auto Indent on Paste” and it doesn’t seem to help.
Atom : 1.30.0
Electron: 2.0.5
Chrome : 61.0.3163.100
Node : 8.9.3
It’s not wrong. It’s doing what it thinks it’s supposed to do. Because you’re copying the end of the less-indented line that <tbody> is in, Atom indents your pasted code another level. You should not copy that newline, and instead just press enter before pasting.
Hello @DamnedScholar, thanks so much for your reply and help, I really appreciate it. 
Hrm, I’m not sure I agree … Maybe that’s how Atom does it, but I think it’s less than optimal behavior.
Having to copy, hit return and then paste is one more key stroke than I’d prefer. This is especially true if you are doing lots and lots of HTML data entry.
Examples are better than words …
<table>
<thead>
<tr>
<th>test</th>
<th>test</th>
<th>test</th>
</tr>
</thead>
<tbody>
<tr>
<td>test</td>
<td>test</td>
<td>test</td>
</tr>
</tbody>
</table>
Using the above code, here’s how Atom (fresh install) handles copy/paste of the <tr>:
For comparison’s sake, here how other Editors/IDEs handle it:
I hate to say it, but I’ve been doing this kind of HTML data entry, on and off, for years … Based on all the editors I’ve used during that time, I’d say that Atom is going against the grain on this one.
I should clarify, the <table> is just one example. This happens for other markup situations as well. I’m using the <table> as the example because it was the latest situation where I noticed this issue and felt annoyed enough to research and then ask for help.
It’s logically consistent and it was designed that way by the developers. I’ve worked with Atom for years and I did have trouble with this behavior when I started (because I, too, came from other editors that behaved differently), but now I accept it and my copy/paste behavior has adapted to work with the behavior. It’s not “wrong” because it works according to a design. It’s just a different methodology than what you’re used to. Since Atom is so hackable, you have the option of writing a function to replace it if you really want to. I can tell you what you need to do if you want to pursue that, but I also think that you might be able to adapt and work around the issues to the point where how Atom treats copying indents can be used as a strength.
Having to copy, hit return and then paste is one more key stroke than I’d prefer. This is especially true if you are doing lots and lots of HTML data entry.
I agree. HTML data entry sucks and I try to automate it with JavaScript whenever possible. If that’s not available, then it’s nice when an editor has the tools to help you cut down on time spent on repetitive tasks. You know what’s a lot of work compared to a key stroke? Moving your mouse or shift-moving to select a certain number of rows. Copying and pasting kind of sucks as a repetitive task. That’s why the package emmet exists. With emmet, you can write out how you want your element tree to look and then the package will expand it, and you can include a lot of information in your instruction. Scope this example:
Now, emmet has a weakness in that the tab navigation doesn’t highlight the sample text like Atom’s snippets package does for any snippets you use, but snippets requires that you define the inserted content ahead of time while emmet lets you map it out on the fly. Reach your last tr and realize you need another row? Press return and type tr>li{moar data!}*5 and you will have it in (at normal typing speeds) less time than it would have taken to laboriously select the previous row. Or maybe you do it one row at a time and just keep tr>li*5 on the clipboard and return, ctrl-c, tab for a three-key solution with the option to customize before you commit.
In terms of skill transferability, emmet has sister extensions for a variety of editors, including Sublime, TextMate, and VS Code, among others.
How do you think that will work for you?
Hi @DamnedScholar, thanks again for your reply/help, it’s greatly appreciated.
Fair enough. 
I don’t think you’ll convince me that it’s a good design decision, but I can live with this functionality and continue working around it.
I appreciate you taking the time to converse about it.
Thanks for tips! I’ll take another look at Emmet. I used it a bit when it first came out. Thanks for the refresher course!
I appreciate the help.
@mhulse: I don’t have anything useful to add to the conversation, but just wanted to let you know I love how you went all out and provided an exhaustive list of animations of how other editors handle it. 
I completely agree with @mhulse
The way Atom is handling in paste is absolutely ridiculous. I should not have to use a separate plug-in or hack any JavaScript to make it work the way it should work. Atom has terrible UX, let’s be 100% honest… Atom, is great, it’s better than most other IDEs out there but Atom still has terrible UX!
This thread illustrates how programers don’t know how to make good software operate in an intuitive user experience.
All those apologists for Atom, as an example of the person and in this thread who stated they adopted they’re working process to support the flaws of Atom, are only paving the way for poor quality software.
If we as users of the product allow such rubbish UX, do you honestly think that the next generation of the product is going to be better or worse? If you don’t complain, things won’t get better.
Bottom line, Atoms paste indentation functionality is absolutely terrible and is unacceptable.
Go ahead, subtweet people and assert that your subjective value judgments are objective fact. Your approach is unnecessarily aggressive (very different from the eminently reasoned and abundantly exampled @mhulse with whom you claim commonality).
If you don’t complain, things won’t get better.
Correction: if you don’t put in a pull request implementing the feature you think is so important, you don’t have much say in how things turn out. In open-source communities, you either have to do the work or convince someone else that it’s right to do the work, and your tactic is unlikely to convince anyone who doesn’t already agree with you (you should really take a page from @mhulse’s book here, as they do present a good argument).
