inserting tabs in contenteditable divs (patch attached)

[GoogleCodeExporter]

Attached is a small patch that tries to improve behavior a little bit when 
pasting content that includes TABs into contenteditable divs.  It just adds 
some regex translation for the unicode tab character and HTML tab entities to 
single spaces.

AFAIK true tab-stop support in a DIV would be much harder than in a textarea.  
At least, it seems like it would require a more complex structure for the HTML 
children of the div, and that is not currently in the scope of what the divhack 
code can handle.

Here is a summary of what to expect regarding TAB and contenteditable divs:

1) when typing in a contenteditable div with jV/divhack enabled, hitting the 
TAB key will insert a single space when the jV option "The tab key, in insert 
mode, should... insert a tab" is selected.  Hitting the TAB key will move focus 
out of the div when the jV option "The tab key, in insert mode, should... move 
focus out of the textarea, as usual.".  This should all be true both in a gmail 
compose contenteditable div as well as in a simple unadorned contenteditable 
div.

2) pasting plain text content which includes ascii or unicode TAB characters 
differs in gmail compose vs an unadorned contenteditable div.  In the latter 
case HTML content is inserted into the DIV which simulates tabs (this appears 
to be the same whether or not a simple paste or a "paste and match style" is 
selected).  It should still be possible to use jV to edit plaintext above the 
pasted HTML content as long as the jV option "allow editing above HTML content" 
is enabled, but the pasted HTML content (nor anything below it in the div) will 
be editable.

3) pasting plain text content which includes ascii or unicode TAB characters in 
gmail compose differs depending on whether the compose div is set to "plain 
text mode".  If so then TAB characters are translated to single spaces upon 
paste, and the pasted content is considered plain text and remains part of the 
jV/divhack-editable region in the div.

4) pasting plain text content which includes ascii or unicode TAB characters in 
gmail compose with "plain text mode" off behaves the same as a paste into an 
unadorned contenteditable div (case 2 above)

5) pasting cells of an HTML table (for example, a clipboard copy of a region 
from a google spreadsheet) into an unadorned contenteditable DIV behaves as 
case 2 above when selecting "paste and match style".  For a plain paste an 
actual HTML table is inserted into the div (and the same caveats about 
jV/divhack being able to edit only content above it apply)

5) pasting cells of an HTML table into a gmail compose with "plain text mode" 
on and selecting "paste and match style" behaves as case 3 above: tabs are 
converted to spaces and the result is editable plaintext.  A simple paste in 
this case also results in editable plaintext but the tab characters are deleted 
entirely, cramming adjacent cell contents together.

6) pasting cells of an HTML table into a gmail compose with "plain text mode" 
off behaves as case 5 above

Original issue reported on code.google.com by martyv...@gmail.com on 17 Dec 2013 at 8:58

[GoogleCodeExporter]

forgot attachment

Original comment by martyv...@gmail.com on 17 Dec 2013 at 8:59

Attachments:

• jv-057_1-chrome-vona-divhack-tab-translation.diff

[GoogleCodeExporter]

case 2 should end "will not be editable"

Original comment by martyv...@gmail.com on 17 Dec 2013 at 9:00