New Code Tags (Syntax Highlighting)

Hey,

Just added a new UserCP option so you can change the code tags to look like the code tags in this example (turn this on and off):

Note: I set the default to "SyntaxHighlighting" for debugging purposes. We can change the default back to the original code tags later.

You can change this (turn it off or on)

in the UserCP -> Thread Display Options:

I'm still experimenting with different brushes and formats. Also, I have not yet been able to get the scroll bars to work (same issue as before), but I'm working on it, LOL

Here is a list of "brushes" used by this SyntaxHighlighter.

I may make most or all off the configuration settings available in the UserCP as time goes by.

Please go into your UserCP and turn this off if you want the original code tags (made the default to the new system for now):

Also, if you really want to help out, visit the examples and demos on the web and comment on what you would like to see in the code tags.

Thanks!

OBTW, for those interested, here is the HTML I'm using for the new bbcode tags:

<if condition="$bbuserinfo[field41]=='SyntaxHighlighting'">  

<br />
<div class="smallfont" style="margin-bottom:2px;">$vbphrase:</div>
<div>
<br />
<pre class="brush: bash php xml css plain;">$code</pre><br />
</div>
<br />
<else />
<style>
pre {
   overflow:auto;
   margin:2px;
   padding:15px;
   border:1.2px solid;
   margin-right:10px;

}
</style>
<br />
<br />
<div class="smallfont" style="margin-bottom:2px;">$vbphrase:</div>

<div><pre class="alt2">$code</pre><br /></div>
</if>

EDIT/ UPDATE: I turned off the option to (turn it off) while we are debugging. The reason is that I want to debug for guests who do not have the option to use user profile fields and options.

9 Likes

The line numbering will be very helpful in many cases. The missing shaded frame around the code tagged sections is a wee bit irritating; right now I'd appreciate to have it, but may get along without it in the course of time.
Would it be possible to switch the syntax highlighting when reading the post / thread, on top of setting it in options?

I may be in the minority here, but I'm not sure I like it - yet. It's a good idea, and the line numbering is especially helpful, but the feature needs to be thought through.

This disrupts our habitual use of [color=red] to highlight important changes, for one thing. Either it needs to be opt-in a la [code=bash] or the syntax highlighting colors should be more subdued.

And unless it's done very well, syntax highlighting can be misleading. The one thing which really needs to work perfectly here, the detection of lines and strings, has done a hash job. It looks great, until you think about it -- it's highlighting "shell code" inside quoted and unquoted string literals! It's finding strings inside strings! I really don't want to explain to new programmers why I'm right and the website is wrong.

1 Like

I agree with Corona688... There are problems with the current presentation.

When I use:

```text
command <<word
text
delimiter
```

I get:

command <<word
text
delimiter

I expect to see command in black text (not red), << in red (not black text with color tags showing), and word and delimiter (not seeing those words in normal text with the bold tags).

Note that the printed color tags in the code tags were displayed with the [ and ] tag delimiters, but the and tags were translated to &lt;b&gt; and &lt;/b&gt; ???

1 Like

Agreed. So, let's try the "plain" brush and see how that does.

So, I just changed:

<pre class="brush: bash css php xml plain; ruler: true;">$code</pre>

To this:

<pre class="brush: plain;">$code</pre>

That (the "plain" brush) did not help much (just removed all the color).

So it looks like this will not work well for all of the reason's posted above.

Without objections, I have reverted back to the original way of the code tags.

Do you guys want me to turn it back on and try on "plain" as a final test?

I agree that this syntax highlighter is "pretty" but not accurate and so therefore misleading.

It's certainly faster using the original HTML without all the extra JS code to load in the browser.

If it is not adding real value (and not solving the "original sin" scrollbar issue), we don't need the overhead and performance hits.

Should I turn on "plain" and see how it goes without the colors? Or just abandon this idea?

Suggestions welcome!

1 Like

While I still appreciate the line numbering, I found editing and formatting code snippets extremely tedious with the new approach, having to go to and fro many times more than before.
In retrospect, I'd vote for the original code tags.

1 Like

FWIW, the old tags apparently are still active:

for((i=1; i<=n; i++)); do
printf "%s\n" "Hello World"
done

[highlight=c]#include <stdio.h>

main()
{
printf("Hello World!\n");
}
[/highlight]

class HelloWorld {
static public void main( String args[] ) {
System.out.println( "Hello World!" );
}
}

<script>
alert( 'Hello, world!' );
</script>

There is no "awk" however
BEGIN {
print "Hello World!"
}

--
See also this thread:
https://www.unix.com/the-underground/120578-issues-highlight-bbcode-tags.html

I think the issue with the scrollbars and code tags boils down to the fact that this site uses very old HTML <table> attributes in the templates.

If I manually convert the HTML <table> attributes to <div> tags, I am pretty sure all these kind of annoying problems like scrollbars not working in code tags will go away.

Horizontal scrolling works fine on the mobile site, because I got rid of all the HTML <table> attributes when I updated it and replaced all with <div> tags.

<table> attributes are long dead. vBulletin 3.x is all <table> based, so there lies the problem, I am pretty sure.

It's a lot of work, but it might just be the best way forward.

Since the JS is a filter which creates new text, it's a one-way function.

This means to switch back-and-forth requires us to keep both code tags (original and JS filtered) and write some extra Javascript to switch back and forth.

It's doable, but not sure it is worth the coding extra effort since I am guessing most like the flexibility of the original code tags more than the syntax highlighting javascript.

As mentioned, editing is much easier when WYSIWYG.

That highlighter code uses GESHI and GESHI has an AWK filter for example.

There may even be a much more recent version which has AWK built in, since our version of GESHI is very old.

The latest stable version of GeSHi is 1.0.8.11, released on the 19th of Aug, 2012, but that version also does not directly support AWK.

We are running GeSHi 1.0.8.4 from 2009.

GeSHi - Generic Syntax Highlighter

Here is a PHP filter for GeSHi and AWK:

<?php
/************************************************
 * awk.php
 * -------
 * Author: George Pollard (porges@porg.es)
 * Copyright: (c) 2009 George Pollard
 * Release Version: 1.0.8.8
 * Date Started: 2009/01/28
 *
 * Awk language file for GeSHi.
 *
 * CHANGES
 * -------
 * 2009/01/28 (1.0.8.5)
 *   -  First Release
 *
 * TODO (updated 2009/01/28)
 * -------------------------
 *
 *************************************************************************************
 *
 *     This file is part of GeSHi.
 *
 *   GeSHi is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   GeSHi is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with GeSHi; if not, write to the Free Software
 *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 ************************************************************************************/

$language_data = array (
    'LANG_NAME' => 'awk',
    'COMMENT_SINGLE' => array(
        1 => '#'
        ),
    'COMMENT_MULTI' => array(),
    'CASE_KEYWORDS' => GESHI_CAPS_NO_CHANGE,
    'QUOTEMARKS' => array('"'),
    'ESCAPE_CHAR' => '\\',
    'KEYWORDS' => array (
        1 => array(
            'for', 'in', 'if', 'else', 'while', 'do', 'continue', 'break'
            ),
        2 => array(
            'BEGIN', 'END'
            ),
        3 => array(
            'ARGC', 'ARGV', 'CONVFMT', 'ENVIRON',
            'FILENAME', 'FNR', 'FS', 'NF', 'NR', 'OFMT',
            'OFS','ORS','RLENGTH','RS','RSTART','SUBSEP'
            ),
        4 => array(
            'gsub','index','length','match','split',
            'sprintf','sub','substr','tolower','toupper',
            'atan2','cos','exp','int','log','rand',
            'sin','sqrt','srand'
            ),
        5 => array(
            'print','printf','getline','close','fflush','system'
            ),
        6 => array(
            'function', 'return'
            )
        ),
    'SYMBOLS' => array (
        0 => array(
            '(',')','[',']','{','}'
            ),
        1 => array(
            '!','||','&&'
            ),
        2 => array(
            '<','>','<=','>=','==','!='
            ),
        3 => array(
            '+','-','*','/','%','^','++','--'
            ),
        4 => array(
            '~','!~'
            ),
        5 => array(
            '?',':'
            )
        ),
    'CASE_SENSITIVE' => array(
        GESHI_COMMENTS => false,
        1 => false,
        2 => false,
        3 => false,
        4 => false,
        5 => false,
        6 => false
        ),
    'STYLES' => array(
        'KEYWORDS' => array(
            1 => 'color: #000000; font-weight: bold;',
            2 => 'color: #C20CB9; font-weight: bold;',
            3 => 'color: #4107D5; font-weight: bold;',
            4 => 'color: #07D589; font-weight: bold;',
            5 => 'color: #0BD507; font-weight: bold;',
            6 => 'color: #078CD5; font-weight: bold;'
            ),
        'COMMENTS' => array(
            1 => 'color:#808080;'
            ),
        'ESCAPE_CHAR' => array(
            0 => 'color: #000099; font-weight: bold;'
            ),
        'SYMBOLS' => array(
            0 => 'color:black;',
            1 => 'color:black;',
            2 => 'color:black;',
            3 => 'color:black;',
            4 => 'color:#C4C364;',
            5 => 'color:black;font-weight:bold;'),
        'SCRIPT' => array(),
        'REGEXPS' => array(
            0 => 'color:#000088;'
            ),
        'STRINGS' => array(
            0 => 'color: #ff0000;'
            ),
        'NUMBERS' => array(
            0 => 'color: #000000;'
            ),
        'BRACKETS' => array(
            0 => 'color: #7a0874; font-weight: bold;'
            ),
        'METHODS' => array()
        ),
    'URLS' => array(
        1 => '',
        2 => '',
        3 => '',
        4 => '',
        5 => '',
        6 => ''
        ),
    'OOLANG' => false,
    'OBJECT_SPLITTERS' => array (),
    'REGEXPS' => array(
        0 => "\\$[a-zA-Z0-9_]+"
        ),
    'STRICT_MODE_APPLIES' => GESHI_NEVER,
    'SCRIPT_DELIMITERS' => array (),
    'HIGHLIGHT_STRICT_BLOCK' => array()
);

?>
1 Like

These GeSHi-based tags are good.

That reminds me that if we move off generic plain-ole-vanilla code tags to syntax highlighting tags like this, there will be a burden on all mods to tag correctly based on what kind of code it is.

This seems like a lot of extra work with little value; and since we are not a blogging site specializing in C# or CSS, for example, it would be too much work to try to heard cats and get each user to use the exact right codes tags for their code.

I'm not sure how to proceed; the main reason I moved down this path was to try to fix the scroll bar issue in the <pre> tags used in our code tags. This problem exists with all of this bbcode, so I am hesitant to jump down the rabbit hole on syntax highlighting at this time.

A higher priority is for me to purchase a new dedicated computer running modern Ubuntu and PHP7 and port the site over to that new site and get off this old hardware and depreciated PHP code.

I agree. I seem to me it would be best to just keep it as is, that is we ask the users to minimally use plain-ole-vanilla code tags for code and data and we just provide the highlight tags as an extra option for whoever wants to use it.

I think the plain code tags are preferable in most cases since its supports custom formatting which we regularly use as indicated earlier in the thread..

1 Like

Yes. Our existing GeSHi syntax highlighter works OK and it is a server side process. SyntaxHighligher is client-side JavaScript process and so it is therefore kinda' slow to load; and since it does not solve the scrollbar issue and does not do a great job of actual syntax highlighting, I think better to table this and stick with our generic code tags and let people use GeSHi highlighting if they want.

I will put it on my TODO list to upgrade GeSHi to the latest version and add the AWK syntax highlighting code. Maybe I will create a few buttons in the editor for highlighting.

1 Like

A lot of code works fine on the mobile site which does not work on the legacy (main) site, because the mobile site does not use any HTML <table> tags and only uses <div> tags.

For example. the scrollbars work perfectly fine on the mobile site.

So, I may enable the "plain" (not color or syntax highlighted) new SyntaxHighlighter on the mobile site and see how it works.

Also, instead of spending time trying to covert the existing legacy site which uses <table> tags to <div> tags, I'm thinking I will just convert more legacy pages to <div> tags on the mobile site; and keep building out that site.

Then, maybe someday, we can merge the mobile site and the main site together; but there are so many many pages on the legacy (main) site which uses these obsolete <table> tags, that is will take a long time to move all the plugins and pages to <div> only and so the site would be totally merged (mobile and desktop) and responsive to all form factors.

I'm thinking what is the best way ahead; but my focus will be changes to the mobile site.

You can use the mobile site on the desktop by setting styleid=137

https://www.unix.com/?styleid=137

and you can go back the the original legacy site:

https://www.unix.com/?styleid=38

Using that https://www.unix.com/?styleid=137 on my desktop doesn't change a thing in the presentation of unix.com. What am I doing wrong here?

No idea. Works fine on my end in all browsers.

Update 1: Confirmed this works for me, but not for other users. I must have some bool set from the development days which only permits this for me. I will have to hunt down this error.

Thanks.

Update 2: Working Now. I had to update permissions so other users can change to other styles.

See attached screen recording.

OK. Thanks.

Seems like a bug (update - fixed bug), where it works for me but not for others.

Let me hunt this bug and get back.