It looks like Notepad++ as of ver. 6.6.7 is now actively blocking the AutoSave (ver. 1.4) plugin.
Notepad++ will remove AutoSave when upgrading and re-loading AutoSave with the Plugin Manager now fails.
Live and die by the ability to make a quick .PHP script change and switch over to the browser window without having to remember to click on the Save file toolbar icon.
Any suggestions or alternatives?
OK, found the solution.
Rather than relying on the Autosave version downloaded by Plugin Manager, go to the link listed -- http://sites.google.com/site/fstellari/nppplugins -- and download v1.40 from there.
The zip file will have 2 versions of the dll (A for ASCII and U for Unicode ?). Copy the AutoSaveU.dll file to "C:\Program Files (x86)\Notepad++\plugins\" and you should be back in business.
Update: After running for a few days with Autosave enabled, found that automatic spell check and the ability to right click on a word or phrase would randomly disappear. Disabling "Auto Save when Notepad++ looses focus" solves that problem. For now, have decided that spell check and right clicking are more important than auto-saving.
I have found the best solution to this, if you install notepad++ and use 'Resource Hacker' (google it) to change the menu (cut it down) and the icon (change to notepad), and install the autosave plugin in notepad++, then you have something that looks almost entirely indistinguishable to classic notepad! And txt files have the notepad logo.
Also you need to go into settings and turn off a bunch of settings, including under editing tab, turn off line numbering, and change colours in 'style configurator'.
The only notable difference is that highlighted text remains black.
Check out this image to see how close it is, you could even cut and rename menu items to look identical but there is no need to be that pedantic.
Related
My VSC shows the wavy underlines when something's wrong with my code, but does not display the hint overlay when I hover my mouse on it.
This happens whatever the language used (from CSS to Typescript) and whatever the type of irregularity (e.g. notice, warn, danger)
I'd say that's a setting I may have changed at some point, but can't find which one. Any idea?
More details:
I do have the message displayed in the Problems tab besides to the Terminal, but it forces me to switch from tab to tab ;
I do have other overlays like autocomplete/autosuggest ;
No extensions in my setup could have led to that situation (only a few installed, widely downloaded, nothing fancy or dodgy).
Actual behavior (nothing happens):
Expected behavior (from google images)
Go to File > Preferences > Settings.
Search for 'hover.enabled' (See below photo).
Toggle it.
If your editor still does not pick up the change, close all tabs, close all VSCode windows, and reopen it.
If it's still not working, try uninstalling VSCode and reinstalling it (make sure you don't have setting sync on).
Also, this question has been answered in at least one other place (Disable tooltip hint in Visual Studio Code)
I have recently switched to VSCode, and am loving it, except for one specific thing that drives me nuts.
My "goto" command is {Command+P}, the easy search-and-open-file bar. If I type the name of a file into this bar and it does not exist, I want to be able to hit ENTER and have it open a tab editing that file as a new file. This is the behavior I would get in old-school Windows Notepad, or in mvim :e <filename>, but I can't figure out how to do it in VSCode.
Is there a toggle or a plugin I can use to get this behavior straight out of the Go To File dialog?
Answering my own question:
No, there's no way to do this using {Command+P}. This is strictly a file finder and I've yet to see any plugin that changes the behavior.
If you're using the VsCodeVim plugin, an almost-as-good approach is just :e <file> - immediately open a new buffer editing the given file. There's no tab autocomplete this way, but you just have to live with that.
I've followed all the suggestions here.
When I press return, I get a new line that is indented with tabs instead of spaces.
If I backspace to clear the tabs, and then press TAB a series of times, it correctly indents with spaces.
I'm pretty sure I have all my settings set up correctly. I created a new Code Style > Formatter policy for every language in the project, and specified to always use spaces. It seems as though these settings are partially active (ex: when I press tab), but inactive when I use return. I tried restarting Eclipse. I'll try restarting the computer now...
I'm using Mac OS X 10.9.2 and a Liferay Developer Studio (1.6.3.v201312111844) version of Eclipse (not sure which Eclipse build its based on though).
Can anyone think of another setting/solution to ensure that newlines are created with spaces instead of tabs? I recently saw http://editorconfig.org/, and I'm wondering if there's some interference.
Thanks for any suggestions
If the file has existing lines that are using tabs, then Enter will respect that and try to create new lines in a similar way (see this comment by topchef for a solution). Also, it could be something in Liferay Studio's proprietary settings is overriding Eclipse standard preferences (as suggested by user John).
Keep in mind that each type of editor in Eclipse can have its own preferences and perhaps that's what you're running into here. You can try to find them all by opening Preferences and searching for "indent" in the search field. That will show all the preferences pages where indentation can be configured.
Also note that the Formatter settings don't have any affect on as-you-type formatting; that's for when you select a file or group of files or part of a file and choose Source > Format from the menu.
I'm running NetBeans 6.9, can't seem to figure out where to set the encoding. I found some guides on google but all of them were for older versions.
The method by Mr. LordofFatality doesn't work for out-of-project files that you open via 'open file' menu.
In order to accomplish that, find a netbeans.conf file in you netbeans installation\etc\, find there a netbeans_default_options line and add there -J-Dfile.encoding=UTF-8 string.
If you don't find the "netbeans_default_options" option there, add a whole new line as following:
netbeans_default_options="-J-Dfile.encoding=UTF-8"
Relevant to NetBeans 7.2, also works in 7.4
In 6.9.1:
open the project pane if you don't see it already (Window > Projects);
right-click on the name of your project in the tree-view;
click properties;
make sure the menu item "sources" on the left is highlighted;
you should see "Encoding:" and a select-box next to it;
click OK. Done.
It SHOULD work that way and does work for anyone on the internet except me. On my Windows XP dev system files are still not saved as UTF-8. Still wondering why ...
open the project pane if you don't see it already (Window > Projects)
Right-click on the name of your project in the tree-view click
properties make sure the menu item "sources" on the left is
highlighted you should see "Encoding:" and a select-box next to it.
click ok. done.
it SHOULD work that way and does work for anyone on the internet
except me. on my windows xp dev system files are still not saved as
utf-8. still wondering why...
Your file should content one or more non-latin chars, this is why.
its bug always the editor saving my files as utf-8 without bom
See here !!!
I have a very strange effect when using subclipse with eclipse. Whenever I use Team->Export to export a file from the editor the export works fine, but the label of the tab of the file is removed.
Effect can be seen here: http://www.daspferd.de/img/tabs.png
Strangely enough it happens with php-files, css-files, html-files but NOT with javascript-files. So I'm assuming it's some kind of setting that I haven't found yet and not a bug in subclipse.
Anyone know where I can shut down this behaviour?
It could be a bug in the editors. If eclipse opens an editor on the exported file, it might not open it as an IFileEditorInput, and the editors therefore do not set the title correctly (that's the job of each individual editor implementation).
This is just a guess, but it would be consistent with some editors behaving ok and some not. It would basically be a missing feature in some of your editors.