Vim syntax highlighting: make region only match on one line - unix

I have defined a custom file type with these lines:
syn region SubSubtitle start=+=+ end=+=+
highlight SubSubtitle ctermbg=black ctermfg=DarkGrey
syn region Subtitle start=+==+ end=+==+
highlight Subtitle ctermbg=black ctermfg=DarkMagenta
syn region Title start=+===+ end=+===+
highlight Title ctermbg=black ctermfg=yellow
syn region MasterTitle start=+====+ end=+====+
highlight MasterTitle cterm=bold term=bold ctermbg=black ctermfg=LightBlue
I enclose all of my headings in this kind of document like this:
==== Biggest Heading ==== // this will be bold and light blue
===Sub heading === // this will be yellow
bla bla bla // this will be normally formatted
However right now when ever I use an equals sign in my code it thinks that it is a title. Is there anyway that I can force a match to be only on one line?

UPDATE: My previous answer was wrong, you can do this with a region, just do
syn region SubSubtitle start=+=+ end=+=+ oneline
See :help syn-oneline and :help syn-arguments. Guess it shows that I can't actually run vim right now, hunh?
Previous answer
According to my reading of the :help syntax, there's no way to do this with a region. However, you could do this with a syn-match:
syn match SubSubtitle /=\#<!=[^=]*==\#!/
The /=\#<!/ says there's no = immediately before your match, and the /=\#!/ says there's no = immediately after, so this matches exactly one =, a bunch of non-= (not including newlines - to include newlines it would have to be \_[^=]), then exactly one =.
The rest are similar
syn match Subtitle /=\#<!=\{2}[^=]*=\{2}=\#!/
syn match Title /=\#<!=\{3}[^=]*=\{3}=\#!/
syn match MasterTitle /=\#<!=\{4}[^=]*=\{4}=\#!/
You can still do matches within syn-matches, so if you have any nesting going on, it will still work.
For example
syn match Todo /\<TODO\>/ containedin=SubSubtitle,Subtitle,Title,MasterTitle contained

Related

How to customize the look of currently selected(highlighted) completion in zsh?

Main question
I would like to add powerline characters at the start and at the end of the selected completion, like this:
Started the completion menu by inserting c and pressing the TAB key.
Moved right in the completion menu by pressing the right arrow key.
Moved down in the completion menu by pressing the down arrow key.
Is there any way to make zsh look/behave like in the pictures?
Note
Added powerline triangle + blank character at the beginning and blank character + powerline triangle at the end should somehow be accounted when columns are created to keep the alignment correct.
Bonus
Add 2 blanks at the beginning of every completion in the list, so that when the completion is selected it doesn't look like the text was moved to the right.
( This issue can be seen by comparing the completion with and without the selection. )
Alternative question
In case that previously explained behavior is impossible to get without changing the zsh source code, is it at least possible to add powerline triangle only at the end of the selected completion?
My unsuccessful attempts
I have tried using the lc, rc, and ec variables in the list-colors style but that didn't help:
Completion list was badly aligned and it created all kinds of visual problems.
Symbols were inserted in all elements of the completion list, not just the selected one.
I have also tried using the ma variable, but I couldn't properly insert a character at the beginning:
The variable expects only a number that represents a color and it is probably wrapped in some escape sequences, so the output did not look as expected.
This works for me.
zstyle ":completion:*:default" list-colors ${(s.:.)LS_COLORS} "ma=48;5;153;1"
Uses my LS_COLORS and then ma sets the background of my selection to bold and color 153 from https://jonasjacek.github.io/colors/.
Found from https://www.zsh.org/mla/users/2010/msg00811.html

How to escape new line in man pages

I have refactored a man page's paragraph so that each sentence is it's own line. When rendering with man ./somefile.3 The output is slightly different.
Let me show an example:
This is line 1. This is line 2.
vs.
This is line 1.
This is line 2.
Are rendering like so:
First:
This is line 1. This is line 2.
Second:
This is line 1. This is line 2.
There is an extra space between the sentences. Note that I have made sure that there is no extra white space. I have more experience with Latex, asciidoc, and markdown and I can control that there, is it possible with troff/groff? I'd like to avoid that if possible. I don't think it should be there.
The troff input standard is to have a newline at the end of each sentence, and to let the typesetter do its job with filling. (Althought I doubt it was the intent, it does make it play nicer with source control.) Therefore, it considers sentence ends to be at the end of a line that ends with a period (or ? or !, and optionally followed by ',",*,],),or †). It also believes that sentences should have two spaces between them. This almost certainly derives from the typography standards at Bell Labs at the time; It's rather curious that this behavior is not settable through any fill modes.
groff does provide a way to set the "inter-sentence" spacing, with the extended .ss request:
.ss word_space_size [sentence_space_size]
Change the size of a space between words. It takes its units as one
twelfth of the space width parameter for the current font. Initially
both the word_space_size and sentence_space_size are 12. In fill mode,
the values specify the minimum distance.
If two arguments are given to the ss request, the second argument sets
the sentence space size. If the second argument is not given, sentence
space size is set to word_space_size. The sentence space size is used
in two circumstances: If the end of a sentence occurs at the end of a
line in fill mode, then both an inter-word space and a sentence space
are added; if two spaces follow the end of a sentence in the middle of
a line, then the second space is a sentence space. If a second
argument is never given to the ss request, the behaviour of UNIX troff
is the same as that exhibited by GNU troff. In GNU troff, as in UNIX
troff, a sentence should always be followed by either a newline or two
spaces.
So you can specify that the "sentence space" should be zero-width by making the request
.ss 12 0
As far as I know, this is a groff extension; heirloom troff supports it, but older dwb derived versions may not.
Example:
This is line 1. This is line 2.
This is line 1. This is line 2.
This is line 1.
This is line 2.
SET SENTENCE SPACING
.ss 12 0
This is line 1. This is line 2.
This is line 1. This is line 2.
This is line 1.
This is line 2.
Results:
$ groff -T ascii spaces.tr |sed -n -e/./p
This is line 1. This is line 2.
This is line 1. This is line 2.
This is line 1. This is line 2.
SET SENTENCE SPACING
This is line 1. This is line 2.
This is line 1. This is line 2.
This is line 1. This is line 2.
So the following will work, but I hope there is a better option.
This is line 1. \
This is line 2.
renders as
This is line 1. This is line 2.

How to turn off word wrap in iTerm2?

How to turn off word wrap in iTerm2? Is there a specific command to do so or in the preferences? I am trying to avoid having the text run down to the next line. I would rather scroll side to side.
lifted directly from https://apple.stackexchange.com/a/210666/115119
Props to #michid
Disable line wrapping:
tput rmam
Enable line wrapping:
tput smam
It appears that iTerm2 does not have the ability to turn off word wrap. There is an open issue (iTerm2 issue #1790) reported to "Provide toggle to turn on/off line wrapping".
The description of that issue reads:
Looks like a conversation was had in the Google Groups about this but no one ever actually filed a feature request.
http://groups.google.com/group/iterm2-discuss/browse_thread/thread/e0f4e9b552d8acd4
In general I don't like having horizontal scrollbars and prefer to have the lines wrap, but there are occasions...such as looking at long stack traces, that I'd rather just have sequentially indented lines line up and just be forced to scroll to the right to expose all the details. To accomplish this task now, I end up making the text incredibly small so I can read stack traces lined up, but even that doesn't always work.
In October, 2014, the creator of iTerm2 commented regarding the feature request to toggle word wrap, "I'd like to do this but it's a lot of work, so feel free to send a pull request, but don't be [a jerk]."
In April, 2015, the milestone for the feature request was changed to "Future Release".
For me, my issue was purely down to the configuration of my PS1 - not what I had originally expected!
The key for me was surrounding the following with any characters that wouldn't be printed as in your prompt - such as encoding colours. Sourced from https://linoxide.com/how-tos/change-bash-prompt-variable-ps1/
\[ This sequence should appear before a sequence of characters that don’t move the cursor (like color escape sequences). This allows bash to calculate word wrapping correctly.
\] This sequence should appear after a sequence of non-printing characters.

are multiple linear white space allowed in http header

I'm trying to understand http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT )
Can i put any number of <CR><LF><SP>, without putting any header value on the line ?
i.e. is this valid : Header:<CR><LF><SP><CR><LF><SP>Value
Yes, but see http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-22.html#rfc.section.3.2.4.p.3 - it's deprecated in the upcoming revision of the HTTP spec.

ed - line editor (what does $p do?)

I am using ed a unix line editor and the book i'm reading says to type 1,$p
(also works in vim)
after trial and error I figured the first value means the line number but whats the purpose to $p? from what i can tell is the 1 goes to the beginning of the line and $p goes to the EOF and displays to me everything it picked up. is this true or am i way off?
The 1,$ part is a range. The comma separates the beginning and end of the range. In this case, 1 (line 1) is the beginning, and $ (EOF) is the end. The p means print, which is the command the range is being given to, and yes.. it displays to you what is in that range.
In vim you can look at :help :range and :help :print to find out more about how this works. These types of ranges are also used by sed and other editors.
They probably used the 1,$ terminology in the tutorial to be explicit, but note that you can also use % as its equivalent. Thus, %p will also print all the lines in the file.

Resources