from https://stackoverflow.com/a/21666354/433570
It's dos based solution though, can it be done for linux based system?
I'm trying to highlight stuff in my log file.
For instance, I want to highlight the line of nginx log which has slower response time than 1 sec.
** edit **
Currently I'm using hi-lock-mode
eg, I put a mark on a line that shows slow response, then use regex & hi-lock to highlight it.
I guess this is ok solution, for now.
I am wondering if there's a better solution.
hi-lock mode with user-defined function rather than regex is what I would hope for.
I would define functions, and mapping between function-color.
Then I would M-x apply [function]
def slow(line):
if ... :
return True
return False
slow: yellow,
iPhone: blue,
I think this would be useful to inspect logs..
I wonder if there's a similar functionality available out there?
Why don't you write your own major mode for your files?
A basic major mode with font-lock support is not hard to implement. There are plenty of documentation on this on the net. All you need is a syntax table (so that Emacs would know which characters start strings etc.) and some font-lock rules for syntax highlighting.
The easiest, though, is to start with an existing one, for example ini-mode, a small major mode for editing Windows-style ini files.
Unless your files have a specific file extension or otherwise follow a specific naming convention, you might want to add an entry to magic-mode-alist, which provides you with a way to recognize specific files based on the content rather than the file name.
If you would like to see your files colored in a terminal window when viewed using more or less, you can use e2ansi, a package that use Emacs to generate an ANSI version of syntax highlighted files.
Related
There are some files like GEDCOM and ADIF that are plain text files, but many people tend to work with them through GUIs. Say I wanted to do data entry on these files directly without any GUI.There are a number of things that make this a little dangerous. Things like misspellings of necessary file-grammar, missing a necessary key, incorrect types for values, etc. There is also something to be said for the additional difficulty of having to type additional characters relative to a GUI.
From what I can tell by thinking about this for 15mins ;) is that having the following would make the job of plain text entry much easier.
A formatter. I think of something like Python's Black which is a CLI that can be run on a file. It can let users know of bad formatting and can provide fixes.
A linter. I think of flake8 to ensure the styling matches the standard.
Autocomplete. The file type examples I showed above have a dictionary of key words. To save on typing it would be nice to have autocomplete.
Syntax Highlighting. Having a way to know if my data entry is good or bad in real-time would be helpful.
It seems like requirements 1-2 could be solved by making a file specific CLIs that combs through plain text files.
Requirement 4 seems IDE specific. vim and vscode allow users to make syntax highlighting plugins. The problem is that this is normally solved by connecting to a language server. When you are not looking for a language server, but for key words and proper values in a plain text file how does let their IDE know that to look for? Is this just a regex soup solution or is there a better way?
Requirement 3 may also be IDE specific, but the same question applies as for requirement 4. When there is not a language server how can I let an IDE know what/how to autocomplete?
Any examples of plain text data entry made easier would be appreciated.
Thanks!
I have 10-20 configuration files in which I have to change the same setting quite often.
I was thinking about multi cursor approach (like in Sublime Text), but in multiple documents at the same time.
I can use find/replace in files, etc, but I would love to see what is being edited and selecting same 'setting key' just by pressing CMD + D would be just amazing.
Anyone knows an editor which can do multi-cursor editing in multiple buffers/documents? Or maybe another way of efficiently editing multiple files which are almost identical?
This is not possible in Sublime, nor any other editor of which I'm aware. In Sublime, for example, you can have multiple open files in different tabs and/or windows, but only one has the focus at any one time. It just doesn't make much sense to have input going to multiple windows at once.
Your problem is just crying out for a scripted solution. In Sublime you can create macros and Python-based plugins, as well as using regex-based search and replace. If you're using a shell like bash with access to the standard array of command-line utilities, you can use any number of ways (sed, awk, Python, Perl, expect, and many more) to identify the desired files, select the setting that needs to be changed, and change it, either automatically or with confirmation at each step.
I use ctags+Vim for a lot of my projects and I really like the ability to easily browse through large chunks of code quickly.
I am also using Stata, a statistical package, which has a script language. Even though you can have routines in the code, its code tends to be series of commands that perform data and statistics operations. And the code files can be very long. So I always find myself in need of a way to browse it efficiently.
Since I use Vim, I can use marks. But I was wondering if I could use ctags to do this. That is, I want to create a tag marker which (1) won't cause a problem when I run the script (2) easy to introduce to ctags.
Because it is supposed to not break the script, it needs to be a comment. In Stata, comment lines start with * and flow comments can be made by /* ..... */.
It would be great, for example, have sections in the code, marked by comments:
* Section: Data
And ctags picks up "Data Manipulation" as the tag. So I can see a list of sections and jump to them easily without the needs for creating marks.
Is there anyway to do this? I'd appreciate any comments.
You need a way to generate a tags database for your Stata files. The format is simple, see :help tags-file-format. The default tags program, Exuberant Ctags can be extended with regular expressions (--langmap, --regex); that probably only yields an approximate parsing for complex languages, but it should suffice for custom section marks; maybe you could even directly extract interesting language keywords.
First off, I was about to write a long list of if/else statements in vim and realized that 1) there was a better way to do what I was trying to do and 2) SO would be ripe with help on the subject. So! I have a variety of files spread about like
foo/src/file01.C
foo/src/file02.cc
foo/src/file03.c
foo/include/file01.hh
foo/include/file02.h
foo/include/file03.h
If you notice that the C/H, cc/hh, c/h extension may or may not match then you are keen and I'd like you to please help. I've look at things like the following vim scripts from the Vim wiki for "Easily switch between source and header file" and although I only dumped a few hours into a.vim without success, it doesn't seem that the others would work via the docs on that page. So can anyone help out on how to make this work?
A good lead I had was a quick How to Easily Switch between Header and Source topic, but still couldn't make it work.
I guess what I really want is how to avoid the multiple if statements and use real matching to do what I want. I want to look into another directory and if look for a header file of the same name with any familiar extension if it was a source C/C++ file, or look for a source file of any regular extension if it was a header file. Thanks for your help!
UPDATE: I specifically want to open the file in a new tab. I live on vim tabs!
I recommend using the FSwitch plugin. https://github.com/derekwyatt/vim-fswitch
This does exactly what you need out of the box. It is better than a.vim in more than one way, being a rewrite of the idea behind a.vim.
The link you posted presents it as a solution, too.
I have just installed it to my vim configuration and it does its job well.
Enjoy.
Just to make sure I was using the most current version, I downloaded the latest a.vim script (2.18) and copied it into my ~/.vim/plugin directory.
You can define certain variables in your ~/.vimrc file to get a.vim to recognize alternate file extensions.
To get the files in your example to match their alternates I added the following to my ~/.vimrc:
let g:alternateExtensions_C = "H,hh"
let g:alternateExtensions_hh = "C"
These are global variables that allow you to override what's already defined. You'll have to define
both relationships (they don't work both ways).
You can see what the current mappings are by typing:
:echo g:alternateExtensionsDict
If you need to define other mappings, follow the same pattern. What comes after the underscore is the file extension you're editing. What's in the double quotes is a comma-separated list of alternate extensions.
let g:alternateExtensions_<ext> = "<list,of,alt,ext>"
If you have a different directory structure, you can define what paths to search by overriding the g:alternateSearchPath variable. ../src and ../include are already included by default.
:echo g:alternateSearchPath
To open the alternate file in a new tab:
:AT
By the way, the a.vim script is pretty well documented. You might want to open it up and take a look. I found a setting or two that I didn't know about and I've been using it for years ;o)
I hope that helps.
IMO your best option is to adopt existing scripts to use :tabf instead of :e or whatever the scripts use right now to open the counterpart file. You can also try to make the change configurable and submit it to the script author. (I'm pretty sure many would find the enhancement useful.)
That reminded me of a trick I used very long time ago. Instead of guessing where the corresponding source/header files are, I have used at the top of file special comment containing relative path to the counterpart file. Switching was as simple as finding the special comment, extracting file name and opening it. Problem was similar to yours in that file extensions were not predictable. My rational solution was to stop guessing and denote counterparts explicitly in the source code. (This days I would have probably tried to put the relationship table into an external file with a standard name and look it up in VIM using the upward search.)
Two helpful things
:he 'path'
:he tabfind
So you would do
:set path=../,/usr/include/,/home/buildagent/SDKROOT/mysdk/inc
:tabfind error_codes.h
to open error_codes.h from somewhere exotic without having to specify it. Note how vim globbing is very very flexible, so you might not need mucht
:argadd ./**/*.[h,H] | tab sall
will open all header files under the current directory, regardless of how many levels deep. Be careful running this command on a large tree or with symlinks outside the tree
Background:
It seems that some text editors and IDEs are starting to get more "browser-like" in their features. Specifically, one such feature is the ability to treat ordinary text in an open text buffer as a hyperlink to another file, resource, or even a runnable command.
Programming this as an editor plugin or macro
Since this seems like a good idea, I have started programming some scripts and editor addons to do this very kind of thing, so that the user of a text editor can open or operate on links of the following style:
href="c:/files/foobar.txt" (click to open file)
href="c:/files/foobar.txt" jumpto="34" (jump to a line number)
href="c:/files/foobar.txt" find="Lorem" (jump to 1st line containing word)
href="find_in_files://c:/files" find="Lorem" (show all matching lines)
[[find_in_files://find=Lorem;exten=*.htm*]] (alternate syntax option)
href="redir://c:/files/feebar.txt" (replace current edit buffer)
href="run://c:/files/foobar.jpg" (open in default image editor)
[[run://c:/files/foobar.jpg;runwith=foo.exe]] (alternate syntax option)
Questions:
Is there any kind of emerging convention for forming text-based hyperlinks?
If there is a convention for this kind of thing, is there a published specification?
Is there an implementation of this idea in your favorite editor/IDE?
Is there an alternate pre-existing approach for this idea that does not use hyperlinks?
How is this feature handled in the "grand-daddy" editors? (Vim, Emacs)
Update:
It looks like the question could have been clarified, but it turns out that Emacs Org mode is one specific example of what I was looking for that answers all of my questions.
Emacs' Org-Mode has support for all kinds of Hyperlinks.
There are several script for Vim that add hyperlinks and markup. One of the most popular is Viki.
URLs, such as http://example.com/ (notice SO automatically links that), and sometimes a "www." prefix, just because it's so common. Email addresses are another example commonly recognized.
But not this quasi-xml-attribute stuff you have.
Of course not; once you try and make plain text follow some convention, you no longer have plain text.
Yes, see #5.
Yes, see #5.
It's extremely common for editors, especially programmers' editors, to have scripts, macros, tools, or whatever-they-want-to-call-it. Usually these are not controlled directly by the text in the file, but may use the file, filename, selection, cursor position, directory of the current file, etc. I expect many good programmers use such features without thinking about them anymore.
Mostly it sounds like you're trying to solve a problem that doesn't exist.
Surely the jumpto="34" and find="Lorem" could be replaced with web-browser-style # and ? marks.
So your second and third example would look like so:
href="c:/files/foobar.txt#34" (jump to a line number)
href="c:/files/foobar.txt?Lorem" (jump to 1st line containing word)
Although, as Roger Pate says above, it does sound like you're solving a problem that doesn't exist.
Emacs also has "find-file-at-point", which you can invoke with M-x ffap
See also LinkD. Nothing fancy like Org. Simple, small.