[erlang-questions] Controversial subject of the day: tabs and spaces for indentation

[Vlad Dumitrescu]

On Thu, Feb 6, 2014 at 11:46 AM, Vance Shipley <vances@REDACTED> wrote:
> I was inspired by my loathe of emacs indentation to consider how to
> solve the style problems completely.  My solution goes a step further
> than what is proposed above.  I would keep only the Abstract Syntax
> in the repository.  The repository tools (git, svn, etc.) would be
> extended to run the appropriate tool (syntax_tools) on checkout/commit.
> Each user could have any presentation they wanted.  If you like your
> ';' before the case clause you get that style 'cause that's what your
> tools are configured for.  All style debates would be ended.

This would be the ideal solution. However it requires that ALL tools
know haw to handle this, including for example github or another
cloud-based source code handling tool. Also, this assumes that all
code that is checked in is parseable, which is not always the case.

> On Wed, Feb 05, 2014 at 09:27:35PM +0100, Vlad Dumitrescu wrote:
> }  Absolutely, this would fix it. But we don't have tools that can handle
> }  that yet and I fear that implementing those and convincing people to
> }  use them would take longer than agreeing on a saner alternative for
> }  whitespace.
>
> When I first suggested this I was quickly reminded that all preprocessor
> information would be lost.  There would be no macros and no comments.
>
> But didn't you solve that problem in Erlide Vlad?  I remember looking
> and seeing where you were doing preservation of macros and comments
> when working with abstract syntax.

Yes, we have to use a scanner/parser that exactly mirrors the
structure of the code as written, with comments and macros. The
assumption is that the macros are well-behaved, which isn't always
true. Not even the OTP code was free of such macros last time I
checked (R15, I think), but at least now the ?line macros have been
deprecated.

If a scanner/parser is used only to mirror the structure of the code,
then it's possible to implement it relatively easy. If the resulting
tree has to match the structure of the code after macro expansion too,
then it's not possible in the general case. The latter applies to
erlide, where we need to feed the code structure to other tools, so we
are only doing it in "best effort" style and there's still more work
to do.

regards,
Vlad