I use Sublime Text for reading program logs and sometimes logs can be very verbose !
I wonder if there is a trick/add-on in Sublime Text that can hide some verbose lines (based on regexp for example) ?
Thanks.
You can do this if you create a new syntax definition .tmLanguage file for your logs, and include the foldingStartMarker and foldingStopMarker keys. These files are XML-based, and the folding markers are defined by regular expressions, ranging from the straightforward (from SCSS):
<key>foldingStartMarker</key>
<string>\{\s*$</string>
<key>foldingStopMarker</key>
<string>^\s*\}</string>
to the complex (from Python):
<key>foldingStartMarker</key>
<string>^\s*(def|class)\s+([.a-zA-Z0-9_ <]+)\s*(\((.*)\))?\s*:|\{\s*$|\(\s*$|\[\s*$|^\s*"""(?=.)(?!.*""")</string>
<key>foldingStopMarker</key>
<string>^\s*$|^\s*\}|^\s*\]|^\s*\)|^\s*"""\s*$</string>
If you can divine some regexes for your log files, then all the magic and convenience of code folding is yours. Good luck!
Related
Something like those Unicode code point listings and similar plain text lists and tables meant for easy parsing that use hashes for line comments.
I'm asking because I'd like to use syntax highlighting for such formats if text editors support it.
I am copying a bunch of log output to a github issue and I want to indent it so that it is distinguishable as code/output from the rest of the issue.
How do I do this?
I tried:
CTRL+Tab
CTRL+[
CTRL+]
CTRL+Spacebar
but none seem to work? I really don't want to do every single line individually..
Wrap your code inside ```.
You can also specify language name after if your log file is analogus to any programming language's syntax.
e.g.
```yaml
You can refer Gihub Flavored Markdown for more info.
How can I prevent sublime text from extracting keywords in comments?
e.g. I have the following javascript source file
// some keyword
I do not want to have either some or keyword to be in the completion list.
Thought it would be a common question but couldn't find anything on it.
If you use Sublime Code Intel - https://github.com/SublimeCodeIntel/SublimeCodeIntel - you can get read suggestions for the correct methods and variables rather that just words that are used in your code.
If you are on ST3 it's a little hard to get up and running, but it's totally doable.
I found these instructions to work https://johnblackbourn.com/sublimecodeintel-st3
Assuming a syntax highlighter uses a lexer to do the background work: when typing in an IDE with live syntax highlighting, does the lexer have to re-tokenize the entire file (in whatever language, ex. Java, C++, Python, etc), does the lexer only have to re-read and tokenize the current line, or does it only keep itself occupied with a single character/word at a time?
I'm asking because in a lot of editors/IDEs, most code remains the same as the programmer is typing, however, in some cases there's stuff like starting a string literal, which re-highlights the rest of the line, and in other cases like starting a multi-line comment, the whole text file becomes re-highlighted from the point where I start the multi-line comment, to the end of the file.
If the lexical analysis has to be done for the entire file for every single letter typed, wouldn't that make it slow, especially for larger (100.000+ lines) text files?
There is a syntax highlight and semantic highlight.
Syntax highlight is when editor only decorates based on language syntax - e.g. identifiers are black, keywords are pink and comments are green. Syntax highlight does not necessarily reparses (or, rather, tokenizes) the whole file - it can only tokenize "damaged region" (e.g. tokens around edit location). Of course, editor developer may opt to tokenize the whole input - as it is really fast, error-proof and easier to implement.
Semantic highlight (one that, for instance, can highlight global and local identifiers differently) usually require complete reparse - e.g. in Java adding "static" to function declaration would require you to invalidate function references both above and below the cursor. In some cases caching may be implemented (e.g. cache include files parse result as user edit does not change it that much). Semantic highlight is slow so it is usually combined with syntax highligh (you may see in Eclipse that the keywords are highlighted instantly - while member variable changes the color from the black after some small delay).
I didn't look this up, but I am pretty sure that it depends what is being highlighted. That is, comparing the local area you are typing in with basic syntax; versus, say an open comment that until closed highlights from that point until the end of the file.
I'm currently using BlueCloth to process Markdown in Ruby and show it as HTML, but in one location I need it as plain text (without some of the Markdown). Is there a way to achieve that?
Is there a markdown-to-plain-text method? Is there an html-to-plain-text method that I could feel the result of BlueCloth?
RedCarpet gem has a Redcarpet::Render::StripDown renderer which "turns Markdown into plaintext".
Copy and modify it to suit your needs.
Or use it like this:
Redcarpet::Markdown.new(Redcarpet::Render::StripDown).render(markdown)
Converting HTML to plain text with Ruby is not a problem, but of course you'll lose all markup. If you only want to get rid of some of the Markdown syntax, it probably won't yield the result you're looking for.
The bottom line is that unrendered Markdown is intended to be used as plain text, therefore converting it to plain text doesn't really make sense. All Ruby implementations that I have seen follow the same interface, which does not offer a way to strip syntax (only including to_html, and text, which returns the original Markdown text).
It's not ruby, but one of the formats Pandoc now writes is 'plain'. Here's some arbitrary markdown:
# My Great Work
## First Section
Here we discuss my difficulties with [Markdown](http://wikipedia.org/Markdown)
## Second Section
We begin with a quote:
> We hold these truths to be self-evident ...
then some code:
#! /usr/bin/bash
That's *all*.
(Not sure how to turn off the syntax highlighting!) Here's the associated 'plain':
My Great Work
=============
First Section
-------------
Here we discuss my difficulties with Markdown
Second Section
--------------
We begin with a quote:
We hold these truths to be self-evident ...
then some code:
#! /usr/bin/bash
That's all.
You can get an idea what it does with the different elements it parses out of documents from the definition of plainify in pandoc/blob/master/src/Text/Pandoc/Writers/Markdown.hs in the Github repository; there is also a tutorial that shows how easy it is to modify the behavior.