33 comments

[ 6.2 ms ] story [ 43.4 ms ] thread
I don't see a license specified anywhere. What is it released under?
Hi rpicard, as Hirvesh mentioned, the project is released under MIT. I will be adding the license details to the repo files shortly. Thanks for your interest!
Something like this would make markdown editing in Github comments usable.
It's rather unfortunate that tab is also used for keyboard navigation between fields, since this would be the default behavior of text areas I would like.
Indeed. Many of the commenters have suggested alternatives, such as using Ctrl-[ and Ctrl-] instead, but the best by far that I've seen would be also binding a listener to the "escape" key, so that tab functionality is restored.

I believe I'll probably end up doing that, unless somebody else does it before I do.

This is awesome. I'd love if the developer would add (even if it were optional) Command+[ / Command+] functionality to indent multiple lines at a time.
Windows/Emacs user here. What does these shortcuts do ?
If you have a block of code/text selected, Cmd+[ and Cmd+] shift the entire textblock one tabindent to the left or right, maintaining the relative indent level of each individual line.
Is it different from ctrl+tab / ctrl+shift+tab ? Because these shortcuts works in this editor ("Multi-line highlighted text is also tab-able, and shift-tab removes a tab character instead").
multiple lines indentation at a time is supported. You have to select multiple lines and press tab (to indent) or shift+tab (to remove indentation).

I like the fact that if you select multiple lines with one line partially selected, it works as expected (selecting whole of the partially selected line)

Thanks for your interest! It has been noted. Once I work through the existing backlog of bugs, I'll revisit ideas such as this one.
Pretty cool! Would be even cooler with vim commands ;-)
Awesome. One could make a useful bookmarklet out of this.

I'm worried about accessibility.

Most of the time tabs are used to navigate between fields, so it'd be cool if this was "opt-in", eg entering the textarea would render an icon to click that enabled this feature. Or at least some way to tell the user that pressing the ESCAPE key is how you should tab-out of the field.

You could also let people tab-through by not enabling this functionality until you move within the text-field.
Very nice, it would be great if stackoverflow used this.
This is really awesome! I've always wondered why is this not the default behaviour on a text area?
Because it would brake tab-index functionality.
Seeing as delete will remove a tab I think shift-tab would be better used for the normal behaviour, take you to the next input.
shift-tab over selected lines removes one level of indentation.
Shift-tab generally has the meaning of "untab" already. Overloading it to mean "move to next input" would be very confusing for those of us expecting the old behaviour, and not at all discoverable for anyone else.
Good stuff! I was going to point out the undo/redo and multiline tabbing affecting the line with the cursor on it, but bugs are already filed on 'thub.
Hi everybody, this is Julian, the author of the project. I had no idea a small weekend project like this would be so widely accepted! Thank you all for your comments -- I'll be keeping track of them, and implementing features based on demand.

Follow the development on the issue tracker: https://github.com/julianlam/tabIndent.js/issues

Thanks again!

Feature wish: when pressing enter, indent the new line as deep as the previous line.
I'm a little late to the discussion here, but thought I'd post a comment anyway. My project (https://github.com/wjbryant/taboverride) has been around for a while and I'm always open to pull requests and feature enhancements / improvements. It looks like you're trying to solve the same problems and implement features which I've already implemented. Why not collaborate?