1. 36
  1. 17

    If there’s no Emacs implementation, does it actually exist?

    1. 3

      No vim either, clearly this is vaporware. At best it is a UI concept such as you might find on displays in SciFi moves…

    2. 10

      Sounds like an interesting idea to explore! Sadly, there doesn’t seem to be an Emacs implementation yet, wonder if it’s due to difficulties w.r.t. to Emacs?

      1. 9

        I read about this first in 2014. Back then I wondered when this was going to take off but it never really did. This website and this idea is very old and has never been implemented well enough beyond the reference implementation which is sad.

        1. 1

          I feel like the focus on tab(stop)s hinders it. If you’re forced to use a codebase with spaces, you’re already left out. If the editor gives inline type information, everything breaks anyways. These days editors understand your code well enough that it could be implemented as a rendering feature, without needing a change in how you code. It would work together with inline information and it could work beyond continuous cells (eg variable declarations interleaved with doc comments).

        2. 5

          Is there a VSCode extension that does this?

          1. 4

            Yes. There are 2 implementations with their own quirks. Edit: lmao I forgot how bad the quirks were. Don’t try to use them.

          2. 5

            Another advantage is that proportional fonts can now be used

            After coding with mono fonts for 30 years, I recently switched to proportional fonts. I’m surprised at how much I enjoy it. The article suggests Input. I favor Literata which was designed for reading not code.

            1. 2

              I’m using a customized Iosevka Aile, with the code ligatures turned on. They call it quasi-proportional. All width are simple fractions so you can still align using spaces.

              I’ve also used the proportional Go font, not as pretty but it has the nerd stuff. It all works fine without elastic tabstops.

              1. 1

                Hey I updated my customized Iosevka and I’ve made it easily available if you want to check it out https://github.com/VulumeCode/Iosevka-Aile-Code

              2. 4

                I’m all for encoding indentation as tabs instead of spaces, so the number of spaces per indentation level becomes a matter of personal preference.

                But if working with code is a thing you do, wrangling diffs is something that comes with it – imagine how nice it would be if only the change in indentation level was encoded in the text: Instead of encoding an absolute level of indentation, and repeating it for every line, the indentation was relative, encoded with a pair of special indentation increment/decrement characters. Then, you could indent a stretch of code without git telling you that you’ve changed every single line, which conflicts with every other change. This would not only make the diff readable (a solved problem) but actually decouple it from other changes, so you could rebase it (an unsolved problem). That, I would call a quality of life improvement. I think repurposing a couple of unused control characters is about time anyway (there are too many already).

                1. 3

                  Could the same thing be achieved by changing the diff program?

                  1. 3

                    This leads eventually to AST diffing, and storing of AST rather than plain text, then allowing for per-preference visual layout during view and edit.

                    1. 1

                      I’m skeptical. AST / “semantic” diff is only necessary if you actually want it to anything else than what an (ideal) textual diff could. And until that need arises, my nullhypothesis would be that you rather don’t want it – I’m not at all convinced that people know what they want before a better textual diff has even been attempted.

                      1. 1

                        … which is, to my way of thinking, the Correct Answer for storage of source code, in any event.

                      2. 1

                        Absolutely, I think both approaches have advantages, and both should be done. I can’t believe nobody has tried either.

                        1. 1

                          The advantage of changing the diff program is that people who care about this can change it for themselves without affecting the format of files distributed to others. What would be the advantage of the other way?

                          1. 1

                            Yes, obviously, it’s an uphill battle to change the definition of text. But it’s fundamentally redundant information – if you don’t remove it, the alternative is to support ignoring it everywhere. Remark that I’m not merely talking about any freestanding diff tool; the pressing problem for me is the rebase machinery in git.

                            And here’s an idea for a compression preprocessor: I would be surprised if it didn’t compress better too.

                            1. 1

                              But it’s fundamentally redundant information – if you don’t remove it, the alternative is to support ignoring it everywhere.

                              I’m not sure what you mean by that.

                              If we imagine that every tool affected by this change can be updated, then your proposal has the benefit of slightly smaller file sizes – on the order of one byte per line per level of indentation (perhaps this is the advantage you had in mind?). But adoption takes time and it will never be 100%, so you have to weigh it against the problems caused for tools that don’t support it. In this case, it would either prevent display of the files altogether, or show strange characters and no indentation.

                              On the other hand, changing the diff procedure would be easier to adopt because there are fewer tools that would need to be changed (still a lot). Those that don’t adopt the change would simply have the status quo, which is way better than losing the ability to view a file or its indentation.

                              Remark that I’m not merely talking about any freestanding diff tool; the pressing problem for me is the rebase machinery in git.

                              Still a much smaller change than changing everything that might display the file.

                    2. 3

                      I read this title and my first reaction was “Elastic product development is becoming a little absurd”.

                      1. 2

                        I’m a little worried about someone talking about aligning code when they chose to full-justify their blog.

                        I am less worried about how editors interpret tabs for indentation, since I believe that people who hate how an editor does that will change the behavior or change editors.

                        1. 6

                          Meh, in a single-column layout like that the lines are wide enough that full justification is fine IMHO, Butterick says basically “it’s an individual aesthetic choice” on that page you linked to.

                          I do worry about tabs/indents, because of reading or editing other people’s code. If they use spaces I’m stuck with their indentation preference, and some people think 2-space or 8-space indents are OK (they’re wrong.) If they use tabs I see the indentation I prefer, but any spacing within the line, like marginal comments, gets badly messed up. And lines that have extra indentation to match something on the previous line, like an open-paren, come out wrong.

                          This elastic system seems like a nice idea for within-line spacing. Maybe it can be combined with a syntax-driven rule that generates the leading indentation automatically when the file is opened; then the editor can just ignore leading whitespace. (Except in indent-sensitive languages like Nim and Python, obvs.)

                          1. 3

                            The problem is that one often has to work with others, and they have different preferences.

                            By separating the semantics of the code (indented blocks, columns of code/comments) from the presentation of the code (amount of whitespace added), you provide the option for each reader to see a presentation that is most pleasing to parse without forcing a everyone to align their editor settings.

                            1. 3

                              The most recent versions of clang-format finally support my preferred style: tabs for indentation, spaces for alignment. Each line starts with one tab for each indent level. If you have whitespace beyond that (or anywhere other than the start of a line) then it is spaces. This means that the comment in the motivating example in this article looks correct for any tab width, and even with tabs not set to a uniform, but consistent, value (for example, in C++, it would be great if my editor could use a single 2-space tabstop inside a namespace but 4-space tabstops everywhere else, including the second tabulator in a line inside a namespace). This doesn’t need the editor to do anything special and works fine even with cat.

                            2. 2

                              I’m a little worried about someone talking about aligning code when they chose to full-justify their blog.

                              Any links I can read about justification concern?

                                1. 4

                                  To piggyback off this – I consider Butterick’s Practical Typography a must read. I’ve learned a ton and improved my written communication thanks to his guidelines.

                                2. 3

                                  HTML/CSS has few, if any affordances for hyphenation, so setting text to be fully justified runs the risk of getting huge gaps in some lines if there’s a long word that can’t be hyphenated correctly.

                                  It’s not a dealbreaker for most but it can look a bit unprofessional if you’re unlucky.

                                  1. 5

                                    CSS has the hyphens property, which gives coarse control over hyphenation, set to auto (aka, use hyphens) by default.

                                    1. 3

                                      It’s also simple to make it gracefully degrade to left-aligned text in browsers that don’t support hyphens, via @supports (hyphens: auto). In the modern browser world, I see no valid reason not to enable justification for browsers that support it, at least not for websites with significant amounts of text.

                              1. 2

                                I remember years ago, probably in the 2010’s or even late 2000’s, talking to Allan Odgaard, the author of TextMate about adding this feature. Sadly it never happened, but I often use similar ideas when writing code - in VS Code being able to select a =, hit cmd-d a bunch of times to select all the definitions in a block, then hit left, opt-a to align them, makes for much more readable code, particularly with my dyslexia.

                                1. 1

                                  This is a nice take.

                                  I can’t help thinking about xkcd’s comment on standards.

                                  Stories with similar links:

                                  1. Elastic tabstops - a better way to indent and align code via gasche 4 years ago | 32 points | 42 comments