I keep typing "t eh" instead of " the" which is, of course, annoying in the amount of time it takes me to correct myself.
The obvious answer is "Learn to type, noob!" or at least to type more slowly and/or more correctly. This error is frighteningly consistent so it appears I've trained my muscle memory for that pattern already.
But I'm wondering if it's possible to write a small, windows portable script or application that, when it detects the incorrect sequence, backspaces and corrects it automatically at a layer where it would apply to any keyboard input.
Does C# have access to that layer of the OS that intercepts keypresses systemwide?
Will I run into UAC issues with Vista?
Am I re-inventing the wheel (ie, are there open source tools I can modify or use out of the box)?
In DOS this sort of thing was quite easy and one could make TSRs (Terminate and Stay Resident) programs that would, for instance, give you a calculator onscreen with a special keypress. Not to mention the many, many practical joke programs based on this concept (dial "M" for monster!)...
I would, of course, never suggest such a utility could be used that way for co-workers...
-Adam
On windows you could use AutoHotKey. That allows you to create little scripts or macros to automate and correct things like mistypes.
One use was posted on lifehacker which took the common mistyped words and corrected them. It is at http://lifehacker.com/192506/download-of-the-day-universal-autocorrect
UPDATE Per Comment: This is Free software and windows only as far as I know.
The above script is just an example of what it can do. There are a slew of scripts available at AutoHotkeys Site
I suggest AutoHotKey. If you've never used it before, have a quick read of the tutorial: http://www.autohotkey.com/docs/Tutorial.htm
The feature you are looking for is called "hotstrings." http://www.autohotkey.com/docs/Hotstrings.htm
In your case, your script would look something like:
::teh::the
That's it! Add other things you want corrected on additional lines. AutoHotkey scripts can be compiled so you don't have to install AutoHotKey on all of your machines.
It's a very cool program. It's primary use (for making custom hotkeys) rocks! These scripts are system wide so you'll also probably want to make a hotkey to be able to turn them off too!
EDIT: In a comment, it was mentioned that he actually types "t eh" (with a space in it) and I wondered if something additional would be needed for it to work. I just tested it and it works fine. Just install autohotkey, and create a file with the .AHK extension. In that file put in the following line
::t eh::the
and save the file. Then double-click on the AHK file to load AutoHotKey with your script (you'll see a green square in your system tray to let you know it is running). It should work fine!
Yes, you can use pinvoke commands from C# to intercept the low-level os commands. I recommend you take a look at http://www.pinvoke.net. The coding isn't easy but it does work.
I suggest learning to type more slowly. I also suffer from "teh" and "ahve" in part due to autocorrect giving me the leniency. If you forced yourself to retrain then you would not be at a disadvantage when using someone else's machine.
Not to mention the unfortunate event when you need to write "t eh" and are being prevented by an overzealous 'corrector'.
Related
It seems like it is not all that easy to create an executable from a PowerShell script - do you know if it was ever meant to be an option?
I have found tools like PS2EXE, but still it does not seem like it was meant to be.
I am asking, if it is worth it to go the extra mile or leave it.
Background reason: I have some less technical users that need a smoother workflow.
As #Bill_Stewart kindly noted:
PowerShell is a shell that contains a powerful scripting language.
Which is perfectly in line with Microsoft's definition :
PowerShell is a task-based command-line shell and scripting language built on .NET.
Basically, wrapping it in an executable would go beyond its purpose. The nice thing about scripting is, that it's lightweight and task based. And in this case, that you can easily run it on multiple OS-ses.
So, I wouldn't go through the effort creating an exe.
If you want to run it easily, just create a .bat or .cmd file (if using Windows). On windows, I believe, you can also create a shortcut with command arguments and a little icon.
For Linux you clould use a .sh.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
First of all, this is not a question on emacs vs vim. I use eclipse IDE for programming and I intend to continue using it. Having read many advantages of emacs and vim, especially the ability to do almost anything without using the mouse, I want to use a similar typing/editing scheme in my eclipse IDE; I'm aware that there are plugins available for eclipse to change the editing style to emacs or vim (emacs+, vrapper to name a few..).
Since I plan to continue using eclipse, the various advantages of vim and emacs like small memory foot print, vim/elisp scripting, availability on different platforms, configurablity etc are all lost. I want to import only the text editing scheme to eclipse and master it while keeping all of eclipse's features.
So, I would like to have an objective comparison of the benefits/disadvantages of only the text editing styles of emacs and vim.
EDIT: the reason I cannot move away from eclipse is because my company uses a customized version of eclipse which has specific plugins and dsls to interact with our product(hardware)
I cannot move away from eclipse because my company uses a customized version of eclipse
Please note that Vim is not an IDE (a search will bring up various discussions of this topic), therefore this dichotomy does not exist. You can very well use both Vim (for text editing) and a real IDE (for debugging, source code browsing, etc.), in parallel. A simple "launch current file in Vim" integration is quickly done, and you've already noted that there are several plugins that bring the basic key bindings (but not the huge customizability) into the IDE.
Also, it strikes me as odd that you have no preconception of Vim vs. Emacs yet. Most people breathe and live their key bindings so much that they desire them in their IDE, too; you just seem to "have heard" about those advantages, but haven't experienced them yet.
My advice: Use your IDE for work (as you have to, anyway), and try out Vim (as well as Emacs) in parallel, maybe for recreational tasks, a little scripting, blogging, whatever. You can then see for yourself whether you'll "get hooked" on one of them, or maybe the IDE will just work out fine for you. Also, time will tell whether a simple integration is sufficient, or whether you want something tight and deep like the Eclim project.
I can only tell something about vim, I have used emacs once in a while, but it doesn't seem to be compatible with me. Although I really like scheme which is a lisp dialect. Vimscript is a horror to program in, but it is possible.
The main feature vim offers is that it adds structure to text beyond the syntax of your language. You can manoeuvre, edit and transform your text with vim's movements. These are at the heart of vim and have to be learned well. This in combination of modes, makes vim a powerful tool for text editing.
On the other hand, for code editing, vim needs some modifications to be useful. You will a considerable amount of configuration. Most people keep their vim configuration in a fire and bullet-proof safe, so they will not lose their painfully built stack of options, plugins and other configurational paraphernalia. That is including me. A vimrc is quite personal. Emacs is easier to configure. I could pick it up much faster.
You have to learn a tremendous amount of knowledge to even be able to use it. Emacs is much easier, you can use it at once. My first encounter with vim was being not be able to leave the damn program, whatever I did. My second encounter, was carefully hitting i and the type some text and quickly hit :wq. But somewhere later I suddenly wanted to tame it.
Vim has macro's, which make a lot of text transforming tasks fun. E.g. this removes al spaces at the end of a line, something I sometimes run to stop the nagging of pylint about spaces:
qs:g/ $/s///g<CR>#sq
You should read this as: record a macro in register s, replace globally all spaces at the end with nothing, apply macro in register s, stop recording. When hitting:
#s
This macro will run endlessly, until you are satisfied. I still want to find one, which stops after he hunted the last space. This makes vim fun, it is a little language with one letter commands. You can combine letters together:
4f,d$
This means find he 4th comma (,) and delete (d) the line from there till the end ($). That makes it quite attractive.
I would personally go for vim, but you have to try the editors out. They have different philosophies and one of those will bite you and the other will seem reasonable. I don't believe you will find many people, who uses both and mastered both. They are both usable as code editor.
I still have emacs on my wishlist, maybe I will swap.
I would suggest reading these answers as they contain a good amount of differences between the two (although a lot of the benefits mentioned don't matter for you). I strongly suggest just trying them out.
A big difference that you will notice is that Vim uses modes, which makes it have a high initial learning curve, while Emacs is modeless, and you can use it like a normal text editor (notepad), but with added functionality. And his is where your style/preference matters. I personally don't like holding control down to move around in Emacs, where in Vim, you escape to normal mode and use hjkl to move around.
This might be of interest:
https://github.com/senny/emacs-eclim
It's a frontend to eclipse, providing Emacs features alongside with Eclipse, not just to mimic Emacs-keys only.
Some screenshots here:
http://www.skybert.net/emacs/java/
There are a number of GUI hosts for Powershell (Powershell ISE, PoshConsole, etc) but I'm not aware of any purely console hosts other than powershell.exe. Are there any that offer any advantages over powershell.exe?
I'd like to be able to customise more of the host behaviour - specifically to add and customise key bindings other than TAB, and to customise error reporting. There could well be more...
If there aren't any "extended" versions of powershell.exe that offer this, how difficult would it be to write one? I have the SDK sample code, and it looks fairly accessible, but it's hard to be sure what features powershell.exe provides as opposed to the powershell "engine" (as there's no documentation I've found that focuses specifically on the host capabilities).
How about Console it can host multiple shells. Might be worth a look.
The best pure-console for PowerShell is obviously PowerShell Plus, which actually uses a fullblown "native" Windows console, but it wraps it up in candy coating and adds tons of IDE-style features. As far as I know this is the only third-party host that's capable of running "graphical" console apps like edit.com
As a sidenote, I'm honestly not sure it's worth the handicap of a true console just to keep compatibility with whatever graphical interactive console applications like Edit.com might still be around. Considering the limitations, and the amount of work that has to be done to pull off something like what PowerShell Plus has... Personally I can't wait for the day when I no longer have to worry about and can move on to console apps that are really MEF-style plugins in a console-style interface like PoshConsole :-)
I realise that this question is years old, but since I stumbled across it in search of answers, I thought I would add my findings.
I settled on Cmder, for the following reasons:
It wraps cmd and Powershell, so you get the same set of features you would find in either.
The default colour scheme is Monokai, which is not only pleasing to the eye, but actually readable. Maybe I was missing something, but the default output for most of my tasks (Git, Mocha tests etc.) had poor contrast most of the time and I found myself squinting at the screen.
Tab support - I've wanted this for a while, but until now I hadn't found a solution that provided tabs as well as everything else. Powershell IDE has some character encoding / text colour issues that I couldn't ignore.
It's portable - stick it on a USB stick and take it with you wherever you go.
It's configurable - the developer (Samuel Vasko) has done a great job here. It's not lacking for customisation.
Specifically answering the OP's requirements, you can remap key bindings and create macros. I don't see the ability to customise error reporting however.
Hopefully anyone else out there still searching for a decent command line emulator on Windows will see this answer and rejoice.
If you stick with a "Console" subsystem approach you will be saddled with all the limitations that come along with a Windows console subsystem application. Many complaints about PowerShell.exe limitations are really limitations of this feature of Windows (kbd shortcuts, line editing, etc).
What's wrong with PoshConsole? Even though it allows graphics to be displayed it is still a "console-style" UI on top of the PowerShell engine?
When we click the check box "Install files for complex script and right to left languages (including Thai)" in Regional and Language settings what exactly happens?
Changes to registry keys?
I noticed that it installs some .fon files and keyboard dlls.
Is this totally necessary if one just wish to read complex script on Windows XP? My test inside VirtualBox as Windows 7 as the host OS seems to indicate that for reading Complex Script need not be enabled. Yet that's not what all the literature on the subject says. What's going on?
Update:
http://hi.wikipedia.org should not be readable if Complex Script is not enabled
http://hi.wikipedia.org/wiki/विकिपीडिया:Devanagari_Help
Problem is that it is readable.
Font files. Rendering libraries ('Uniscript'). Input methods. Certainment beaucoup de cle-registry. (Certainly lots-o-registry-keys.)
Note that IE will tend to get things right even when other things don't, since it builds in a good deal of fancy-pants rendering. Try, oh, Outlook, or some simple sample Win32 program.
I have a script that runs several little programs I don't have the source code to, one of which requires filling out some fields in a GUI. I've been doing this by hand, but I'd like to have the Perl script focus the GUI window, then enter some hardcoded text into each field and close the window.
In the past I've used the Win32::GuiTest module for tasks like this. Have a look at the example scripts and documentation.
Unless there's a specific reason you're using Perl, Autoit is a Basic-like scripting language pretty much specifically designed for automating GUI tasks. It's very easy to pick up.
You can have it wait for a window to become active, send any sequence of keystrokes or tell it to specifically focus on a GUI element with a given handle, and much more. You can also package the scripts as standalone executables, which can be a nice benefit when you need it.
You might want to look into Win32::OLE. There's also a book on this topic.