-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add fontFamily
and fontSize
to CodeEditor configuration.
#4673
Conversation
This is very cool, and definitely answers #4139! I'm really excited about this, and have even started some of the stuff on the repo linked over on jupyterlab-fonts. I'll do some more thorough review comments, and then swing back around with some more summary stuff... |
packages/codeeditor/src/editor.ts
Outdated
@@ -602,6 +612,8 @@ namespace CodeEditor { | |||
*/ | |||
export | |||
let defaultConfig: IConfig = { | |||
fontFamily: '\'Source Code Pro\', monospace', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am -1 on moving this (and almost only this) to having a canonical value in the source code... perhaps leaving these as null such that the theme layer can carry it's preferred font, and these settings are really an end-user override.
packages/codeeditor/src/editor.ts
Outdated
@@ -602,6 +612,8 @@ namespace CodeEditor { | |||
*/ | |||
export | |||
let defaultConfig: IConfig = { | |||
fontFamily: '\'Source Code Pro\', monospace', | |||
fontSize: 13, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other thing that contributes significantly to code readability is line-height
... this has a variable, --jp-code-line-height
, and is particularly fickle with respect to which font a user might pick.
tabSize, | ||
readOnly, | ||
...otherOptions | ||
} = config; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having to enumerate all of these seems like it will be easy to miss when something changes... perhaps explore going back to Partial
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is easy to miss things if something changes. I don't think it's too bad though.
I thought it might be nice to annotate bareConfig
as a CodeMirror.EditorConfiguration
object so that the typescript compiler could catch some of that stuff. However, when I tried that I found that the CodeMirror typings were not quite up to snuff. That being the case, I think this is a fine solution.
packages/codemirror/style/index.css
Outdated
@@ -23,8 +23,6 @@ | |||
|
|||
.CodeMirror { | |||
line-height: var(--jp-code-line-height); | |||
font-size: var(--jp-code-font-size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as mentioned, leaving this managed by default by the theme would be nicer for theme implementers...
@@ -9,6 +9,12 @@ | |||
"autoClosingBrackets": { | |||
"type": "boolean" | |||
}, | |||
"fontFamily": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
permitting this to be null
and handling that explicitly, with some doc suggesting that it will delegate to the CSS theme if left blank might be more robust... just deleting the key might not be sufficient if the style is already set, for example.
@@ -39,6 +45,8 @@ | |||
"$ref": "#/definitions/editorConfig", | |||
"default": { | |||
"autoClosingBrackets": true, | |||
"fontFamily": "'Source Code Pro', monospace", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here use default null
...
Hi @bollwyvl, I wiped out the CSS piece of code related to editor font properties because I'm not convinced font settings are just a matter of style for a text editor. Anyway, if we keep setting default editor font properties via stylesheets, then we have to make a choice, we should decide what values
The latter one is my preferred solution. Trying to increase font size, for example, without knowing current size, it's like walking blindly. If we opt for the first solution, instead, we have to clearly explain to users why font properties are unset. This requires to add description fields to them. Let me know your ideas. |
thanks for submitting it!
Agreed, and absolutely needs to be directly accessible to the user. In fact, I would like to see this PR take a stab at adding commands/menu items to modify these values so we can flush out some of the limitations, as "go hack some JSON" isn't going to jump out and show someone they have that kind of agency.
Jupyter frontends live in a weird place, as they aspire to not just be code editors, but show code in more contexts than standard editors, become the first place people will compute, and be more hackable than a traditional editor. For giggles, one can already change the two values proposed thus far with, e.g. an IPython console: %%html
<style>body {--jp-code-font-size: 48px; --jp-code-font-family: "Comic Sans"; }</style> It will make all code basically unusable... but in a way that it is consistently unusable. By keeping everything in CSS variables, these values are available to higher-order style concerns like vertical rhythm, coordinated character width and others... though it would be even better to yet more font metrics available for these purposes. I look forward to the day when we have a letter-perfect, archival-grade, css-powered static representation from nbconvert without SHAME 🔔 Of course, over on jupyterlab-fonts, I'm directly going to some dark places with JSS, and not even generating intermediate CSS, but that's the nice thing about proof-of-concept extensions. :P
I think at the data layer (JSON, without comments),
Again, if you're hacking the scary-sounding |
Set property default values to `null`. Use style from theme as default.
Hi @bollwyvl, please take a look at changes I made. I think the only thing left over is deciding if we should add descriptions for the new properties in the |
xref: #4648 |
Add `fontFamily`, `fontSize` and `lineHeight` configuration options to editors used in notebook cells.
I added some comment on use of new properties to Cheers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the hard work @AlbertHilb (and thanks for the reviews @bollwyvl)! I think this is in really good shape. I had a couple of questions, but overall this is a great contribution, and I think we should move forwards with it.
@bollwyvl, anything to add about how the current implementation will interact with your experiments with juptyerlab-fonts
?
@@ -981,7 +990,7 @@ namespace CodeMirrorEditor { | |||
* (it will default to be to the right of all other gutters). | |||
* These class names are the keys passed to setGutterMarker. | |||
*/ | |||
gutters?: ReadonlyArray<string>; | |||
gutters?: string[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for changing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without that change I get:
../codemirror/src/editor.ts(1127,8): error TS2345: Argument of type '{ mode?: string | IMode; theme?: string; smartIndent?: boolean; electricChars?: boolean; keyMap?:...' is not assignable to parameter of type 'EditorConfiguration'.
Types of property 'gutters' are incompatible.
Type 'ReadonlyArray<string>' is not assignable to type 'string[]'.
Property 'push' is missing in type 'ReadonlyArray<string>'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. It's another example of the CodeMirror typings being slightly different from ours. I think this is fine, in that case. Thanks!
tabSize, | ||
readOnly, | ||
...otherOptions | ||
} = config; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is easy to miss things if something changes. I don't think it's too bad though.
I thought it might be nice to annotate bareConfig
as a CodeMirror.EditorConfiguration
object so that the typescript compiler could catch some of that stuff. However, when I tried that I found that the CodeMirror typings were not quite up to snuff. That being the case, I think this is a fine solution.
"fontSize": { | ||
"type": ["integer", "null"], | ||
"minimum": 1, | ||
"maximum": 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any particular reason you chose this maximum number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an upper limit to fontSize
helps catching typos early.
But no, there is no particular reason to choose 100
, except for being a round number, the same chosen by Atom editor and big enough to be confident no one wants larger fonts.
Thanks @AlbertHilb, I think this is great. It would be nice to have some sort of UI to increase and decrease the font size for the file editor, but I think we can do that in a follow-up. |
This PR intends to fix issue #4139.
I'm new to jupyterlab code, so the way I implemented this feature can be completely wrong.
If that is the case, feel free to move it to trash. 😊
Otherwise, I'll be happy to add any change you request.
Cheers