Just for the record, what Vincent describes below is what DrRacket
does (by default). The problem is that not everyone then hits return a
second time.

Robby

On Wed, Oct 21, 2015 at 3:45 PM, Vincent St-Amour
<stamo...@eecs.northwestern.edu> wrote:
> FWIW, I believe what emacs does (or maybe it's configurable?) is to
> delete trailing whitespace when a newline is inserted.
>
> That way, if you start a new line, it will be indented as it should, and
> if you press enter again to leave the line blank, that indentation just
> goes away and you get a true blank line.
>
> Vincent
>
>
>
> On Wed, 21 Oct 2015 15:17:43 -0500,
> Robby Findler wrote:
>>
>> Well, one part of the answer is that DrRacket indents empty lines so
>> when type something like "(define (f x)<return>x" the second "x" is in
>> a reasonable place. Perhaps it could behave differently, but
>> auto-indent-on-return seems less surprising than
>> auto-indent-when-typing-a-character-on-a-whitespace-line.
>>
>> Also, Max made some improvements to how DrRacket treats newlines
>> whitespace at the end of lines (that I think are in a release by now,
>> but I'm not sure). So if you're seeing bad behavior there, more
>> specific info would be helpful.
>>
>> Robby
>>
>>
>> On Wed, Oct 21, 2015 at 2:47 PM, Paolo Giarrusso <p.giarru...@gmail.com> 
>> wrote:
>> > Hi all!
>> >
>> > Every time I reindent a file with DrRacket in a Git repository, DrRacket 
>> > and Git fight over whitespace. Git assumes that spaces at the end of lines 
>> > are whitespace errors, while DrRacket indentation will add spaces to empty 
>> > lines (including existing ones), if they are inside parens (that is, not 
>> > at the outermost level).
>> >
>> > What's more, the official coding style says "Don’t pollute your code with 
>> > spaces at the end of lines", suggesting DrRacket is not behaving well even 
>> > according to Racket guidelines:
>> > http://docs.racket-lang.org/style/Textual_Matters.html#%28part._.Spaces%29
>> >
>> >> Don’t pollute your code with spaces at the end of lines.
>> >
>> > I suspect most people don't have these issue because their empty lines are 
>> > at the outermost level, so they don't need to be indented anyway. But I'm 
>> > writing module statements, namely (module checker handin-server/checker 
>> > ...), and switching to `#lang handin-server/checker` fails for me, 
>> > apparently because that language is defined in a package and not a 
>> > collection, so I'm stuck.
>> >
>> > ==
>> >
>> > What's more, the style guide continues confusingly:
>> >
>> >> If you find yourself breaking long blocks of code with blank lines to aid 
>> >> readability, consider refactoring your program to introduce auxiliary 
>> >> functions so that you can shorten these long blocks of code. If nothing 
>> >> else helps, consider using (potentially) empty comment lines.
>> >
>> > But I find the discussion confusing: are empty lines at the outermost 
>> > level fine (as I'd guess), or does the text discourage empty lines 
>> > everywhere (as the actual text suggests)?
>> > And what are "(potentially) empty comment lines"? Do you actually mean
>> >
>> > ;
>> >
>> > ? Why's that better?
>> >
>> > Finally, does DrRacket not indent empty lines well because they're 
>> > discouraged?
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to racket-users+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to