85

Look here: a typical holy war on tabs vs spaces.

Now look here: elastic tabstops. All problems solved, and a bunch of very useful new behaviours added.

elastic tabstops

Are elastic tabstops even mentioned in that tabs vs spaces discussion? Why not? Are there drawbacks to the elastic tabstop idea so serious that nobody has ever implemented them in a popular editor?

EDIT: I apologise for putting too much emphasis on "why aren't they mentioned". That wasn't really what I intended; that question is possibly even off topic. What I really mean is, what are the biggest drawbacks of this that prevent wider adoption of an obviously beneficial idea? (in an ideal world where everything supports it already)

(Turns out there's already a request on the Microsoft Connect for a Visual Studio implementation of elastic tabstops, and a request in Eclipse too. Plus there's a question asking about other editors that implement elastic tabstops)

Roman Starkov
  • 4,469
  • 3
  • 31
  • 38
  • 5
    This would be a great question for http://ux.stackexchange.com – JonnyBoats Feb 28 '12 at 11:43
  • 1
    i would like to use it, is it implemented for Visual studio , netbeans , notepad ++ for any chance ?!! – Ali Feb 28 '12 at 12:17
  • 11
    They're never mentioned in the "tabs versus spaces" discussion because there is almost no way for a working programmer to use these things. Maybe if you had an Eclipse, VS, gvim and emacs implementation, that might change. – Paul Tomblin Feb 28 '12 at 12:24
  • 2
    I really like the idea, but it's only when you live with it for a month or so that you *really* know what the pitfalls are. Like everything ever, there are guaranteed to be some cases where it does things you wouldn't expect... – Chris Burt-Brown Feb 28 '12 at 15:09
  • 3
    @ChrisBurt-Brown That's always a risk, yes. IntelliSense has its pitfalls too, like subsituting text when you didn't want it to. Overall, however, IntelliSense in C# a big fat win. – Roman Starkov Feb 28 '12 at 15:13
  • 4
    I want this in notepad++...I want this now – Ben Brocka Feb 28 '12 at 18:03
  • I would love to see someone attempt an implementation that works with Python – Izkata Feb 29 '12 at 03:19
  • 1
    It totally works in jEdit if you guys want to try it. – Chris Burt-Brown Feb 29 '12 at 09:17
  • 1
    I want this in VS2012 SO BAD – THE JOATMON Jun 10 '13 at 22:25
  • You know, come to think of it isn't this how tabs were originally meant to be used anyway? [According to Wikipedia](http://en.wikipedia.org/wiki/Tab_key), tab is just an abbreviation for "tabulator". As in, a character for putting data (or in this case code) in tabular form. – Ajedi32 Feb 07 '14 at 17:14
  • I'm voting to close this question as off-topic because it is asking about the usage of a software tool (source code editor). –  Oct 05 '15 at 02:37
  • There are deeper issues in this problematic. e.g. what semantics does a tab reflect? should one use another control character for tables (vs. indentaton) ? And similar issues, which all unfortunately all have grown roots and are unlikely to change in existing languages and editors. In an ideal world such problem should not simply exist - code should be inputed with special systems that _disallow_ freedom of input, i.e. in a [Syntax Directed Editing](http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs.html) – Mikhail V Aug 29 '17 at 21:54
  • So in ideal world such question as 'which character use for indentation' should be obsolete - I should not input it, but I should input instructions in current branch or e.g. input table in table editor, and then link it in code. – Mikhail V Aug 29 '17 at 22:02

12 Answers12

34

Many times I have had to fight with a word processor to get the document to look the way I want without some hidden automatic rule controlling the placement of my words. I don't want to spend one second trying to figure out why the editor is insisting on placing those words there.

mhoran_psprep
  • 2,328
  • 2
  • 16
  • 14
  • 14
    Nor do I. I fully sympathise with this sentiment, as such rules really frustrate me too. But this is different in two ways. One: Just like tabstops now, you don’t have to use them if you don’t want to. You can leave your colleagues’ text alone if it uses them. Two: Elastic tabstops don’t have hidden rules, but blatantly obvious ones. The behaviour is completely natural — perhaps even more natural than traditional tabstops, which occur at some arbitrary, usually irrelevant, position within the text. This is why nobody uses tabstops for anything other than indentation anymore. – Timwi Feb 28 '12 at 14:58
  • 10
    @Timwi:The question was to list drawbacks. I did. – mhoran_psprep Feb 28 '12 at 15:04
  • 16
    It might not be obvious from the GIF, but the only figuring out involved is that when you press "TAB", whatever comes after will come out properly vertically aligned. It's nothing like a word processor. Just try the actual interactive demo at the link I posted, and you'll see how natural it is. – Roman Starkov Feb 28 '12 at 15:11
  • 3
    @mhoran_psprep: Fair enough, I appreciate your input. I guess we were looking at different interpretations of the question. You are listing drawbacks of yourself using the feature, while I thought it was about drawbacks of introducing the feature (i.e. making it *available* and not *mandatory*). – Timwi Feb 28 '12 at 15:33
34

Holy Wars are Subjective

Nick's elastic tabstops are an amazing concept that could help a lot of people agree on a workable solution, though I highly doubt it would entirely end this Holy War: it is, after all, also a matter of taste and many programmers will not move an inch from their position on this matter, even at the cost of compromise. So that would be a first reason.

For instance, a lot of people on the "spaces" side will still dislike it as it requires an additional piece of logic in your software for a decent rendering (e.g. simply viewing a changeset in your SCM's webview).

Implementation Issues

But the most obvious reason is just its technical barrier to entry: it's a fundamentally different concept from what has been implemented for a number of years (if not decades) in IDEs and text editors. It would require to rewrite some of them to process lines in a fairly different fasion, which makes it difficult for older and bigger systems that have a higher chance of suffering of deep and tight coupling in their line processing code. It is, however, a lot easier to do when you start from scratch (think of Nick's demo or of Go's tabwriter package).

For a personal anecdote, I remember approaching the author a while back to ask if there was any emacs support in sight, and in this particular case he mentioned this as the reason for it not being trivial. He also asked for help from the community to help implement this feature and bring it to the masses.

Do We Care Enough?

A third reason, is that some developers are not that hung up on the matter and don't really care so much that they would go the extra mile to support the effort. In most cases, the spaces-vs-tabs conflict is not a business blocker, so there's not so much drive behind the issue.

If you want it, you'll have to fight for it. Which is doable in open-source software. And if you change enough of these, closed-source ones will have to follow at the risk of losing to some of their userbase, if an ever so small part of it.

So, if you want it, give Nick a hand.

haylem
  • 28,856
  • 10
  • 103
  • 119
  • (off topic) I often wonder how other "this is nice but very minor" kind of features ever make it into products like Visual Studio. It seems that someone on the team just simply found the time to implement it for personal reasons. Think of [typing into several lines at a time](http://vs2010tips.wordpress.com/2010/10/07/making-square-selections/) in Visual Studio, for example; it's not like tens of thousands of people asked for it, but I do rather like it. – Roman Starkov Feb 28 '12 at 16:47
  • 3
    @romkyns: As for many things, it takes either one quiet insider or a thousand voices screaming at the gates. – haylem Feb 28 '12 at 17:05
27

This is the first time I heard of those. Not sure if they are a good idea but they seem of little use since we have tools (such as indent) that automatically format code already.

What happens when I open your clever elastic tabstops in vim and edit it? Do the tab automatically clean up or are you left with a mess?

The main drawbacks, as I see them are possibly breaking diffs, version control, and not being compatible with editors that do not support them. It maybe a lot of code modification to support them and there are more important things than "yet another tab thing to format code" feature. After all, we can all use indent which does all the above if memory serves.

haylem
  • 28,856
  • 10
  • 103
  • 119
  • 11
    What a backward-thinking attitude. Let’s have no progress because people’s favourite old, outdated tools can’t cope *just yet*! (The irony, of course, being that these tools (such as vim) are open-source, so if it were really important to you, you could (and probably *should*) add elastic tabstop support to it) – Timwi Feb 28 '12 at 12:12
  • 14
    @Timwi: You are utterly missing the point I was making. What happens when your code file is parsed by something that is not aware of elastic tabstops? Do you end up with a mess or can they cope? What about version control and diffs? Just wishing that all tools did support $feature is unrealistic even if those tools are open source. – Sardathrion - against SE abuse Feb 28 '12 at 12:31
  • Obviously it won’t be perfect (until they implement it). Still clearly better than not having them at all. Something isn’t “unrealistic” just because it has minor issues for a temporary transitionary period. – Timwi Feb 28 '12 at 12:48
  • 14
    @Timwi: You assume that everyone finds elastic tabstops to be as awesome as you think they are. This may not be true. – Sardathrion - against SE abuse Feb 28 '12 at 13:03
  • 7
    @Sardathrion is right. What happens when I have to remote into my *nix server with no windowing system in place and need to examine some code with Vim/Emacs/Pico/Whatever? If there is a mechanism so that it is readable that would be fine...otherwise it would be a nightmare. I don't see the benefit of elastic tab stops being that beneficial anyway. I can already autoformat my code to look how it should in the IDEs I use. – Rig Feb 28 '12 at 13:16
  • 7
    The version control point is a good one -- I don't think people are going to appreciate an editor that silently starts changing the placement/format of comments in code arbitrarily far away from the code they are modifying (see magenta section in OP's animated gif). It would helpful to have a reference implementation to play with, but what I see so far is not remarkable - emacs already does much of this, just with a couple extra keystrokes (which arguably is a good thing). – mcmcc Feb 28 '12 at 15:10
  • 2
    who says the underlying source has to be different or special. I suggested 2 tabs at the end of a line of text could be detected by the IDE and presented to the user in a different format (eg lined up with other comments that had 2 tabs at the end of a line of text). There would be no difference to a SCM or anything else. Sure it'd look un-optimal when viewed in vim, but it would still be readable. – gbjbaanb Mar 02 '12 at 23:07
  • 3
    In fact, I find that the main issues with elastic tab-stops are the same issues as with tabs, when using a non-supporting environment or different settings. That's why spaces always win as the common denominator for everybody. – haylem Mar 06 '12 at 14:32
  • Not breaking diffs and version control is a plus of elastic tabstops. Elastic tabstops ensure that the text is aligned without any change to the file. So aligned columns stay aligned, but the whitespace for alignment doesn't change. If there is alignment with spaces, making one table cell wider means that all rows have added spaces, which means larger diffs. Elastic tabstops are a feature of the editor to interpret tabs; diffs and other such tools see just normal tabs. – matj1 Mar 29 '23 at 14:30
17

Why don't we just make the vertical tab character (VT, ASCII 11) serve to indicate the use of elastic tabstops? It serves no purpose in any mainstream programming language, yet is parsed as valid whitespace in all of them, AFAIK.

This would mean that the use of elastic tabstops is no longer an externalized convention (e.g. "this file was formatted with elastic tabstops, please turn them on") but something you opt in to on a case by case basis.

Existing text editors usually display a glyph or a single space in place of a vertical tab. This is not ideal, but a small price to pay, IMO.

Richard Nelson
  • 301
  • 2
  • 2
16

One drawback is that it doesn't work if you want alignment on one group of lines and then indentation on the next, since it groups the tab stops of adjacent lines.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

What I wanted:

def foo( bar,
         xyzzy ):
    wibble()

For curly-brace languages this might be less of a problem, as you can usually solve this by putting the opening brace on a line of its own (like in the animation), but for whitespace-sensitive languages, this quickly becomes a pain, and you end up having to fall back to using spaces.

hammar
  • 893
  • 6
  • 12
  • Agreed. Nick's implementation doesn't work for languages like Python very well at all. – Roman Starkov Feb 28 '12 at 20:08
  • 3
    Why wouldn’t this work? This isn’t a fundamental limitation, the algorithm just needs to be language-aware. But to some extent this is true even today, Vim for instance defines different indentation rules depending on the language. This could easily accommodate Python indentation. – Konrad Rudolph Feb 28 '12 at 20:17
  • 2
    @KonradRudolph No, they couldn't. The draw of elastic tabstops is the ability to automatically indent/unindent groups of text together. One simply example is the end of an "if" statement: You try and un-indent because you're exiting the statement, but the "smart" elastic tabstops decide you meant to also un-indent the line or two above, so on and so forth... And if you have to explicitly group text together, then - what is the point? It's more work to do that than fix the indents yourself... – Izkata Feb 29 '12 at 03:25
  • 1
    @Izkata Unindenting manually would (should) simply end the current group. Why would you ever control indentation with the elastic tab stops manually? You wouldn’t, so the algorithm knows that when you do it, it’s to end a block, not to un-indent the above block. – Konrad Rudolph Feb 29 '12 at 08:07
  • @KonradRudolph If you were changing the indenting on something, you would. See the animated GIF in the question. – Izkata Feb 29 '12 at 15:36
  • @Izkata You simply don’t change the indentation manually, why would you? The animated GIF also never shows changes of indentation – it only shows change of actual code. If you think you’ve found a scenario which wouldn’t work in Python, describe it to me in detail and I will tell you what the elastic tabstop algorithm should do in response. I’m fairly certain that there will never be ambiguities. – Konrad Rudolph Feb 29 '12 at 15:52
  • @KonradRudolph Exactly as I said in my first comment: `if something:``somethingElse()``anotherSomethingElse()` – Izkata Feb 29 '12 at 22:46
  • @KonradRudolph Even if you make it create a new grouping when un-indenting specifically on a blank line, what about a statement you now plan on removing from the text group? Elastic tabstops simply don't work (consistently) on languages like Python, that don't have syntax markers such as `}` (while `:` could be considered to match `{`) – Izkata Feb 29 '12 at 22:48
  • @Izkata Simple: the above lines never unindent, only the currently selected one(s). In fact, this is *exactly* how I use Python at the moment. The only difference is that my editor doesn’t insert elastic tabs, merely fixed-width ones (and therefore doesn’t need to update tab with once I edit anything). – Konrad Rudolph Mar 01 '12 at 00:34
  • It seems that inserting an extra newline between the argument list and the function body (thus creating an independent indentation group for `wibble()`). @Izkata, it sound like you have a separate use case than @hammar's specific scenario where elastic tabstops fail. Could you elaborate in a new answer (not a new comment)? – kostmo Aug 27 '13 at 02:17
  • 2
    Oh, good point. Hmm... maybe you could double-indent the arguments? So then `wibble()` would only have a single indentation and therefore wouldn't be aligned with the function arguments? – Ajedi32 Feb 07 '14 at 17:39
  • This problem is because the algorithm can't distinguish alignment from indentation. It would work if spaces were used for indentation and elastic tabstops for alignment. That sounds strange, but it may make sense in e. g. Python, where indentation with spaces is encouraged. – matj1 Jan 06 '23 at 11:16
  • Yeah elastic tabstops elegantly solves this, you just have to first unlearn the thinking damage that was done to us by getting used to a world where we have to manually do alignment/indenting with crude tabstops or spaces: two tabs before `bar` and `xyzzy` instead of one. – mtraceur Feb 10 '23 at 04:12
13

To be honest, I don’t find them that useful once you get over the initial excitement. For instance, I don’t like comments at the end of a line anyway – I always put my comments on a separate line. With that, elastic tabs lose their main use.

After that, you can of course still use them to align function arguments (and parameters) and long lists of assignments.

But for the former I tend to just indent all arguments by one additional level and that works entirely fine with me:

void foo(
    int x,
    int y,
    string z
)

And I don’t see any need to change that.

And as for aligning assignments, I don’t do that. I put single spaces around assignments, that’s it. I also tend not to cluster lots of assignments together so there is rarely any readability issue.

In summary, elastic tabs have absolutely zero usefulness for me. This is of course a very personal preference that may vary but I find that it works well and I guess that the lack of support for elastic tabs is because other people think similarly.

If an editor would implement them, I still wouldn’t use them.

Konrad Rudolph
  • 13,059
  • 4
  • 55
  • 75
  • Appreciated. It seems that you could happily use a variable width font too if you just wanted to, since you don't align anything other than the start of the line anyway. Visual Studio has pretty good support for this, actually, and the readability boost is nice. – Roman Starkov Feb 28 '12 at 16:15
  • 1
    @romkyns We had discussions about that and in the course of [one](http://stackoverflow.com/q/218623/1968) I tried using a proportional font for programming for some time. The upshot was that monospaced fonts work better, even when disregarding the indentation. Apart from that I’m currently working exclusively in Vim and the console, neither of which will in all probability ever support proportional fonts. – Konrad Rudolph Feb 28 '12 at 16:22
  • 1
    @romkyns That said, these problems are solvable (or perhaps even solved, with a proportional font designed for programming). But I still don’t really see the necessity. – Konrad Rudolph Feb 28 '12 at 16:25
10

They're not mentioned because they're not implemented in most IDEs of text editors; they're a novelty of little real use in a project.

Spaces have been used to lay out programming since the days of punch cards. Tabs came along and someone obviously thought they were a good idea (they were mistaken :p).

In the days where most modern editors can convert tabs to spaces automatically... they are fairly pointless.

Having to install yet another tool to deal with something as trivial as tabs vs spaces certainly doesn't appeal to me, and I don't think it would to most of my colleagues.

TZHX
  • 5,052
  • 2
  • 25
  • 32
  • I've cleared the comments as they were descending into insult. – ChrisF Feb 29 '12 at 16:49
  • 2
    Just thought I'd point out, the main reason why I like the idea of elastic tabstops isn't because it solves the problem of tabs vs spaces, but because of the behavior shown in the GIF in the original question; automatic, pain-free alignment. Plus, for VCS diffs there's the added benefit that there were no whitespace changes required in that example. – Ajedi32 Feb 07 '14 at 17:25
  • "Having to install yet another tool..." isn't a good enough argument... As if there aren't enough tools being used already. – Milind R Dec 04 '14 at 16:53
  • @MilindR Whether you consider it a good enough argument or not, it's the reason why (at the time three years ago) I would have no interest in this. There being a lot of tools used that do something useful isn't a reason to add another one that, really, doesn't add anything to your environment. – TZHX Jan 26 '15 at 10:29
  • Attitudes like this are why companies like MS decide to force users into new UXes ... I shudder to think what would happen if the same attitude were applied to the floppies -> CD transition. – Milind R Jan 26 '15 at 11:42
  • Except... CD's offer a great deal of utility over floppy disks. Elastic tabstops do not offer anything. You're making a massive logical leap if you think the two situations are comparable. – TZHX Jan 26 '15 at 11:44
  • @TZHX, I don't see why you think elastic tabstops offer nothing. Just see the GIF in the question. They offer automatic alignment, which you won't get with either normal tabs or spaces. If you think it's overkill, or not that great, it's OK, but it's certainly a feature some people like. – Arturo Torres Sánchez Apr 11 '15 at 16:03
  • @ArturoTorresSánchez there are lots of things people like that I think are useless. Like turtles. Screw those little shelled bastards. – TZHX Apr 11 '15 at 16:17
6

I think they'd find much use if IDEs supported them (Microsoft!). Once people found they could slap their flowerboxes at the side and have them nicely readable, they will. You might more comments being added to source code suddenly (which can only be a good thing).

I suppose we could also add comment "tooltips" to the list of 'would it be good if...', so your large comment blocks could be hidden away and viewed easily when needed. Maybe we could also have comment blocks that form part of documentation (not sandcastle type stuff, proper user-readable documentation snippets that were embedded in the code, not just the method headers)

Disadvantages: it might make your source diffs look bad if a bunch of lines looked like they were changed when really only 1 was modified (if the editor saved the file with the tabs converted to spaces). Or, if the elastic tab was implemented with a single character (or more likely, 2 tabstops) then viewing your source outside the editor could look bad.

I think I like the idea though, 'tab tab' at the end of a line elasticates the comment block and lines up all comments on subsequent lines (that have the double-tab spacing) accordingly.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
6

Here's how I see it: if most of the popular tools already supported elastic tabstops, many people would be using them. The same happened with vi’s navigate/edit mode, with syntax highlighting, and later with Intellisense. In each case, the established wisdom was that it is not useful or not needed, but it got implemented and it took off.

Elastic tabstops do, of course, have a relatively low impact. Most people are sufficiently happy with the status quo and so don’t care. A similar reasoning is applied to many situations in which some people are just happy with what they’ve got and see no reason to switch to something more advanced. In other words, the biggest problem with elastic tabstops is the same as for almost every other good idea: it needs to gain traction.

But that doesn’t mean the feature can’t be adopted incrementally. Every single programming language was adopted incrementally, even though an entire team requires a new compiler and a new IDE to start using it. The same is true of every single hardware architecture and many other examples. It is also not the case that lack of integration with existing tools is a show-stopper: the same is true, for example, of “unified-diff format”, which incrementally replaced an earlier less readable format that was nonetheless understood by automated tools (such as patch). Those tools have been upgraded over time.

I appreciate the interop issues others have mentioned, but despite them, there certainly will be teams (like mine) who would adopt this without hesitation, in our entirety. External tools such as diffing, merging etc. will initially not support it, but we would do our part to encourage vendors to include the feature. This is how progress has always been made. It requires some pains for a temporary transitionary period, but in the end, it is worth it.

Timwi
  • 4,411
  • 29
  • 37
2

The biggest problem I would have with it is inconsistent spacing throughout the documentation. I know as a programmer I would get annoyed to see a loop or if statement at 'standard' indentation and then to notice at different indentations. I know personally I like seeing all my curly braces alined throughout the documentation, not just in the block of code I am looking at.

Overall I think it is a nice idea however, but personally, I would not like it.

Falcon165o
  • 194
  • 1
  • 4
1

I just tried out jEdit's implementation of elastic tabstops, which works amazingly well with the programming languages in with which I'm familiar (primarily HTML/XML and C-like languages). With Python code, however, here is how it rendered (spaces used in place of tabs to illustrate how things align):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

For a language like Python that relies upon spacing, this is a deal-breaker unless you disable the functionality provided by elastic tabstops. Editors like Vim and Emacs make disabling most kinds of functionality simple if you know the name of the option and how to disable it, but this functionality would be required to be disabled for code like the above.

That being said, it's great for x86 ASM, C, C++, Go, XML, HTML, and others that don't rely on whitespace so much:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

I will say that Lisp dialects such as Scheme have their own conventions that would also make elastic tabstops render "ugly" code. If I change my tabstop settings to match the convention of 2 columns and insert tabstops at unusual places (between a function and its arguments):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. the more readable:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Granted, this one isn't as bad as the Python example, but it definitely reduces readability of the code. While I very much enjoy the functionality when coding in something like C# or C++, I abhor the functionality when coding in a language like Python or Scheme where whitespace is functional and/or visually helpful. Elastic tabstops were created specifically to be helpful without requiring a separate indentation utility, but clearly it's not meant for all programming languages.

  • 1
    At least the lisp example is just using elastic tabstops wrongly. If you want something aligned, you use the same number of tabs *from the start of the line* on it. You don't just use the same *inconsistent* number of tabs for the lines that you had to use previously just to work around the inelastic tabstops you had before. – mtraceur May 29 '20 at 05:05
  • 1
    I also don't see any real issue with the Python example - why are you tabbing a line comment - just use two spaces unless you *mean* that you want it aligned. That's what tabs *mean* - a desire for alignment (like in a **tab**le) - and elastic tabstops just give you a 1-to-1 correlation between number of tabs in the line and which (dynamically positioned) column it aligns with. If you tab your comment, you are saying you want it aligned with the next line's thing one tab over. If you don't tab the comment, it won't do that. – mtraceur May 29 '20 at 05:09
  • But I vote +1 on this answer because it reveals that one problem with elastic tabstops is that people will just use their existing tabbing habits (which only made sense for fixed tabstops) and then see it as a problem with elastic tabstops rather than take the few minutes of thought to realize how elastic tabstops let them use the tab key to achieve what they want even more efficiently. – mtraceur May 29 '20 at 05:13
0

Emacs already handles indentation in the presence of unclosed parentheses, and will automatically align wilma with fred. I have no idea why Eclipse doesn't do the same. Ok, I have an idea, but it's uncomplimentary.

You could get Emacs to align the comment too, without much trouble, but AFAIK no one but you has ever wanted that.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 2
    I can only interpret your last sentence as trolling, since obviously at least one other guy wanted it pretty darn badly enough to create a well-argumented page, a Java implementation and a GIF to show why it's good. If you read through the answers, you'll find that Nick isn't alone, either. Oh wait, [look here](http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2533029-support-elastic-tab-stops) too. – Roman Starkov Feb 28 '12 at 18:31
  • By the way, does Emacs re-indent `wilma` as you make edits, such as changing the length of the function name? If it does, that's fairly close to what elastic tabstops do. – Roman Starkov Feb 28 '12 at 18:43
  • @romkyns: I didn't mean to be trolling, I just meant that **I** had never seen that style of comment indenting in EMACS. Generally EMACS does not re-indent multiple lines as you type, but that could be changed too. – kevin cline Feb 28 '12 at 22:08