Location of formatter files for VIM - formatting

I found the following code snippet on the internet, and want to use it in my own .vimrc.
augroup CodeFormatters
autocmd!
autocmd BufReadPost,FileReadPost *.py :silent %!PythonTidy.py
augroup END
However, I'm not quite sure where to put the PythonTidy.py script, so that it is accessible from everywhere.
Furthermore I read that using BufReadPre is better than BufReadPost, respectively FileReadPre, is that true?

As it stands, PythonTidy.py must be accessible through your PATH. If you have a convenient place already contained in there, e.g. ~/bin, just place it there.
Alternatively, you can place it somewhere into your .vim directory, and use something like expand('<sfile>:p:h') to resolve the directory of your Vimscript, and build a relative path from there.
As you want to filter the read buffer contents with the :%! command, you have to use the BufReadPost event; with BufReadPre, the buffer hasn't yet been read and nothing would be sent to the filter.

PythonTidy is a command line executable: put it somewhere in your $PATH.
You can also put it anywhere and use an absolute path in the autocmd:
autocmd BufReadPost,FileReadPost *.py :silent %!/path/to/PythonTidy.py

Related

How do I tell Octave where to find functions without picking up other files?

I've written an octave script, hello.m, which calls subfunc.m, and which takes a single input file, a command line argument, data.txt, which it loads with load(argv(){1}).
If I put all three files in the same directory, and call it like
./hello.m data.txt
then all is well.
But if I've got another data.txt in another directory, and I want to run my script on it, and I call
../helloscript/hello.m data.txt
this fails because hello.m can't find subfunc.m.
If I call
octave --path "../helloscript" ../helloscript/hello.m data.txt
then that seems to work fine.
The problem is that if I don't have a data.txt in the directory, then the script will pick up any data.txt that is lying around in ../helloscript.
This seems a bit fragile. Is there any way to tell octave, preferably in the script itself, to get subfunctions from the same directory as the script, but to get everything else relative to the current directory.
The best robust solution I can think of at the moment is to inline the subfunction in the script, which is a bit nasty.
Is there a good way to do this, or is it just a thorny problem that will cause occasional hard to find problems and can't be avoided?
Is this in fact just a general problem with scripting languages that I've just never noticed before? How does e.g. python deal with it?
It seems like there should be some sort of library-load-path that can be set without altering the data-load-path.
Adding all your subfunctions to your program file is not nasty at all. Why would you think so? It is perfectly normal to have function definitions in your script. The only language I know that does not do this is Matlab but that's just braindead.
The other alternative you have is to check that the input file argument, data.txt exists. Like so:
fpath = argv (){1};
[info, err, msg] = stat (fpath);
if (err)
error ("could not stat `%s' : %s", fpath, msg);
endif
## continue your script knowing the file exists
But really, I would recommend you to use both. Add your subfunctions in your main program, the only reason to have it on separate file is if you plan on sharing with other programs, and always check input arguments.

Rename a file after building it in Sublime Text 3

Is it possible to rename a file after building it in Sublime Text 3? By default, the output is the same as the input; so filename.scss is built to filename.css. But what if I want filename.scss.css by default (to indicate that this file is based off of a scss file). Is this possible?
Yes. Read through the Build Systems Reference for details. First, there are several variables you can use. $file is the reference to the full path of the current file, say /home/foo/test.php. There is also $filepath (/home/foo), $file_name (test.php), $file_extension (php), $file_base_name (test), and some others. You can also use regexes just about anywhere inside curly braces ($file is the same as ${file}). For example, ${file/\.php/\.txt/} will rename its suffix from .php to .txt (/home/foo/test.txt). ${filepath/testing/production} changes the directory. Here are several combined in a contrived example:
"cmd": ["myprocessor", "--infile", "$file", "--outfile", "/mnt/${project_name}/var/www/assets/${file_base_name/test/final}.css"],
...
For your particular case, this should work:
"cmd": ["myprocessor", "--infile", "$file", "--outfile", "$filepath/$file_name.css"],
should take /path/to/yourfile.scss and spit out the processed /path/to/yourfile.scss.css if that's what you want.

CMake: Get the complete representation of a path minus relative elements

I want to take a variable that has been set to a combination of path elements (potentially both absolute and relative) and get the absolute path from it. Something like what boost::filesystem::system_complete() does in C++. For example, I have something like:
set(EXTERNAL_LIB_DIR "${CMAKE_SOURCE_DIR}/../external" CACHE PATH "Location of externals")
which works but in the UI it's a bit ugly, as it might end up looking like C:/dev/repo/tool/../external. I'm wondering if there's a CMake built-in command to turn that into C:/dev/repo/external before I go and script a macro to do it. find_path kind of does this, but it requires that the path already exist and something worth searching for be there. I want it to work whether the path exists or not (I might use it for an overridden CMAKE_INSTALL_PREFIX default, for example).
You can use:
get_filename_component(NEW_VAR ${EXTERNAL_LIB_DIR} REALPATH)
As of CMake 3.20, you can use the cmake_path command to normalize the path, which supersedes the get_filename_component command.
cmake_path(SET MY_NEW_PATH NORMALIZE ${EXTERNAL_LIB_DIR})
This also converts any backslashes (\) into forward-slashes cleanly.

Matlab can't find member functions when directory changes. What can I do?

I have a Matlab program that does something like this
cd media;
for i =1:files
d(i).r = %some matlab file read command
d(i).process();
end
cd ..;
When I change to my "media" directory I can still access member properties (such as 'r'), but Matlab can't seem to find functions like process(). How is this problem solved? Is there some kind of global function pointer I can call? My current solution is to do 2 loops, but this is somewhat deeply chagrining.
There are two solutions:
don't change directories - instead give the file path the your file read command, e.g.
d(i).r = load(['media' filesep 'yourfilename.mat']);
or
add the directory containing your process() to the MATLAB path:
addpath('C:\YourObjectsFolder');
As mentioned by tdc, you can use
addpath(genpath('C:\YourObjectsFolder'));
if you also want to add all subdirectories to your path.
Jonas already mentioned addpath, but I usually use it in combination with genpath:
addpath(genpath('path_to_folder'));
which also adds all of the subdirectories of 'path_to_folder' as well.

batch scripting: how to get parent dir name without full path?

I'm working on a script that processes a folder and there is always one file in it I need to rename. The new name should be the parent directory name. How do I get this in a batch file? The full path to the dir is known.
It is not very clear how the script is supposed to become acquainted with the path in question, but the following example should at least give you an idea of how to proceed:
FOR %%D IN ("%CD%") DO SET "DirName=%%~nxD"
ECHO %DirName%
This script gets the path from the CD variable and extracts the name only from it to DirName.
You can use basename command:
FULLPATH=/the/full/path/is/known
JUSTTHENAME=$(basename "$FULLPATH")
You can use built-in bash tricks:
FULLPATH=/the/full/path/is/known
JUSTTHENAME=${FULLPATH##*/}
Explanations:
first # means 'remove the pattern from the begining'
second # means 'remove the longer possible pattern'
*/ is the pattern
Using built-in bash avoid to call an external command (i.e. basename) therefore this optimises you script. However the script is less portable.