Can we also do the following expression in Xaringan, in particular left brace?
I borrow the idea from https://tex.stackexchange.com/questions/164664/how-to-create-an-array-with-both-vertical-and-horizontal-braces-around-the-eleme.
There might be some package limit in xaringan, but it would be great if this can be possible with Xaringan.
Related
I'm trying to create a regular expression in sieve. The implementation of sieve that I'm using is Dovecot Pigeonhole
I'm subscribed to github project updates and I receive emails from github with the subject in the format that looks like this:
Re: [Opserver] Create issues on Jira from Exception details page (#77)
There is a project name in square bracket included in the subject line. Here is the relevant part of my sieve script:
if address "From" "notifications#github.com" {
if header :regex "subject" "\\[(.*)\\]" {
set :lower :upperfirst "repository" "${1}";
fileinto :create "Subscribtions.GitHub.${repository}"; stop;
} else {
fileinto :create "Subscribtions.GitHub"; stop;
}
}
As you can see from the above, I'm moving the messages to appropriate project IMAP folders. So the message with the subject above will end up in Subscribtions.Github.Opserver
Unfortunately, there is one small problem with this script. If someone adds square brackets in the title of their github issue, the filter breaks. For example if the subject is:
[Project] [Please look at it] - very weird issue
The above filter will move the message to folder Subscribtions.Github.Project] [please look at it which is completely undesirable. I'd like it to be moved to Subscribtions.Github.Project anyway.
This happens because by default regular expressions are greedy. So they match the longest possible match. However when I try to fix it the usual way changing "\\[(.*)\\]" to "\\[(.*?)\\]" nothing seems to change.
How do I write this regular expression so that it acts as desired?
The answer is to change "\\[(.*)\\]" to "\\[([^]]*)\\]".
By reading regex spec linked in the question we disvover that POSIX regular expression are used. Unfortunately those do not support non-greedy matches.
However there is a work around in this particular case, given above.
I pose the question because I think both the question and possible answers might help Emacs users who write Lisp code that defines font-lock-keywords. I'm providing one answer that I think helps. I'm also interested in other answers.
That variable's value is a list of expressions, each of which can specify one or more patterns to match or functions to perform matching, and one or more faces for highlighting the matching text. The possibilities for font-lock-keywords values are numerous and complicated. (The doc describing this is the Elisp manual, node Search-based Fontification.)
In most cases the list has more than one element, which means more than one regexp pattern. These can interact in different ways. Some can prevent others from taking effect, or they can alter the effect of others. My library Dired+, for instance, defines font-lock-keywords in Dired mode with 31 entries (regexps), many of which interact.
How to keep all of that straight? How do you debug such a list when you are defining it or modifying it? You might comment out all but one of the list items, to see its effect when alone. And then repeat for another. And then perhaps add a few together, and maybe in different orders. There are various possibilities, I suppose, but just what do you do?
(OK, I know that most Elisp coders do not write super complex font-lock-keywords definitions. But even for simple definitions this can become complicated. And perhaps if this process were easier then users would not unnecessarily limit themselves to only one or two entries.)
You could use my newly released Font Lock Studio. The following is from the readme-file:
font-lock-studio - interactive debugger for Font Lock keywords
Font Lock Studio is an interactive debugger for Font Lock
keywords (Emacs syntax highlighting rules).
Introduction
Font Lock Studio lets you single-step Font Lock keywords --
matchers, highlights, and anchored rules, so that you can see what
happens when a buffer is fontified. You can set breakpoints on or
inside rules and run until one has been hit. When inside a rule,
matches are visualized using a palette of background colors. The
explainer can describe a rule in plain-text english. Tight
integration with Edebug allows you to step into Lisp expressions
that are part of the Font Lock keywords.
When using the debugger, an interface buffer is displayed, it
contains all the keywords and is used for navigation and
visalization of match data.
When Font Lock Studio is started, comments and strings are
pre-colored, as they are part of the earlier syntactic phase
(which isn't supported by Font Lock Studio).
Start the debugger by typing "M-x font-lock-studio RET". Press ?
or see the menu for available commands.
Example
For a buffer using html-mode, the interface buffer looks the
following. Other major modes typically have more and more complex
rules. The arrow on the left indicates the current active location.
A corresponding arrow in the source buffer is placed at the current
search location.
========================
=== Font Lock Studio ===
========================
--------------------------------------------------
=> "<\\([!?][_:[:alpha:]][-_.:[:alnum:]]*\\)"
(1 font-lock-keyword-face)
--------------------------------------------------
"</?\\([_[:alpha:]][-_.[:alnum:]]*\\)\\(?::\\([_:[:alpha:]]
[-_.:[:alnum:]]*\\)\\)?"
(1
(if
(match-end 2)
sgml-namespace-face font-lock-function-name-face))
(2 font-lock-function-name-face nil t)
--------------------------------------------------
"\\(?:^\\|[ \t]\\)\\([_[:alpha:]][-_.[:alnum:]]*\\)\\(?::
\\([_:[:alpha:]][-_.:[:alnum:]]*\\)\\)?=[\"']"
(1
(if
(match-end 2)
sgml-namespace-face font-lock-variable-name-face))
(2 font-lock-variable-name-face nil t)
--------------------------------------------------
"[&%][_:[:alpha:]][-_.:[:alnum:]]*;?"
(0 font-lock-variable-name-face)
--------------------------------------------------
"<\\(b\\(?:ig\\|link\\)\\|cite\\|em\\|h[1-6]\\|rev\\|s\\(?:
mall\\|trong\\)\\|t\\(?:itle\\|t\\)\\|var\\|[bisu]\\)
\\([ \t][^>]*\\)?>\\([^<]+\\)</\\1>"
(3
(cdr
(assoc-string
(match-string 1)
sgml-tag-face-alist t))
prepend)
==================================================
Public state:
Debug on error : YES
Debug on quit : YES
Explain rules : YES
Show compiled code : NO
Press space to single step through all the keywords. "n" will go
the the next keyword, "b" will set a breakpoint, "g" will run to
the end (or to the next breakpoint) and "q" will quit.
Features
Stepping
You can single step into, over, and out of Font Lock
keywords. Anchored rules are fully supported. In addition, you
can run to the end or to the next breakpoint.
Breakpoints
You can set breakpoints on part of the keyword, like the matcher
(e.g. the regexp), a highlight rule, or inside an anchored highlight
rule.
If you want to step or run without stopping on breakpoints, prefix
the command with C-u.
Note that in an anchored rule, you can set a breakpoints either on
the entire rule or on an individual part. In the former case, only
the outer parentheses are highlighted.
Match Data Visualization
After the matcher of a keyword or anchored highlight has been
executed, the match data (whatever the search found) is visualized
using background colors in the source buffer, in the regexp, and
over the corresponding highlight rule or rules. If part of a regexp
or a highlight didn't match, it is not colored, this can for
example happen when the postfix regexp operator ? is used.
Note that an inner match group gets precedence over an outer group.
This can lead to situations where a highlight rule gets a color
that doesn't appear in the regexp or in the source buffer. For
example, the matcher "\(abc\)" will be colored with the color for
match 1, while the higlight rule `(0 a-face)' gets the color for
match 0.
Normalized keywords
The keywords presented in the interface have been normalized. For
example, instead of
("xyz" . font-lock-type-face)
the keyword
("xyz" (0 font-lock-type-face))
is shown. See font-lock-studio-normalize-keywords for details.
Explainer
The explainer echoes a human-readble description of the current
part of the Font Lock keywords. This help you to understand that
all those nil:s and t:s in the rules actually mean.
When using the auto explainer, Font Lock Studio echoes the
explanation after each command.
Edebug -- the Emacs Lisp debugger
Tight integration with Edebug allows you to single-step expressions
embedded in the keywords in the interface buffer, and it allows you
to instrument called functions for debugging in their source file.
Follow mode awareness
The search location in the source buffer is visualized by an
overlay arrow and by updating the point. If the source buffer is
visible in multiple side-by-side windows and Follow mode is
enabled, the search location will be shown in a suitable windows to
minimize scrolling.
To help with this problem, I coded up an Icicles multi-command, icicle-font-lock-keywords. It lets you do things like the following:
Cycle among the separate font-lock-keywords entries (patterns), applying them individually to see the effect of each alone.
Pick individual entries and apply them separately, to see the same thing.
Pick a set of entries and apply it, in the same order the entries appear in font-lock-keywords. You can do this for any number of sets.
Accumulate the effect of multiple sets of entries, in the order you choose them.
Revert, to see the effect of all entries together, i.e., all of font-lock-keywords.
And you can do all of that, in any order, in a single invocation of the command.
M-o is the prefix key for Facemenu and font-locking, so I put this command on key M-o I, when in Icicle mode.
I'm trying to implement vim folding into an existing syntax file for the fountain.io markup language. The existing syntax file is here: http://www.vim.org/scripts/script.php?script_id=3880
But no matter what I do, my folding region doesn't end where I expect it to. The regexes work perfectly when I test them in search. But when used in a syntax region they created a series of nested folds. The fold starts on the appropriate line, and then the next fold is created inside the existing fold. Essentially I've tried to do the following so that a fold begins on any line that starts with INT or EXT, and ends after a line ends in TO: or a line begins with >:
syn region fountainScene start="^\(INT\|EXT\)" end="^\(\(\L\)* TO:\|\s*>\(.*\)\)$" fold transparent contains=fountainCharacter,fountainDialogue,fountainParenthetical,fountainSceneHeading,fountainTransition
Even stranger, if I use \ze on my 'end' argument to get the line previous to the matched line, it works as you would expect. It stops the fold on the line above the match, leaving the last line outside the fold. The following will stop folding above a line that says "CUT TO:"
\n\ze\(\L\)* TO:\n
To troubleshoot, I basically started rebuilding the syntax file from the ground up. Here is what is in the file so far (minus the hi commands) I have extensively modified the regular expressions to prevent them from overlapping with one another. The original regexes had this issue and I thought it might be the cause:
syn match fountainCharacter "^\(\s\)*\n\zs\(INT\|EXT\)\#!\(\L\)*[^:]$"
syn region fountainDialogue matchgroup=fountainCharacter start="^\(\s\)*\n\zs\(INT\|EXT\)\#!\(\L\)*[^:]$" end="^\s*$" contains=fountainCharacter,fountainParenthetical
syn match fountainParenthetical "^\s*\((.*)\)$"
syn region fountainSceneHeading start="^\(INT\|EXT\)" end="$" contains=fountainSceneNumber,fountainBoneyard,fountainNotes
syn match fountainTransition "^\(\L\)* TO:$"
syn region fountainScene start="^\(INT\|EXT\)" end="\n\ze\(\L\)* TO:\n" fold transparent contains=fountainCharacter,fountainDialogue,fountainParenthetical,fountainSceneHeading
Thanks for any help you can provide, and please let me know if I've been unclear in any way. I am using MacVim version 7.3.646 custom compiled with python support.
I finally figured this out. One of my elements was extending beyond the "end" argument. I had to use the "keepend" argument in my syn region.
This line fixed everything:
syn region fountainScene start="^\s*\(\.\|INT\. \|EXT\. \|INT\./EXT\. \|INT/EXT\. \|INT \|EXT \|INT/EXT \|I/E \|int\. \|ext\. \|int\./ext\. \|int/ext\. \|int \|ext \|int/ext \|i/e \)" end="^\(\(\L\)* TO:\|\s*>[^<]*\)$" fold transparent keepend
For more details see :he keepend
Background
I use JScript (Microsoft's ECMAScript implementation) for a lot of Windows system administration needs. This means I use a lot of ActiveX (Automated COM) objects. The methods of these objects often expect Number or Boolean arguments. For example:
var fso = new ActiveXObject("Scripting.FileSystemObject");
var a = fso.CreateTextFile("c:\\testfile.txt", true);
a.WriteLine("This is a test.");
a.Close();
(CreateTextFile Method on MSDN)
On the second line you see that the second argument is one that I'm talking about. A Boolean of "true" doesn't really describe how the method's behavior will change. This isn't a problem for me, but my automation-shy coworkers are easily spooked. Not knowing what an argument does spooks them. Unfortunately a long list of constants (not real constants, of course, since current JScript versions don't support them) will also spook them. So I've taken to documenting some of these basic function calls with inline block comments. The second line in the above example would be written as such:
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
That ends up with a small syntax highlighting dilemma for me, though. I like my comments highlighted vibrantly; both block and line comments. These tiny inline block comments mean little to me, personally, however. I'd like to highlight those particular comments in a more muted fashion (light gray on white, for example). Which brings me to my dilemma.
Dilemma
I'd like to override the default syntax highlighting for block comments when both the beginning and end marks are on the same line. Ideally this is done solely in my vimrc file, and not in a superseding personal copy of the javascript.vim syntax. My initial attempt is pathetic:
hi inlineComment guifg=#bbbbbb
match inlineComment "\/\*.*\*\/"
Straight away you can see the first problem with this regular expression pattern is that it's a greedy search. It's going to match from the first "/*" to the last "*/" on the line, meaning everything between two inline block comments will get this highlight style as well. I can fix that, but I'm really not sure how to deal with my second concern.
Comments can't be defined inside of String literals in ECMAScript. So this syntax highlighting will override String highlighting as well. I've never had a problem with this in system administration scripts, but it does often bite me when I'm examining the source of many javascript libraries intended for browsers (less.js for example).
What regex pattern, syntax definition, or other solution would the amazing StackOverflow community recommend to restore my vimrc zen?
I'm not sure, but from your description it sounds like you don't need a new syntax definition. Vim syntax files usually let you override a particular syntax item with your own choice of highlighting. In this case, the item you want is called javaScriptComment, so a command like this will set its highlighting:-
hi javaScriptComment guifg=#bbbbbb
but you have to do this in your .vimrc file (or somewhere that's sourced from there), so it's evaluated before the syntax file. The syntax file uses the highlight default command, so the syntax file's choice of highlighting only affects syntax items with no highlighting set. See :help :hi-default for more details on that. BTW, it only works on Vim 5.8 and later.
The above command will change all inline /* */ comments, and leave // line comments with their default setting, because line comments are a different syntax item (javaScriptLineComment). You can find the names of all these groups by looking at the javascript.vim file. (The easiest way to do this is :e $VIMRUNTIME/syntax/javascript.vim .)
If you only want to change some inline comments, it's a little more complicated, but still easy to see what to do by looking at javascript.vim . If you do that, you can see that block comments are defined like this:-
syn region javaScriptComment start="/\*" end="\*/" contains=#Spell,javaScriptCommentTodo
See that you can use separate regexes for begin and end markers: you don't need to worry about matching the stuff in between with non-greedy quantifiers, or anything like that. To have a syntax item that works similarly but only on one line, try adding the oneline option (:h :syn-oneline for more details):-
syn region myOnelineComment start="/\*" end="\*/" oneline
I've removed the two contains groups because (1) if you're only using it for parameter names, you probably don't want spell-checking turned on inside these comments, and (2) contained sections that aren't oneline override the oneline in the container region, so you would still match all TODO comments with this region.
You can define this new kind of comment region in your .vimrc, and set the highlighting how you like: it looks like you already know how to do that, so I won't go into more details on that. I haven't tried out this particular example, so you may still need a bit of fiddling to make it work. Give it a try and let me know how it goes.
Why don't you simply add a comment line above the call?
I think that
// fso.CreateTextFile(filename:String, overwrite:Boolean, unicode:Boolean)
var a = fso.CreateTextFile("c:\\testfile.txt", true, false);
is a lot more readable and informative than
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
I quite often use the regular expression search and replace in SQL Server Management Studio 10.5 editor to clean up auto generated sql before use. The same behaviour described below occurs in Visual Studio 2010 editor as well.
I have the following sql insert statement that I'd like to clean up:
INSERT INTO [lttadev].[dbo].[GameInst]
([GameInstId]
,[GameSetId]
,[UserInfoId]
,[GameLevelId]
,[CreatedOn]
,[CreatedBy]
,[ModifiedOn]
,[ModifiedBy])
VALUES
(<GameInstId, uniqueidentifier,>
,<GameSetId, uniqueidentifier,>
,<UserInfoId, uniqueidentifier,>
,<GameLevelId, uniqueidentifier,>
,<CreatedOn, datetime,>
,<CreatedBy, uniqueidentifier,>
,<ModifiedOn, datetime,>
,<ModifiedBy, uniqueidentifier,>)
To alter the values clause I have the two following regular expressions:
,[^,]*,\>
\<
Both are replaced by an empty string to delete the unwanted text. The first one strips out the comma, type, second comma and final angle bracket. The second one strips out the initial angle bracket. Both work as expected.
However if I join the regexes up into a single expression to speed the text processing, they select different text:
(,[^,]*,\>|\<)
The first expression selects the expected text. However the second expression gets the first angle bracket as well as the preceding comma. Is this a defect in the regular expression engine or am I not understanding something here?
Try wrapping the first alternative in parentheses:
(,[^,]*,\>)|\<
The documentation doesn't indicate what precedence | has, and it gives only this example:
(sponge|mud) bath
but elsewhere on that page are various examples where | is used with parentheses that would have been unnecessary (though harmless) in another regex engine:
(("[^"]*")|('[^']*'))
(- [a-z][1-3])|(- [0-9][a-z])
(([0-9]+.[0-9]*)|([0-9]*.[0-9]+)|([0-9]+))
so I'm guessing that | might have a fairly high precedence — lower than the trivial within-string concatenation of sponge or mud, but higher than more complex concatenations like in "[^"]*". (Of course, that last expression was written by someone who didn't notice that . has a special meaning, so it may warrant a grain of salt.)
Since I don't have Visual Studio, I can't test this out further.