Conversation:
Notices
-
testing unuglifying patch for neo-quitter
-
I don't know how the mobile profile plugin does its thing, but it should probably just load another CSS which overrides some of the configured theme's settings.
-
I glanced at your second request, wasn't it just replacing whitespaces with other whitespaces?
-
So no functional difference?
I did a ':%s/\t/ /g' in vim before commiting your diff and also cleaned up some trailing whitespace.
If that wasn't enough and you want to make your CSS look prettier, use a better interpreter or editor that shows you a better layout. :)
-
All code so far is indented with 4 spaces per level. Coding style is documented here: https://web.archive.org/web/20140720111313/http://status.net/wiki/Coding_style
But I don't feel like accepting purely cosmetic patches since they make it more confusing when looking at 'git blame' to figure out who wrote what and when. cc: @marcus@gnusocial.ch
-
Full developer documentation for !gnusocial (as it was with !sn ) is available here: https://web.archive.org/web/20140702073828/http://status.net/wiki/Category:Dev_doc
-
It'd be much easier to accept it anyway if you made it as a merge request on #Gitorious.
-
If I expressed it as _preferred_ to get it over email I must've been clumsy with the keyboard.
I prefer it as a merge request over Gitorious, but if someone is just doing a one-off patch, don't want to get an account there or go through the hassle of setting up their own clone etc, a _quick way_ to send patches is via email.
-
If you've got a fix that actually changes functionality, like your first one, I'll gladly accept it.
And then you can sneak in some "cosmetic changes" in a separate commit in your merge request :)
-
The thing is that there are probably leftover tabs and spaces and whatnot everywhere. Going hunting for those things won't make anything work better, won't improve knowledge of the codebase for the one who does it and will only be a hassle to verify that they don't introduce - intended or not - bugs due to simple mistakes. I think the focus should be on improving func…
-
vi here too, and I can configure it to handle whitespaces like tabs and spaces in a sane enough way to avoid being annoyed with various mistakes from previous developers.
-
I don't see the problem. vim lets you jump from start to finish and back of { } blocks using % when the marker is on either end of the block. It also hilights the other end. You can also split the window horizontally to see both the start and the finish of the block at the same time. And you can do a bunch of other tricks which remove annoyances caused by different cod…
-
And no, it's not GNU social that handles it automatically, it's HTML which doesn't represent multiple whitespaces as more than a single whitespace. 'white-space: pre;' will make that notice look as you intended. GNU social doesn't touch whitespace besides running nl2br().
-
It's about coding style and some guidelines. Of course you can always work around with some overlay tools, but if it could easily be fixed in code, why not. I do not want to depend on tools for good readable code. And that's why there are coding guidelines (which you even pointed to me).
Besides that I know Web developer tools and already linked to !snbug
-
@aqeel if indentation is one commit and a real, functional change is another.