I switched over to Sublime Text 3 but now that I was coding some Haskell in ST3 I noticed something quite odd, which is the syntax highlighting logic for guards.
As you can see, when I write it this way, it highlights the first guard in white colour and the different sign in a mix of white/magenta:
Only when I use this wrong syntax (with an equal sign after the argument) it displays correctly.
Does anyone know how to fix this?
You're probably using the default Haskell syntax highlighting. I would recommend disabling the Haskell package and installing SublimeHaskell. Its syntax highlighting is much better, and it recognizes things like otherwise as being a "built-in" (it's mainly Prelude functions that are considered built-in).
If you're using the built-in Haskell highlighting, you can check that it's buggy by using the CtrlAltShiftP shortcut. Highlight each guard pipe individually and then hit this shortcut. In the status bar it'll briefly show the syntax scope names associated with the region. For the first pipe, you'll get source.haskell meta.function.type-declaration.haskell, and for the second you'll get source.haskell keyword.operator.haskell. Using SublimeHaskell's syntax you'll get source.haskell keyword.operator.haskell for both pipes. I won't say that SublimeHaskell's is perfect (try indenting an entire file after module Name where), but it's definitely better. Since the syntaxes have the same name and because SublimeHaskell comes with snippets and whatnot that cover everything that the built-in does, I recommend disabling the Haskell plugin and only leaving SublimeHaskell's syntax selectable.
(NOT SURE!!!)
I now believe this is not a bug, instead I believe this is actually ST3's way of telling you you have non-exaustive patterns in that function.
Non-exaustive: http://i.imgur.com/74o4sgp.png
Exaustive: http://i.imgur.com/M9a4TTL.png
Related
Inspired by several posts, like Your syntax highlighter is wrong, Coding in color and A case against syntax highlighting and some others, I decided making a Vim theme that applied some of these concepts would be a good idea.
The thing is I'm not exactly sure how.
From what I can tell, in order to make a Vim theme you need to basically link a color with a syntax identifier or name. And repeat this hundreds or dozens of time in order to have in your lap a theme.
Like for example linking the color #ff0000 (red) and the syntax identifier, or key, Error. As an example. Not sure if that's actually the syntax key.
This would work fine, except that, every syntax that I don't consider important I have to define as just a default foreground value.
And let's say I wanted to add a new syntax keyword, I'd have to do it with ftsyntax and stuff (I believe) and that would be filetype specific etc.
So the first question is:
What would be the best way to give everything a default foreground color and only pick the exceptions to have some colors?
And the second, perhaps more important question is:
How do I syntax highlight a specific piece of text without having to add a syntax rule? For example have a regex that finds any = and highlights them green, without having to add a syntax rule specific for that.
Any help is appreciated. Of course if the approach I'm taking to this is not ideal or sucks I am open to suggestions to alternatives. Thank you. :)
See the example syntax file below:
syn keyword myKeywords We Are Important Keywords
syn match myEquals '='
hi link myKeywords Special
hi link myEquals Operator
This will put We, Are, Important and Keywords into the myKeywords syntax group and = into the myEquals syntax group.
Then we specify how we want to highlight them, by linking it to the Special and Operator highlight groups.
See: :help group-name for a list of the highlight groups and what the colors look like with your color-scheme.
In my color-scheme, Special is Red and Operator is green.
By default, everything else is set to the default foreground color.
I saved this to ~/.vim/syntax/greduan.vim and tested with :set syntax=greduan
Your question touches two domains:
syntax definition
syntax highlighting
Syntax definition, as in Caek's answer, is simple for the first 10 minutes but grows very quickly into a major PITA because it is a core aspect of Vim's architecture with ramifications far beyond syntax highlighting.
Syntax highlighting has its pitfalls but it is a lot simpler than syntax definition.
I think that you can tackle the problem described in those blog posts with syntax highlighting first and, if needed, graduate to syntax definition.
Grab a simple colorscheme like Busybee.
Link all the highlight groups you don't need to Normal while leaving the ones you want to keep:
hi link Foo Normal
What would be the best way to give everything a default foreground
color and only pick the exceptions to have some colors?
What is best depends ... for me the best, because quickest way was clearing unwanted highlighting in ~/.vimrc:
sy on
hi c Constant|hi c Error|hi c PreProc|hi c Special|hi c Statement|hi c Type
hi c Identifier
How do I syntax highlight a specific piece of text without having to
add a syntax rule?
If by syntax rule you mean syntax item, I'd say you cannot have syntax highlighting without defining syntax items.
I'm using Vim's SmartTabs plugin to alingn C code with tabs up to the indentation level, then spaces for alignment after that. It works great for things like
void fn(int a,
________int b) {
--->...
Tabs are --->, spaces are _. But it doesn't seem to work so well for cases like
--->if(some_variable >
--->--->some_other_variable) {
--->...
In the case above, Vim inserts tabs on the second line inside the parentheses. Is there a way I can modify what Vim sees as a continuation line to include cases like this, so I get:
--->if(some_variable >
--->___some_other_variable) {
--->...
If there's an indentation style that would both allow flexible indentation width according to one's preferences, and consistent alignment, your suggested scheme would be it. Unfortunately, this style requires some basic understanding of the underlying syntax (e.g. whether some_other_variable is part of the line-broken conditional (→ Spaces) or a function call within the conditional (→ Tab)), and this makes implementing it difficult.
I'm not aware of any existing Vim plugin. The 'copyindent' and 'preserveindent' options help a bit, but essentially you have to explicitly insert the non-indent with Space yourself (and probably :set list to verify).
I don't know about that other Editor, but the situation is similar for most other inferior code editors. Without good automatic support, this otherwise elegant style will have a hard time gaining acceptance. I would love to see such a plugin for Vim.
I have access to a syntax highlighting program for an internal-only language. Is there any way in which I could get vim to call this program to perform syntax highlighting? I figure that it's worth seeing if this is possible before I write my own syntax file, since it's quite complex (not to mention prone to change). The program in question could be quite easily customized to output in a new intermediate format (it's only currently outputting HTML), if that would make things easier.
I would suggest to write a quick throwaway script in the language of
your choice to convert the output of the program in question to the Vim
highlighting syntax. You mentioned the program is prone to change, but
its output format can be easily customized: using your own conversion
script (which parses the programs output format) you could easily stay
up-to-date with the latest changes (just run your script again). And as
others have mentioned: creating a new syntax file is really easy in Vim,
so it's up to the complexity of the programs output how hard this actually is.
Yes, you can use vim job/channels to communicate with external process and highlight text using textprops.
Type :help channel and :help textprop in vim to get more info.
This method is used to implement treesitter highlighting in vim-treesitter plugin
I installed haskel-mode in emacs. Then I write in my .emacs:
(load "~/.emacs.d/haskell-mode/haskell-site-file")
(add-hook 'haskell-mode-hook 'turn-on-haskell-doc-mode)
(add-hook 'haskell-mode-hook 'turn-on-haskell-indentation)
(add-hook 'haskell-mode-hook 'haskell-font-lock-symbols t)
(put 'downcase-region 'disabled nil)
What must I add in my conf file that emacs could autocomplete for Haskell? Or Haskell mode there is no such possibility?
When there is no language-specific support, you can use tags. This is a generic completion mechanism.
Generate a TAGS file, which contains a list of identifiers and where they are defined. Emacs comes with the etags program to do this in many languages, but not Haskell; ghc comes with hasktags.
Load the TAGS file with M-x visit-tags-table.
Tags are not context-dependent, so they'll indiscriminately suggest types, values, constructors, etc everywhere. They also won't provide advanced features such as easily showing the type of a value. The most important tags commands are:
M-TAB (complete-symbol) completes an identifier according to the loaded list of tags.
M-. (find-tag) goes to the place where the identifier at point is defined, opening the containing file if necessary.
M-* (pop-tag-mark) goes back where you were before M-..
M-x tags-apropos shows a list of identifiers matching a regexp.
For more information, look under "Tags" in the Emacs manual.
For an even cruder, but fully automatic mechanism, there is the dynamic abbrev feature. C-M-/ (dabbrev-completion) looks in most open buffers for a completion; this is completely language-independent, so it'll even find words in strings, comments, whatever. M-/ (dabbrev-expand) is similar, but directly completes to the nearest match before point.
ghc-mod provides some completion for Haskell within Emacs, as well as checking with hlint and ghc. In combination with M-/, it's good enough for me.
haskell-mode currently provides no such possibility. There is some work on implementation of haskell parser for CEDET - in this case, users will get autocompletion features automatically. But this work had started not so much time ago...
My setup is a little more complicated. It uses the auto-complete infrastructure which
shows a dropdown list of candidates automatically similar to traditional IDEs. I downloaded this script that hardcodes all the keywords. In addition to that, I use ghc-mod to generate module names.
As a "cheap and cheerful" autocompletion mechanism, don't overlook M-/. It's completely heuristic and language-independent, but surprisingly effective.
Besides autocompletion for your own code, you can also get autocompletion (with apidocs even) for the standard library, import names, and pragma names using company-ghc. I found this guide to be very helpful. Note, I didn't get it to work fully for myself yet, but I can feel I'm close :-)
Background: JEdit (and some other text editors as well) support a feature called Multiple simultaneous text insertion points. (at least that's what I'm calling it here).
To understand what this means, take a look at the link.
Out of all the features in use in modern text editors, initial research seems to indicate that this is one feature that both Emacs and Vim do not actually support. If correct, this would be pretty exceptional since it's quite difficult to find a text editor feature that has not made its way into at least one of these two old-school editors.
Question: Has anyone ever seen or implemented this feature in either Emacs, Vim, or both? If so, please point me to a link, script, reference or summary that explains the details.
If you know an alternate way to do the same (or similar) thing, please let me know.
The vim way to do this is the . command which repeats the last change. So, for instance, if I change a pointer to a reference and I have a bunch of
obj->func
that I want to change to
obj.func
then I search for obj->, do 2cw to change the obj-> to obj., then do n.n.n. until all the instances are changed.
Perhaps not a flexible as what you're talking about, but it works frequently and is very intuitive and fast when it does.
moccur-edit.el almost does what you want. All the locations matching the regexp are displayed, and the editing the matches makes changes in the corresponding source. However, the editing is done on a single instance of the occurrence.
I imagine it'd be straight forward to extend it to allow you to edit them all simultaneously (at least in the simple case).
There is a demo of it found here.
Turns out, the newest versions of moccur-edit don't apply changes in real-time - you must apply the changes. The changes are also now undoable (nice win).
In EMACS, you could/would do it with M-x find-grep and a macro. If you really insist that it be fully automatic, then you'd include the find-next in the macro.
But honestly, this strikes me as a sort of Microsoft-feature: yes, it adds to the feature list, but why bother? And would you remember it existed in six months, when you want to use it again?
For emacs, multiple-cursors does exactly that.
Have a look at emacsrocks episode 13, by the author of the module.
I don't think this feature has a direct analogue in either Emacs or Vim, which is not to say that everything achievable with this feature is not possible in some fashion with the two 'old-school' editors. And like most things Emacs and Vim, power-users would probably be able to achieve such a task exceedingly quickly, even if mere mortals like myself could spend five minutes figuring out the correct grep search and replace with appropriate back-references, for example.
YASnippet package for Emacs uses it. See 2:13 and 2:44 in the screencast.
Another slight similarity: In Emacs, the rectangle editing features provided by cua-selection-mode (or cua-mode) automatically gives you multiple insertion points down the left or right edge of the marked rectangle, so that you can type a common prefix or suffix to all of those lines.
e.g.:
M-x cua-selection-mode RET (enable the global minor mode, if you don't already use this or cua-mode)
C-RET down down down (marks a 1x3 character rectangle)
type prefix here
C-RET (unmark the rectangle to return to normal editing)
It should be something like this in vim:
%s/paint.\((.*),/\1.paint(/
Or something like that, I am really bad at "mock" regular expressions.
The idea is substitute the pattern:
/paint(object,/
with
/object.paint(/
So, yes, it is "supported"
It seemed simple to do a basic version of this in Emacs lisp. This is for when you just want two places to insert text in parallel:
(defun cjw-multi-insert (text)
"insert text at both point and mark"
(interactive "sText:")
(insert-before-markers text)
(save-excursion
(exchange-point-and-mark)
(insert-before-markers text)))
When you run it, it prompts for text and inserts it at both point (current position) and mark. You can set the mark with C-SPC. This could be easily extended for N different positions. A function like set-insert-point would record current position (stored as an Emacs marker) into a list and then when you run the multi-insert command, it just iterates through the list adding text at each.
I'm not sure about what would a simple way to handle a more general "multi-editing" feature.
Nope. This would be quite difficult to do with a primarily console-based UI.
That said, there is similar features in vim (and emacs, although I've not used it nearly as much) - search and replace, as people have said, and more similarly, column insert mode: http://pivotallabs.com/users/brian/blog/articles/350-column-edit-mode-in-vi