Here are 2 :s commands. Work fine at command line or as part of a key mapping, but I cannot get them to run correctly in a vim script. I've used normal, execute, execute "normal..." and call normal on them. I've put the range with the s, and before normal, I've tried them with and without a : before the s. How should I write them within a .vim file?
:%s/<[\/]\?SPAN\|DIV\|OPTION[^>]*>//gi
:%s/<\(hr\|h[1-6]\|ul\|li\|p\|tt\|ol\|table\|tr\|td\|p\) [^>]\+/<\1/gi
You can put Ex commands like yours into a myscript.vim file, then execute the commands via
:source myscript.vim
This should work without modifications (you don't need the leading :, but it doesn't hurt). I don't see any problems, and you don't need :execute unless you want to include variables. :normal is for normal-mode commands (like diw, for example).
Typically, you'd place those custom commands into a function, though (which would be placed in ~/.vimrc or ~/.vim/plugin/myscript.vim), and invoke it via :call, either directly, via a mapping, or custom command.
You should just add them to a script. You don’t have to prefix them with anything in this case.
Related
We have special files that contain JSON data mixed with # comments.
I figured I need to enhance Code's json.settings file with:
"files.associations": {
"*.ourextension": "jsonc"
}
but then I discovered that jsconc is about JSON data with // comments.
Is there a convenient way to get VS code to accept # comments in JSON data?
Edit: VS code recognizes the jsconc language, it gives me this error message:
And it also accepts // comments:
adding the // got me a green first line, and now the second line gets the first error (because starting with #).
If you use the Change Language mode command (or click on the language indicator on the status bar) you can select "jsonc JSON with Comments".
I think this is only auto-detected when the extension is .jsonc.
NB. JSON with comments uses JavaScript style single line comments: from a \\, outside a string literal, to the end of line.
To support some different comment indicator would require a new language mode (and an extension to add it).
A distinct non-answer: it might be possible to add a such a new language definition, but it would require quite a bit of work. I also had a quick look if I could simply change the corresponding config json file for jsonc that ships with VS code, but that file is rather complex, and would probably be overridden with the next VS code update.
Thus a straight forward workaround. Two scripts to replace one command style with the other:
#!/bin/sh
# a helper script that turns all # into //
# with the syntax that works for sed on MAC OS
for file in "$#"
do
sed -i '' -e 's,#,//,g' $file
done
Not exactly convenient, but fast and robust, given our specific requirements.
Basically, I know I can go through my control panel and modify the path variable. But, I'm wondering if there is a way to through batch programming have a temporary path included? That way it is only used during that batch file execution. I don't want to have people go in and modify their path variables just to use my batch file.
Just like any other environment variable, with SET:
SET PATH=%PATH%;c:\whatever\else
If you want to have a little safety check built in first, check to see if the new path exists first:
IF EXIST c:\whatever\else SET PATH=%PATH%;c:\whatever\else
If you want that to be local to that batch file, use setlocal:
setlocal
set PATH=...
set OTHERTHING=...
#REM Rest of your script
Read the docs carefully for setlocal/endlocal , and have a look at the other references on that site - Functions is pretty interesting too and the syntax is tricky.
The Syntax page should get you started with the basics.
There is an important detail:
set PATH="C:\linutils;C:\wingit\bin;%PATH%"
does not work, while
set PATH=C:\linutils;C:\wingit\bin;%PATH%
works. The difference is the quotes!
UPD also see the comment by venimus
That's right, but it doesn't change it permanently, but just for current command prompt.
If you wanna to change it permanently you have to use for example this:
setx ENV_VAR_NAME "DESIRED_PATH" /m
This will change it permanently and yes, you can overwrite it in another batch script.
I have a C extension to Tcl where command mytest is defined. The extension is compiled correctly (I am on Linux, extension is *.so). For example, I can start tclsh and use it like this:
$ tclsh
% load /path/extension.so
% mytest abc
...
But, if I create a file myscript.tcl with the following content:
load /path/extension.so
mytest abc
then I get error:
$ tclsh myscript.tcl
invalid command name "mytest"
while executing
"mytest abc"
(file "myscript.tcl" line 2)
I am using bash on Ubuntu 14.04. Tcl 8.6.
EDIT 1: My question/problem is that I want to use tclsh with a script as an argument - this script should properly load extensions in such a way that mytest and other implemented functions are working without error.
EDIT 2: Uhh, If I use command "source myscript.tcl" inside tcl shell the result is the same. If I use absolute path for myscript.tcl the error is still the same --- "load" executes without warning but I am not sure about it because I get invalid command name "mytest". Maybe the problem is with scope, but it is working correctly when tclsh is used interactively.
If you are using the full path of the extension library in both cases, that part should work identically. It probably is doing though; if it couldn't load it, it would generate an error (which might or might not be helpful, as some of the ways that things fail give very little information; Tcl reports what it has got, but that's sometimes not enough, as it is dependent on the OS to tell it some things). Instead, the problem is probably elsewhere.
The main difference between interactive use and scripted use is that in interactive use, the unknown command will expand unknown command names to Tcl commands that the thing you typed is an unambiguous prefix of. This is convenient, but when converting to a script, you should always use the full command name. OK, not the full full command name — you mostly don't want or need the :: namespace on the front — but without abbreviation, so don't use lappe for lappend. (In interactive use, Tcl will also exec things as external programs without requiring you to type the exec explicitly; again, that's turned off in scripts as it is rather fragile.)
Could it be that this is what is going on? You can check by setting the global variable tcl_interactive to 0 before typing in your code (I recommend using cut-n-paste for that typing, so that you know exactly what is going in). If that fails, it's the interactive-mode helpfulness that is tripping you up. Check what commands you might have as an expansion for a prefix with info commands (after the load, of course):
info commands mytest*
If that just reports mytest, my theory is wrong. (Well, if it does that and the length of that string is 6; there could theoretically be extra invisible characters have been put on the command name, which would be legal Tcl but very nasty and DON'T DO THAT!)
I'm not entirely sure how to define an Erlang function within an Erlang module. I'm getting the following error:
11> invoke_record:invoke().
** exception error: undefined function erlang:rr/1
From this simple code trying to invoke the rr(?MODULE). from within the beam executable in order to "initialize" records so that it doesn't need to be called from the shell every time.
-module(invoke_record).
-export([invoke/0]).
-record(process, {pid,
reference="",
lifetime=0
}).
invoke() ->
erlang:rr(?MODULE).
The command rr("file.hrl"). is meant to be be used only in shell for debugging purposes.
As other users highlighted in their answers, the correct way to import a record (or a function) contained in a .hrl file within your erlang code consists in using the command -include("file.hrl').
Once you have included the .hrl file in your code (and usually in a module based on OTP behaviours this is done after the -export(...) part) you can refer to the Erlang record (or function) without any problem.
rr is a shell command. You cannot use it it compiled code.
http://www.erlang.org/doc/man/shell.html
If your intent is to read many record definitions in the shell, in order to facilitate the debug, you can write a file containing all needed include statements and simply invoke rr once in the shell.
in rec.hrl:
-include("include/bank.hrl").
-include("include/reply.hrl").
and in the in the shell
1> rr("rec.hrl").
[account,reply]
2>
I didn't find any way to execute this automatically, when starting the VM.
When working on a project, you can gather all necessary includes and other command line arguments that you want to use for that particular project in a plain text file. After having made the plain text file, you can start your shell:
erl -args_file FileName
where FileName is the name of the plain text file. Note that all command line arguments accepted by erl are allowed. See also erl Flags in the ERTS Reference Manual
For example,
!vim
in iPython opens vim. Is there such a thing in Octave?
The following might work system("vim");
If you want the interactivity of calling something inside of Octave and interactivity with it directly try exec("vim") instead.
See Controlling Subprocesses for more examples.
Otherwise you can either combine calls to system, fork and exec or extend octave with Python/iPython or C++.
If you only want to run another process then , the already suggested system() or exec() should work.
However, if you plan on using this to simply open up a text editor and edit an Octave file, set the value of EDITOR with EDITOR ("vim") (you can add this to your .octaverc file) and then use edit (foo) to open up the foo function on the text editor.