I'm using Emacs as my main Haskell editor, and as such, I of course use haskell-mode as the main mode for editing Haskell code.
Now for whatever reason, haskell-indentation doesn't offer an indent point for function arguments.
What I mean is that Emacs will consistently do this: (□ is the other indent point(s))
myFunction = maybe arg1
□ arg2
□ arg3
Instead of doing this:
myFunction = maybe arg1
□ □ arg2
□ □ arg3
Sometimes I need to break functions up onto multiple lines due to the lines getting too long, but not having haskell-mode offer the right indent level is bugging me some.
Anything I can do to alleviate this?
Edit
Seeing as I'm not the only one with this issue, I've opened a ticket on the haskell-mode github page [here]
The haskell-indentation haskell-mode issue was closed last year and won't be fixed.
For desired behavior, use haskell-indent.
Related
we all know what ci" ci' ci( ci[ ... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target"
foo 'target'
foo (target)
foo {target}
foo [target]
foo <target>
if my cursor at the beginning of each line, (on the 'f'), then I type ci", ci', ci(...
the cix works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix, vix the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks #romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci", no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else "
foo (target x some(thing else )
I have above two lines, if (cursor at x) I type ci" and ci(, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
ci( is consistent with ci[, ci{ and cit and all the other <action>i<something>. Only ci' and ci" work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci" it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a " is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something> mechanism is somehow tied to a specific subsystem (maybe the same as showmatch?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i" to how the others work. To the point of actually doing 2t"ci" or some variant instead of ci"!! Inefficient, I know.
Did you read :h a'? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci" is different from ciband friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
make use of %
" nnoremap cb cib
nnoremap cb %cib
" nnoremap vb vib
nnoremap vb %vib
nnoremap yb %yib
nnoremap db %dab
to enhance %:
https://github.com/andymass/vim-matchup#tocbar-dopjfd
b can match ( [ {,
Want to use ' to match both ' and "?
nnoremap c' :call DoubleAsSingleC()<CR>
func! DoubleAsSingleC()
" When [!] is added, error messages will also be skipped,
" and commands and mappings will not be aborted
" when an error is detected. |v:errmsg| is still set.
let v:errmsg = ""
silent! :s#\"\([^"]*\)\"#'\1'#g
if (v:errmsg == "")
echo "双变单"
endif
exec "normal ci'"
endfunc
Similar for:
d'
y'
v'
Even though it says it does in the release notes for V 2.1.2 (which was quite a while ago). Obviously the code runs as it should, but it's distracting to have these forms syntax colored as though they were uncommented code. Does anyone have this working or know how to fix it?
Highlighting #_ correctly is hard. Since #_ 5 comments the 5 and #_ (foo) comments (foo) one has to highlight arbitrary expressions. Which may be separated from #_ by arbitrary whitespace. I never had enough pain to make it work. I'm not even sure, that Vim's highlighting capabilities are sufficient.
The issue tracker is here. However VimClojure's development is officially frozen. You might want to consider using the newer plugins.
The title has pretty much covered my question.
CallInstDLL is straigh forward and documented here.
CallInstDLL $INSTDIR\somedll.dll somefunction
Question is how is it different from a plugin (also called extension DLL). Extension DLLs are invoked as below
MyExtDll::MyFunction arg1 arg2 ...
There is no difference in the generated code, Dll::Export is just a syntax shortcut.
MyExtDll::MyFunction arg1 arg2 is expanded to something like this:
InitPluginsDir
File "/oname=$pluginsdir\MyExtDll.dll" "${NSISDIR}\Plugins\MyExtDll.dll"
Push arg2
Push arg1
CallInstDll "$pluginsdir\MyExtDll.dll" MyFunction
we all know what ci" ci' ci( ci[ ... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target"
foo 'target'
foo (target)
foo {target}
foo [target]
foo <target>
if my cursor at the beginning of each line, (on the 'f'), then I type ci", ci', ci(...
the cix works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix, vix the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks #romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci", no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else "
foo (target x some(thing else )
I have above two lines, if (cursor at x) I type ci" and ci(, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
ci( is consistent with ci[, ci{ and cit and all the other <action>i<something>. Only ci' and ci" work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci" it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a " is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something> mechanism is somehow tied to a specific subsystem (maybe the same as showmatch?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i" to how the others work. To the point of actually doing 2t"ci" or some variant instead of ci"!! Inefficient, I know.
Did you read :h a'? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci" is different from ciband friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
make use of %
" nnoremap cb cib
nnoremap cb %cib
" nnoremap vb vib
nnoremap vb %vib
nnoremap yb %yib
nnoremap db %dab
to enhance %:
https://github.com/andymass/vim-matchup#tocbar-dopjfd
b can match ( [ {,
Want to use ' to match both ' and "?
nnoremap c' :call DoubleAsSingleC()<CR>
func! DoubleAsSingleC()
" When [!] is added, error messages will also be skipped,
" and commands and mappings will not be aborted
" when an error is detected. |v:errmsg| is still set.
let v:errmsg = ""
silent! :s#\"\([^"]*\)\"#'\1'#g
if (v:errmsg == "")
echo "双变单"
endif
exec "normal ci'"
endfunc
Similar for:
d'
y'
v'
we all know what ci" ci' ci( ci[ ... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target"
foo 'target'
foo (target)
foo {target}
foo [target]
foo <target>
if my cursor at the beginning of each line, (on the 'f'), then I type ci", ci', ci(...
the cix works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix, vix the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks #romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci", no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else "
foo (target x some(thing else )
I have above two lines, if (cursor at x) I type ci" and ci(, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
ci( is consistent with ci[, ci{ and cit and all the other <action>i<something>. Only ci' and ci" work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci" it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a " is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something> mechanism is somehow tied to a specific subsystem (maybe the same as showmatch?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i" to how the others work. To the point of actually doing 2t"ci" or some variant instead of ci"!! Inefficient, I know.
Did you read :h a'? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci" is different from ciband friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
make use of %
" nnoremap cb cib
nnoremap cb %cib
" nnoremap vb vib
nnoremap vb %vib
nnoremap yb %yib
nnoremap db %dab
to enhance %:
https://github.com/andymass/vim-matchup#tocbar-dopjfd
b can match ( [ {,
Want to use ' to match both ' and "?
nnoremap c' :call DoubleAsSingleC()<CR>
func! DoubleAsSingleC()
" When [!] is added, error messages will also be skipped,
" and commands and mappings will not be aborted
" when an error is detected. |v:errmsg| is still set.
let v:errmsg = ""
silent! :s#\"\([^"]*\)\"#'\1'#g
if (v:errmsg == "")
echo "双变单"
endif
exec "normal ci'"
endfunc
Similar for:
d'
y'
v'