On 22 October 2015 at 01:59, Robby Findler <ro...@eecs.northwestern.edu> wrote: > 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.
Thanks, I had never figured! Each programmer editor I know has different amounts of magic for this kind of scenario (I think that simply leaving the newly created line often erases the whitespace). That's tricky to maintain, but seems worthwhile. ***But adding spaces in the whole file when *reindenting* (Ctrl-I / Cmd-I) is a bigger pain, and what I tried to focus on. That makes Cmd-I painful to use for me. *** While IMHO that should be fixed, DrWhitespace appears a sufficient solution for my immediate problem. Thanks a lot! Also thanks for all other replies; I missed the earlier thread. Cheers, Paolo > 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. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ -- 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.
