Skip to main content
19 events
when toggle format what by license comment
Feb 3, 2019 at 10:42 history edited N0rbert CC BY-SA 4.0
edited tags
Jul 29, 2018 at 21:57 history edited N0rbert CC BY-SA 4.0
added 69 characters in body
Jul 21, 2018 at 11:45 history edited N0rbert CC BY-SA 4.0
added 1 character in body
Jul 21, 2018 at 11:37 history edited N0rbert CC BY-SA 4.0
added 244 characters in body
Jul 19, 2018 at 17:42 comment added Zanna Mod If the output appears in a terminal, no matter how short it is, I feel it needs code formatting, not blockquote, because once you format short errors that way, you make people think it's OK to format any errors that way and it makes anything longer than one line really hard to read. The error should look as similar to the way it does when encountered as possible, so that people can recognise it
Jul 19, 2018 at 10:10 comment added Melebius I think quote formatting (>) should be considered for the “code” containing a single error message only. Moreover, the error message in the linked question seems to be incomplete.
Jul 18, 2018 at 21:06 comment added TheWanderer This may seem a bit off-topic at first: I've developed an app for Android that requires running a few ADB commands to get working. I have them listed in the app to just fit the width of the display instead of scrolling sideways, and I can tell you it does not work well. People miss spaces, think each is 2 commands, etc. Granted, when I had it the other way, people didn't know it scrolled, but that wasn't as much of a problem.
Jul 18, 2018 at 21:02 comment added David Foerster I have no strong opinion either way. Ideally there would be a simple and intuitive way to enable or disable line breaks in long lines inside pre-formatted listings as needed but imho the majority of people doesn't think or care enough about this issue to warrant such a solution. I can tell you that web browsers will not insert line break characters at “soft” line breaks when one copies and pastes code listings with the white-space: pre-wrap CSS declaration (which my browser injects as user style for all <pre> elements).
Jul 15, 2018 at 17:22 history edited ZannaMod CC BY-SA 4.0
typo in title
Jul 15, 2018 at 16:11 comment added Zanna Mod FYI you can't ping someone who hasn't commented on or edited a post and isn't its owner, so David won't see that until he happens to read meta. FWIW, I also (strongly) prefer code blocks for code on its own line, even if it triggers scrolling, but I introduce line breaks into command output to avoid scrolling where possible
Jul 15, 2018 at 13:59 comment added dessert @PerlDuck Please write a feature request here on meta and tag it accordingly!
Jul 15, 2018 at 13:07 comment added PerlDuck I'd like it best if there was something like the <!-- language: lang-js --> thingy, e.g. <!-- render: no-scroll --> or whatever so the author can decide. Sometimes scrolling is OK, sometimes it isn't.
Jul 15, 2018 at 12:51 comment added N0rbert I think we need to invite @DavidFoerster here for the discussion. This problem started with styling of console output - I preferred backticks to get non-scrollable output, but David likes four-spaces and got non-scrollable variant by custom user-side CSS.
Jul 15, 2018 at 12:46 history edited N0rbert CC BY-SA 4.0
added 157 characters in body
Jul 15, 2018 at 12:39 history edited N0rbert CC BY-SA 4.0
added 20 characters in body
Jul 15, 2018 at 12:35 comment added dessert Why shouldn’t it be scrollable? It’s code, and a newline can make a difference – code blocks should definitely not break lines automatically IMO!
Jul 15, 2018 at 12:32 history edited N0rbert CC BY-SA 4.0
added 55 characters in body
Jul 15, 2018 at 12:31 history edited dessert CC BY-SA 4.0
edited title
Jul 15, 2018 at 12:26 history asked N0rbert CC BY-SA 4.0