ID:2424054
 
BYOND Version:N/A (Website Bug)
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 71.0.3578.98
Applies to:Website
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
The website removes tabs from the rendered version of dm code blocks, putting down four spaces for each tab, this makes it impossible to help users with indentation problems because the issue doesn't show up.

This wouldn't be as big of a problem if it weren't for the fact that the website also abstracts away mixed indentation, such as a space followed by a tab on the same line ({space}{tab}{code}), putting down 4 spaces rather than 5, removing the final bit of information about the indentation problem.

See ID:2423980 for an example of this.

Workarounds:

Quote, if the thread isn't locked, to see the raw text, otherwise no dice. (as an aside, the ability to see the source version of a comment would be nice, as this shouldn't be locked away behind quote.)
The source version isn't available because the text has to get processed through a filter before it ever reaches the browser; that's why the quote workaround works. (A separate way of grabbing the post/comment source, even when the thread is locked, wouldn't be bad though.)

The reason the tabs aren't put through directly is that support for styles/params that determine how many spaces are shown per tab is historically poor.

I'm gonna move this to Feature Requests since as it stands this isn't really a bug per se; the behavior is fully intended. But I see value in adding some ways of making it easier to handle these situations.
The reason the tabs aren't put through directly is that support for styles/params that determine how many spaces are shown per tab is historically poor.

<style>
div.dmcode pre {
tab-size: 4;
-moz-tab-size: 4;
-o-tab-size: 4;
-ms-tab-size: 4;
}
</style>

<script>
var fix_tab_size = function(pre, size) {
if(typeof fix_tab_size.supports === 'undefined') {
var bs = document.body.style;
fix_tab_size.supports = ('tab-size' in bs || '-o-tab-size' in bs || '-ms-tab-size' in bs || '-moz-tab-size' in bs);
}
if(!fix_tab_size.supports) {
$('pre').each(function() {
var t = $(this);
t.html(t.html().replace(/\t/g, new Array(size+1).join(' ')));
});
}
}
$(function() {
fix_tab_size($('div.dmcode '),4);
});
</script>


I adapted this to byond's css selectors from https://stackoverflow.com/questions/6686763/ setting-pre-tab-width-in-different-web-browsers

Should be helpful in your pursuits.
In response to MrStonedOne
Doesn't look like Microsoft supports tab-size in IE or Edge yet. Everyone else does, though, which is fine imo. It's not like an 8-space tab width only on IE/Edge would break anything.
The script section of that will detect if the browser supports the css selectors for tab-size, and if not, replace the tabs with 4 spaces
I'll look into that. I'd have to make some modifications to the site code which is a major gear-switch for me right now but I can keep it in mind.

That script however has a problem: it replaces all tabs with N spaces which is incorrect; the number of spaces will vary depending on the line position the tab was at.
Intentional, doing it "properly" would hide mixed indentation entirely, the issue of this bug report.

by doing a flat 4 space replace, space+tab will properly show up as an issue since it will show up as 5 spaces and not 4.
I see what you mean.
For cases where tabs must be displayed as spaces, you could modify the text that is copied to the clipboard, and either replace it with the original text, or replace a number of spaces with tabs.

For an exact copy, you could delimit the groups of tab spaces with nonprinting characters, so that they could be parsed and converted back into the original tabs.