Kazunobu Kuriyama wrote: > 2017-03-25 5:14 GMT+09:00 Charles E Campbell > <[email protected] <mailto:[email protected]>>: > > Hello: > > On at least two machines, which both run Scientific Linux, I'm getting > odd behavior with a -geometry command: > > gvim -geometry "316x40+0-0" somefile > > The file is opened on the bottom of the screen (316x40, open 0 pixels > from left and 0 pixels from the bottom). > Or, at least, that's what its supposed to do. Sometimes it opens 0 > pixels from the top of the screen instead. > > I haven't found a way to get the problematic opening to occur with > regularity -- I just did it ten times and it opened correctly, for > example. > > Regards, > Chip Campbell > > > Hi Dr. Chip, > > First of all, I think we need to make sure how the geometry of an X11 > app is determined when it appears on the screen for the first time. > > That's a result of a negotiation between the window manager in use and > an X11 app which is going to be substantiated on the screen. > > As the argument to -geometry is seemingly always honored by the window > manager, it's natural that one might have an impression as if > -geometry were a command. > > The reality is, however, that window managers are usually implemented > to take the argument as a hint to compute another geometry which it > thinks is suitable for the app's sharing the whole screen with other > apps already appearing on the screen, based on the geometry management > policy of each window manager. The result of the computation is sent > out to the X11 app under negotiation as an X11 event, and, by > convention, the app is expected to follow the result as it it, not > asking another negotiation. > > Accordingly, the geometry which is actually used is not the one given > by the argument to -geometry, but the one the window manager computed, > taking it as a hint and into account as such. > > Hence, it's not a surprise that X11 apps sometimes appear on the > screen in a way failing one's expectation, depending on the geometry > management policy of each window manager which is often subtle or obscure. > > In addition to that, I think we need to consider another factor > specific to gvim. > > Usually, geometry negotiations are done with respect to the geometry > of the top-level window of an app; it re-computes children's geometry > based on the geometry allocated to the top-level window by the window > manager. It's really straightforward. > > As to gvim, when it computes its geometry, it puts more emphasis on > the geometry of the text area than that of the top-level window. > Naturally, the numbers of columns and lines do matter much more for > Vim than the values of x, y, width and height of the top-level window > because it's THE text editor :) Plus, as can be seen in the richness > of 'guioptions', the text area is surrounded with GUI elements which > can be added or removed arbitrarily even at runtime, which gets the > computation far more involved than usual GUI apps. > > While following the geometry management convention, gvim is struggling > to keep its values as a text editor. The negotiation is always tough > and sometime fails, unfortunately, though I know that's a thing to be > improved. > Just thought I'd mention why I do this: I prefer a tiled display, and in order to emulate how vim works I have gvim opening atop whatever window I used to invoke it (I use the command line, not an icon, etc to do that). So, the space is there, its just not being utilized as I wish.
Regards, and thank you for your answer, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
