Modify

Opened 6 years ago

Last modified 4 years ago

#4196 reopened enhancement

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

Reported by: mikec@… Owned by: anybody
Priority: normal Component: Request-a-Hack
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

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.

Attachments (0)

Change History (10)

comment:1 Changed 5 years ago by rjollos

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:2 follow-ups: Changed 5 years ago by mikec@…

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Trac Release changed from 0.10 to 0.11

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.

comment:3 in reply to: ↑ 2 Changed 5 years ago by 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.

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).

comment:4 Changed 5 years ago by mikec@…

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.

comment:5 Changed 5 years ago by rjollos

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.

comment:6 Changed 5 years ago by rjollos

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') 

comment:7 in reply to: ↑ description Changed 5 years ago by 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.

comment:8 in reply to: ↑ 2 ; follow-up: Changed 4 years ago by 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'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.

comment:9 Changed 4 years ago by rjollos

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

comment:10 in reply to: ↑ 8 Changed 4 years ago by rjollos

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

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.