I've always wondered why vim lacks some indentation files that would be handy for everyday life. Example: I sometimes have to deal with really messed up apache config files (/etc/apache2/sites-available/*). It's impossible to have them indented correctly by vim. With apache config files I usually try to improve indentation by typing
:set ft=xml
gg=G
:set ft=apache
I know that apache configuration files are not XML and that XML indentation doesn't work remarkably good here, but at least it's better than having every config line in the first column. There's a vim script which seems to work correctly but I have to install it on all Linux systems. If we take this plugin as an example: It's from 2007 - why did it never make it into a vim release?
The maintainer of the [indent] script has to submit the file to Bram (Vim's BDFL) for inclusion (and commit to maintaining it); that's how the process works. So, if you want to have this in the runtime, please ask the maintainer, or, (as the last update of that script on vim.org is from 2007 and he may be gone), ask on the vim_dev mailing list for someone to volunteer as such.
But... you shouldn't have to rely on those files being in the official runtime. Unless you're an atypical user without any customization, you must already have a mechanism in place to distribute your personal ~/.vimrc and plugins; if you put the script into ~/.vim/indent/, you should be all set.
Related
I've been trying to set up a WiX component such that the user can specify that the installer should not upgrade that component on a MajorUpgrade. I had the following code, but this means that if the condition is met then the new version is not installed, but the old version is also removed.
<Component Id="ExampleComponent" GUID="{GUID here}">
<Condition>NOT(KEEPOLDFILE="TRUE")</Condition>
<File Id="ExampleFile" Name="File.txt" KeyPath="yes" Source="File.txt"/>
</Component>
Ideally, if the user specifies "KEEPOLDFILE=TRUE", then the existing version of "File.txt" should be kept. I've looked into using the Permanent attribute, but this doesn't look relevant.
Is this possible to achieve without using CustomActions?
A bit more background information would be useful, however:
If your major upgrade is sequenced early (e.g. afterInstallInitialize) the upgrade is an uninstall followed by a fresh install, so saving the file is a tricky proposition because you'd save it, then do the new install, then restore it.
If the upgrade is late, then file overwrite rules apply during the upgrade, therefore it won't be replaced anyway. You'd need to do something such as make the creation and modify timestamps identical so that Windows will overwrite it with the new one. The solution in this case would be to run a custom action conditioned on "keep old file", so you'd do the reverse of this:
https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/
And it's also not clear if that file is ALWAYS updated, so if in fact it has not been updated then why bother to ask the client whether to keep it?
It might be simpler to ignore the Windows Installer behavior by setting its component id to null, as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
Then you can do what you want with the file. If you've already installed it with a component guid it's too late for this solution.
There are better solutions that require the app to get involved where you install a template version of this file. The app makes a copy of it that it always uses. At upgrade time that template file is always replaced, and when the app first runs after the upgrade it asks whether to use the new file (so it copies and overwrites the one it was using) or continue to use the existing file. In my opinion delegating these issues to the install is not often an optimal solution.
Setting attributes like Permanent is typically not a good idea because they are not project attributes you can turn on and off on a whim - they apply to that component id on the system, and permanent means permanent.
I tried to make this a comment, it became to long. I prefer option 4 that Phil describes. Data files should not be meddled with by the setup, but managed by your application exe (if there is one) during its launch sequence. I don't know about others, but I feel like a broken record repeating this advice, but hear us out...
There is a description of a way to manage your data file's overwriting or preservation here. Essentially you update your exe to be "aware" of how your data file should be managed - if it should be preserved or overwritten, and you can change this behavior per version of your application exe if you like. The linked thread describes registry keys, but the concept can be used for files as well.
So essentially:
Template: Install your file per-machine as a read-only template
Launch Sequence: Copy it in place with application.exe launch sequence magic
Complex File Revision: Update the logic for file overwrite or preservation for every release as you see fit along the lines as the linked thread proposes
Your setup will "never know" about your data file, only the template file. It will leave your data file alone in all cases. Only the template file it will deal with.
Liberating your data files from the setup has many advantages:
Setup.exe bugs: No unintended accidental file overwrites or file reset problems from problematic major upgrade etc... this is a very common problem with MSI.
Setup bugs are hard to reproduce and debug since the conditions found on the target systems can generally not be replicated and debugging involves a lot of unusual technical complexity.
This is not great - it is messy - but here is a list of common MSI problems: How do I avoid common design flaws in my WiX / MSI deployment solution? - "a best effort in the interest of helping sort of thing". Let's be honest, it is a mess, but maybe it is helpful.
Application.exe Bugs: Keep in mind that you can make new bugs in your application.exe file, so you can still see errors - obviously. Bad ones too - if you are not careful - but you can easily implement a backup feature as well - one that always runs in a predictable context.
You avoid the complicated sequencing, conditioning and impersonation concerns that make custom actions and modern setups so complicated to do right and make reliable.
Following from that and other, technical and practical reasons: it is much easier to debug problems in the application launch sequence than bugs in your setup.
You can easily set up test conditions and test them interactively. In other words you can re-create problem conditions easily and test them in seconds. It could take you hours to do so with a setup.
Error messages can be interactive and meaningful and be shown to the user.
QA people are more familiar with testing application functionality than setup functionality.
And I repeat it: you are always in the same impersonation context (user context) and you have no installation sequence to worry about.
Is there a way to do so ? I searched Google but couldn't find any answer, so I guess the answer would be no. Is there anything close ? If not, would it be easy to extend red-lang to do so ?
From http://www.rebol.com/docs/setup.html
Startup Scripts
When REBOL starts it will automatically run the rebol.r and user.r files, if they exist.
The system looks for these files first in the current directory (or the directory of the script being run), then in the directory that contains the REBOL executable program.
Note that REBOL/Core runs fine without the rebol.r and user.r files. They simply provide an easy way to include additional code and data on startup, such as your network preferences.
If you compile your own Red interpreter you can add an autoloading file, maybe in console.red after system/console/init "Red Console" and before system/console/launch Best advice is to ask on the https://gitter.im/red/help site to ask for help. I guess this was already discussed.
I use clion for quite a while now and in the past there was a dedicated window which shows all cmake variables/options for the current projet. Here you could see and change all variables/options. It was very convenient. I guess they changed this now and you have to open the CMakeCache.txt file and change the options in this file. But this file is so big it is very annoying to search for the option you want to change. It is even more annoying when you don't know the exact name of the option. So, my feeling is, there should be better way to list at least all options. So, is there a better way or do I have to go through the hassle and search for the options in the CMakeCache.txt?
As mentioned by #Maxim Banaev in the comments, there is a feature request on youtrack. Quoting from the discussion thread:
we hope to deliver this feature this year. Hopefully, in 2022.2 release
We've added the editor to CMake settings in EAP3 link and more updates for it are yet to come in EAP4 and EAP5.
See the interactive dialog applications that come bundled with CMake, ccmake (a curses-based terminal gui), and cmake-gui (a gui application). Both provide user-friendly interfaces to edit the CMake cache variables, including appropriate GUI inputs based on the cache variable's type (string, bool, path, filepath, etc.), and enable hide/show of variables that are marked as being for advanced usage scenarios. They also provide the option to group options by common prefixes of cache variable names and to visually expand and collapse those groups.
I'm trying to get a Cocoa development environment working in Emacs, and I'm 80% of the way there. The one feature I miss is Xcode's "Open Quickly", which basically performs a fuzzy match of the string you type against the filenames referenced in the Xcode workspace and the symbols defined in those files.
My problem is that our project is huge: if I generate a TAGS file using etags for the .h and .m files in our project's sub-directories, the result is over a gig in size and Emacs complains "TAGS file is large. Really open?", and if I say yes, then Emacs hangs and becomes essentially unusable. Of course, this is before I've even considered indexing tags for system libraries. I've also tried projectile, but unfortunately it's similarly unusable on a project of my size (on the order of a full minute to find a match).
It occurs to me that all the indexing information I really want is in the Xcode projects themselves, so if I had an Emacs package that could parse them and traverse their dependencies, that might be a start, but I'm not aware of any such package.
Any suggestions/solutions in this respect?
I've never found a single function quite as convenient as Xcode's "Open Quickly", but these days I use
helm-projectile-git-grep when I want to match on strings I know to be in the filenames, and
helm-git-grep for quick searches through the contents of the files themselves.
I've found that this gets me really close to what I wanted in my original question.
I currently use Programmer's Notepad with the Rebol syntax scheme. It's not bad--does any insightful person have another suggestion?
For my Windows programming work I use the Zeus editor, but I'm not sure if it does Rebol?
Another windows option is TextPad. It is commercial but it is quite a useful editor.
There are 2 Rebol syntax files available from the official site
http://www.textpad.com/add-ons/synn2t.html
I also wrote a TextPad syntax file generator uploaded it to rebol.org
http://www.rebol.org/view-script.r?script=textpad-syngen.r
It is probably quite easy to modify this script to support other editors.
vim.
Especially with the following binding in your _vimrc/.vimrc:
nnoremap <Leader>fr :w<CR>:silent ! %<CR>
In normal mode, Leaderfr saves your current file and executes it: (fr is a memo for 'fast-run')
:wEnter save current file
:silent execute without messages: ! open shell % paste current file name Enter
Leader is usually \ key, I have this mapped to spacebar. In case anyone is interested on how to do that, post a comment.
Programmer’s Notepad better than Crimson Editor with Code Folding and Great Project Management
http://www.pnotepad.org/
It's opensource so you can even modify it in C++
For Windows, there is Crimson Editor or E with the REBOL bundle.
For Mac, there is TextMate.
Emacs, I believe has a REBOL syntax too.
Sublime Text is a really nice Windows editor (commercial, but reasonably priced) that supports TextMate configurations (well, at least for syntax and snippets) so if you manage to get a REBOL bundle from somewhere, you can use it with this.
SciTE also has REBOL syntax coloring support because the Scintilla editor component it's based on includes this.
Notepad++ should also support REBOL syntax coloring, being Scintilla based, but as it is currently distributed, the support is not compiled in. If you're so inclined, you could probably compile it yourself and add the support back in. It might be worth it because Notepad++ is quite a good editor too.
I can't include proper links because I don't have enough rep, but this should do:
www.sublimetext.com
www.scintilla.org/SciTE.html
www.scintilla.org/index.html
notepad-plus-plus.org
http://rebol.wik.is/index.php?title=Notepad%2b%2b
which is a REBOL plugin for Notepad++
I use JEdit which not only has REBOL syntax highlighting but also auto-indenting. It has most of the features you'd expect from a text editor (e.g. block selection, configurable keyboard shortcuts).
There are versions for Windows, Mac OS X and Linux so if you choose to work cross-platform you won't need to learn a new editor. The web page is Jedit.org1
I use UltraEdit.
with its advanced project, syntax highlighting, macro, command-line control and total keyboard shortcut configuration, per language and project, you can program the editor to do just about all of what you need at a single click of the mouse, or keyboard.
my setup starts rebol on any file, and assigns a launch "default project script " to a shortcut, so wherever I am in the files, I still launch the project's relevant script. change project, it will run that new project's scripts. another key for unit tests, another key for "find in all opened files, etc, etc..
also, the actual text-exiting, when combined with a few macros which create functions, objects, and more using the clipboard and "currently highlighted" text makes it much faster than any Visual IDE including MSVC.
ultra edit itself has thousands of other advanced features, and they all work... really they do.
I've tried other editors and they always fall short when I start to push them.
yeah, you have to buy it... but its cheap (like one or two hours of your life salary ;-)
so considering you might use it for several months or years... its a cheap investment.
also, ultra edit is now released on linux and the mac port is just around the corner.
I use EditPlus for several years, it is not free but not expensive. It has Rebol syntax highlighting file (downloadable from its web site).
It is especially useful & very fast if you work with huge files (over 100 mb) or with lots of files (say 300 files.), find & replace takes a second.
For syntax highlighting and a simple autocomplete, you can use http://komodoide.com/komodo-edit/.
It's free and open source with several nice features, including folder browsing while editing, which I personally find very useful.
There is also a bunch of other languages supported in case you want to take a closer look and give this editor a chance.