• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Indentation handling is different between richtext and BB code components

Status
Not open for further replies.
Level 14
Joined
Dec 12, 2012
Messages
1,007
It seems that when posting code directly in the richtext component, indentation (i.e. tabs and spaces) are handled differently compared to the BB code component. This can result in broken indentation when posting code from the richtext component, compare this discussion.

I think it would be good if indentation, or code in general, would be handled consistently over the two different editors to avoid confusion.

EDIT: Just saw there is a bug report forum, please move this thread there.
 
Level 14
Joined
Dec 12, 2012
Messages
1,007
Copy-pasting from rich text to plain text works just like pasting it into Notepad AFAIK. Otherwise you will have to click the "plain text" button and copy it then.

I don't think so, because when I copy the linked code (the one with sane indentation) to notepad, the indentation stays sane. Same applies for other text editors (I tried notepad, edit pad lite, scite and the visual studio editor). Only here, in the richedit component, indentation gets broken.

The problem is, that the current behavior is both confusing and can be tedious to deal with.

For example, consider the linked post. If you just try to quote this post, indentation in the quoted code will be broken - even though in the original post, indentation is correct.

Same applies for edits - if I would now edit the linked post, indentation would be automatically broken. I would have to fix it manually, switch to BB code, paste the fixed code there, then apply my edits and finally save the changes.
 

Ralle

Owner
Level 77
Joined
Oct 6, 2004
Messages
10,101

Attachments

  • indent.gif
    indent.gif
    5.2 MB · Views: 116
Level 14
Joined
Dec 12, 2012
Messages
1,007
Looks fine to me. See attached file.

The code in the "Richtext code" hidden tag is broken in both the post and the preview-version. Please take a look at the code within the "BB code" hidden tag.

Could you perhaps record what it is you are doing for comparison?

Sure, please find attached an animation. Notice how the code in the "Richtext code" tag is wrong in both cases (original post and preview version).

The code in the "BB code" hidden tag however, is correct in the original post (all equal signs are aligned nicely), however, once added to a quote you can see that indentation is broken in both the "Richtext code" and the "BB code" fields. This is, because once pasted to the richedit component, indentation gets bad.
 

Attachments

  • indentation.gif
    indentation.gif
    8.2 MB · Views: 81

Ralle

Owner
Level 77
Joined
Oct 6, 2004
Messages
10,101
Okay, more progress. I just had a look at the post you have in the database. It looks like this:
Screenshot 2017-04-05 21.43.30.png


Turns out you are using both spaces and tabs. The highlighting converts tabs to spaces but not in the way you expect. More like a 1 tab = 4 spaces kind of way.

Which editor outputs tabs like this? I thought everyone used spaces with JASS.
 
Level 14
Joined
Dec 12, 2012
Messages
1,007
Okay, more progress. I just had a look at the post you have in the database.

Nice!

Which editor outputs tabs like this? I thought everyone used spaces with JASS.

TESH 2.0 does so. I will make that configurable in the next release since I think both have their pros and cons, so the user should decide which one to take.

Nevertheless I think it is good if that will be fixed in the forum, because it will make displaying code more robust.

Turns out you are using both spaces and tabs. The highlighting converts tabs to spaces but not in the way you expect. More like a 1 tab = 4 spaces kind of way.

Thats funny because my method in the TESH menu is currently doing it like that as well. Will be fixed in the next update, solution is simple:

Code:
1. Iterate over the text and track the current position
2. Reset the position to 0 on every new line
3. If the current char is a tab, replace it with N spaces where N = (tab_width - position % tab_width) and increment the position by N
 
Level 14
Joined
Dec 12, 2012
Messages
1,007
I just sat thinking some more about this. What would N be?

N would depend on the tab_width, but I am pretty sure you meant this ;)

For me it would be 4, but I should not make such assumptions. Therefore, I think it's better people just always post spaces instead of tabs. What do you think?

I understand your point (I also want to avoid making such assumptions whenever possible), however there are several thing to consider here:

Posting only spaces instead of tabs is ok, but that won't fix the original problem. You can't avoid that people will upload code that contains actual tabs, not spaces.

  • Even if I make that the default option in TESH 2.0 (which I will), people might just change that option and use tabs anyway.
  • Or consider Wurst script, which uses Eclipse. Its editor can also be configured to use actual tabs instead of spaces.
  • Same applies for custom highlighting tools like this notepad++ extension.

So there will always be the possiblity that users upload code containing tabs. Whenever that happens and you convert their tabs to spaces, you have to choose some tab_width. The only way to avoid this would be to not convert tabs and display them as tabs - but even then you would have to define the visual tab_width, which will lead to more or less the same result, requiring the same assumptions. There is no way around this.

Remember that this is also nothing new, it has always been like that: the tab_width in BB code (since there, tabs are not converted to spaces) has always been 4. In the old version of the forum, this was the standard tab_width as well.

Therefore I would either display tabs as they are (with a tab_width of 4) or convert them by taking their width into account (again using an effective tab_width of 4).

Why 4? There are several good reasons for that:

  • The first I already mentioned, it has always been like that in this forum, so I see no need to change this.
  • A tab_width of 4 has also always been the (unchangable) tab_width of the TESH (also in the old TESH by SFilip)... so its like that for almost 10 years now in vJass coding.
  • Also, Blizzard uses a tab_width of 4 in their Jass code (compare common.j or Blizzard.j), which was also one of the reasons why this tab width was chosen for TESH.
  • Most resources in both the Spell section and the Jass section that contain (v)Jass code, use a tab width of 4.
  • In the JPAG (JASS Proper Application Guide, coding conventions for code submissions), there was once a discussion on this topic and the consensus was (more or less) that a tab width of 4 is the most "reasonable" choice. Arguments were similar to the ones listed here.
  • Other sites with focus on displaying code like Stackoverflow also do it like that: tabs are converted to spaces assuming a tab width of 4.

On the other hand, the only real reason to use a tab width different than 4 would be personal preferences. Which is a valid point, but this point also applies to a tab width of 4 (I would also assume that the majority of people prefers a tab width of 4 due to the points mentioned above).

So, my suggestion would be: Convert tabs to spaces, taking their actual length into account (like posted above), with assuming a tab width of 4.

No need to make things more complicated than they are, and this approach will basically always work without breaking indentation.
 
Last edited:
Status
Not open for further replies.
Top