#7704: JS comments put after statements break make-messages.py output
-------------------------------------+-------------------------------------
               Reporter:  robbyd     |        Owner:  nedbatchelder
                   Type:  Bug        |       Status:  assigned
              Milestone:             |    Component:  Core (Management
                Version:  1.0        |  commands)
             Resolution:             |     Severity:  Normal
           Triage Stage:  Accepted   |     Keywords:  djangojs, make-
    Needs documentation:  0          |  messages
Patch needs improvement:  0          |    Has patch:  0
                                     |  Needs tests:  0
-------------------------------------+-------------------------------------

Old description:

> {{{
> #!rst
>
> To test, make a JS file (say ``myfile.js``) with the following valid JS
> content:
>
> .. code-block:: javascript
>
>     var a = 1;
>     if(a != 2 && a != 5) //this comment breaks the file
>     {
>         //this does not
>         alert(gettext("foobar"));
>     }
>
> Running ``make-messages.py -d djangojs -a`` will then yield the following
> output for that (in the ``myfile.js.py`` intermediate file it produces):
>
> .. code-block:: javascript
>
>     var a = 1;
>     if(a != 2 && a != 5) //this comment breaks the file
>     {
>     #this does not
>         alert(gettext("foobar"));
>     }
>

> As you can see, the comment after the if statement was not replaced, and
> since ``xgettext`` is then run in Perl mode, it seems to choke on that
> input.
> The result depends on the exact code: This example will cause only that
> next ``gettext("foobar")`` not to be generated (ones further down in the
> code will).
> With other code I had that had a similar line, nothing was generated. The
> failure is silent and the only way to know is by checking the gettext
> output (or lack thereof :).
>
> This is due to the regexp in make-messages: ``pythonize_re =
> re.compile(r'\n\s*//')``
> and then the replacement code: ``src = pythonize_re.sub('\n#', src)``
>
> That assumes that comments come after newlines. I'm not submitting a
> patch right now because I'm unsure about the best regexp to use for this
> that will get all the valid JS comment cases (or if that is even
> something the django devs want to do). At the very least, if you all
> choose not to address this in the code, there should be a note in the
> documentation telling folks to always put JS comments on their own lines.
>
> As ``make-messages.py`` is now included in django-admin AFAIK, I've
> categorized it to that.
>
> }}}

New description:

 {{{
 #!rst

 To test, make a JS file (say ``myfile.js``) with the following valid JS
 content:

 .. code-block:: js

     var a = 1;
     if(a != 2 && a != 5) //this comment breaks the file
     {
         //this does not
         alert(gettext("foobar"));
     }

 Running ``make-messages.py -d djangojs -a`` will then yield the following
 output for that (in the ``myfile.js.py`` intermediate file it produces):

 .. code-block:: js

     var a = 1;
     if(a != 2 && a != 5) //this comment breaks the file
     {
     #this does not
         alert(gettext("foobar"));
     }


 As you can see, the comment after the if statement was not replaced, and
 since ``xgettext`` is then run in Perl mode, it seems to choke on that
 input.
 The result depends on the exact code: This example will cause only that
 next ``gettext("foobar")`` not to be generated (ones further down in the
 code will).
 With other code I had that had a similar line, nothing was generated. The
 failure is silent and the only way to know is by checking the gettext
 output (or lack thereof :).

 This is due to the regexp in make-messages: ``pythonize_re =
 re.compile(r'\n\s*//')``
 and then the replacement code: ``src = pythonize_re.sub('\n#', src)``

 That assumes that comments come after newlines. I'm not submitting a patch
 right now because I'm unsure about the best regexp to use for this that
 will get all the valid JS comment cases (or if that is even something the
 django devs want to do). At the very least, if you all choose not to
 address this in the code, there should be a note in the documentation
 telling folks to always put JS comments on their own lines.

 As ``make-messages.py`` is now included in django-admin AFAIK, I've
 categorized it to that.

 }}}

--

Comment (by lrekucki):

 Fixed formating in description :)

-- 
Ticket URL: <http://code.djangoproject.com/ticket/7704#comment:10>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to