Revert default behavior of plugin-enhanced {noformat} macro to original (no line numbers)

Issue #32 resolved
Graham Hannington created an issue

I very much like the additional features offered by this plugin.

However, I don't like the fact that you have to add hide-linenum to get the previous default behavior of the original {noformat} macro. The default behavior of the plugin changes the appearance of all existing JIRA descriptions and comments. I think that, by default, {noformat} should "do what it says on the label", whatever other features it might offer - thanks to your excellent plugin - if you choose to use them.

Feel free to mark as "won't do". I just wanted to express this opinion (via this "proposal" issue).

Comments (13)

  1. Jason Zaugg

    +1

    A lack of control over the defaults makes me unsure whether we'll be able to use this on issues.scala-lang.org. I'd like to disable line numbers by default, and to set a default language for {code}...{code} blocks.

  2. Brett Maton

    It would be very useful to have some control over the defaults. Like retronym, I'd very much like the default for line numbers to be off.

  3. Holger Schimanski repo owner

    Actually I don't understand your concerns of adding line numbers by default. Can yo give a practical example, where this is a problem? Just saying it changes previous behaviour doesn't help me to understand.

    Cheers, Holger

    P.S. Looking at retronyms code at https://github.com/retronym/syntaxplugin-public/compare/master...topic/scala-lang there is another feature request of being able to set the default language. Nice idea. :-) I have created a new issue #39.

  4. Holger Schimanski repo owner
    • changed status to open

    I started working on this issue.

    • I will not provide an admin page to config if linenumbers is default yes / true or no / false.
    • linenumbers default will be false similar to Confluence code macro and JIRA standard behaviour (no line numbers available)
    • Parameter hide-linenum parameter from version 1.x will be dropped and replaced by parameter linenumbers e.g. {code:java|linenumbers}...{code} or {code:java|linenumbers=true}...{code}
  5. Holger Schimanski repo owner

    Version 2.0.0-beta1 is now available for download here.

    It contains implementation for

    • syntax highlighting in emails
    • syntax highlighting in activity streams
    • has support for collapse parameter
    • switches to line numbers not being shown by default
    • layout is now similar to Confluence

    Sample with all features of JIRA Syntax Highlighter Plugin incl. line numbers, first line, highlight and title. (Only collapse is not shown here).

    {code:java|linenumbers|firstline=5|highlight=7,8-9|title=Example for HelloWorld.java}
    // Hello World in Java
    class HelloWorld {
      static public void main( String args[] ) {
        System.out.println( "Hello World!" );
      }
    }
    {code}
    

    This will be rendered as shown in the following screenshot. example-layout.png

    Please raise an issue here, if you find any problems or bugs.

    Currently brushes for Objectiv-C, TCL, Gherkin and D are missing, but will be delivered as part of 2.0.0-beta2 resp. the final release.

    Best regards, Holger

  6. Phillip Ponzer

    However, I don't like the fact that you have to add hide-linenum to get the previous default behavior of the original {noformat} macro.

    The original intent of this feature request was to make the noformat macro default to show no line numbers (not the code macro).

    Personally, I think most people are fine with having line numbers by default for code blocks. To me, noformat macros should have no line numbers by default while code blocks should.

  7. Chris H

    +1 on starryknight64's comments.

    I've got users complaining about line numbers in the noformat block, saying they're unnecessary, but I think line numbers in a code block would be fine.

    They also don't like that it displays all of the lines, not enclosing it in a fixed-size scrollable view. Some of the information they're adding to tickets is excessively long output, and makes the ticket itself very long and difficult to scroll through. This is the way that the noformat tag works with the default, as far as I remember. Could that be returned, or is there some way to get that functionality in the current version?

  8. Holger Schimanski repo owner

    Together with 2.0.0 there will a collapse parameter available. That will help with long code or noformat blocks.

  9. Log in to comment