Is it true that code tags now "know" what forum they're in? Because I was only posting one line of code so I didn't use the =Java tag in the Java forum, yet it got posted with the Java code tags instead of the regular code tags. If that is true, it's definitely cool because now new members won't be able to post with the other tags. But maybe I'm just going crazy.

Recommended Answers

All 16 Replies

I noticed that recently too :)

Saved me typing another 4 characters each time :D

Yes, Dani made that change a few weeks ago.

because now new members won't be able to post with the other tags

Yes however I use to use code tags with no syntax a lot for non-code text and now old posts like the many I've posted are highlighted in code when they are just important text. There are ways around it but as good as this new feature is for new comers, I kinda miss the short-cut the displaying monospaced text just by using code tags. O'well, I guess some things do change and perhaps for the better.

Just use [code=text]...

It preserves your formatting and uses a terminal font:

col1            col2                           col3
--------------- ------------------------------ ----
abc             def                            xyz

(1 row(s) affected)

Yes however I use to use code tags with no syntax a lot for non-code text and now old posts like the many I've posted are highlighted in code when they are just important text. There are ways around it but as good as this new feature is for new comers, I kinda miss the short-cut the displaying monospaced text just by using code tags. O'well, I guess some things do change and perhaps for the better.

That's the main problem, I think. I'm not crazy about the syntax-defaulting the way it is now, but since I know about it, I can get around it when I want to. However, the code syntax defaulting has been retroactive, so you have all sorts of stuff like this in the C++ forum:

Now is the time for all good men to come to the aid of their country.

It was intended as a text input file and is now flagged as "C++ Syntax" and "time for" is highlighted as keywords. Not the end of the world, but the result is a lot of high quality posts now looking much less high quality IMO. I don't know anything about the parsing mechanism, but I would imagine that it could check for a post-date and if it were pre-change, don't use the language-assumption.

commented: Very good point about the retroactive changes. This is the second or third time I've watched beautiful posts turned to crap after an "upgrade". A lesson I'm beginnning to take from this is not to use any tags. +0
commented: Yup +0
commented: great idea +0

>It preserves your formatting and uses a terminal font:

...but is still not enough since the original CODE tags didn't add line numbers. This auto-line numbering feature kinda breaks posts in which code tags were used for the sole purpose of preserving formatting and using a terminal font *without* the line numbers. E.g.

1. Wake up early
2. Brush your teeth
3. Take a bath
4. Off to work, which kinda sucks

I'd recommend the people who miss the old code tags to use [code=plain] [/code].

1. Wake up early
2. Brush your teeth
3. Take a bath
4. Off to work, which kinda sucks

As DaniWeb grows and evolves over the course of years, things are going to change which (at leat the intention is) to be for the better for the majority of our vast traffic and memberbase. This is an inevitable.

I strive to be as absolutely backwards compatible as possible, but backwards compatibility can only go so far. The new behaviour of the code tags is 100% backwards compatible as long as they were used for their intended purpose which is to display code. (i.e. *many* extra lengths were taken to preserve the ability for the system to be smart enough to not automatically syntax highlight when bbcode is used to highlight code manually).

However, using code tags for something outside of code to achieve a visual effect as a result of the current way code tags happen to be handled cannot ever be guaranteed in the future. It is almost like exploiting the current system to do something it isn't designed to do ... it cannot be guaranteed in future versions. The same goes for quote tags or any other DaniWeb feature. It is not recommended to use quote tags for non-quotes because there are many undesired side effects when using something not for its intended purpose (for example, did you know that quote tags use the html blockquote tag which tell Google that the content within them is not unique and not to spider it?)

>However, using code tags for something outside of code to achieve
>a visual effect as a result of the current way code tags happen to be
>handled cannot ever be guaranteed in the future.

Translation: "Bite me. You didn't use tags for the narrow purpose they were designed, so you don't have a right to complain when I change their behavior".

That's all well and good if you're a cruel dictator, but it's not generally a good idea to make your members angry. Daniweb isn't the only tech forum out there, after all, and the ones most likely to be annoyed by this change are the ones who provide you with the most value.

>It is almost like exploiting the current system to do something it isn't designed to do
IIRC, code and quote tags were used to "exploit" the system because there wasn't any other way to achieve anything remotely like the presentation we wanted. Perhaps instead of giving us the proverbial finger, you could incorporate something into the system so we don't need to exploit it?

commented: :) +0

I agree that for new users it has for sure changed for the better but there are things that can be done to make things easier for the more experienced users. I believe that the solution to this is not changing quote/code tags but instead adding a new tag which will simulate the old code tag and possibly with a few minor differences for the better depending on what the community thinks. This new tag would basically be just to set text in monospacing which some replies require and the ability the have bbcode inside that tag. That is how I would solve the problem so what does the community think.

However, using code tags for something outside of code to achieve a visual effect as a result of the current way code tags happen to be handled cannot ever be guaranteed in the future. It is almost like exploiting the current system to do something it isn't designed to do ... it cannot be guaranteed in future versions.

Oh ... my post above is in response to this thread: http://www.daniweb.com/forums/thread235826.html

I agree that for new users it has for sure changed for the better but there are things that can be done to make things easier for the more experienced users.

As cwarn says, the change is for the better moving forward. Therefore, what's the best way to always grow and evolve and constantly get better? It's always a delicate balance trying to come up with improvements without any negative impact at all. Therefore, my policy is to ensure 100% backwards compatibility ... but it's not feasable to expect 100% backwards compatibility for features that were knowingly not being used as they were meant to be and I never endorsed or told anyone was a viable alternative to what they were trying to do. Otherwise, where would it end?

Suppose there's a bug in the system where if you type [fdsa] then it gets interpreted as a code tag. So you start using [fdsa] instead of (code) because it's easier to type even though you're aware that it isn't meant to be a real bbcode tag. If the bug is squashed, are you going to complain that we're not ensuring backwards compatibility with all your code tags? :)

I am simply saying that if you knowingly use features not as they are expected to be used, do not expect them to last forever. (Such as using quote tags for code or using code tags for plaintext).

However, I do understand that people want to have a way to use plaintext or just force the system to not syntax highlight and that ability is already built into the current system. You can use (code=text) if you don't want to parse bbcode or syntax highlight or just (code) if you do want to parse bbcode (and if bbcode is present, the system is smart enough to not syntax highlight).

Therefore, my policy is to ensure 100% backwards compatibility

:icon_lol:

Therefore, my policy is to ensure 100% backwards compatibility

You mean like with the old smilies? :icon_twisted:

Or the fact that we first had to use [code=cplusplus] [/code] tags because [code=cpp] [/code] was invalid according to you, but now we have to use [code=c++] [/code] tags because the [code=cplusplus] [/code] tags are now invalid?

but it's not feasable to expect 100% backwards compatibility for features that were knowingly not being used as they were meant to be and I never endorsed or told anyone was a viable alternative to what they were trying to do. Otherwise, where would it end?

Suppose there's a bug in the system where if you type [fdsa] then it gets interpreted as a code tag. So you start using [fdsa] instead of (code) because it's easier to type even though you're aware that it isn't meant to be a real bbcode tag. If the bug is squashed, are you going to complain that we're not ensuring backwards compatibility with all your code tags? :)

I am simply saying that if you knowingly use features not as they are expected to be used, do not expect them to last forever. (Such as using quote tags for code or using code tags for plaintext).

Key word here is "knowingly". We're not "knowingly" doing anything wrong. Quite the opposite. We're explicitly FOLLOWING the directions given. There was no "bug" in any of this. These were code tags, mostly being used for code, but not always. Nowhere did it say that they should only be used for code.

We're given a link to code tags and how they work:

http://www.daniweb.com/forums/announcement8-3.html

Which contains a more in-depth link on how to use them:

http://www.daniweb.com/forums/misc-explaincode.html

Specifically, we were (and erroneously still are, according to the links, which have a (code) example with no line numbers or syntax-specific coding) explicitly given the option of using code tags with or without syntax highlighting. Since code tags seemed to be the only game in town, that's what people used for non-code too. Now apparently for "Draw a triangle" type problems, we're supposed to use (code=plain), which is still a code tag, for stuff that's not code? That's using code tags properly, but it should have been obvious not use (code)? Or we should use (code=text)? None of this is in the links. These links are in serious need of a through update if you want people to know exactly how they should post.

   *
  ***
 *****
*******

(code=cpp) works, but (code=cplusplus) no longer does, but you told us to change from (code=cpp) to (code=cplusplus), so when we typed (code=cplusplus) to demonstrate C++-style coding in the Java forum, it now comes up as Java syntax.

It's a perfectly reasonable assumption that people are intentionally going to post code in a language other than the forum being posted as compare and contrast between languages. The "code" tag icon added (code), not (code=C++) when you pressed it, it looked fine in the Preview. so you hit "Submit". The link pinned to the forums specifically STILL has syntax-specific and non-syntax-specific examples.

Really, this is about as far removed from "knowingly" using tags incorrectly because of some "bug" as one can get. The "fdsa" analogy is in a completely different realm. You have a pinned thread that hasn't been updated apparently since 2004 and says nothing about only using code tags for code. We used code tags for non-code because that was the only tool that was in the shed. If you don't want us to use a screwdriver to pound nails, give us a hammer. I guess the hammer is now (code=text), so people will use that from now on, which solves the problem going forward, but you still have several years of posts that now look really bad.

If the bug is squashed, are you going to complain that we're not ensuring backwards compatibility with all your code tags?

Um, you fail. This isn't a bug, it's documented behavior that's been in place for years. You may as well just call it what it is: changing basic functionality of the forum, retroactively altering all of our posts, screw backward compatibility, and tough shit if we don't like it.

Honestly, I don't think the change itself is that big of a deal. But blaming us for not using the forum as it was "intended", despite the fact that we used it as it was documented? That's a new low.

I'm only guessing here but wouldn't for better backwards compatibility with the cplusplus tag be as simple as making another language template?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.