I knew it was me because it was only happening in my default browser. After finally purging the cache all the glitches went away and I can't make it produce a <p> tag now without asking for one. (Yay!)

Thanks very much!

The only oddity I've noticed now is that if someone adds a trailing space before ending a line it starts a paragraph.

Since typing a space before hitting enter is 'erroneous' I'm fine with a strange result.

I've loaded 3.5 with:

forced_root_block : 'false',

And it has no effect?

<p><span style="font-size: medium;">This is a</span><br /><br /></p>
<p><span style="font-size: medium;">test<br /></span></p>
<p><span style="font-size: medium;">with&nbsp;<br /></span></p>
<p><span style="font-size: medium;">forced_root_block<br /></span></p>
<p><span style="font-size: medium;">set&nbsp;<br /></span></p>
<p><span style="font-size: medium;">to&nbsp;<br /></span></p>
<p><span style="font-size: medium;">false<br /></span></p>

I was expecting/hoping to get:
<p><span style="font-size: medium;">This is a <br />test <br />with <br />forced_root_block <br />set <br />to <br />false<br /></span></p>

I'm merely stating a simple fact that my user base would use TinyMCE more readily if the feature to reverse the functionality of shift+enter was available or even accessible via some documentation.

Read into that what you want, it's a very simple fact.

our client portal their CSS leaves it looking

a bit hard to

read because of

all the wicked double

spaced paragraphs.

[...] but we can't control the client portal's layout/css

You can't blame TinyMCE's functionality for that. Try to talk to your client instead!

From a semantics point of view the above markup makes a lot more sense.

The output of TinyMCE works GREAT for viewing locally, when we post the same HTML data to our client portal their CSS leaves it looking

a bit hard to

read because of

all the wicked double

spaced paragraphs.

If we use shift+enter the result looks good locally in our 'tools' and it looks great on the client portal so this is why I say 'for our needs' flipping that around would solve 'our' issue.

Made sense at the time, still does.

Would it be nice to help the users make an unordered list? YES this is true in both the client portal and our 'tools' .. same with almost all of TinyMCE's plugins.

So TinyMCE is a great asset to us, but we can't control the client portal's layout/css so we have to hold down shift as we hit enter if we expect the message may get posted externally.

We could debate everyone else's needs, semantics, opinions, etc.. But what I am pointing out is accurate and we would benefit from knowing how to reverse the shift-enter logic or an option to reverse it.

Hello Mike,<shift-enter>How are you doing today?<enter>I have more information on your issue:<shift-enter>XYZ is at 30%<shift-enter>ABC is at 12%<shift-enter> ...

Why do you think that this "document structure" is what you really need? Why not this one instead?

<p>Hello Mike,<br />I have more information on your issue:</p>
<ul>
    <li>XYZ is at 30%</li>
    <li>ABC is at 12%</li>
    <li>...</li>
</ul>

From a semantics point of view the above markup makes a lot more sense. As a result of this your wish for inverting the functionality of [enter] vs. [shift][enter] seems just wrong.
I dare say that your example shows a use case for which TinyMCE wasn't designed primarily, because your email (or at what else is your example hinting?) doesn't have to be in HTML - it works beautifully in plain text.

We recommend using shift+br if you enter text in uncommon elements like <label>. The default should always be paragraphs since normal text consists of paragraphs.

Finally! .. I've tried all the suggested flags for tinymce's init section and they only seem to break the init, and only work on the jsFiddle copy of tinymce? (I'm using Version: 3.4.7 (2011-11-03))

This shift-enter is great but here's how I have to use it.

Hello Mike,<shift-enter>How are you doing today?<enter>I have more information on your issue:<shift-enter>XYZ is at 30%<shift-enter>ABC is at 12%<shift-enter> ...

See how efficient it would be to switch the function around so that I only have to shift-enter when I want a new paragraph, and otherwise I'll get a <BR>?

Any way I could do this easily?

I built a plugin that wraps selected text in a span ... but the editor wraps a p around the span ... this breaks my text into multiple lines.

force_p_newlines : false
force_root_block : false

Both are in my init

How do I turn off ALL injected tags?  I simply want what is in the HTML view to be posted.  I do not believe I should have to use server side cleanup for this.  Isn't this is something the editor should do natively? I would hate to see the project ported to get this functionality.

Readmores are added automatically by any cms, and can only be added after the entered content which has the automatic P tags you've inserted and I cant get rid of.