I'm going through my vim dotfiles to tidy them up. I've noticed that through time I've added various filetype specific settings in various inconsistent ways. Let's suppose I'm customizing for Python:
au BufRead,BufNewFile *.py (do something). I don't like this because some Python files might not have the .py termination.
au FileType python (do something). This seems a better option because it doesn't depend on the file having the .py termination. The drawback is that Vim doesn't know about some filetypes. I can make Vim recognize additional filetypes, but I also have various inconsistent ways of doing it: a .vim/filetype.vim file, another in .vim/after/filetype.vim and various set filetype commands in .vimrc.
Add a .vim/ftplugin/python.vim file with filetype specific settings. I understand the $VIMRUNTIME/ftplugin/python.vim can override whatever settings I make here. One problem is that I'm not sure how this interacts with .vim/filetype.vim and .vim/after/filetype.vim.
Add a .vim/after/ftplugin/python.vim. I understand that this is loaded after $VIMRUNTIME/ftplugin/python.vim so it can overwrite settings from there. As in the previous method I'm not sure how it interacts with the filetype.vim files.
So I have at least four ways of doing this, not mentioning syntax files and filetype-specific plugins. It seems to me the best way to do this is to put my filetype specific settings in after/ftplugin so they don't get overwritten, and filetypes.vim in after for the same reason.
However, before I proceed I'd like to ask if anyone has suggestions about the best way to deal with filetype specific settings.
I store my Python-specific settings is in $HOME/.vim/ftplugin/python.vim, since I do nothing to conflict with $VIMRUNTIME/ftplugin/python.vim.
Keeping these settings in an ftplugin file keeps my .vimrc nice and generic and easier to maintain (it's still pretty big after over ten years of Vim usage).
If you want to overrule what the ftplugins with your Vim distribution set up, then $HOME/.vim/after/ftplugin/python.vim is what you want, as it is read after these.
Similarly $HOME/.vim/filetype.vim will be sourced before $VIMRUNTIME/filetype.vim and that in turn will be sourced before $HOME/.vim/after/filetype.vim.
Invoking :scriptnames will list all sourced script names, in the order they were first sourced.
:help filetype provides pretty comprehensive information on all of this.
Related
In our app we have lots of photos that we need to read while using the app, we have to also orgenize them into groups/categories.
this option is to make a plist with their names, and just put them into the app and read the plist.
create folders inside the app, order them inside, and read the specific folder.
Option 2 took me days and I couldn't even make it work reliably, and it also seems not the right way to work for some reason.
Option 1, the problem is that if you have 100 files you have to edit your plist every time again for a new file you add.
Is there a way to make option 1 outside of xcode so I can put all files in a folder on my mac, get their plist, and put this plist inside Xcode ?
What's the right way to achieve this ?
plist is just a simple XML file. You can create the plist file and add to xcode as any normal file to the bundle and read it.
macOS comes with two command-line tools for manipulating plists:
/usr/bin/plutil can convert a plist between formats. You might like this because you could write your photo catalog in JSON using whatever tools you like, then convert it to a plist. Of course, then you could just use JSON directly in your app…
/usr/libexec/PlistBuddy (note that /usr/libexec is not normally in one's PATH) can modify a plist in place, adding, removing, or changing entries.
Both of these tools have man pages (man plutil, man PlistBuddy) and substantial built-in help (plutil -h, /usr/libexec/PlistBuddy -h).
First, you're making a false assumption. There is no need to use a plist file here. An ordinary text file listing the names will do just fine, and you can just make up your own format to dictate groups and suchlike. And that sort of file is trivially easy to maintain.
Second, your rather confused claim that "Option 2 took me days and I couldn't even make it work reliably, and it also seems not the right way to work for some reason" is just a cop-out. Folder references are not a difficult thing to use (you can configure them in the Finder, which is as simple as you can get), they do work just fine, and they are a perfectly reasonable solution here.
I can use:
#+INCLUDE:
to include an org file in another org file, which allows me to assemble, say, a website from various org files. I'm exporting from the C-c C-e exporter in org-mode 7.5.
I could maintain a quite complex publication this way. This modular approach is quite common in, e.g. LaTeX and Texinfo publications.
However, links to images no longer work from the #+INCLUDEd org files. What seems to be happening is that the path to the images is taken as being from the org file that I am exporting from, rather than the actual org file that references the image.
The only ways I can see to resolve this are to:
use a flat file structure; or
make the image path from the referencing file (which I might not know in advance) rather than itself.
Neither of these is really sustainable.
How do I tell org to use the correct image path from its own relevant org file rather than the parent org file?
From what I know of the exporter, INCLUDE files are inserted into the document before export. Therefore the content is part of the document before it starts following paths to reach any links to files (images).
After a bit of testing you likely will need to use absolute file paths. Since you move between Windows and Linux your best bet would be to use a consistent scheme on both starting from your home directory.
Like that you can make the Org link:
[[~/path/to/image.jpg]], which will work on both systems (assuming you have set %HOME% on Windows).
Option 1 is potentially an alternative (although I agree it wouldn't be ideal at all), whereas the second option would have obvious pitfalls if you INCLUDE the file in more than one future document.
For years I've put my application data files in c:\MyCompany\MyDataFileFolder\App where 'App' is my application name. I made this choice in the early days of Wild-West-Windows when Microsoft seemed to keep changing its own mind (My Documents, Documents, Program Data etc). As I've learnt more about how to do things correctly, and as Windows has now 'settled down' and is more picky about permissions I'd like to move my files. Users have got used to where they are though, and what I'd really like to do is to implement something like Windows does with 'special folders' where there are several synonymous names, thus in my legacy folder I'd like to put something in (or change a folder to) an alias for the real location which will now be something descended from Program Data. This way, the files are in a good place with the correct permissions and if we run a utility expecting or modifying files in the 'old' place this gets changed transparently to the 'new' place (thus a simple shortcut wont work).
Is this possible? Is there are recognised technique for this? I'm using Delphi XE2.
What you are looking for is either a Symbolic Link or a Reparse Point.
I want to import a (text) file into maple on a mac.
According to all available information, the command should be of the form
read "MacIntosh HD/Programme/myfile"
but I did not succeed.
I tried various variations, slash/backslash, slash at the beginning, with and without Mac HD at the beginning, local language and English language name for the system directories.
I always get
Error, unable to read pathname I entered.
I would be content with any solution, either the syntax, or the default maple directory where I can put the file without worrying about the path or the existence of a menu item with the same effect.
Found the answer myself in the meantime:
For the above example
read "/Applications/myfile";
would succeed, so in particular, one has to use the English names for the systems directories even though in finder they are only ever given in the language you chose for your account.
Also, currentdir() and currentdir("Applications/Maple 15") allows you to see the current directory and to change it, respectively.
Sometimes when I add a new file to my path, I have to restart MATLAB or it won't be detected. There must be an other way to this!
I have experienced similar problems (Matlab does not notice it when I change a file). Unfortunately, I have no idea what causes it or how to solve it. I usually find that CLEAR ALL solves the problem, but be aware that it clears all variables in the work space. Some 'REHASH' command (e.g., REHASH TOOLBOXRESET) may also be useful.
I'd love to see a better answer; all documentation that I came across seems to indicate that this cannot happen.
Perhaps this is a problem with Matlab caching certain files at startup to improve performance. This happens with files in certain directories.
From Matlab help for path command:
Note (...) Also note that locations of files in the matlabroot/toolbox directory tree are loaded and cached in memory at the beginning of each MATLAB session to improve performance. If you save files to matlabroot/toolbox directories using an external editor or add or remove files from these directories using file system operations, run rehash toolbox before you use the files in the current session. If you make changes to existing files in matlabroot/toolbox directories using an external editor, run clear functionname before you use the files in the current session. For more information, see the rehash reference page or the Toolbox Path Caching topic in the MATLAB Desktop Tools and Development Environment documentation
I've often seen this happen with networked file locations. I don't understand the mechanism, but it definitely happens. A solution that often works:
path(path);
or, if that fails to pick it up, try this: (NB, this will clear your workspace)
clear classes;
path(path);
We did this last one so much, we put it in script on our common code path called:
shazaam;
Yes, my age is showing.
You want the "rehash" function or you need to set the path again using "path(path)" or similar. It also depends on whether you're using a "frozen" path. Look at the help for ADDPATH.
MATLAB will keep a cached copy of the compiled M-file unless it know that you've changed it. If you've created the file or you've edited it outside of MATLAB, then it may not know that it's changed.
This happens to me when the networked drive connection is lost then restored. rehash does not work but rehash toolboxreset does