|
I don't know the details, however as there was a need to change the URLs, I don't think a regex and a simple one-to-one translation will suffice. But, whatever it takes, I too am in favor of keeping the old links functioning properly.
|
|
|
|
|
Wow, I didn't even realize you had a colourizer for article text. Could be I'm wrong, but something's amiss with this:
Dictionary(Of String, BasePiece)
Why did String get set off?
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
It defaults to C++
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Because you didn't set the lang attribute. I think it defaults to C++ colorizing in that case. Typing this:
<code lang="vb">Dictionary(Of String, BasePiece)</code>
Creates this:
Dictionary(Of String, BasePiece)
|
|
|
|
|
 Oh. Thanks. I didn't know the code blocks had a language attribute.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
Sure does, check ITEM 15 in the Article FAQ (Applies to forum messages also)
Code Project Article FAQ[^]
list of supported languages are there.
Dave
Find Me On: Web| Facebook| Twitter| LinkedIn
CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.
|
|
|
|
|
Hmm. Have you read it? Nothing there about the code tag accepting a language attribute. The pre tag does, but I already knew that.
I really don't think colourizing article text is a good idea, either. Multi-coloured text will make it look like a rainbow spilled on it. I'll just rewrite my article to avoid "Of" and "String" so I don't have to deal with the problem.
I do believe this is a bug, though.
This type of colourizing should be for code, not for article text. IMHO, the code tag is should color article text to add clarity to the content. For example, if my article is about a text formatter and I have a variable or object called "read", I want to avoid the confusion created by this text:
"You can read in the code where the paragraph is now read."
When articles apply all the color-coding -- far from adding clarity -- they actually take away from the article by over-focusing the reader's attention on the colors, pulling the reader out of the context of that article.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I agree with you, the default for CODE should be lang="text" which means no colorizing, since CODE is for short, single-line snippets, and hence does not benefit from any colorization. I have been pleading this for many years, without any luck.
|
|
|
|
|
I disagree. Most code posted on this site that has no lang tag in the PRE blocks is of a C flavour. Having a few messages be colourised incorrectly is a better tradeoff than having the majority of code blocks with no lang tag be uncoloured - especially given that the colouriser came in only after several hundred had already been posted.
[Edit: and yes, a compromise is to have the default language set different for different modules]
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I also suggest, and this is new, you automatically replace CODE tags by PRE tags as soon as they span a newline. Yes, I want PRE blocks to be syntax colorized, as the colors work well on the PRE's background, whereas they don't work at all (at least for me) on the CODE background (especially the blueish one in forums).
|
|
|
|
|
Interesting, but trying to outthink what an aithor is attempting to do often ends in tears.
However, for the forums it is a different matter.
Very interesting. I'll add that to the list.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I guess your list is actually a heap. I sometimes wish it were more of a stack. 
|
|
|
|
|
It's an ordered queue. 
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: an ordered queue
a pleonasm if ever I saw one.
|
|
|
|
|
Ever since I visited Italy I've found it very useful to be clear on what sort of queue I mean.
Italy vs the Europe[^]
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
technical people outside Italy agree on calling that a "heap", not an "ordered queue" 
BTW: first time I visited Boston, MA it reminded me a lot of Rome, Italy. Car drivers over there seemed very unamerican.
|
|
|
|
|
|
Luc Pattyn wrote: also suggest, and this is new, you automatically replace CODE tags by PRE tags as soon as they span a newline
Adding to Luc's suggestion, we should also remove one PRE(or CODE) tag automatically if it's followed by another one immediately. In Q&A, many times, people put PRE tag to code part explicitly (for second time) even though when by default code gets formatted by a PRE tag while pasting.
Ex:
<pre lang="cs">protected void SampleCodeSnippet(object sender, EventArgs e)
{
}
HTML presentation of above:
<pre><pre lang="cs"> protected void SampleCodeSnippet(object sender, EventArgs e)
{
// some code
} </pre></pre>
Above highlighted part can be formatted internally(i.e. remove one PRE tag)
modified on Wednesday, September 29, 2010 2:31 AM
|
|
|
|
|
Yep - good idea. Added to the TODO
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
You need to pay more attention to the discussion. We're not talking about the pre blocks. Those need to be colourized, where the colour adds a great deal to the clarity of the reader. By contrast, the code tag is for marking, as I said, usage of code within the article text.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
Thanks for the subtle hint. I wouldn't have thought to specify lang="text".
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
I never said the FAQ article said the CODE block supported a lang attribute, i was merely pointing you to a list of attribute values for the various languages. 
I think some authors get mixed up when to use CODE and PRE and as a result some of the articles look too coloured.
Agree that only code should be colourised using the CODE(for single inline statements, parameters, function names etc) and PRE for blocks of code.
(Off Topic: Not fed up of Wonderware InTouch yet? we are ditching it as our main system in preference of Emerson DeltaV, although our turbine HMI's still use Intouch)
Dave
Find Me On: Web| Facebook| Twitter| LinkedIn
CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.
|
|
|
|
|
Oh. Well, thanks for the heads up, but I actually did give it a cursory read before I published my article. A good thing, too, because I was initially colorizing the code within the pre blocks using the CSS classes. Manually.
As for InTouch, we often don't get to choose. When we do choose, we go with Windows Forms. But sometimes our customers buy our furnace and insist on integrating our Level 2 HMI within their existing SCADA system.
Without darkness, there are no dreams.
-Karla Kuban
|
|
|
|
|
Silver members and above can edit that article. I've gone and added the magic few words.
knockNrod wrote: When articles apply all the color-coding -- far from adding clarity -- they actually take away from the article by over-focusing the reader's attention on the colors, pulling the reader out of the context of that article.
I've gone back and forwards on this a few times. I'm leaning towards removing it again.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
The inline coloring seems useless much of the time. One of the editors did that to one of my articles and I felt it reduced the quality of the article. I could have changed it, but of course that becomes more difficult once an editor gets his/her grubby hands all over it. It can be useful to color code (or, say, italisize) code when it is needed, such as when emphasis is desired or when the term is ambiguous. But that doesn't always apply. For example, it is common practice to uppercase SQL terms when writing SQL code, and that's a practice I carry over to articles. Emphasizing that additionally by adding color is just too distracting, unnecessary, and purposeless. Especially if the article is already broken into small chunks of text with lots of PRE blocks (with so much emphasis, where's a reader to focus?).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Nice one!