Uncommenting does not work on any Linux distro with Gnome 3+

General
1

This is a long running issue, even before 8.5. I reported it (not here) maybe 2 or so years ago, when I switched to latest Fedora that came with Gnome 3. At that time both comment/uncomment did not work. By the way, both worked on ubuntu (at that time).

Version 8.5 fixed the commenting, but not uncommenting. Just to make sure, I tried earlier this year latest: Ubuntu, Manjaro, and Fedora. All with Gnome, and on all; uncommenting does not work.

That made me switch to Mint (with Cinnamon instead of Gnome) and there both comment/uncomment work. Last few month I was occupied with one (3000 lines) GUI program development, so ability to uncomment was important to me, but I would still like to be able to go back to Gnome.

Just to be sure, I installed today Ubuntu 22.04 (64) on my daughters rpi4B (with Gnome) and result is the same, uncommenting does not work.
When I switch rpi4 (just change the micro SD card) to older Raspberry OS 32 (with older version of Gnome, not using Wayland), everything works.

1 Like
2

I can reproduce this on my machine; I will open a bug.

3

I filed "Uncomment" menu item fails on Linux/Wayland/GTK3 · Issue #587 · racket/drracket · GitHub about this.

4

Here I go again. :laughing:
The Comment/Uncomment has obviously been fixed since my last post, but still, not all works as it should!
Again, I'm talking about DrRacket running on Mint Linux (Cinnamon, which is gnome anyway).

The comment and Uncomment work both as ";", and as Box.
";" works absolutely well, but Box does not!

That is, one can comment out with a box, and then Uncomment the box, and this is when strange behavior starts. The gray, parentheses matching highlight, stops working, which is very annoying, because I depend on that when I'm editing the file.
The only remedy I found for this it to quit the DrRacket and then reopen it again, and never touch the Box Commenting again.
Honestly, this is OK with me because I'm an old guy, used to Lisp/Scheme style comments anyway, but still, if it's there, it should work.

5

Sorry for the slow response: I just gave this a try in the git version and cannot make the bad behavior happen.

Can you share a screen recording, starting from a fresh DrRacket, to show the problem? Or maybe just a set of precise instructions to make it happen, starting from a fresh DrRacket? It may be the case that the problem only happens sometimes which might make this hard. If so, that's okay and we'll just be on the lookout for the problem.

Also, i suppose that closing the window that's having the problems and opening a new one will reset the internal state that's gone wrong without having to close the entire DrRacket. (Probably ... :slightly_smiling_face:)

6

I just opened one small .rkt file with two procedure definitions in it, and then executed exactly the following steps:

  1. I marked with a mouse one of definitions, and then clicked on "Comment out with a box".

  2. Then I tried gray shading of the other definition, and it works normally.

  3. Then I clicked with the mouse at the beginning of box comment, and it shaded gray the definition inside the box.

  4. Then I clicked on "Uncomment" menu, and it removed the box.

  5. Immediately after, the gray shading disappears, but this is a surprise to me now, after a few seconds it starts working again. I noticed this now without taking any action (I was writing this text here).

Okay, this is new, did not notice this before, so I tried with a much larger rkt file (200k), and the same thing happened again. But I noticed another (similar strange behavior). As soon as you uncomment, it will not gray highlight the parentheses, and as long as you are trying, and clicking all around the file, to see what's going on, it will not highlight expressions. However, if you just let it be, the highlighting will come back! ???

Hmm, now it's getting more complicated. It looks like the highlighting gets restored after you shift focus to another window. As long as focus remains in racket window, it will not work, but as soon the focus is shifted to something else, like this email, the highlighting returns. This, I did not notice before. I was just clicking inside racket window, and this will not help.
Yes, tested now thoroughly. I shifted my mouse policy back to "click" (which I had when I first noticed this, but did not report it then). Later I changed the policy to sloppy, and this is how tests were done in the upper part of this mail. But now with click policy, gray highlighting will not come back unless I click on another window outside of the racket window. Then the highlighting returns right away.

Also, I did not notice this before. To lose highlighting is even easier than I described above. It is enough to comment a definition out with a box, and then click inside the box. You get the highlighting there, but it is lost outside the box right away. Click on another window restores it. And you can repeat this as many times as you want, with the same box comment.

A bit more about the computer this is reported from. It is Intel I5(10gen), and I'm running Linux Mint with Cinnamon. In my post I said that it is Gnome, but I checked later. It is forked from Gnome3, but it is not using Wayland. So all of this maybe does not happen on Ubuntu or Fedora, which are running gnome with Wayland.

Uhhh... This turned out to be too long, sorry for that.

1 Like
7

Oog. I'm slow, and I lost track. It seems like you put together a bunch of steps (1-5) but then you made several changes and the problem changed somewhat? Is that right? Would you consider re-doing your list of steps to reproduce? It may be that Robby can assemble a useful sequence from this, but it seems pretty fuzzy to me.

8

I was able to reproduce the bug thanks to the fuller description, indeed. Thanks @hrvoje064 !

I also narrowed it down to what seems like something going wrong in wxme. Here's the program:

#lang racket
(require racket/gui/base)
(define t%
  (class text%
    (define/override (on-focus on?)
      (printf "on-focus ~s ~s\n" on? (send this get-text))
      (super on-focus on?))
    (super-new)))

(define t-inner (new t%))
(send t-inner insert "inner")
(define t-outer (new t%))
(send t-outer insert (new editor-snip% [editor t-inner]))
(send t-outer insert "outer")

(define f (new frame% [label ""] [width 200] [height 200]))
(define ec (new editor-canvas% [parent f] [editor t-outer]))
(define b (new button% [parent f] [label "delete editor snip"] [callback (λ (x y) (send t-outer delete 0 1))]))
(send f show #t)

Here's how to reproduce:

  1. run
  2. click to set the focus on the inner (see the corresponding printfs, showing focus moving into inner).
  3. click the button
  4. expect to see the focus move back to outer, but only see it leave inner and then no other printf
9

This seems to fix the problem. I'm not sure if it is the right change to make, however.

10

Yes, very fuzzy. That's just because I was discovering new behavior as I was writing the test. What complicated the matter is that I changed focus policy of Cinnamon few months ago from CLICK to SLOPPY, and this seems to affect the test.
Anyway, it looks like my explanation was understood, so no need to repeat.