Nedit skill highlight revisited

Discussion in 'Cadence' started by Svenn Are Bjerkem, Apr 6, 2005.

  1. Hi,
    I downloaded the skill highlight pats from www.nedit.org. This file has a
    major flaw, it doesn't add syntax highlight because of one missing command
    line that tells nedit about the highlight.

    Here is a working version. You may need to fix some newlines because the
    original is not limited to 75 characters per line.

    ! Syntax Highlighting Patterns for SKILL-Code (script-language of the
    Cadence
    ! Design System).
    !
    ! These are written for the "c" type syntax vs the lisp syntax. In these
    ! patterns a procedure call, "function(" will be highlighted differently
    from
    ! a variable + paren, "function (" so you can tell if you have a white
    space
    ! error.
    !
    ! Contributed by Andrew Stanaski
    !
    ! In NEdit Version 5.0.1 and beyond, load this pattern by starting nedit
    with:
    !
    ! nedit -import <name of this file>
    !
    ! Then, check that the patterns were loaded correctly, and choose Save
    Defaults
    ! from the Preferences menu. The new patterns will now be incorporated into
    ! your own .nedit file, so the next time you start NEdit, you will no longer
    ! need to use -import.
    !
    ! In version 5.0, without -import, you must edit your .nedit file by hand
    and
    ! add the contents of each resource below to the corresponding list in your
    ! .nedit file. Be sure to separate new entries with \n, and continue
    resource
    ! strings by escaping all newlines within a resource value with \
    (backslash),
    ! leaving only the last line of the resource value not ending in \.
    !
    nedit.highlightPatterns:\
    Skill:1:0{\n\
    comment:"/\\*":"\\*/"::Comment::\n\
    skill comment:";":"$"::Comment::\n\
    string:"""":"""":"\\n":String::\n\
    string escape chars:"\\\\(.|\\n)":::String:string:\n\
    numeric constant:"<((0(x|X)[0-9a-fA-F]*)|(([0-9]+\\.?[0-9]*)|(\\
    [0-9]+))((e|E)(\\+|-)?[0-9]+)?)(L|l|UL|ul|u|U|F|f)?>":::preprocessor::D\n\
    procedure calls:"<(procedure|return)\\(":::plain::D\n\
    procedure color:"\\1":""::Storage Type:procedure calls:DC\n\
    control calls:"<(if|when|unless|cond|case|caseq|while|for
    foreach)\\(":::plain::D\n\
    control color:"\\1":""::Subroutine:control calls:DC\n\
    control then else:"<(then|else)>":::Subroutine::D\n\
    function calls:"<([a-zA-Z][a-zA-Z0-9_?]*)\\(":::plain::D\n\
    function color:"\\1":""::Identifier1:function calls:DC\n\
    braces:"[{}]":::Comment::D\n\
    }
    nedit.languageModes: Skill:.il .tf::::::\n\
     
    Svenn Are Bjerkem, Apr 6, 2005
    #1
  2. Svenn Are Bjerkem

    Collin Weiss Guest

    Thanks!
     
    Collin Weiss, Apr 6, 2005
    #2
  3. Well, personally I use vi, and since I write in LISP syntax, I use vi's lisp
    mode :)set lisp ai) which does all the indentation for you. I did write my own
    pp version a while ago which pp's using the same indentation rules as vi does.

    The trouble with pp is that you lose the comments, so it's not a particularly
    good approach.

    If I write in C syntax, I use vi's autoindent mode too, with a shiftwidth of
    4, to indent in 4 space chunks. I then use ^T and ^D in input mode to
    indent or back out of an indent. In non-input mode, I use the < and >
    commands to adjust indentation of existing code.

    I do have a number of macros that I use in vi (others use them in nedit) to do
    commenting neatly (for example, I have a program which allows me to put very
    flexible boxes around text).

    That said, I've never written a SKILL beautifier, which is probably what
    you're after.

    Most decent editors have functions to allow you to adjust indent levels
    easily, so it's mainly a matter of discipline when you write the code. I
    always think you should write your code beautifully in the first place, since
    the layout of the code helps you understand it better as you're writing it.
    Trying to fix it up automatically afterwards is never going to be as
    effective.

    It's much the same reason why you should comment as you go along - otherwise
    you'll never go back and do it. Often commenting makes you think more
    carefully about the code, and more likely to identify bugs early.

    Two of my former colleagues, Ian Dobinson and James Kenney, wrote a style
    checker, along the lines of SKILL Lint (which they were also involved in),
    which allowed you to define a set of style rules, and then check that you'd
    adhered to them. Quite neat!

    Regards,

    Andrew.
     
    Andrew Beckett, Apr 7, 2005
    #3
  4. Did you cut and paste from the article, or did you get it from
    www.nedit.org? If you got it from the article, you may need to check the
    newlines. If you got it from the web, you only need to add the line:

    nedit.highlightPatterns:\

    before the

    Skill:1:0{\n\

    line. I assume you have nedit version > 5.0
     
    Svenn Are Bjerkem, Apr 8, 2005
    #4
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.