Rename box does not respect editor font

[isidorn]

Try to rename any variable in TS, notice that the rename box is not respecting the font in the editor.
This is like this since forever but not sure if there is an issue already for this

[jrieken]

Unsure if it should be like that at all? @bgashler1 Ideas? Answers?

[jrieken]

Comparing this to search/replace I don't think we should do it. Please reopen when and explain why this shouldn't be like search/replace or quick outline/

[isidorn]

Arguments that this should respect the code font:

• lives more connected to the source code than search replace
• always has the variable name as the content
• visually not appeleaing to have two different fonts so close to each other

Thinking about it, I would vote that search / replace and quick outline also respect editor fonts. What is the reasoning for those to have different fonts?
QuickOpen makes sense to have different font when displaying titles of files, but not when displaying variable names imho.

Feel free to leave closed if you do not think the arguments are strong enough.

@bpasero @stevencl opinions welcome

[stevencl]

I have to admit I had never really noticed that before. I don't feel very strongly about it. Consistency is good though, so if it was a simple, inexpensive change to make I would be for it. If it was to change, I'd expect it to change in search too.

[bgashler1]

Sorry I let this one slip by me in not replying quickly. I also agree with Steven that consistency is key.

I tend to lean towards not having the monospaced code font in the input box. The reason why is that the input box is a UI overlay, and UI has its own non-monospaced font. We're not editing inline—we're merely entering something as input to the overlay which then makes the change on our behalf.

[isidorn]

Then it makes sense to keep this closed, thanks for feedback.

[jrieken]

so who did this change then?

[joaomoreno]

I just saw the monospace font and I love it. It always felt weird to me that it was non-monospace, regardless of the other input boxes. The same goes for the find & replace.

[isidorn]

I did not change it, but I do like it. Thanks misterious contributor

[jrieken]

Sorry, reverted. IMO consistency goes over personal preference

[joaomoreno]

Consistency goes both ways.

You seem to be on the side of widget consistency: most text input widgets show non-monospace font, so this one should to. Examples are in the search and git viewlets' input boxes, quick open, find and replace. Counter examples are the debug evaluate input box and watch expressions, both of which use monospace font, imo correctly.

I don't agree with that type of consistency.

I feel content consistency is more important. Meaning: wherever code is always shown, monospace should be used; non-monospace otherwise. This already is very consistent nowadays: editor, output, suggest widget, parameter hints, hover widget; they all show monospace font. It is even consistent with quick open and the search and git viewlets' input boxes, since you do not always write code in there; you might write plain text, so that is non monospace.

This leads me to point out where this consistency is not followed: find all references, peek definition, search viewlet contents and, finally, the rename widget. All of these are examples in which I don't feel we're doing the right thing: they should all show monospace font.

[stevencl]

That's a very compelling argument @joaomoreno, I agree.

[jrieken]

I think we agree on consistency, I just disagree about making that change in small increments and starting with a random widget. If we can establish and formulate a rule then we should go by it.

[jrieken]

Assigning this to @stevencl to coordinate this effort across all the areas @joaomoreno mentioned above

[felixfbecker]

I would also say that writing RegExps in the search box would be much easier with a monospaced font.