- Ubuntu 22.04.2 LTS - geany 1.38-1
When either typing or moving the cursor column location, the column indicator value change causes everything to the right of "col" to shift left and right. With a fresh install of geany from the ubuntu repo in a vm and no configuration of geany, the shift only occurs when the col count goes from 9 to 10. On my configured installation of geany, it shifts left and right on certain col values between 0 and 100. I compiled git source and got the same results as my normal install. I believe the git install is using my custom config.
I would suggest that this should not happen at all, not even when going from 9 to 10.
[geany-bug-statusbar-col.webm](https://user-images.githubusercontent.com/117324331/219980254-84f10ca9-6cc1-...)
Here the status bar moves when the column goes from 99 to 100, not 9 to 10, and it doesn't jump backward and forward like your video.
As the [manual](https://www.geany.org/manual/current/index.html#statusbar-templates) say, the default template has a tab after the lines and cols. That moves the next item to a position that will not move ... until the number of digits needed to show the line/column exceeds the tab width, then everything moves one tab further, but then nothing should move for many more digits.
Tab positions are set by GTK, not Geany, so we have no control over it, its eight spaces wide[^1]. That is what happens here, when the `cols: 99` which is 7 characters wide goes to `cols: 100` which is eight characters wide the rest of the statusbar moves along one tab.
But ... (there is always a but isn't there) the width of 8 spaces depends on the font, and for some variable width fonts it can be less than the actual width of some characters. It looks like you have been (un)lucky enough for the width to be very close to the end of `cols: nn` and, depending on the width of the digit characters the tab position was exceeded or not, probably only by one pixel, and when it was exceeded the rest of the line jumped to the next tab position, then back as later digits were narrower and so didn't pass the tab position.
In your case you could try a different font where the spaces are better defined (its the standard system UI font IIUC, so Ubuntu should have a way of setting it, here its `sans regular`, but thats an alias I think, not sure what to), or it may be better to remove the tab and just use spaces, the line will still move, but only when the number of digits changes, it should not jump backward and forward like your video.
[^1]: GTK 4.8 finally added the capability to set it, but ATM there are no plans for porting Geany to GTK4.
Just thinking, maybe we could have a field width specifier so we could limit this kind of behavior, if not eliminate it entirely (though with variable-width fonts there's no guarantee).
Anyway, a trick you can use is add a couple of spaces in *front* of that field so it moves the tab stop farther after the field and thus will offset the moment it starts jumping around (you should be able to move this to the many thousands enough to virtually eliminate it).
maybe we could have a field width specifier ... (though with variable-width fonts there's no guarantee).
Yeah, thats the problem with field widths in characters, and "somebody"s got to do it, currently the status template is a simple replacement of %letter, not analysed for width, alignment (which becomes an issue if the width is greater than the contents) etc.
Thanks for the answers. Is it not possible to set the font for the statusbar within the code of Geany? It seems that having monospace font in the statusbar would be a decent solution, though imperfect.
All widgets outside the editor pane follow the GTK theme, for better or worse.
But you can set font-family for the statusbar in geany.css, there is even a commented out statusbar section at the end of that file[^1], and an example near the top of setting `font-family: monospace`.
[^1]: at least it is in the git version, not sure if its released, but you can read it on github if not.
A decent workaround is to simply move the busiest counters to the right, where they won't be as much of a bother. ``` %w %t %mmode: %M encoding: %e filetype: %f scope: %S sel: %s line: %l / %L col: %c ```
Yeah, thats the problem with field widths in characters
Actually if we implement it manually we *could* mesure the width of the largest digit, compare that to the width of the space character, and use Maths to know how many of the latter we need for padding. A bit of a complex hackaround maybe though.
Actually if we implement it manually we could measure the width of the largest digit, compare that to the width of the space character, and use Maths to know how many of the latter we need for padding.
How will that work? If we measure the widest digit then when the thinnest digit is present it will be off again ;-)
A number of ways of minimising the issue have been outlined above (including by the OP) so I don't think its worth the effort.
@relatable975 if you re-arrange the template its probably best to keep scope last because its a function/class name and its length can vary quite a lot.
How will that work? If we measure the widest digit then when the thinnest digit is present it will be off again ;-)
Hum, indeed… another solution that has been on my mind for ages and I've seen implemented in other apps "lately" would be changing plaintext to individual widgets, and this way we could easily also make it interactive (to change mode, file type, got to line, etc.). But well, somebody has to do it, as you'd say 🙂
changing plaintext to individual widgets, and this way we could easily also make it interactive (to change mode, file type, got to line, etc.). But well, somebody has to do it, as you'd say :slightly_smiling_face:
Put it on the "during the GTK4 port" list ;-P
github-comments@lists.geany.org