racket / drracket

DrRacket, IDE for Racket
http://www.racket-lang.org/
Other
448 stars 95 forks source link

Error status bar stays open when no error #379

Closed massung closed 2 years ago

massung commented 4 years ago

Just an annoyance, but when the error being reported in the status bar is resolved, it'd be great it the status bar would close itself.

rfindler commented 4 years ago

It doesn't do that because the window would bounce a lot. But maybe there is a way to make it disappear after a short time to make it bounce very infrequently or something?

massung commented 4 years ago

I don't know about the other platforms, but on Windows closing the error status bar doesn't resize the window or anything, it just makes it disappear. Perhaps the bouncing was something that used to happen and doesn't any more?

rfindler commented 4 years ago

Oh, it makes the other things in the window take up more space which perhaps is a minor amount of bounce but enough to annoy at least me. I did make the error message appear automatically appear but the coming and going seemed too annoying as it would come and go a lot as one edits the file.

massung commented 4 years ago

I wonder if a decently sized debounce would take care of the "bouncing". E.g. typing stops and 2 seconds later the error status either is there or not?

massung commented 4 years ago

Another option would be to have a preference setting to just disable it completely. I see the red marks on the right-side of the editor and can deduce what the syntax error is for myself just fine.

sorawee commented 4 years ago

Yet another possibility is an option that makes the bar close automatically. By default, it's not on to be consistent with the current setting.

I always manually close the error bar whenever it's empty, so I really agree with @massung that it's annoying. Vertical space is very precious.

rfindler commented 4 years ago

I like the idea of trying the pause-before-hiding approach (on by default).

spdegabrielle commented 4 years ago

how about just one status bar, which shows the error when an error is triggered and is normal status otherwise. No bounce. Fixed height. Error modal when clicked.

Note: I understand this is more work but getting g agreement on an endpoint might open up the opportunity to break it up into smaller tasks.

rfindler commented 4 years ago

What is "normal status"? Do you mean adding a message to the currently blank region?

sorawee commented 4 years ago

I fail to see how "normal status" will help.

At least for me, the goal of closing the status bar is to maximize the vertical space of the editor so that I can see more code. My eyesight is pretty bad, and I prefer to use a larger font size to make me see code better, but that means I can see fewer lines of code. Closing the status bar gives me one more line, which is not a lot, but it does help.

When I code, I don't always type. There's a period of time that I simply navigate around to read code. That is when gaining this one line back will help.

I agree that the pause-before-hiding (debouncing) seems like the best solution.

spdegabrielle commented 4 years ago

I'm suggesting the lower status area code do double duty. As @sorawee mentioned vertical space is precious. I'm guessing this is true for students on cheap laptops with small screens.

Unnecessary screenshot showing my status bars. image

I'm not saying it won't be tricky as the language menu lives there.

spdegabrielle commented 4 years ago

Another option would be to display the error as an overlay like the signature blue box/arrow bubble. (but have it at the bottom and pink) image (I just love uploading images with the eyes)

massung commented 4 years ago

If the bottom status bar could do "double duty" as well - as @spdegabrielle suggested - that's an OK solution with me as well. But, my gut tells me that's going to be a lot of work to root out the edge cases (e.g. the error status bar appears to be part of the tabbed interface where the actual status bar is part of the window).

Which brings me to my next thought... When there's an error, it's always showing the filename along with the error, which is quite often an absolute path (see screenshot). It doesn't need to as the error status bar is bound to the file being edited. It can't possibly be any other file. It could literally just show line number, column, and error, making much better use of the space. Even if it should show the filename, it could just be the filename and not the whole path to it.

image

One other possible suggestion if the debounce doesn't seem to work out very well: only report (and clear) the errors on save instead of while typing?

rfindler commented 4 years ago

It actually can be other files. The error can be anything you want it to be; try out just things like this:

#lang racket
(begin-for-syntax
  (raise-syntax-error "<<<do what you want here, including manufacturing syntax objects with arbitrary source locations>>>"))

and while it does seem like more work than the delay-and-hide solution, switching to something that overlaid the error (with some dimming of the background) is definitely within reach. As you say it would probably live in a different class (as it has to be on a different callback) but it doesn't strike me as a lot more work.

rfindler commented 4 years ago

Another approach we might try: there are a number of vertical-space-eating doodads that can pile up at the bottom of a drracket window (search bar, the thing we're talking about, and I think there are more too) that all have the exact same little "close me" icon (the red "x" thingy). Maybe there should be a keybinding that just closes all of those those things that it finds? (I have had this thought before when watching over people's shoulders as they interact with DrRacket and some people are always going and clicking on those buttons over and over and over.)

aymanosman commented 2 years ago

@rfindler I think I'd like to try implementing the pause-before-hiding solution.

spdegabrielle commented 2 years ago

I think I'd like to try implementing the pause-before-hiding solution. @aymanosman I can't signal approval for your proposed solution but I am interested in things that improved the UX for DrRacket users so let me know if you want a collaborator? I'm on Discourse and Discord.

rfindler commented 2 years ago

@aymanosman I think you want to start with the method set-bottom-bar-status in drracket/private/module-language. I guess what you'd want to do is detect that there's nothing in the bar and then set a timer that'll expire after some point. If there is still nothing, then you'd close the bar at that point. Looks like the hide-module-language-error-panel method (in that file) hides it.

aymanosman commented 2 years ago

@spdegabrielle @rfindler I made a PR that works, but it doesn't add the functionality to set-bottom-bar-status. I added it to update-bottom-bar.

spdegabrielle commented 2 years ago

Thank you @aymanosman I won't be able to test this till tomorrow evening at the earliest but I will as soon as possible.