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
More extensions #60
Merged
Merged
More extensions #60
Changes from 26 commits
Commits
Show all changes
31 commits
Select commit
Hold shift + click to select a range
46f2654
patch literal blocks captions; add result directive
2bndy5 9b716b2
update docs for results directive
2bndy5 d015933
add task-list directive and keys role
2bndy5 186e5ca
add experimental button idea
2bndy5 8e60344
add in new demo CSS
2bndy5 a150c2b
pleasing pylint
2bndy5 f9697ce
ran black on button.py
2bndy5 e89e923
partial solution to content tabs in #56
2bndy5 c699f76
improve api doc signatures and code block captions
2bndy5 6c931a9
pleasing stylelint
2bndy5 b03e916
pleasing pylint
2bndy5 3fe60a0
polish & remove experimental button.py
2bndy5 86f1c0d
pleasing stylelint
2bndy5 454dc69
still pleasing stylelint
2bndy5 a0fe3b2
hopefully the last stylelint fix
2bndy5 21624e2
[stylelint] WTH is with property ordering in scss
2bndy5 b1f58d0
adjust custon keys' CSS for chrome
2bndy5 d411a7a
remove button testing CSS
2bndy5 50629a2
use descrptive directive name
2bndy5 ba707ef
use snake casing for docutils node
2bndy5 40a0e9e
move a margin reset to typeset.scss
2bndy5 bb6ed63
review changes to kbd_keys.py
2bndy5 a33bd45
use plain text for keys role in latex
2bndy5 67e7b64
simplfy example CSS for custom task-list
2bndy5 3f8a83f
move rst-result CSS to _highlight.scss
2bndy5 10d3931
wrap each param in span & style said span
2bndy5 f45ac1a
[no ci] move comment to proper location
2bndy5 ceef35f
condensed selectors = less deviation from upstream
2bndy5 00c0f1c
set autocrlf to input
2bndy5 3231096
try overriding git global config for this repo
2bndy5 727abf5
override config for all files (not by core config)
2bndy5 File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
# Set the default behavior, in case people don't have core.autocrlf set. | ||
* text=auto | ||
|
||
# Explicitly declare text files you want to always be normalized and converted | ||
# to native line endings on checkout. | ||
*.py text eol=lf | ||
*.rst text eol=lf | ||
*.scss text eol=lf |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 never use Windows, but why do we want any conversion of line endings at all? It seems like it would be be better to just have them always be LF at all times.
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.
This bit was copied from the github docs. I can remove it, but it matches the settings I use globally (which I think is the default).
I added this file since
npm run check
spits out hundreds of errors from stylelint about the wrong line ending when Igit checkout
with windows.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 guess you have
core.autocrlf
enabled?I think we can disable any line ending conversion with:
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.
It seems risky without that safety net. It is a major pain in the ass to revert CRLF to LF manually if any get introduced (git diffs don't really show the distinction of different line endings - so I've been bogged down by this in the past).
I read yesterday (on the git docs) that the value
input
would convert CRLF to LF ("but not the other way around"). The docs are terribly worded to the point where the config option's explanation is actually confusing.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.
It is not too hard to convert line endings if you find a problem --- e.g. you can use the dos2unix program.
I think the way you currently have it, autocrlf behavior will apply to all files by default if the user has
core.autocrlf
enabled, except that.py
,.rst
, and.scss
files will always haveLF
line endings when checked out (even on Windows).I'm not sure why we want some files to have autocrlf mode and some files always LF.
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.
well, I did some experimenting.
core.autocrlf=input
provides LF endings in the local workspace on checkout. But this overrides theeol
config option.eol
is set tolf
, then the workspace uses LF endings (which is the desired result - even on Windows), but this meansautocrlf
should be set tofalse
(which means no normalizaton of line endings on checkout).core.autocrlf=false
andcore.eol=lf
are set via .gitattributes, they seem to have no affect when the git global config is notcore.autocrlf=false
.So, I think I found a compromise to override a user's global config for this repo:
* text autocrlf=false
prevents line ending normalization* text eol=lf
ensures workspace uses LF on checkoutThis way if a CRLF is introduced, then
npm run check
will likely fail. At that point the user should be aware of the line endings' preference for this repo and convert them manually as needed.git docs links
This problem seems to have been addressed so many times (in various ways) that the docs are very nuanced and damn confusing.