lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code formatter


From: Carl Sorensen
Subject: Re: Code formatter
Date: Fri, 13 Nov 2009 16:51:25 -0700



On 11/13/09 4:24 PM, "Ian Hulin" <address@hidden> wrote:

> Hi Carl and list,
> 
> Carl Sorensen wrote:
>> 
>> 
>> On 11/13/09 9:59 AM, "Trevor Daniels" <address@hidden> wrote:
>> 
>>> 
>>> Chris Snyder wrote Friday, November 13, 2009 4:35 PM
>>>> Graham Percival wrote:
>>>>> I know that you're thinking "this is ridiculous", but unless
>>>>> somebody does it, newbies will continue to face this difficulty.
>>>>> This job won't get done by itself.
>>>> Yes, I do think it's ridiculous. As I understand, you're saying,
>>>> "go find a tool that makes the code conform to a standard we
>>>> haven't defined yet."
>>> Chris is right: if progress is to be made the rules
>>> must be defined first.  They can be defined
>>> incrementally; in fact some already exist.  If we
>>> can't agree on the rules there is little point in
>>> searching for a tool.
>> 
>> The rules are already defined (albeit unsatisfactorily in my opinion):
>> 
>> Do whatever emacs does.
>> 
>> Yes, this is unsatisfactory, because many of us don't use emacs.
>> Nevertheless, it is the defined standard.
> 
> In which case we need to understand, note and detail "whatever emacs
> does" in the CG, so users of other editors can set their environment up
> not to get into trouble (this is the voice of bitter experience speaking
> here).

This is probably OK, as long as we don't identify it as the standard.  That
is, we identify these rules as ways to achieve compatibility with the
standard, rather than as the standard itself.

Really, the correct way to do it is to run code through emacs (although
this doesn't apply to Scheme in .ly files, as emacs won't recognize them
as Scheme unless we put a Scheme header on the file (which might not be a
bad idea for (yet to be standardised) .ily files).

> Unfortunately emacs has language-sensitive information in its various
> "mode" codes, so that it can be intelligent about indenting things to
> the right level when you, as the programmer do something like hit the
> enter key and then press <TAB>. This presumably is hidden in the lisp
> code which defines the modes for C++ and Scheme.
> 
> There are lots of variables here as
> Graham pointed out in his one-man role-play earlier in this thread.
> Things like:
> o Are tab characters used, or does the editor convert these to spaces?

emacs can behave either way.  IIUC, the standard is ambivalent concerning
tabs vs. spaces.  I proposed spaces only, Han-Wen agreed, and Jan said "fine
as long as it's made part of the GNU standard."  So it's developer's choice.

When I edit code, I convert tabs to spaces in my changed lines, and nobody
has ever complained about that.


> o What is the maximum number of spaces per tab stop?

GNU standard is 8 spaces per tab.

> o What is the indentation size for the language in which the developer
>       is currently programming?
>   Note: We've got three main language environments when coding for
> Lilypond:
> C++, Scheme, Lilypond source, and in addition we've got to cope with
> Scheme embedded in Lilypond source [e.g. init.ly].  This last one
> confuses the hell out of emacs as it expects all Scheme language code to
> be in a *.scm file.
> This stuff is hidden in the emacs mode definitions and we need it in
> black and white in the CG for users of other editors (e.g. JEdit,
> Frescobaldi, vim) so they can configure their environments correctly.
> 
> Are these assumptions correct?
> o C++ - Tabstops at every eighth character, indent size is four
> characters

Yes, as far as I can tell.

> o Scheme - Tabstops at every eighth character, indent size is two characters

Tabstops, yes.  Other rules, no.

There are specific indentations for let blocks.

In general, indentation for lists puts all list elements at the same level
(which is a one-space indent for an the second element of a list if it's on
a different line than the first element of the list).

Since we're talking about unofficial rules aimed at being compatible with
the standard "whatever emacs does", I think we could refer to some
unofficial rules that teach proper scheme indenting (although we're on
shaky ground here, I admit).

Some references that have helped me:

http://community.schemewiki.org/?scheme-style  (my favorite)

http://www.cs.indiana.edu/proglang/scheme/indentation.html (some additional
explanations)

> o Lilypond - Tabstops at every eighth character, indent size is four
> characters.

No -- Lilypond indent is two characters.  LilyPond coding style is *not*
"whatever emacs does".  It's already defined in the CG.

> o Overall club rules -
> oo Whitespace should be zero or more tab characters followed by any
> spaces necessary to indent to the correct level.
> oo Thou shalt not have whitespace followed by a newline or the git
> gremlins will come and drag out of your bed at 4 a.m. and eat you alive.

oo Thou shalt not have space followed by tab or the git gremlins will get
you as well.  I don't know if emacs fixes this kind of whitespace error
or not.

> oo "Whatever emacs does" seems to imply we don't want the editor to
> convert tab characters to spaces.

If you want to, you may.  emacs has that capability and it's acceptable
according to Han-Wen, but it shouldn't be applied wholesale to files that
are already indented properly.

> 
> Bert and Wilbert (and the man or woman who can program vim, if (s)he's
> out there),
> is there any way we can get JEdit+LilyPondTool and Frescobaldi (and vim)
> to do
> "whatever Emacs does" for Lilypond, Scheme and C++?
> 
> Carl, I'm attempting to write a Chapter for CG to outline the bare bones
> of what new developers can get involved in (a sort of 'Intended
> Audience' Chapter), and I'd like to be able to include answers to the
> questions I've asked here.

Here they are, but I'm not sure we really want to go there, other than in
some appendix that is clearly marked as "this is *not* the standard".

Thanks,

Carl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]