2 new comment-like characters in Python to aid development?

Discussion in 'Python' started by dbhbarton@googlemail.com, Mar 9, 2007.

  1. Guest

    Had a thought that's grown on me. No idea if it's original or not- too
    inexperienced in programming- but I guess there's no harm floating it
    out there.

    Python wins big on readability, and there's no doubt that context-
    dependent text formatting in IDEs (keywords, strings, comments etc) is
    a massive help too, therefore benefitting development and maintenance.
    This idea is in a similar vein, especially for when scripts grow
    large.

    What if 2 new 'special' comment-like characters were added to Python?:


    1. The WIP (Work In Progress) comment:

    A '?' placed in the preceding whitespace of a line as a means of
    quickly highlighting a line or block of code for special attention.
    The interpreter simply ignores these characters, and executes the code
    as if each WIP character wasn't there. The value-added comes from how
    IDEs can exploit this to color the line or code block (in a
    customisable fashion as with other context-dependent IDE formatting).

    Thus...
    ?a=6 #This line gets highlighted.
    ?class MyClass: #This entire class gets highlighted.
    def __init__(self):
    self.val=3
    ?def MyFn(): #This entire function gets highlighted.
    return 'x'
    ?for each in range(9): #This entire block gets highlighted.
    print each

    Simply delete the ? and the associated highlighting vanishes
    immediately.
    Indeed if the interpreter can tolerate one '?' then perhaps it can
    also allow '??' and '???', letting the IDE color each differently for
    some additional flexibility.

    Applications...
    Lets you highlight / un-highlight entire blocks with a single
    keystroke: to record which part of a long script you're working on, or
    which part needs development or optimization. IDEs could add
    additional functionality if they chose: options to remove all wip
    comments, or step through them, or even to automatically add WIP
    comments (to highlight syntax errors, potentially infinite loops, or
    rate-limiting code blocks, perhaps?)


    2. The HALT comment:

    A '!' at the start of a line, indicating the end of the script proper.
    The interpreter would register this one, and ignore everything after
    it, a bit like a sys.exit() call but also stopping it from picking
    syntax errors after the HALT. IDEs could then 'grey out' (or 'yellow
    out' or whatever) all following characters, including later HALT
    comments.

    Applications...
    Lets you mask / unmask the tailing parts of a py script with a single
    keystroke: potentially quite useful during the writing / testing phase
    of coding when you might not want to run the whole thing, or as
    another means of adding extensive comments to the end of a file. Could
    also be rather handy in 'tutorial scripts' and the like...

    E.g...
    # Welcome to my Python Tutorial Script
    my_string="Hello World"
    print my_string
    ! # Everything after this '!' is ignored and greyed out for now, but
    when you're ready to move on to the next part of the tutorial script
    just delete the '!' and run it again.
    my_list=list(my_string)
    print my_list
    ! # <-- delete '!' when ready, etc etc
    my_list_reversed=my_list[::-1]
    print my_list_reversed


    As far as I can see, neither of these would break backwards
    compatibility and, like the @ decorator, if you don't like it, you
    wouldn't have to use it. I don't know enough about the guts of Python
    to say much about ease of implementation, but it doesn't seem like it
    would be too hard.

    Personally I'd use these a lot, but I'm a rank amateur so maybe I just
    don't develop code properly.
    That's it. Useful? Pointless? Dangerous? Stupid?


    Dave.
     
    , Mar 9, 2007
    #1
    1. Advertising

  2. En Fri, 09 Mar 2007 06:14:46 -0300, <> escribió:

    > A '?' placed in the preceding whitespace of a line as a means of
    > quickly highlighting a line or block of code for special attention.
    > The interpreter simply ignores these characters, and executes the code
    > as if each WIP character wasn't there. The value-added comes from how
    > IDEs can exploit this to color the line or code block (in a
    > customisable fashion as with other context-dependent IDE formatting).


    This could be implemented without new syntax: just make your editor
    recognize some special comments, and apply the highlighting to the
    following block. By example,

    # XXX Remove this when FuruFaifa is fixed to always provide
    # XXX the names in the same order
    names.sort()
    names.reverse()

    if names==oldnames:
    ...

    would highlight the first 4 lines (let's say, up to the next blank line or
    dedent).

    > 2. The HALT comment:
    >
    > A '!' at the start of a line, indicating the end of the script proper.
    > The interpreter would register this one, and ignore everything after
    > it, a bit like a sys.exit() call but also stopping it from picking
    > syntax errors after the HALT. IDEs could then 'grey out' (or 'yellow
    > out' or whatever) all following characters, including later HALT
    > comments.


    You accidentally type a ! somewhere, and your module stops working - not
    so good :( and worse, hard to find.

    I sometimes use '''this string marks''' to ignore whole blocks of code. It
    works fine unless the block already contains the same kind of
    triple-quoted string...

    > As far as I can see, neither of these would break backwards
    > compatibility and, like the @ decorator, if you don't like it, you
    > wouldn't have to use it. I don't know enough about the guts of Python
    > to say much about ease of implementation, but it doesn't seem like it
    > would be too hard.


    The main problem with new syntax is breaking compatibility with older
    versions, and I doubt it's worth the pain just for highlighting or playing
    interactively, so you don't have a great chance of them being
    implemented...

    --
    Gabriel Genellina
     
    Gabriel Genellina, Mar 9, 2007
    #2
    1. Advertising

  3. <> wrote:
    > What if 2 new 'special' comment-like characters were added to Python?:
    >
    >
    > 1. The WIP (Work In Progress) comment:


    I use # FIXME for this purpose or /* FIXME */ in C etc.

    I have an emacs macro which shows it up in bright red / yellow text so
    it is easy to see and the company has a system which makes a web page
    with a list of all the FIXMEs on.

    FIXME is easy to grep for, language neutral and a lot of people use
    something similar (eg XXX or TODO).

    > 2. The HALT comment:


    You can so this with triple quotes. ''' and ''' (if you normally use
    """ """ for docstrings)

    Python just ignores strings that lie around.

    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
     
    Nick Craig-Wood, Mar 9, 2007
    #3
  4. Guest

    Thanks for the thoughts.

    > This could be implemented without new syntax: just make your editor
    > recognize some special comments, and apply the highlighting to the
    > following block. By example,
    >
    > # XXX Remove this when FuruFaifa is fixed to always provide
    > # XXX the names in the same order
    > names.sort()
    > names.reverse()


    Yes I recognise that we can use existing comments for this purpose,
    and if I was suitably gifted I guess I could try to make the IDE
    recognise these 'special comments', and maybe even work out what block
    they're meant to apply to. Of course I'll still argue that the WIP
    character would be a more elegant, speedy and versatile alternative.


    > You accidentally type a ! somewhere, and your module stops working - not
    > so good :( and worse, hard to find.


    By my reckoning it would be very very easy to find. Even if the IDE
    wasn't greying out everything after it. And how often do you
    accidentally mistype a ! at the beginning of a line?


    > I sometimes use '''this string marks''' to ignore whole blocks of code. It
    > works fine unless the block already contains the same kind of
    > triple-quoted string...


    Indeed. Moreover those quotes have to be in pairs, so it's not exactly
    a quick and dandy way of doing what I'd like.


    > The main problem with new syntax is breaking compatibility with older
    > versions...


    Agreed. But both characters are currently disallowed in the positions
    concerned, and in the proposal they're optional extras. This can't
    stop old scripts from working, it can only stop new scripts from
    working on old installations- just like any new feature.

    >, and I doubt it's worth the pain just for highlighting or playing
    > interactively


    Ah well there's the issue!

    >, so you don't have a great chance of them being
    > implemented...


    Obviously I like the idea, but I never hold out much hope that people
    will agree with me!
     
    , Mar 9, 2007
    #4
  5. Nick Craig-Wood a écrit :
    > <> wrote:
    >> What if 2 new 'special' comment-like characters were added to Python?:
    >>
    >>
    >> 1. The WIP (Work In Progress) comment:

    >
    > I use # FIXME for this purpose or /* FIXME */ in C etc.
    >
    > I have an emacs macro which shows it up in bright red / yellow text so
    > it is easy to see


    <ot>
    Care to share this macro ?
    </ot>
     
    Bruno Desthuilliers, Mar 9, 2007
    #5
  6. wrote:

    > Of course I'll still argue that the WIP character would be a more
    > elegant, speedy and versatile alternative.


    I don't think so. Those characters have no syntactical meaning and
    would, IMHO, make the language "dirty".

    Regards,


    Björn

    --
    BOFH excuse #73:

    Daemons did it
     
    Bjoern Schliessmann, Mar 9, 2007
    #6
  7. On 9 Mar 2007 02:31:14 -0800,
    <> wrote:
    > Thanks for the thoughts.
    >
    > > This could be implemented without new syntax: just make your editor
    > > recognize some special comments, and apply the highlighting to the
    > > following block. By example,
    > >
    > > # XXX Remove this when FuruFaifa is fixed to always provide
    > > # XXX the names in the same order
    > > names.sort()
    > > names.reverse()

    >
    > Yes I recognise that we can use existing comments for this purpose,
    > and if I was suitably gifted I guess I could try to make the IDE
    > recognise these 'special comments', and maybe even work out what block
    > they're meant to apply to. Of course I'll still argue that the WIP
    > character would be a more elegant, speedy and versatile alternative.


    But you are overloading the ? character for a purpose which it totally
    was not meant for. What the character means really depends on what
    person you are asking. To me, it means that what precedes it is
    something someone or something does not know and wants to know the
    answer to. To me, it really does not mean that what follows it is work
    in progress.

    Even if I could intuitively tell that a question mark represents a
    work in progress, that information is not very useful. Similarly to
    the "under construction" animated gifs that were popular on the web in
    the mid 90-ties, the symbol does not convey any useful information.
    WHY is it a work in progress? Is there something wrong with it?

    ?def foobar():
    do stuff

    The question mark does not leave me any the wiser. Now if you replace
    that question mark with a comment:

    # foobar() is buggy because it throws weird exceptions when x = 42.
    def foobar():
    do stuff

    That gives me some useful information.

    --
    mvh Björn
     
    =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=, Mar 9, 2007
    #7
  8. Guest

    >Those characters have no syntactical meaning...

    ?
    Neither does # until you give it syntactical meaning. I must be
    missing what you mean.

    > would, IMHO, make the language "dirty".


    Well I'm not a big fan of decorators so I know how you must feel. But
    # FIXME + a hack doesn't seem clean to me. And commenting off the
    bottom half of a long script with triple quotes is ugly and a pain and
    you can't indicate multiple alternate halt points as in the 'tutorial
    script' example I gave.
     
    , Mar 9, 2007
    #8
  9. >
    > Well I'm not a big fan of decorators so I know how you must feel. But
    > # FIXME + a hack doesn't seem clean to me. And commenting off the
    > bottom half of a long script with triple quotes is ugly and a pain and
    > you can't indicate multiple alternate halt points as in the 'tutorial
    > script' example I gave.


    It's not a hack. Without an IDE, there won't be support for that anyway -
    after all, you're about to highlight blocks and the like, how is that
    supposed to work?

    And besides that - you might not _like_ decorators, but they do have a
    semantic. Just inserting "random" characters into the source code that one
    has to overread doesn't make any sense, it just clutters the code.

    With an proper IDE, you could make that tagging of yours bound to a simple
    keystroke, and the IDE could store the tagging information separately. E.g.
    eric3 offers some bookmark features, I presume something like your proposal
    would be possible, too.


    Diez
     
    Diez B. Roggisch, Mar 9, 2007
    #9
  10. Guest

    On Mar 9, 10:59 am, "BJörn Lindqvist" <> wrote:
    > On 9 Mar 2007 02:31:14 -0800,
    >
    >
    >
    >
    >
    > <> wrote:
    > > Thanks for the thoughts.

    >
    > > > This could be implemented without new syntax: just make your editor
    > > > recognize some special comments, and apply the highlighting to the
    > > > following block. By example,

    >
    > > > # XXX Remove this when FuruFaifa is fixed to always provide
    > > > # XXX the names in the same order
    > > > names.sort()
    > > > names.reverse()

    >
    > > Yes I recognise that we can use existing comments for this purpose,
    > > and if I was suitably gifted I guess I could try to make the IDE
    > > recognise these 'special comments', and maybe even work out what block
    > > they're meant to apply to. Of course I'll still argue that the WIP
    > > character would be a more elegant, speedy and versatile alternative.

    >
    > But you are overloading the ? character for a purpose which it totally
    > was not meant for. What the character means really depends on what
    > person you are asking. To me, it means that what precedes it is
    > something someone or something does not know and wants to know the
    > answer to. To me, it really does not mean that what follows it is work
    > in progress.
    >
    > Even if I could intuitively tell that a question mark represents a
    > work in progress, that information is not very useful. Similarly to
    > the "under construction" animated gifs that were popular on the web in
    > the mid 90-ties, the symbol does not convey any useful information.
    > WHY is it a work in progress? Is there something wrong with it?
    >
    > ?def foobar():
    > do stuff
    >
    > The question mark does not leave me any the wiser. Now if you replace
    > that question mark with a comment:
    >
    > # foobar() is buggy because it throws weird exceptions when x = 42.
    > def foobar():
    > do stuff
    >
    > That gives me some useful information.
    >
    > --
    > mvh Björn- Hide quoted text -
    >
    > - Show quoted text -


    perhaps another character would be preferable. '~' perhaps. As to what
    you use the WIP character for- in my mind the purpose is to allow an
    extra type/level of commenting over and above #, which is inherently
    flexible. I could for example choose to use ? (or ~) for blocks I'm
    still writing, ?? (or ~~) for blocks that are buggy, and ??? (or ~~~)
    for blocks that work but could use optimization. It's a commenting
    shortcut for me as the script's developer and its advantage over #
    comments are speed or insertion/removal.
    Ah but I can see I'm not winning anybody over. I shall graciously
    retire!
     
    , Mar 9, 2007
    #10
  11. On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:

    >
    > Nick Craig-Wood a écrit :
    >> <> wrote:
    >>> What if 2 new 'special' comment-like characters were added to
    >>> Python?:
    >>>
    >>>
    >>> 1. The WIP (Work In Progress) comment:

    >>
    >> I use # FIXME for this purpose or /* FIXME */ in C etc.
    >>
    >> I have an emacs macro which shows it up in bright red / yellow text
    >> so it is easy to see

    >
    > <ot>
    > Care to share this macro ?
    > </ot>


    I have this

    (cond (window-system
    (progn
    (font-lock-add-keywords
    'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))

    Robert
    --
    La grenouille songe..dans son château d'eau
    Links and things http://rmstar.blogspot.com/
     
    Robert Marshall, Mar 9, 2007
    #11
  12. wrote:
    >> Those characters have no syntactical meaning...

    >
    > ?
    > Neither does # until you give it syntactical meaning. I must be
    > missing what you mean.


    Yes, it has. It says "disregard the following characters until EOL".
    If you remove it, the following code will be interpreted as ...
    code (and not be disregarded).

    A "WIP character" would only be there for tagging and wouldn't
    change the program logic. Thus, IMHO, it's useless as a part of the
    Python language. Highlighting and tagging is task of editors/IDEs.

    >> would, IMHO, make the language "dirty".

    >
    > Well I'm not a big fan of decorators so I know how you must feel.


    Mh, not sure -- why do you have decorators in mind? I don't dislike
    them.

    > But # FIXME + a hack doesn't seem clean to me.


    I think it's much cleaner to have language and "fixme" levels
    separate. "fixme" features can then depend fully on the editor/IDE
    and don't have to be part of the source code (though they may).

    > And commenting off the bottom half of a long script with triple
    > quotes is ugly and a pain and you can't indicate multiple
    > alternate halt points as in the 'tutorial script' example I gave.


    A proper editor can comment out multiple lines easily.

    A smart script can have multiple halt points user-selectable, though
    this is a big matter of taste. I think that in this case some kind
    of learning environment is better.

    Regards,


    Björn

    --
    BOFH excuse #23:

    improperly oriented keyboard
     
    Bjoern Schliessmann, Mar 9, 2007
    #12
  13. Robert Marshall <> wrote:
    > On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:
    >
    > >
    > > Nick Craig-Wood a ?crit :
    > >> <> wrote:
    > >>> What if 2 new 'special' comment-like characters were added to
    > >>> Python?:
    > >>>
    > >>>
    > >>> 1. The WIP (Work In Progress) comment:
    > >>
    > >> I use # FIXME for this purpose or /* FIXME */ in C etc.
    > >>
    > >> I have an emacs macro which shows it up in bright red / yellow text
    > >> so it is easy to see

    > >
    > > <ot>
    > > Care to share this macro ?
    > > </ot>

    >
    > I have this
    >
    > (cond (window-system
    > (progn
    > (font-lock-add-keywords
    > 'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))


    This is what I use which is very similar

    (font-lock-add-keywords 'python-mode
    '(
    ("\\<\\(FIXME\\):?" 1 font-lock-warning-face prepend)
    )
    )

    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
     
    Nick Craig-Wood, Mar 9, 2007
    #13
  14. Guest

    > Yes, it has. It says "disregard the following characters until EOL".
    > If you remove it, the following code will be interpreted as ...
    > code (and not be disregarded).


    and ! would say "disregard the following characters until End Of
    Program". Is it really so different?


    > > Well I'm not a big fan of decorators so I know how you must feel.

    >
    > Mh, not sure -- why do you have decorators in mind? I don't dislike
    > them.


    Just because I remember reading similar aesthetic arguments against
    the @ syntax- that it looked alien, messy, unpythonic and obfuscating.
    I certainly agree with the latter point even if I find the former ones
    a little hand-wavey for my tastes.


    > I think it's much cleaner to have language and "fixme" levels
    > separate. "fixme" features can then depend fully on the editor/IDE
    > and don't have to be part of the source code (though they may).


    That's certainly a solid ideological argument against the "WIP
    character". Maybe I should just change my editor!

    It sounds like other Python users *do* like to do the kind of things I
    suggested, but seasoned users would rather rely on macros and features
    of specific editors. Unfortunately, to a newbie like myself, these
    seem like obscure 'tricks' to be mastered rather than simple built-in
    conveniences that any newbie can profit from.

    I suppose my ideology is that Python's greatest strength is (and focus
    should be) its visual simplicity and ease of learning, making
    programming more accessible to the masses. But hey I'm just a fresh-
    faced conscript. I guess I've got to leave the battle planning to the
    five-star generals on the hill!

    Thanks for all the comments and the spirit of tolerance.

    dave
     
    , Mar 9, 2007
    #14
  15. > It sounds like other Python users *do* like to do the kind of things I
    > suggested, but seasoned users would rather rely on macros and features
    > of specific editors. Unfortunately, to a newbie like myself, these
    > seem like obscure 'tricks' to be mastered rather than simple built-in
    > conveniences that any newbie can profit from.


    But you _can't_ profit from these conveniences, at least not the ?
    character. It's just garbage put in there for some others to interpret,
    meaningless to the interpreter. So it _always_ boils down to
    editor-support.

    Now obviously _one_ scheme supported by all editors would be a great thing -
    so one could argue that a well-defined PEP that suggests a certain comment
    style that allows for your desired functionality would be a good thing.

    Diez
     
    Diez B. Roggisch, Mar 9, 2007
    #15
  16. Guest

    On 9 Mar, 14:05, "Diez B. Roggisch" <> wrote:
    > But you _can't_ profit from these conveniences, at least not the ?
    > character. It's just garbage put in there for some others to interpret,
    > meaningless to the interpreter. So it _always_ boils down to
    > editor-support.


    I'm sorry I don't follow your logic. Meaningless to the interpreter,
    yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
    conveniences"? Why ever not?
     
    , Mar 9, 2007
    #16
  17. wrote:

    > On 9 Mar, 14:05, "Diez B. Roggisch" <> wrote:
    >> But you _can't_ profit from these conveniences, at least not the ?
    >> character. It's just garbage put in there for some others to interpret,
    >> meaningless to the interpreter. So it _always_ boils down to
    >> editor-support.

    >
    > I'm sorry I don't follow your logic. Meaningless to the interpreter,
    > yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
    > conveniences"? Why ever not?


    Exactly, the ? is meaningless to the language itself, it's only a comment
    sign - but what you want is

    """
    1. The WIP (Work In Progress) comment:

    A '?' placed in the preceding whitespace of a line as a means of
    quickly highlighting a line or block of code for special attention.
    """

    Now tell me - how exactly do you highlight a text? That is solely part of
    the editor you use, either it will parse the ? - the same way it would
    parse a # fixme or # wip comment - and react accordingly, or it won't.

    But for python itself, it has no meaning whatsoever, and would just be a
    character to overread, introducing visual clutter.

    So - if you want that feature, patch your editor of choice to deal with that
    comments, make them added and removed with a key stroke, whatever - be my
    guest. But it has nothing to do with _python_ the language, so it doesn't
    belong there.

    Besides, I don't see how "quick highlighting of text" is something that
    needs to be persisted anyway - if it is quick, hightlight it within the
    editor until the file is closed. If not, it might be well worth a comment
    anyway why you think it needs special attention.

    Diez
     
    Diez B. Roggisch, Mar 9, 2007
    #17
  18. Guest

    > > I'm sorry I don't follow your logic. Meaningless to the interpreter,
    > > yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
    > > conveniences"? Why ever not?

    >
    > Exactly, the ? is meaningless to the language itself, it's only a comment
    > sign - ...
    > ... it has nothing to do with _python_ the language, so it doesn't
    > belong there.


    But # is 'only a comment sign' as well, and equally meaningless to the
    interpreter. But it's still part of the language, very very useful and
    I profit from its existence every day.


    > But for python itself, it has no meaning whatsoever, and would just be a
    > character to overread, introducing visual clutter.


    If you can highlight an entire block with a single character, won't
    there be _less_ visual clutter than the current way of achieving the
    same effect with # comments?


    > So - if you want that feature, patch your editor of choice to deal with that
    > comments, make them added and removed with a key stroke, whatever - be my
    > guest.


    Would if I could!

    > Besides, I don't see how "quick highlighting of text" is something that
    > needs to be persisted anyway - if it is quick, hightlight it within the
    > editor until the file is closed. If not, it might be well worth a comment
    > anyway why you think it needs special attention.


    What we're talking about here is a form of 'alternate commenting
    style'. With the IDE's cooperation it'd work on whole blocks at once,
    it would highlight without disrupting the code concerned (at least the
    way I'm envisaging it), it would be versatile (could probably be used
    for as big a variety of purposes as the # comment), and yes, it'd be
    persistent, which is how it would be different from any IDE-based
    highlighting.

    I think that'd be most useful. You don't. So far nobody else here does
    either, and I've not persuaded anybody differently. Fair enough!

    dave
     
    , Mar 9, 2007
    #18
  19. wrote:

    >> > I'm sorry I don't follow your logic. Meaningless to the interpreter,
    >> > yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
    >> > conveniences"? Why ever not?

    >>
    >> Exactly, the ? is meaningless to the language itself, it's only a comment
    >> sign - ...
    >> ... it has nothing to do with _python_ the language, so it doesn't
    >> belong there.

    >
    > But # is 'only a comment sign' as well, and equally meaningless to the
    > interpreter. But it's still part of the language, very very useful and
    > I profit from its existence every day.


    A language has to have a comment mechanism, some even several.

    But all of them are clear on how they work: they affect one line, or have a
    bracket style like /* */ and thus demark clearly what they affect. Even
    someone not fluent in the language in question will quickly grab what they
    mean.

    But the key-difference is that the comment in python has a meaning for the
    interpreter - ignore this.

    The ? has no meaning. It only has a meaning for an editor.

    >> But for python itself, it has no meaning whatsoever, and would just be a
    >> character to overread, introducing visual clutter.

    >
    > If you can highlight an entire block with a single character, won't
    > there be _less_ visual clutter than the current way of achieving the
    > same effect with # comments?


    Not in my opinion -

    # fixme
    def foo():
    pass

    is much more clear than a rather obscure and by the occasional beholder
    maybe misinterpreted

    ?def foo():
    pass

    > Would if I could!


    Well, grab eric3, it's written in python, and teach it to do so! It's an
    exercise in python then :)

    It already has some features like bookmarks, shouldn't be too hard to build
    upon that.

    > What we're talking about here is a form of 'alternate commenting
    > style'. With the IDE's cooperation it'd work on whole blocks at once,
    > it would highlight without disrupting the code concerned (at least the
    > way I'm envisaging it), it would be versatile (could probably be used
    > for as big a variety of purposes as the # comment), and yes, it'd be
    > persistent, which is how it would be different from any IDE-based
    > highlighting.


    I think you contradict yourself here. On the one side, you want it not
    disturbing to the eye, yet it should be highlighted, so it will be directly
    noticed by that same eyes.

    This is why I believe that your idea by itself - the visually marking of
    code parts - is a good thing, but the embedding into code is not, because
    it _is_ an disturbance. And with an IDE that stores such information in
    e.g. project metainformation, you can even have the persistence, without
    the disturbance and without altering python.

    Diez
     
    Diez B. Roggisch, Mar 9, 2007
    #19
  20. Nick Craig-Wood a écrit :
    > Robert Marshall <> wrote:
    >> On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:
    >>
    >>> Nick Craig-Wood a ?crit :
    >>>> <> wrote:
    >>>>> What if 2 new 'special' comment-like characters were added to
    >>>>> Python?:
    >>>>>
    >>>>>
    >>>>> 1. The WIP (Work In Progress) comment:
    >>>> I use # FIXME for this purpose or /* FIXME */ in C etc.
    >>>>
    >>>> I have an emacs macro which shows it up in bright red / yellow text
    >>>> so it is easy to see
    >>> <ot>
    >>> Care to share this macro ?
    >>> </ot>

    >> I have this
    >>
    >> (cond (window-system
    >> (progn
    >> (font-lock-add-keywords
    >> 'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))

    >
    > This is what I use which is very similar
    >
    > (font-lock-add-keywords 'python-mode
    > '(
    > ("\\<\\(FIXME\\):?" 1 font-lock-warning-face prepend)
    > )
    > )
    >


    Thanks you both.
     
    Bruno Desthuilliers, Mar 9, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Attenborough
    Replies:
    22
    Views:
    2,302
    Mike Treseler
    Mar 13, 2006
  2. Alec S.
    Replies:
    10
    Views:
    10,262
    Alec S.
    Apr 16, 2005
  3. Alex Hunsley
    Replies:
    2
    Views:
    388
    Steve Holden
    Jun 4, 2004
  4. William Gill
    Replies:
    10
    Views:
    579
    Florian Diesch
    Sep 1, 2005
  5. [Jongware]

    xml:aid table to HTML

    [Jongware], Jul 9, 2007, in forum: XML
    Replies:
    6
    Views:
    709
    Pavel Lepin
    Jul 17, 2007
Loading...

Share This Page