EpicEditor TAB implementation

Issue-159.md

“Smart tabs” sound better, a quick look at configuration files for both vim and sublime text:

Vim 
---
noexpandtab
tabstop
smartindent
smarttab

Sublime Text 
------------
tab_size
translate_tabs_to_spaces
use_tab_stops
...

smarttab in vim is used to respect <BS> character in some circumstances. For example if a tab key is to insert 4 spaces, a <BS> will delete 4 spaces if it is performed after smartindent/expandtab inserts 4 spaces in front of a line.

In the case of EpicEditor, we are combining some of these features into one option:

• Enable tab key (and shift-tab);
• Don't expand tab to spaces (and use css: tab-size instead) – I think expansion of tabs could be useful, but may introduce too many options/variables. But it is something we can discuss: my position is to keep it simple, at least for this first implementation. But I will experiment with this, keen to see how this will work;
• By enabling tab key, we introduce smart indentation (rule where previous lines' indentation is respected).

What I can do is try and experiment with internal options such as smartIndentation, smartTabs, expandTab and see how they pull up together. I am quite keen on seeing how others implement this first.

We can always change the name later on. I'll keep it as smartTabs for now.

We try to stick with single var statements

Yep, will change I have changed these on my branch.

Your new API methods like newline, getSelectionRange, etc, are those all meant to be public methods?

Absolutely not, not all of them anyway! Yep, I've been experimenting with public API calls like insertText(text) – which inserts given text at the current cursor/selection. I will definitely clean them up. Most of the methods should be private.

How do you feel about getSelectionEnd/Start to match the other API names which are getter and setter patterns?

At this stage I am thinking of making getSelection public, but selectionStart/selectionEnd into private methods. I will also change their names to _getSelectionStart and _getSelectionEnd.

The reason why getSelection should be public is because, EE's editor (EEE?) is inside an iframe element. Normally we'd use window.getSelection, but for EE we need to make sure we select the iframeDocument. This way, people can use getSelection just like they would on a normal HTML development environment.

---

I've been working on bits and pieces here and there, between home/work so please excuse the delay! I hope to get a solid chunk of work done this Sunday! Hopefully, I can ask you for a proper code review by then!

I like insertText. And totally makes sense about getSelection. Having tried working with it working with selections is hard and IE vs other browsers handle each differently. A standardized set of tools to handle selections for developers using the API would be awesome.

No rush! Do what you can when you want :)