I would also like to see some improvement in this area.

Not only is it confusing and irritating when it insists on auto-linking something you don't want, but in some cases it can actually break Mantis. For example, someone had sarcastically written the phrase 'attempt #938402394820928309482034' in a ticket, and now any time we try to update that ticket we get this error:

Database query failed. Error received from database was #-1: ERROR: value "9223372036854775807" is out of range for type integer for the query: SELECT * FROM mantis_bug_table WHERE id=$1.

Evidently Mantis tries to interpret any number following a hash, no matter how comically large, as a ticket number, and then tries to look it up in the database.

I'd actually worked around the problem for the most part by replacing Mantis's default formatting plug-in with one that has a sort of pre-processor for escaping.... Probably i have Mantis configured not to use my pre-processor for e-mail notifications, so that's why i still get that error.

The attached file contains the method i use in my formatting plug-in for handling back-slash-escaping of # and ~, as well as auto-escaping of #, ~, and @ inside code and pre elements. Not sure how performant it is — it works pretty well for our small installation, though it needs updated to use Mantis's facilities for getting the user-configured sigils instead of having them hard-coded in. If it would be in any way useful to anybody, you can consider this code to be released under the MIT and/or GPL 2+ licences.

<?php

/**
 * Escapes special characters that Mantis might otherwise mangle.
 *
 * @param string $text The text to process.
 *
 * @return string The text after any escaping.
 */
protected function escapeSpecialChars($text) {
	// Escape all #/@/~ inside <pre> and <code>
	$text = preg_replace_callback(
		'%(<(pre|code)(?:\s[^>]*)?>)(.+?)(</\2\s*>)%ism',
		function ($matches) {
			$matches[3] = mb_encode_numericentity(
				$matches[3],
				[
					// '#'
					0x23, 0x23, 0, 0xff,
					// '@'
					0x40, 0x40, 0, 0xff,
					// '~'
					0x7e, 0x7e, 0, 0xff,
				],
				'UTF-8'
			);
			return implode('', [
				$matches[1],
				$matches[3],
				$matches[4],
			]);
		},
		$text
	);

	// Escape all #/~ preceded by back-slashes
	$text = preg_replace_callback(
		'%(\\\\+)([#~])(\d)%',
		function ($matches) {
			$backslashes = $matches[1];
			$char        = $matches[2];
			$number      = $matches[3];

			// Even number of back-slashes
			if ( ($len = strlen($backslashes)) && $len % 2 === 0 ) {
				$backslashes = substr($backslashes, floor($len / 2));
			// Odd number of back-slashes
			} else {
				$backslashes = substr($backslashes, floor($len / 2) + 1);
				$char        = mb_encode_numericentity($char, [
					// '#'
					0x23, 0x23, 0, 0xff,
					// '~'
					0x7e, 0x7e, 0, 0xff,
				], 'UTF-8');
			}

			return implode('', [
				$backslashes,
				$char,
				$number,
			]);
		},
		$text
	);

	return $text;
}

The default text formatting plugin seems to respect hash character when it is immediately preceded by any other character than white space. Attaching a screenshot showing both cases. Mantis 2.0 Beta 3.

Snapshot-2016-10-15-112909.png (79,353 bytes)   

Snapshot-2016-10-15-112909.png (79,353 bytes)   

That's about right, the pattern it uses to catch bug links is:

'/(^|[^\w&])' . preg_quote( $t_tag, '/' ) . '(\d+)\b/'

@dana

Not only is it confusing and irritating when it insists on auto-linking something you don't want, but in some cases it can actually break Mantis. For example, someone had sarcastically written the phrase 'attempt #938402394820928309482034' in a ticket, and now any time we try to update that ticket we get this error:

I can't reproduce that error. If you can, please report it with details, so it can be fixed

Ideally, the bug/note replacement should not be performed within preformatted parts of text. For example: "pre" tags, or equivalent notation.

But that is not feasible with current system, a proper parser is required to do that correctly.

@cproensa done, see 0021802