On Tue, Apr 14, 2009 at 10:37:08PM +0100, Ashley Moran wrote:
>
> On 14 Apr 2009, at 06:57, Trent W. Buck wrote:
>
>> 1. Add Emacs and vim noise to the bottom of each file, so that
>> people using these editors automatically get the right thing,
>> even if their global defaults are wrong. For example
>
> I use TextMate, and I don't think there's an equivalent for this.
You should extend it to support that, then :-)
For collaborative editing, setting per-document or per-project editing
conventions in a way that the *editor* can understand helps forgetful
engineers like me from accidentially violating them.
> But what I'm actually describing is more about lining up existing
> data, than enforcing whitespace rules. Another example
>
> property :id, Serial
> property :response, Integer, :nullable => false
> +property :some_really_long_name, String
> property :made_at, Time, :nullable => false
Ah, I see what you mean now. Personally I've given up on trying to do
"inline" alignment, precisely because of this issue. When you add a
line that "juts out" past the existing alignment, you have to either
re-align all the other lines in the group, or to leave it jutting out.
At most, I will indent to the nearest eighth of a column, so that all
the "short" lines align, and all the "long" lines align, but they
don't align together. For example,
ALTERNATE_EDITOR twb-editor
BROWSER twb-browser
EDITOR ed
EMAIL [email protected]
GREP_OPTIONS --color auto
GZIP --rsyncable
LESS SR
PAGER twb-pager
VERSION_CONTROL numbered
VISUAL twb-emacsclient
> This sort of thing happens to me *all the time*. Maybe it's more
> prevalent in some languages than others? (Almost everything I do is in
> Ruby.)
Certainly in a language like Lisp I don't feel any real need to do
"inline" alignment. I don't know if that's a property of the
language, or me, or an amalgam of both.
> Again, that sort of thing could be useful. (One person I work with
> has an interest in a script that checks for trailing whitespace.)
> But it's actually a separate issue, as it's about universal rules,
> rather than local formatting.
There is one other way to approach this problem. If your language
supports a lossless (i.e. preserving comments) way to read in a
program and write it back out again in a normal form, what you can do
is have a post-apply hook that generates an object database from the
source tree, and a pre-commit hook that serializes the object database
back into a source tree.
When you're editing a function "f", you just call "edit f" within the
run-time environment, and it serializes only that object long enough
to edit it, then reads it back in.
The nice thing about this approach is that each developer can
customize the serialize function used by edit(), so that the VCS
always stores the code in normal form, but each developer can use
their preferred layout (e.g. tabs vs. spaces).
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
