Tricks in doing this well:

- Should be able to select it and *uncomment* it again
- Should be able to comment out things that have comments inside already -- this will result in nested comments, which will generally have to be escaped somehow (language-specific)

Maybe it's useful to list some cases and expected behavior. For example, I would expect the following to happen:

1. Something /* commented inside */ rest of line
                ^--------------^ [uncomment]
=> Something commented inside rest of line
             ^--------------^

2. Something /* commented inside */ rest of line
                          ^----^ [uncomment]
=> Something /* commented */inside rest of line
                            ^----^

3. Something /* commented */inside rest of line
                     ^-----------^ [comment]
=> Something /* commented inside*/ rest of line
                     ^---------^

^--^ indicates a selection, action is within [brackets], result follows after => (including new selection)

Created attachment 266251 [details] [review]
Removing the nested comment is pending

Another case:

4. Something /* commented inside */rest of line
   ^-------------------------------------^ [comment]
=> /*Something  commented inside rest of/* line

Even another case: Nothing selected, but the cursor position inside a commented area.

5. Something /* commented inside */rest of line
                    ^  [uncomment]
=> Something commented inside rest of line

Mass-closing of all gedit-plugins bugzilla tickets.

Special "code" to find again all those gedit-plugins bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.