So, I'm a huge IPython fan, though I'm sure I don't use nearly all the power it has (mainly tab completion and ? for introspection, though I also use %ed a fair amount).
However, I want to really start working with Python3k, and as this thread states, I'll need a Snickers to tide me over til IPython is ported.
So what are my options for Python3k (preferably that best match IPython features)?
Depending on your platform needs, you may want to take a look at bpython (http://bpython-interpreter.org/).
I don't think it has the ? introspection shortcut, though.
Related
Recently, I found that my emacs starts slowly. Sometimes the startup process takes 30 seconds, sometimes 3 seconds. I guess this is related to network enviroment. However, emacs -q can always start up quickly.
This question is like asking "How long is a piece of string". You have not provided anywhere near enough information. Start with telling us which version of emacs and what platform you running on.
You mention that emacs -q starts quickly, so we can assume the slowness is due to your init file. There are a lot of possibilities and no way for us to tell for sure without analysing your init file. However, there are a few things you can do to help identify possible causes.
#Drew's comment about bisecting your init file is a very useful trick to identify the source of a problem in your init file, particularly when trying to track down an error. It can be useful in identifying major contributors to load time when those contributors can be linked to a specific config option or package load etc. It is less useful when the problem is an overly long inefficient init file with too many packages.
Using a profiler as suggested by #legoscia can help identify areas to focus on, but it will still be necessary to interpret and understand what the profiler is telling you.
My suggestions would be to
Additional Packages. Since the introduction of package.el and the emacs package archives, I've observed a tendency for some users to get a little carried away and install lots of packages just in case. run C-h p and go through the packages you have installed. If you don't use any or you see ones there which you no longer want or use, remove them. Each additional package (depending on how they are loaded - see below) will increase your startup time by some amount as each package will need to be loaded. Loading packages you don't need or want will slow down startup time.
Stuff you don't need or understand. Over time, our init file can grow with stuff and we don't remember why we added it or it can be stuff we have copied from others which we thought we might need and forgot about. Every few months (depending on how often you modify your init - maybe more frequently if you make frequent changes, less if you don't) go through your init file and comment out anything you don't need, don't understand or don't rmember why you added it. Just comment it out, don't delete it. Re-start restart emacs and see if it starts faster and whether features or configuration settings you want/need have gone. If there are, look through the stuff you have commented out and see if anything looks relevant. When you find possible candidates, try to work out what the code is doing (look in the emacs manual, use C-h f and C-h v or C-h m etc to try and work it out. If it relates to a specific package, try M-x customize-package and see if there is built in customization which might give you what you want. Even if you prefer to customize things by hand rather than use emacs' built in customization system, M-x customize-group is a great way to find out what customizations are supported by a package and verify you have variable names correct etc.
Learn emacs autoloads. Emacs has this very useful feature called autoload. There are two main ways of loading packages into emacs. The first is to just do a basic 'require'. This will look for an emacs library with the appropriate name and will read it in and evaluate it (it is like adding the file to your init file, so more lines to evaluate, which means increased load time for your init). The good thing about require is that it just loads the whole file and you know that everything gets evaluated. the bad things is that it can in turn require other files, which can require other files and can result in a much longer init time. To try and address this problem, emacs has the autoload facility. Basically, with autoload, you tell emacs that if it tries to execute a command with the name 'foo', it must first load (require) a specific file which you define in the autoload definition. The advantage here is that emacs doesn't try to load the library until you first try to use it, so there is no increase in load time. The disadvantage is that it can mean there is a delay the first time you use a command and it won't work if other parts of your init use the command (well, it will work, but will have no impact on improving load time).
Switch to use-pckage. There is a very useful package called use-package which can help address all of the issues I've mentioned. It helps compartmentalise your configuraiton, simplifies some common configuration tasks and has support for either setting up a package with autoloads or deferring the loading of a package until emacs is idle. It can help speed up your init time considerably provided you use it correctly. Highly recommend giving it a go. See https://github.com/jwiegley/use-package
I built tfs.el to allow developers to do TFS things (checkout, checkin, etc) from within emacs.
There are 13 interactive commands in the tfs package, like tfs/checkout, tfs/rename, tfs/diff, and so on, and I'd like to be able to provide help on all of them in a single place. An overview of all the available functions.
What's the "emacs way" of doing that? I thought of defining an additional function, like tfs/help , that would invoke describe-function-1 on each of the tfs functions, and then present all that in a TFS-Help buffer.
Is there a better way?
Well, there are many "Emacs way"s.
The most polished would be to write an info page, see the page "Info for Experts", which basically says to use Texinfo and convert that into an info page. You can be as verbose as you want there, and the user can search, use hyperlinks, etc. The user can easily get there via C-h F tfs/checkout.
Another way some folks seem to do it is to write short documentation strings for each of the commands, ending with "see documentation for tfs-mode for details" and put all the common documentation in the docstring for tfs-mode.
Another way some packages document things is with a big comment at the top of the tfs.el file.
Take your pick, they all have trade-offs.
You can use
(describe-bindings "\C-xv")
You have multiple, related commands. So far, I guess, they are related only by their names.
Two possibilities come to mind:
Create a mode for this stuff. Document everything in the doc string of the command that turns the mode on/off. It could be a major mode or a minor mode. If a minor mode it could be buffer-local or global.
Create a group (defgroup) for this stuff and document everything in its doc string.
The basic idea is to somehow actually relate these commands: bundle them together in some way, so you can document them together as the doc for the bundle.
Offhand, without knowing more, my guess is that you might want to create a global minor mode.
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?
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.
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'.