Option to suppress CamelCase -> Wiki recognition in version control comments

[Mike Cowperthwaite]

My codebase is primarily C++ and there are many identifiers that are named using CamelCase. We don't want a separate Wiki page for such identifiers; we don't want the links; and we don't the '!' included in checkin comments to suppress it because non-Trac svn clients will display the '!' -- and it's a pain to have to remember that anyway.

Similarly, being able to suppress the !#<number> recognition in checkin comments would be nice; frequently, #1, #2, etc are valid, even necessary strings in the checkin comments and the links are totally pointless and a distraction.

[Ryan J Ollos]

This is implemented in Trac 0.11. See the wiki_format_messages option in the [changeset] section. ​Documentation.

[Mike Cowperthwaite]

I do not find this solution satisfactory. I want some of the Wiki formatting -- in particular, linking to changeset IDs (recognized in brackets) is important.

But the CamelCase interpretation and #N recognition are problems.

For ticket-number recognition, wouldn't it make more sense to require a string that's not so common? Even just doubling the hashmark, as ##4, would be more useful. Auto recognition of something that is at least as likely to mean something that shouldn't be linked just isn't a good idea.

[Ryan J Ollos]

Replying to mikec@lathropengineering.com:

For ticket-number recognition, wouldn't it make more sense to require a string that's not so common? Even just doubling the hashmark, as ##4, would be more useful. Auto recognition of something that is at least as likely to mean something that shouldn't be linked just isn't a good idea.

That is an interesting idea. In fact, I could see the advantage to changing the entire wiki markup so that, for instance, [[1001]] and ##4 are used to link to changesets and tickets, respectively. However, I'd have them display as [1001] and #4. That would fix the problem of accidentally linking to things you don't want linked, particularly for users that aren't familiar with the wiki markup, and particularly in cases were you may not be thinking about how something might be interpreted as wiki markup and can't do a preview (such as log messages).

[Mike Cowperthwaite]

If revising so the markup for those doesn't introduce backwards-compatibility problems, I'm all for it. But the camelcase recognition needs to be handled separately -- that is, separately disabled -- unless you're willing to require extra markup on those strings as well.

[Ryan J Ollos]

I sounds like you want to require two separate options for the [changeset] section, such as wiki_format_messages_traclinks and wiki_format_messages_camelcase.

The current wiki_format_messages option was implemented in ​Changeset 8378.

[Ryan J Ollos]

Specifically, the relevant code is:

if ChangesetModule(self.env).wiki_format_messages: 
    return tag.div(format_to_html(self.env, 
        formatter.context('changeset', (reponame, changeset.rev)), 
        changeset.message, escape_newlines=True), class_='message') 
else: 
    return tag.pre(changeset.message, class_='message') 

[anonymous]

Replying to mikec@lathropengineering.com:

My codebase is primarily C++ and there are many identifiers that are named using CamelCase. We don't want a separate Wiki page for such identifiers; we don't want the links; and we don't the '!' included in checkin comments to suppress it because non-Trac svn clients will display the '!' -- and it's a pain to have to remember that anyway.

If you are willing to disable auto-linking of CamelCase markup to missing wiki pages, then the following TracIni option might work for you: TracIni#wiki-section

[wiki]
ignore_missing_pages

I'm not sure if it takes a 0/1 or enable/disable value.

I'm thinking about submitting comment:5 as an enhancement request and maybe trying to work on it myself.

[Ryan J Ollos]

Replying to mikec@lathropengineering.com:

For ticket-number recognition, wouldn't it make more sense to require a string that's not so common? Even just doubling the hashmark, as ##4, would be more useful. Auto recognition of something that is at least as likely to mean something that shouldn't be linked just isn't a good idea.

I've recently wanted to do this same thing, and remembered this ticket. What I plan to do is write a script that processes the log message and prefixes ! to every camelcase entry. I'd prefer to retain TracLinks for the changeset and ticket number syntaxes, [] and #.

For your purposes, you can probably do something similar - prefix ! to #, except in the case of ##, in which case you strip away one #.

It looks like it would be fairly straightforward to modify the ​post-commit hook to process the changeset message before insertion into the ticket.

I'll post a link to the Trac-Hack when I have the script completed ... probably sometime this weekend.

[Ryan J Ollos]

See also #7557 for a similar feature request for the ChangeLogMacro.

[Ryan J Ollos]

Replying to rjollos:

Replying to mikec@lathropengineering.com:

For ticket-number recognition, wouldn't it make more sense to require a string that's not so common? Even just doubling the hashmark, as ##4, would be more useful. Auto recognition of something that is at least as likely to mean something that shouldn't be linked just isn't a good idea.

I decided to just go with:

[wiki]
ignore_missing_pages = true