I just want to define an autocommand that executes some external commands. For example, delete some auto-generated files after compilation. I work on both Windows and Linux, and the external commands used are different on these two platforms.
Therefore, I can define:
if has("win32")
autocmd foo bar_win
else
autocmd foo bar_nix
endif
If I want to define this autocommand within a augroup, should I simply put this piece of code into an augroup like:
augroup fooo
autocmd!
if has("win32")
autocmd foo bar_win
else
autocmd foo bar_nix
endif
augroup END
I tried this method, and it seems this works. I am wondering if this is the correct way to do it. Another way I can think about is to write the external commands into a function within which I can use if statement. Then define autocommand in the usual way and call this function. Which is better?
Thanks!
augroup foo and augroup END don't delimit a code block so it doesn't matter if you put your feature check there or elsewhere.
But you could follow this alternative pattern if you want safety and flexibility.
Define an empty autocommand group somewhere near the top of your vimrc:
augroup foo
autocmd!
augroup END
Run your feature check later:
if has("win32")
autocmd foo Event * command for windows
else
autocmd foo Event * command for unices
endif
Since your autocommands belong to group foo they are correctly removed when you :source $MYVIMRC.
Related
For example, I create a command named print_info
(gdb) define print_info
> i r
> end
now I want to edit this command to
i r $eax
I know I can just run define print_info and redefine it. But I want to know if I can just edit it base on the existed command. So that when the command is complex, I don't have to do a complete rewrite.
I want to know if I can just edit it base on the existed command.
No.
So that when the command is complex, I don't have to do a complete rewrite.
Save the commands into a file, and use source filename to re-define your print_info command after editing that file.
I want to use the library of babel of org-mode to define a new Clojure function that would be accessible to any org-mode document.
What I did is to define that new function in a named codeblock like this:
#+NAME: foo
#+BEGIN_SRC clojure
(defn foofn
[]
(println "foo test"))
#+END_SRC
Then I saved that into my library of bable using C-c C-v i, then I selected the org file to save in the library and everything looked fine.
Then in another org file I wanted to call that block such that it becomes defined in that other context. So I used the following syntax:
#+CALL: foo
However when I execute that org file I am getting the following error:
Reference `nil' not found in this buffer
Which tell me that it can't find that named block.
Any idea what I am doing wrong? Also once it works, is there a way to add new parameters to that code block when called using #+CALL:?
Finally, where is supposed to be located my library of babel? (how to know if it got properly added or not?)
I am obviously missing some core information that I can't find in the worg documentation.
Try:
#+CALL: foo()
Also, check the value of the variable org-babel-library-of-babel to make sure that the C-c C-v i worked properly.
I defined a macro in a module, and it works fine.
Now, I'm trying to document said macro with an example. Apparently, I need to manually specify the crate line to ask for macros:
/// ```
/// # #[macro_use] extern crate foo;
/// // Some code
/// ```
However, I now get an error saying:
error: an `extern crate` loading macros must be at the crate root
Apparently the example code is loaded in the macro's module, and does not seem compatible with macro_use...
I can't believe everyone writes macros directly in the root module... right?
Well adding a main function did the trick. My example code did not need to run anything (just compile) so I didn't even bother adding a main function, but apparently adding it puts the code in a virtual "crate root", and it accepts the macro_use. Yay!
So what I did is just add :
/// # fn main() { }
I'm trying to use vim plugin hints_opengl.vim, but it is not working as intended. If you look at the plugin's code, it is supposed to :echo some text using :inorea call like this:
inorea glEnd glEnd<c-o>:echoh HintHL<Bar>echo "void glEnd(void)"<Bar>echoh None<cr>
However for me it doesn't echo anything. I tried to define some inoreas with :echo command like this:
inorea hhh hhh<c-o>:echo "hello"<cr>
But those didn't work either. However doing <c-o>:echo "something" manually during typing in insert mode works fine. What should I do then to properly echo text with :inorea? How do I get this plugin to work?
You don't see the messages in insert mode because the default height of the command-line is one, and the -- INSERT -- immediately overwrites your message.
Either increase the height:
:set cmdheight=2
or turn off the display of the current mode:
:set noshowmode
I often write classes with a DLL export/import specification, but this seems to confuse emacs' syntax parser. I end up with something like:
class myDllSpec Foo {
public:
Foo( void );
};
Notice that the "public:" access spec is indented incorrectly, as well as everything that follows it.
When I ask emacs to describe the syntax at the beginning of the line containing public, I get a return of:
((label 352))
If I remove the myDllSpec, the indentation is correct, and emacs tells me that the syntax there is:
((inclass 352) (access-label 352))
Which seems correct and reasonable. So I conclude that the syntax parser is not able to handle the DLL export spec, and that this is what's causing my indentation trouble.
Unfortunately, I don't know how to teach the parser about my labels. Seems that this is pretty common practice, so I'm hoping there's a way around it.
From http://www.emacswiki.org/emacs/IndentingC#toc13 you can set up a "microsoft" style.
Drop this into your .emacs:
(c-add-style "microsoft"
'("stroustrup"
(c-offsets-alist
(innamespace . -)
(inline-open . 0)
(inher-cont . c-lineup-multi-inher)
(arglist-cont-nonempty . +)
(template-args-cont . +))))
(setq c-default-style "microsoft")
or leave the default and set it manually via M-x c-set-style to microsoft.
Your example renders this indentation:
class myDllSpec Foo {
public:
Foo( void );
};