I work with different frameworks, so I have several HTMLs in sublime:
HTML
HTML(Django)
HTML(Jinja2)
By default, Sublime opens all html files with HTML(Django). When I work with django it's fine. But in other cases it appears to be a headache. Do you know how to set up default language for the project?
I don't know much about the various HTML files, but if you have some way to identify different files, you could try ApplySyntax. If I recall, you can define functions to specify what file to use. I'm not sure what information is passed to the file, but perhaps there is something there to look at project settings or the file path.
I do not think you can specify syntax on a per project basis. You may want to look at the Modelines package, specifically
Non-Standard Options
For some common cases, no directly settable option exists (for
example, a setting to specify a syntax). For such cases, Sublime
Modelines provides non-standard accessors as a stop-gap solution.
x_syntax Packages/Foo/Foo.tmLanguage
Sets the syntax to the specified .tmLanguage file.
Related
Ive been looking on the the internet for answer but none comes close to what i was looking for. What is the folder for?
and inside is this json file:
What happen if i delete the folder and do i really need that to be in the folder? Thank you
Short answer:
If you delete it, probably nothing much bad will happen. It'll probably get created again. Your live server may or may not end up on the same port. Probably don't commit it to source control (but maybe you want to).
Longer answer:
.vscode as a folder name has a few clues:
the leading . kind of means "hide this folder". It comes from *nix operating systems where by default if you name a file or folder .anything it'll get hidden.
being called .vscode, which is the name of the editor you're using, suggests it relates specifically to using vscode.
The fact that it gets created when you "do something" suggests that it'll cope if it's not there, but probably the way it'll cope is to re-create it. That's a pretty common thing too.
One use for a settings.json file in a folder is for settings that are specific to that folder. Often you'd have settings that you want to apply to vscode wherever you're using it. But sometimes you have settings that apply to a specific bit of code.
The people that wrote the LiveServer extension seem to think that what port the live server runs on is one of those "per project" settings. I'd agree. You may want to run 2 or 3 live servers (e.g. a PHP web-site and another one that just does API, maybe), or the port that they chose might be in use by something completely else. So to deal with that, they create this settings file. I'd take a stab that if you edit that, then the LiveServer is going to show up on a different port.
But you can probably find the code and check it. Probably this document will tell you what to know.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
(A possibility here that I've chosen the wrong extension, but most vscode extensions are open source, so you should be able to follow the trail to a github repo, and then to either some docs or some code).
Editor settings are that border-line with source control - whether to check in or not. Lots of projects have defined editor settings, such as tabs vs spaces or linting engines. Lots don't. Possibly in this case, if you're part of a large project, the specific ports to use are defined, so it'd go into source control. If it's just you, do what feels good.
I'm using VS code (v1.74.3),Live Server (v5.7.9). There is no settings.json in .vscode folder of my JS project. Instead the settings.json is created in the folder "C:\Users\USER NAME\AppData\Roaming\Code\User" and it is a global settings file to specify extension properties. Most of the Live Server configuration settings mentioned in the documentation can be applied at global level.
When two PHP files are on the same namespace, adding a "use" to them for the other one is not necessary, but possible. However, PhpStorm inspection marks the unnecessary uses on PHP files as errors, warns about using them, and does not autocreate them when typing the class name on the file.
The thing is, I like having them on the file even that they are not necessary. That makes me easier to check the file dependencies, and to search-replace the namespaces when I move classes around. I know about the refactoring features of PhpStorm, but they are not always available for me and my co-workers.
So, is there a way of telling PhpStorm to behave with unnecessary uses as it does with regular ones? Not marking them as errors, autocompleting, etc.
I want to edit find_under_expand (ctrl+d) to consider hyphenated words, as single words. So when I try to replace all instance of var a, it shouldn't match substrings of "a" in words like a-b, which it currently does.
I'm assuming find_under_expand wraps your current selection in regex boundaries like this: \ba\b
I need it to wrap in something like this: \b(?<!-)a(?!-)\b
Is the find_under_expand command's source available to edit? Or do I have to rewrite the whole thing? I'm not sure where to begin.
Sublime's commands are implemented in one of several ways: as macros, as plugins, and internally as part of the compiled program (probably as C++). The default macros and plugins can be found in the Packages/Default directory in ST2 (where Packages is the directory opened when selecting Preferences -> Browse Packages...), or zipped in the Installed Packages/Default.sublime-package file in ST3, extractable using #skuroda's excellent PackageResourceViewer plugin, available via Package Control. Macros have .sublime-macro extensions, while plugins are written in Python and have .py extensions.
I searched all through the Defaults package in ST3 (things are generally the same as in ST2), and was unable to find a macro or .py file that included the find_under_expand command, or FindUnderExpand, which is the convention when naming command classes in plugins. Therefore, I strongly suspect that this command is internal to Sublime, probably written in C++ and linked into the executable or in a .dll|.dylib|.so library.
So, it doesn't look like there's an existing file that you could easily modify to adjust for your negative lookahead/lookbehind patterns (I assume that's what those are, my regex is a bit rusty...). Instead, you'll have to implement your own plugin from scratch that reads the "word_separators" value in your settings file, which the current implementation of find_under_expand doesn't seem to be doing, judging from your previous question and my own testing. Theoretically, this shouldn't be too terribly difficult - you can just open up a quick panel where the user enters the pattern/regex to be searched for, and you can just iterate through the current view looking for matches and highlighting/selecting them.
Good luck!
Since MathWorks release a new version of MATLAB every six months, it's a bit of hassle having to set up the latest version each time. What I'd like is an automatic way of configuring MATLAB, to save wasting time on administrative hassle. The sorts of things I usually do when I get a new version are:
Add commonly used directories to the path.
Create some toolbar shortcuts.
Change some GUI preferences.
The first task is easy to accomplish programmatically with addpath and savepath. The next two are not so simple.
Details of shortcuts are stored in the file 'shortcuts.xml' in the folder given by prefdir. My best idea so far is to use one of the XML toolboxes in the MATLAB Central File Exchange to read in this file, add some shortcut details and write them back to file. This seems like quite a lot of effort, and that usually means I've missed an existing utility function. Is there an easier way of (programmatically) adding shortcuts?
Changing the GUI preferences seems even trickier. preferences just opens the GUI preference editor (equivalent to File -> Preferences); setpref doesn't seems to cover GUI options.
The GUI preferences are stored in matlab.prf (again in prefdir); this time in traditional name=value config style. I could try overwriting values in this directly, but it isn't always clear what each line does, or how much the names differ between releases, or how broken MATLAB will be if this file contains dodgy values. I realise that this is a long shot, but are the contents of matlab.prf documented anywhere? Or is there a better way of configuring the GUI?
For extra credit, how do you set up your copy of MATLAB? Are there any other tweaks I've missed, that it is possible to alter via a script?
shortcuts - read here and here
preferences - read http://undocumentedmatlab.com/blog/changing-system-preferences-programmatically/
At the moment, I'm not using scripts, though this sounds like a very interesting idea.
Unless there are new features that you also want to configure, you can simply copy-paste the old preferences into the new prefdir. I guess this should be doable programmatically, though you might have to select the old prefdir via uigetdir. So far, this has not created major problems for me. Note also that in case of a major change in the structure of preferences, any programmatic version would have to be rewritten as well.
I'm adding paths at each startup, so that I don't need to think of manually adding new directories every time I change something in my code base (and I don't want to have to update directory structures for each user). Thus, I also need to copy-paste startup.m for each installation.
If I had to do everything manually, I'd also want to change the autosave options to store the files in an autosave directory. If I recall correctly, Matlab reads the colors and fonts from previous installations, so I don't have to do that.
I've read many times and agree with avoiding the use of globals to keep code orthogonal. Does the use of the config file to keep read only information that your program uses similar to using Globals?
If you're using config files in place of globals, then yes, they are similar.
Config files should only be used in cases where the end-user (presumably a computer-savvy user, like a developer) needs to declare settings for an application or piece of code, while keeping their hands out of the code itself.
My first reaction would be that it is not the same. I think the problem with globals is the read+write scenario. Config-files are readonly (at least in terms of execution).
In the same way constants are not considered bad programming behaviour. Config-files, at least in the way I use them, are just easy-changable constants.
Well, since a config file and a global variable can both have the effect of propagating changes throughout a system - they are roughly similar.
But... in the case of a configuration file that change is usually going to take place in a single, highly-visible (to the developer) location, and global variables can affect change in very sneaky and hard to track down ways -- so in this way the two concepts are not similar.
Having a configuration file ususally helps with DRY concepts, and it shouldn't hurt the orthogonality of the system, either.
Bonus points for using the $25 word 'orthogonal'. I had to look that one up in Wikipedia to find out the non-Euclidean definition.
Configuration files are really meant to be easily editable by the end user as a way of telling the program how to run.
A more specialized form of configuration files, user preferences, are used to remember things between program executions.
Global is related to a unique instance for an object which will never change, whereas config file is used as container for reference values, for objects within the application that can change.
One "global" object will never change during runtime, the other object is initialized through config file, but can change later on.
Actually, those objects not only can change during the lifetime of the application, they can also monitor the config file in order to realize "hot-change" (modification of their value without stopping/restarting the application), if that config file is modified.
They are absolutely not the same or replacements for eachother. A config file, or object can be used non-globally, ie passed explicitly.
You can of course have a global variable that refers to a config object, and that would be defeating the purpose.