Thanks for replying!
Would this be more valuable than (say) TheDJ's suggestion of it appearing as a hovering block at the bottom of the window
I would definitely prefer the hovering block to its current state, especially if it had a minimize feature that saved its contents but kept it in a "dock"-esque footer-bar. Though, generally I do believe the ability to control it myself would be preferable over having it locked in anywhere, but if it's too much work that's perfectly understandable.
Should the page scroll down so that you get to see enough of the dialog, too?
I don't think it should. Most users probably wouldn't want the editor to move their viewing space without consent or warning, and this would probably make for a bad user experience.
I believe you're referring to the fact that if the user were to be selecting text in (for example) the bottom 200 pixels of the screen, the inspector wouldn't have enough room to open and part of it would be cut off? If I'm misunderstanding please correct me, but the "right-click" dialog already handles this problem quite well. When you right-click near the top of the screen the menu opens downward, but if you right-click near the bottom it opens upwards in order to fit itself into the given area. Making it dynamically able to open above/below the cursor would likely be preferable. Of course, the dock functionality mentioned above would fix this if implemented, and make this issue essentially irrelevant.
what would we do if there were 10 sections? 20? 50?
This kind of contradicts your next point (with regards to the search box) about it being a quick-to-use dialog. If it's capable of reaching 20+ sections, there's probably something wrong with the dialog or its purpose. That would mean hundreds of potential choices in the dialog and there's no good way of organizing that (without a search box ;) ). Currently, it's so large it's cumbersome to look through and my eyes don't scan through it in any real order because it's so condensed. These problems may be fixed by the improved grid but, assuming they aren't, perhaps we could settle at both tabs and sections? Max it to a reasonable number of tabs, e.g. 6, and then allow sections to serve as subheaders for each tab.
Either way, I think collapsible sections will be necessary if you want the dialog to be reasonably usable.
This could turn what should be a quite simple and quick to use interface into something that's very "heavy", and I think it'd only be useful for a minority of characters, and only to some users who already know that they're looking for an "a"-related character (for example, would you expect "α", "א", "æ" and "ɐ" to show up when you typed in "a"?).
With regards to its simplicity and speed, I think this would make it more complicated at the back-end, but the user-facing interface would be much quicker and easier to find exactly what you're looking for. The simplicity may be complicated a bit by a search bar, but we're talking about a huge, difficult-to-organize list of characters. I wouldn't imagine most users would immediately think "simple" upon viewing it.
And while I can understand that users may not understand the features of the search bar immediately, a simple tutorial or note would make it evident and understandable reasonably quickly.
Would it be better if we had some way of organizing the characters so that all the As were clustered together in each section
This would definitely be a good way of organizing it, but again I feel like everything would just be smoother with the Search dialog.
Do you think that we should hard-code a maximum width and show buttons with labels centred regardless of their actual width
I think the approach which uses a maximum size for each panel in the grid is preferable, especially since issues could come up if there was, for whatever reason, a character which was especially long or tall. That character would cause all of the buttons to become that same size and create a really odd-looking interface, especially if the buttons weren't squares.
Note that users' browsers/system/font selection (amongst other issues) can make it unpredictable how wide this will be (and indeed which character is widest), which may be a little confusing.
I may be completely wrong here, but is it not possible to override the user's font selection for this specific dialog? That way all users would see the same size/type of font in the Special Characters window? Obviously not the best way of solving the issue, assuming it's even possible, but its the only I could think of.