Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-scroll to first error in Compiler tab on failed builds #3699

Open
stefanct opened this issue Nov 22, 2023 · 2 comments
Open

Auto-scroll to first error in Compiler tab on failed builds #3699

stefanct opened this issue Nov 22, 2023 · 2 comments

Comments

@stefanct
Copy link

Geany (v1.38 here) already opens the Compiler tab if a build command fails. It is also aware of the lines that denote errors. However, it does not scroll to the first error but simply opens the tab if it's not open and that means that usually(?) it's at the very bottom of the output showing the return value and "Compilation failed."
When using the build commands to actually compile something I am almost always interested in seeing the first problem that occurred. So I kept scrolling up which depending on the verbosity of the output is quite ineffective and stupid and I think that is a quite typical task. In some situations, when "misusing" Geany's build system, it might not be the best option but I could not come up with one so far.
Therefore, I propose that Geany should jump to the first error when opening the Compiler tab due to a build error.

Thanks to another issue on github I have discovered the Build/Next Error functions that can be bound to hotkeys and that's kind of good enough for me but if you don't see any good reasons why it would be unwanted I could take a look into making a PR. It might actually be so trivial for anybody with a prepared build environment for Geany that I wouldn't feel sorry if somebody beat me to it ;)

@dolik-rce
Copy link
Contributor

I think the scroll to end is meant to show you the final result, so you can see it at the first glance. I wouldn't mind if it was optional, but I suspect, that it would be not that useful.

Note that the Next error action (which I use heavily) also changes the location in the editor. If you implemented the scrolling simply using the existing funcionality, it would be very bad from user-experience point of view: The users could write something in one file and be switched to other file in the middle of a word. So if there were such option, it would have to only scroll the compilation output, not change the document and position. This means, that users would than have to press the shortcut for Next error (or navigate to the correct place manually) anyway, if they wanted to see the details and/or fix the error. Which I do want for at least 90% of errors. So in the end, the option wouldn't be that much helpful.

@elextr
Copy link
Member

elextr commented Nov 23, 2023

The user needs to see the end message to tell if it succeeded (eg all warnings, no errors), that would not be visible if the compile output window scrolled to the top when complete. The user may not care about 100000 warnings, they want to know the build succeeded so they can try running it.

But next error after the build is finished goes to the first error/warning so the user is able to read the build result and then look at the messages, so current behaviour meets the use-case at the cost of one click/keybinding.

As @dolik-rce points out the UI is not locked during builds and automatically going to the first message when the build is finished steals the user focus, which is generally considered bad karma. So at best it should scroll just the message window, but as I noted that hides the end status message.

This is the same with at least some other IDEs I use, probably for the same reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants