Is there any way to set white space visible for a given scope?
I'm working on modifying a color scheme to suite my liking and would like to be able to show spaces within a given scope. I haven't seen anything suggesting it's possible within the color-scheme documentation on Sublime's website.
For my specific case, and I imagine there's other useful cases, I'm working with Markdown and want to highlight a double-space line-break. I'm able to set the background, but this doesn't look quite right. I'm hoping to be able to make whitespace visible for this small scope and change the foreground color to make it stick out.
The short answer to your question is no; or rather, Yes, but only in the way that you've already discovered.
Color schemes can only apply foreground/background colors to scopes as well as bold/italic font weights. So assuming that there is a specific scope detected by the syntax you're using that is used for the things you're trying to highlight, the only thing the color scheme can do is alter the background color to make them visible.
The only thing that can render white space natively is the draw_white_space setting, which at the moment only allows you to turn it off everywhere, turn it on everywhere, or turn it on only for selected text. In this case that doesn't really help.
There are possibilities for something like this in the plugin realm though (these examples can be tested by opening the Sublime console with View > Show Console or Ctrl+` and entering the code in there; they also assume that you're using the default Markdown syntax):
view.add_regions("whitespace", view.find_by_selector("punctuation.definition.hard-line-break.markdown"), "comment", flags=sublime.DRAW_NO_FILL)
This will cause all of the hard line breaks to be outlined as if they were find results; the color is selected by the scope (which is comment here); that would make them visible without making the whole character position have a background color.
view.add_regions("whitespace", view.find_by_selector("punctuation.definition.hard-line-break.markdown"), "comment", "dot", flags=sublime.HIDDEN)
This will add a dot (colored as a comment) in the gutter for lines that end with this scope; you can also combine this with the previous example to outline them and also call attention in the gutter.
style = '<style>.w { color: darkgray; }</style>'
content = '<body id="whitespace">' + style + '<span class="w">··</span></body>'
phantom_set = sublime.PhantomSet(view, "whitespace")
phantoms = [sublime.Phantom(r, content, sublime.LAYOUT_INLINE) for r in view.find_by_selector("punctuation.definition.hard-line-break.markdown")]
phantom_set.update(phantoms)
This uses Sublime's ability to apply inline HTML phantoms into the document in order to inject a small inline sequence of two unicode center dots immediately between the actual whitespace and the text that comes before it. Here the content can be what you like if you can generate the appropriate HTML; we're just applying a color to the text in this example.
A potential downside here is that the characters you see in the inline HTML aren't considered to be part of the document flow; the cursor will skip over them in one chunk, and they're followed by the actual whitespace.
The result of this example looks like this:
Going the plugin route, you'd need an event handler like on_load() to apply these when a file is loaded and on_modified() to re-update them after modifications are made to the buffer. There may or may not be a package that already exists that has implemented this.
Related
I have been trying to solve this problem for a while in Python3.
I normally use to extract some information from DOCX documents, by using python-docx library.
from docx.document import Document
from docx import Document
document = Document("test.docx")
for paragraph in document.paragraphs:
for run in paragraph.runs:
print(run.font.name)
#returns None
So, as you can see from the above code, this is a very simple python-docx code to extract some information. I can access some properties such as; font name, size, outline levels, etc.
However, all of these properties are returning None. Because they haven't been explicitly defined.
I have checked StackOverflow for a similar problem and found these.
Extracting word document with styles associated to the content
How to get actual style of text in word document using python docx
In the documentation, it also says, if it returns None, then it's the Default style, that is inherited.
Also tried some XML parsing, but could not reach the desired parameters:
words = document._element.xpath('//w:r')
WORD_NAMESPACE = '{http://schemas.openxmlformats.org/wordprocessingml/2006/main}'
PARA = WORD_NAMESPACE + 'p'
for elem in document.element.getiterator():
if elem.tag == WORD_NAMESPACE + 'p':
for i, child in enumerate(elem.getchildren()):
if child.tag == WORD_NAMESPACE + 'pPr':
...
# No idea how to access, all the styles with which
# tags etc.
How do we extract these default styles too? I would want to extract, the indentation levels, bold, italic, font name, size, etc properties from a DOCX. What could be the alternative ways. I want to solve it in Python3.
I believe what you're trying to discover is the effective style, which is to say, after the style hierarchy for this run has been traversed, which character formatting attribute has which of its possible values for this particular run.
This is a non-trivial problem. The style hierarchy work similarly to Cascading Style Sheets (CSS) in that formatting attributes can be set at various levels and the "closest" setting wins. At the same time, a run can have no assigned character formatting or style in which case the "farthest away" or "default of last resort" determines its character formatting.
In order to compute the effective formatting you need to traverse the style hierarchy level by level until you find the setting you're looking for (like say font.name). To do that, you need to know what the style hierarchy is for a particular run and then have access to each level of it.
So that's a pretty big ask. Roughly, just to give an idea, the style hierarchy would typically be:
character formatting applied directly to the run, like bold, italic, font name and size.
character formatting applied using a character style
character formatting applied using a character style attached to a paragraph style.
character formatting associated with the default paragraph style.
an assigned document-level default
A client-internal final fallback, client being something like Word, OpenOffice, etc.
There are exceptions when the text appears in a table and a table-style may fit in that hierarchy somewhere. I expect there are others as well.
There's no API support for this in python-docx at the moment and I haven't seen any successful implementations of it. I don't believe it is impossible to get a pretty useful implementation, it's just hard enough that most folks find some way to avoid it.
How to change color of certain type label of syntax?
I know that there is file of color scheme but what line of that file is related to colors of certain label (e.g. class or function).
For example, there is a piece of code in Sublime Text 3:
I do not want to see label 'Node' (that is class-label) yellow but want to see it blue. How I can do it?
To do this you need to make a modification to the color scheme that you're using to tell it to color things in a different format. In particular, you need to know two things:
The color scheme that you're currently using.
The scope of the thing whose color you want to change.
To determine your color scheme, look in your preferences for the value of the color_scheme setting. Here I'm going to assume that it looks like this:
"color_scheme": "Mariana.sublime-color-scheme",
Depending on how you set up the color scheme this might have part of a path as well, like Packages/Color Scheme - Default/Mariana.sublime-color-scheme instead. The file may also have a tmTheme extension instead of sublime-color-scheme if you're using a legacy color scheme.
To determine the scope you need to change, put the cursor on the thing whose color you want to change and use Tools > Developer > Show Scope Name (or press the key that menu tells you about), then make a note of what the last line of the popup says. In this case, we're assuming it is:
entity.name.class.c++
Your color scheme has a rule in it that tells it that things with a scope that matches this should appear the color that they do, so you need to adjust that color to be what you want.
To do that, you create a file in your User package, which you can locate by using Preferences > Browse Packages.... The file that you create should be the name of the color scheme you're using (just the filename, not the path if any) with an extension of sublime-color-scheme (even if the extension on your color scheme is tmTheme.
In our example, that means that we would create a file named Mariana.sublime-color-scheme in the User package.
The content of your file should look something like this:
{
// http://www.sublimetext.com/docs/3/color_schemes.html
"rules": [
{
"scope": "entity.name.class",
"foreground": "var(blue)",
},
]
}
This tells Sublime that for anything whose scope matches entity.name.class, it should use the color outlined by the variable blue instead of what your normal color scheme is doing. As soon as you save the file, you see the results appear.
We use entity.name.class here instead of entity.name.class.c++ to make the scope match anything that's considered a class in any file. Basically the more of the scope from #2 above that you use, the closer the match will be. So if you use it all, it only affects C++.
The last thing to note here is that var(blue) will only work if your color scheme defines a variable named blue. The Mariana color scheme does, which is why I used that here. Yours may not, in which case you need to specify the color a different way.
The link in the example above points to the color scheme documentation with more details, but you could use something like #0000FF in place of var(blue) to get pure blue (adjust as required, that blue is likely far too dark).
So I've updated Sublime Text 3 to version 3170 on Ubuntu today and apparently this broke my whitespace coloring - I always have this option set:
draw_white_space": "all"
because I like seeing my spaces and tabs in dark grey - not distracting, but visible enough to be able to see/count them or locate tabs that should be spaces instead.
After the update, the whitespaces are light green, which makes them super distracting. Is there any way to set this back to grey?
One of the features of Stable build 3170 (and many of the Dev builds in this series) is support for invisibles in the tmTheme color scheme as well as in the new sublime-color-scheme format. This is something that existed in tmTheme prior to this, but Sublime did not use the value in that color scheme key and instead used another color.
At the moment it's unclear exactly what color was originally used, but possibly it was the foreground color with an alpha value applied to "dim" it, so the following may require some experimentation to find the right color.
A side effect of this change is that for some color schemes, the color scheme author may have had a value in the invisibles key that was not honoured previously but which now is, which makes things display incorrectly. Or correctly, depending on how you look at it.
You mentioned in comments above that you're using Neon Color Scheme and in that scheme the invisibles value is set to #06FF05 which is indeed a green color.
In order to solve your problem you need to edit the color scheme to apply a different color to that part of the color scheme to get the gray color that you want.
The easiest way to accomplish this would be to take advantage of the addition of the sublime-color-scheme resource type in Sublime Text. Many resource types in Sublime "stack" together at load time to allow for the creation of a partial override.
It turns out that in the case of this particular file format, sublime-color-scheme stacks with tmTheme files of the same base name, since they are represented the same way in memory once they're loaded.
As a result of that, you can adjust the invisibles color by creating a file with the name Neon.sublime-color-scheme in your User package with the following contents:
{
"globals":
{
"invisibles": "#FF00FF"
}
}
The Neon.sublime-color-scheme stacks with the Neon.tmTheme from the package, and since the User package content is always loaded last, this overrides just the invisibles color (in this case to magenta) but leaves the rest of the color scheme untouched.
This of course applies to any color scheme so long as you know the name of the tmTheme file that you're using. The same mechanism can be used to extend your theme to include colors for new scopes or alter the colors of existing scopes without having to recreate a whole new tmTheme or sublime-color-scheme file. See the color scheme documentation for more information.
Doing this creates a partial override, which means that regardless of the content of the underlying color scheme, your changes will still take effect with no overt warning. In this case that's pretty low key as far as potential problems are concerned.
Another way to accomplish this goal is to make changes to the tmTheme file by creating an override. This is marginally more complicated than the above but potentially still useful. For example, this can be used for any package resource of any type in order to modify things to your liking.
In order to create such an override:
Install PackageResourceViewer if you don't already have it installed.
Enter prvo in the command palette and select PackageResourceViewer: Open Resource
Select Neon Color Scheme, then Neon.tmTheme (or the appropriate package and file, depending on what you're doing)
Make appropriate changes to the file as desired and save
This sequence of steps opens the underlying package resource file for you to look at and/or modify. Saving the file creates an override by creating a folder in the Packages folder named for the package and putting the modified file inside. When Sublime loads package resources, the version that's unpacked in the Packages folder takes precedence over the version that's in the package.
In the case of a color scheme tmTheme file, near the top you'll see a settings key, and inside of it, this set of tags sets the color used for invisibles, which you can modify as you see fit.
<key>invisibles</key>
<string>#06FF05</string>
As with any override, once you do this your version of the color scheme (or any other package reaource) will supersede the version that ships with the package, which means that if the package gets updated, your version of the file will still be used without any warnings or messages to tell you that it's happening.
That's probably not a big deal for a color scheme; the OverrideAudit package will warn you if this happens if you're worried. Alternatively, you can make the modifications as above but do a Save As instead of a Save and save the file in your User package, and then alter the color scheme setting to use that version of the color scheme instead.
If you do that and use the same file name, the scheme will appear twice in the color scheme selector; make sure you choose the version that says it's in the User package to be sure you're using your modified version.
Customize your color scheme's whitespace setting:
Sublime Text > Preferences > Customize Color Scheme
{
"globals": {
"invisibles": rgba(255, 255, 255, 0.15)
}
}
No plugins necessary (:
Sublime Theme Customizing Docs here
Using HitTestTextPosition style API from IDWriteTextLayout I did not managed to handle properly text positions inside "ti", "ffi" or other ligatures with fonts like Calibri. It always returns position after or before ligature not inside like t|i or f|f|i.
What is the recommended way to do a caret movement inside ligatures with DirectWrite API?
There... is no "inside" position if you have GSUB replacements turned on?
Opentype GSUB ligatures are single glyph replacements for codepoint sequences, rather than being "several glyphs, smushed together". They are literally distinct, single glyphs, with single bounding boxes, and a single left and right side bearing for cursor placement/alignment. If you have the text A + E and the font has a ligature replacement that turns it into Ӕ then with ligatures enabled there really are only two cursor positions in that code sequence: |Ӕ and Ӕ|. You can't place the cursor "in the middle", because there is no "middle"; it's a single, atomic, indivisible element.
The same goes for f. ligatures like ff, fi, fl, ffi, ffl, or ſt: these are single glyphs once shaped with GSUB turned on. This is in fact what's supposed to happen: having GSUB ligatures enabled means you expressly want text to be presented—for all intents and purposes—as having atomic glyphs for many-to-one substitutions, like turning the full phrase "صلى الله عليه وعلى آله وسلم", as well as variations of that, into the single glyph ﷺ.
If you want to work with the base codepoint sequences (so that if you have a text with f + f + i it doesn't turn that into ffi) you will need to load the font with the liga OpenType feature disabled.
The text editors I know of use the simple hack of (1) dividing the width of the glyph cluster by the number of code points within the cluster (excluding any zero width combining marks), rather than use the GDEF caret positioning information. This includes even Word, which you can tell if you look closely enough below. It's not precise, but since it's simple and close enough at ordinary reading sizes, it's what many do:
(2) I've heard that some may (but don't know which) also use the original glyph advances of the unshaped characters (pre-ligation) and scale them proportionally to the ligature cluster width.
(3) Some text editors may use the GDEF table, but I never knew of any for sure (possibly Adobe In-Design?).
The most challenging aspect of using methods 2 or 3 with IDWriteTextLayout is that accessing the corresponding IDWriteFontFace in that run requires quite the indirection because the specific IDWriteFontFace used (after resolving font family name+WWS+variable font axes) is stored in the layout but not publicly accessible via any "getter" API. The only way you can extract them is by "drawing" the glyph runs via IDWriteTextLayout::Draw into a user-defined IDWriteTextRenderer interface to record all the DWRITE_GLYPH_RUN::fontFace's. Then you could call IDWriteFontFace::GetDesignGlyphAdvances on the code points or IDWriteFontFace::TryGetFontTable to read the OpenType GDEF table (which is complex to read). It's a lot of work, and that's because...
The official PadWrite example has the same issue
IDWriteTextLayout was designed for displaying text rather than editing it. It has some functionality for hit-testing which is useful if you want to display an underlined link in a paragraph and test for it being clicked (in which case the ligature would be whole anyway within a word), or if you want to draw some decorations around some text, but it wasn't really intended for the full editing experience, which includes caret navigation. It was always intended that actual text editing engines (e.g. those used in Word, PowerPoint, OpenOffice, ...) would call the lower level API's, which they do.
The PadWrite sample I wrote is a little misleading because although it supports basic editing, that was just so you can play around with the formatting and see how things worked. It had a long way to go before it could really be an interactive editor. For one (the big one), it completely recreated the IDWriteTextLayout each edit, which is why the sample only presented a few paragraphs of text, because a full editor with several pages of text would want to incrementally update the text. I don't work on that team anymore, but I've thought of creating a DWrite helper library on GitHub to fill in some hindsight gaps, and if I ever did, I'd probably just ... use method 1 :b.
I'm using LaTeX and I would like to have vertical rule along left side of page, topmargin to bottommargin, 0.5in from the left edge of the page. I want this on every page, so I assume that means it must somehow be tied to the header or the footer?
I've made no progress at all, so I need help with (1) making the full-length rule itself and (2) making it happen automatically on every page of the document.
Can someone tell me how to do that?
I got a working answer to my question on the Latex Community forum: http://www.latex-community.org/forum/viewtopic.php?f=5&t=9072&p=34877#p34877
The answer I got uses the 'Background' package and this code:
\documentclass{article}
\usepackage{background}
\usepackage{lipsum}% just to generate filler text for the example
\SetBgScale{1}
\SetBgAngle{0}
\SetBgColor{black}
\SetBgContents{\rule{.4pt}{\paperheight}}
\SetBgHshift{-9cm}
\begin{document}
\lipsum[1-90]
\end{document}
Works great and was easy to adjust to put one vrule in left margin area and one in the right margin area.
There could be a LaTeX package to do this for you, but I'm more of a TeX person, so I tried to come up with a TeX solution (not always the best idea to mix plain TeX with LaTeX but I think I have it working).
Try this. Box 255 is the box register that TeX places the page contents into before the page is output. What I've done is taken the existing output routine, and changed it to insert into box 255: a 0-height, 0-width infinitely shrinkable-but-overflowing set of boxes containing a rule that is the height of the page, 0.4pt thick and with any luck, half an inch away into the left. The existing contents of box 255 is then added after this rule. Then I call the previous output routine which outputs the page (which now includes a rule), and also the headers and footers.
\newtoks\oldoutput
\oldoutput=\expandafter{\the\output}%
\output{%
\setbox255\vbox to 0pt{%
\hbox to 0pt{%
\vsize\ht255%
\vbox to \ht255{%
\vss
\hbox to -0.5in{%
\hss
\vrule height \ht255 width 0.4pt%
}%
}\hss
}\vss
\box255%
}%
\the\oldoutput
}%
Put it before your \begin{document} command. This might not solve your problem completely, but hopefully it should get you started. Here's a great page for learning about TeX primitives and built-in things.
Have a look at the eso-pic package. From memory, what you want would look like this:
\AddToShipoutPicture{%
\setlength\unitlength{1in}%
\AtPageUpperLeft{%
\put(0.5,\topmargin){\vrule width .5pt height \textheight}%
}%
}
It's not clear in your question if you want the line to span the text area or the whole paper height. Depending on the case, you have to replace \topmargin and \textheight by the correct values, either 0pt or whatever your top margin is, or by \paperheight. See the geometry package if you don't already use it for how to control those dimensions.