With latest phpStorm 9 we have new feature called simultaneous tags editing.
This is generally very nice feature that i'd like to use, but i have one old project with very bad code with a lot of mixed PHP, HTML and JS code, where it breaks code.
I know i can disable this in settings->editor->General->simultaneous tag editing, but it disables this feature for whole phpStorm. Is there way to disable it only per one project?
Is there way to disable it only per one project?
Nope -- this is an IDE-wide setting.
The only possible solution I can think of is to have separate PhpStorm installation that will use custom folders to store IDE settings (look into idea.properties file from PhpStorm distribution, e.g. on Windows 7 it would typically be %PhpStorm-Install-Folder%\bin\idea.properties).
With IDE settings stored in different location you can now configure this installation with different settings (e.g. have that option turned off). Obviously, all settings here will be different to your original setup, unless you configure it the same way or will keep certain config files synced (e.g. Keymaps, Color, Web Servers, Live Templates and other things could easily be synced on file level).
Just remember to launch this installation when you want to work with that specific project.
Related
I have a project that uses both PHP and Python, and I would like to use JetBrains IDEs (in this case PhpStorm and PyCharm) to work with both languages.
However when I open the project using both IDEs concurrently I get a pop up whenever I switch from one to the other, as the newly focused IDE detects metadata that has been written to the project directory by the other IDE. I imagine this would be a problem between other combinations of JetBrains IDEs as well (hence the use of the generic jetbrains tag).
I have a work around (I will post in an answer for others to view), but it is somewhat awkward to set up, and I may well be working with other projects that use the same combination of languages.
Is there an easier solution?
My current workaround:
Create a new directory separate to the main project directory - using the language specific IDE for the second-most used language in the project, open the new directory as a project, and using the options in Settings > Project > Project Structure, add the main project directory as a separate content root.
Whenever needing to work on the parts of the project written in the secondary language, you can now open the new directory instead; this keeps metadata for both IDEs separate.
A workaround which allows for two IDE's to share the same directory without IDE settings conflicts.
JetBrains software allows you to store project settings as either a file based project (*.iml), or a directory based project (.idea).
To choose file or directory based projects, change the file storage type when opening a project.
Note: Directory based projects are preferred to file based projects, as they allow for versioning of shared settings. Support for file based projects is deprecated and may be removed.
Can the Google Chrome dev tools be used to directly change the files on the server for example by directly interacting with an ftp server? It would make PHP editing much easier.
The DevTools can update any files that are editable via Sources, including PHP and HTML. CSS is only updated directly via the elements panel. Other text file types can be updated through the Sources panel where you map the files.
DevTools directly has no knowledge of FTP/SFTP/FUSE mounts/etc. All it knows is local filesystem structures. So, if you use some software to mount a remote filesystem locally as a new folder or drive, then you can map it to DevTools just fine. I have done this myself in the past and have seen others do this setup as well. You simply need to research your OS and see what software is available that you are comfortable with to handle the mounting.
Warning though, with large project file structures this can make things slow.
Unfortunately editing DOM elements doesn't update PHP or HTML mapped local files. This is currently a limitation of the workspace feature. CSS Styles only.
As for server mapping, it should be possible but Chrome seems to be crashing when I try adding a mapped FTP location. I haven't had a chance to test any other computers of versions of Chrome/Windows
Currently using Chrome 43.0.2357.130 on Windows 10 Insider Preview 10130
I am working on Sublime Text 2 at home and at work. I need the same configuration on both computers. When I change something at home, I want to see this change at work and vice versa. I think I can do something like that with Dropbox?
I need to share user configuration, user bindings, snippest and plugins installed by Package Control. How can I share the configuration between two computers and more?
I recommend putting your files in Dropbox or any similar file-syncing service.
(I do exactly this with AutoHotKey scripts, and it works really well.)
There is a thread on the SublimeText forum that asks the same question, and in there, an answer refers to the page Using Dropbox to synchronise Sublime Text settings across Windows computers, saying "I don't have any issue with this method."
Other suggestions mentioned in that thread are:
Keeping your configuration in an online version-control system (such as GitHub or Bitbucket) - but it warns "some plugins does contain some private infos (SFTP plugin, for example, keeps its license into the user's folder)"
"For whatever it's worth, I use the Windows portable version and dump the whole of it into my Dropbox."
Using a shell script to do the sync between OS X and Linux
Here's a solution in order to sync between Windows and Mac
Hi I am running 2 copies of sublime text 2. One on a windows box and another on a laptop running ubuntu.
I am wondering if it is possible to move the sublime packages folder to a shared location. I only use one machine at any given time but it would be nice if the packages/snippets etc were consistent across both environments.
Any one had any luck with this?
Thanks,
Sublime Text 2 may hold write lock on the files of the settings files, so sharing files might not work as intended if you are trying to use them from multiple locations simultaneously.
However, it is possible to share settings and on UNIX users do it via symlinks (mklink on Windows). I am pretty sure you cannot set the path of the config files from Sublime itself, so you need to instead do some kind of file-system trickery.
But as the recommended method I'd use some file sharing service like Dropbox which will also automatically keep back-ups from your files in the case you manage to destroy them within Sublime Text 2 accidentally:
http://opensourcehacker.com/2012/05/24/sync-and-back-up-sublime-text-settings-and-plug-ins-using-dropbox-on-linux-and-osx/ (have pointers for OSX, Linux, Windows)
Also I am not sure if there is anything operating system specific in those configs, but I can confirm it works 100% if you are using the same OS.
To get an application installed on a new computer there seems to be two major approaches in current use:
Separate installer: Create a separate installer package
that creates all directories, files,
registry entries required by your
application (ie an MSI, InstallSheild etc) and then finally copies your application to the target computer.
Self installer: Include all required
installation steps in a component
that is part of your application. Then use this component to check and create required settings each time the main application executable is run. ie Just run the application to install.
I've used a few applications that corrupt their settings over time, and most had a separate installer. Therefore the only fix was to to re-install, sometimes with settings and even data being lost (very frustrating).
Also during software projects I've worked on, the separate installer approach often dictated spreading application specific knowledge across both the installer package and the actual application. Then, when code/functionality changes were made, both the installer and app needed to be updated. It always felt a bit too brittle and prone to human error.
So I'm currently leaning toward the self installer approach because of a simpler more robust installation/setup, ie just run the app. This self installing approach I feel would also lend itself a more robust application.
Integration with in application settings (options) would also be much more clean, in many cases the same component could perform both installation and settings management.
On the negative, however, performing these extra checks/steps each time the app starts might negatively impact startup times, and OS integration might be a bit more work then using a standard installer.
So which approach to people recommend and why?
(I'm most interested in installation of desktop rich client applications at present.)
There are pros and cons to both approaches:
Having an installer is the proper way to install necessary system components, like drivers, libraries, COM components and so on. Since many of these activities need elevated permissions the install may be performed by the administrator, while the application can be used by all users.
There may actually be requirements for a scriptable installation procedure in corporate environments.
Not having an installer opens the way to portable applications. If the program has everything in a directory, then this can simply be copied to a USB stick and be run on any system. This may of course not make sense for your particular kind of app, but that is for you to decide.
I'm not sure that the issue about corrupted settings is really important here. If settings are corrupted (why?) - how is the application to know what to do about it? OTOH the installer can of course also be written to not blindly overwrite any old settings. It all depends...
Edit: You write in your comment:
Even portable apps require certain configuration/settings, Isn't it better to have the main app check that settings are valid/exist on each startup, and only prompt the user when needed.
and again, it really depends on your needs. There are different types of configuration settings or preferences, and you have to decide individually:
Per-user configuration settings will be missing if the application is run for the first time by the current user. It can be helpful to show a message that it is missing, and how to create it. For example in FlameRobin (a database administration program for Firebird) we have a message that is shown when no registered servers and databases are found on program startup, and how to register them.
Per-user settings for UI behaviour will also be missing, but there are default values for them. The user will get the default behaviour of the application, and can later change things in the option dialog. Since it is best to minimize the number of such settings, and since the defaults should be what most users expect or what works best in the general case, there is also no need to bother the user at program startup.
Some configuration may be not per-user, but per-program. This is generally stored in a location where standard users have no write access, so checking for this and prompt the user to enter it is not really helpful. What could be done is to start an external program, asking the standard user for the account with sufficient privileges and its password.
Going with a separate installer is the "better" way from my point of view. Making an application self-installing does not only add additional workload to the application itself, it also "works around" any installer system of the underlying operating system (like MSI on windows).
And if the application corrupt its settings over time it's broken and need to be fixed. How should corrupt settings be handled by the self-installer? Just overwrite it with the defaults? Users will get annoyed by that too, so having them to run a separate installer and choosing a "repair" option makes this at least more transparent.
I would recommend a separate installer that can do the following:
Install a new installation
Repair an existing installation
Remove an existing installation
The reason I recommend these options is because that is what I have come to expect for installers in Windows environments.
The reasons I recommend separating installation and application logic into two different applications area:
There may be conflicts between dependencies used used by the installer and application.
I want to be sure my team don't inadvertently use classes in the dependencies from the installer framework when developing the application.
Thanks for your feedback. I'm starting to think something along these lines would be a good compromise approach:
Choose the self installer approach by creating an installer component (class library) that is referenced by the main application.
This component is a core part of the application and is responsible for ensuring all configuration/settings exist and are valid.
The main app. executable, on each run, asks this component to check existance/validity of settings, and only prompt the user when required. This could be easily done in a user friendly manner by grouping all setting issues and presenting them in a single GUI (avoids a sequence of annoying dialogues).
For OS integration, the installer component (in the case of Windows) ensures an entry is added to the "Add Remove Programs" list for the application, as well as any other OS required conventions.
Within the application the standard options/settings screen is also provided by the installer component. This avoids duplicating settings management code.
I've asked this question because I've met many non-technical users who ask why they cannot simply copy an application from one computer to another, they can do this with their data (eg photos, documents etc). It's an extremely valid question, in particular for GUI oriented desktop applications.
Separate installers are certainly "the way it's been done" on Windows for many years. For drivers/system components, obviously they are often a necessity. But for desktop GUI style applications I don't believe they are the best in terms of simplicity and realiability for the user/customer.