drimsun [drimsun] [#569606]

Hi there,

I've been an avid Drupal user for about 3 years and have used it for small personal homepages as well as for full-blown e-commerce sites. What made me stick with Drupal is it's open source spirit and community, it's modular design and it's commitment to certain standards (valid XHTML 1.0 strict being one).

I've been submitting patches and developing Drupal modules for about 1 year, the peak being an e-commerce site where, despite using Ubercart, I had to develop about a dozen custom modules.

For a recent project, a web design tutorial site located at http://www.tagbytag.org/, I've been experimenting with different code highlighting tools, both Drupal modules and external solutions. However, the Drupal modules left me unsatisfied because they either:

- didn't correctly highlight all markup (geshifilter sometimes picked up attribute="value" pairs, sometimes not or in a messed up way)
- were overblown (geshifilter is 5mb in size)
- depended on Javascript (chili_highlighter, syntaxhighlighter)
- were not very customizable or too involving/difficult to do so
- had to be told the programming language manually and didn't recognize it automatically
- depended on external libraries
- forced features or layout looks on the user (chili_highlighter, syntaxhighlighter)
- had no "link tag/keyword/etc to page" feature

With these shortcomings in mind, I started developing my own syntax highlighter called PrettyPrint, which can be seen in action here: http://www.tagbytag.org/tutorials/css-beginner/css-internal

It's currently in it's first version, working 100% and tested for functionality, coding standards and security as well as conflicts with other modules. It has the following features among others:

- Light-weight: It consists of 1 module file, 1 CSS file and a /rules directory with highlighting rules, totaling to around 60kb and likely staying so because all main functionality is already there (future features are likely small additions to the module file, new rules are simply placed in the /rules folder).
- Filter: The module is implemented as filter allowing for caching and thus having no highlighting delay (unlike Javascript solutions) or affecting page construction times.
- Universal highlighter: The module does away with specifying the programming language and recognizes it automatically. All you need to do is wrap the code bits in <code></code> tags and that's it (though classes may be provided if you wish, some of which are reserved for special functionality such as forcing block-level display of code).
- Easily customizable: The true power of the module is that the highlighting rules are fully customizable using regular expressions. The module holds all rules in the /rules folder which together create a $rules array that's passed to the parsing engine. The coloring is set with CSS classes (no inline CSS to keep the output small).
- Flexible highlighting rules: The rules are provided as a pair of one or more CSS class names and one or more regular expressions. If more than one regex is provided, they will be chained together recursively, allowing for complex pattern matches and subpatterns (e.g.: 1st regex to match opening HTML tags, 2nd regex to look for attribute="value" pairs in the results). The regex chaining is a vital feature for allowing the module to recognize the programming language automatically.
- Tabbing: Whitespace used for indenting lines of code is preserved in the final output.
- Auto-entities: HTML code can be placed as is between the <code></code> tags and will be automatically turned into the entity equivalents for display. This makes it more convenient to edit code bits as you don't have to juggle with < >.
- Emphasized code parts: Any number of code parts can be emphasized (the background will appear slightly colored) by enclosing them in special symbols.
- Auto-wrappers: The <code></code> parts are automatically transformed into either in-line <span></span> or block-level <div></div> elements depending if the content is multi-line, single-line, of a certain length or forced to a certain display style.
- Filter conflict protection: PrettyPrint can be used together with for example a HTML filter set to remove all HTML tags, as it takes care of protecting the <code></code> parts from being messed up by other filters.

Planned/being worked on for the next version:
- Code links: Similar to how rules are defined, you'll be able to provide an array of links that should be associated with certain code bits. If internal links, they will properly support Drupal features such as language prefixes.
- Custom code tags: Right now code tags are hardcoded to be <code></code>. This will be customizable through the admin pages.
- More highlighting rules/languages: Right now HTML and CSS is provided, though this is likely to grow for the next release as well as with user submissions.

Kind regards,
drimsun

[Edited by KiamLaLuno to escape the HTML tags added in the text, and which were not visible]

Comment	File	Size	Author
#1	prettyprint-6.x-1.0.zip	16.77 KB	account-deletion-needed

Comments

Comment #1

account-deletion-needed commented 5 September 2009 at 23:28

Component:	Miscellaneous	» Code
Status:	Postponed (maintainer needs more info)	» Needs review

Status	File	Size
new	prettyprint-6.x-1.0.zip	16.77 KB

Comment #2

avpaderno

he/him

Italian

Brescia, 🇮🇹 🇪🇺

commented 6 September 2009 at 22:09

Issue tags:

+Drupal 6.x, +Module review

Comment #3

avpaderno

he/him

Italian

Brescia, 🇮🇹 🇪🇺

commented 8 September 2009 at 17:22

Component:	Code	» Miscellaneous
Status:	Needs review	» Needs work

The file LICENSE.txt needs to be removed, as it is not possible to commit it in Drupal CVS.
See the Drupal coding standards to understand how a module code should be written.

  return t('You may post source code by wrapping it in @tag1...@tag2 tags.', array('@tag1' => '&#039;, &#039;@tag2&#039; =&gt; &#039;'));

It should not be necessary to user placeholders in this case; just use the HTML tags but use < instead of <.

      global $prettyprint_rules;
      $prettyprint_rules = prettyprint_load_rules();
    
      // start highlighting process for specified tag(s)
      return preg_replace_callback('/\[(code)(\b[^\]]*)\](.*?)\[\/\1\]/is', 'prettyprint_process', $text);

It is possible to not use a global variable, for this task; see what db_query() does when calls _db_query_callback(). If you really need a global variable because it is used from more than one function, then see the coding standards about global variables.

function db_query($query) {
  $args = func_get_args();
  array_shift($args);
  $query = db_prefix_tables($query);
  if (isset($args[0]) and is_array($args[0])) { // 'All arguments in one array' syntax
    $args = $args[0];
  }
  _db_query_callback($args, TRUE);
  $query = preg_replace_callback(DB_QUERY_REGEXP, '_db_query_callback', $query);
  return _db_query($query);
}

  // load default rules
  require($path . 'default.php');
  if (!is_array($rules))
    return $text;
    
  // load any additional rules found in the rules folder
  $excludes = array('.', '..', 'default.php');
  $files = scandir($path);

The code should use module_load_include(), and file_scan_directory().

  // replace all newlines to a common form
  $text = str_ireplace("\r\n", "\n", $text);
  $text = str_ireplace("\r", "\n", $text);

It would be enough a call to preg_replace().

```
  // check if content is multiline
  if (stripos($text, "\n") !== false)
    $multiline = true;
```
If the module is using a function that is present only in PHP5, then it should declare its dependency on PHP5; Drupal 6 still supports PHP4.

  if ($multiline || strlen($text) > 40 || in_array('block', $classes))
    $wrapper = 'div';
  else
    $wrapper = 'span';

I should have already mentioned the Drupal coding standards.

```
        else if ($rule['classes'])
          $class = $rule['classes'];
        else
          continue;
```
It is still against the Drupal coding standards. I normally mention the code that doesn't follow the coding standards only once; that doesn't mean the code doesn't follow the standards just in one place.


/**
* Code wrapper styles.
*/ 
div.ppr, span.ppr {background:#f8f8f8; border:1px solid #ddd; -moz-border-radius:5px; -webkit-border-radius:5px; padding:0em 0.2em}
div.ppr {margin:0 0 1em; padding:1em}
.ppr {font-family:consolas,monaco,"lucida console","liberation mono","dejavu sans mono","bitstream vera sans mono","courier new"; font-size:13px}
span.ppr {font-size:14px}

I think the coding standards say something about the CSS styles too.