The new release of IPython does not depend any more on readline but uses the pure Python library prompt-toolkit, solving maintenance problems on Apple's and Windows' systems.
A new feature is the ability to edit a multi-line code block, using the cursor keys to move freely in the code block — with this power it comes, at least for me, a problem: because a ret inserts a new line in your code, to pass the whole block to the interpreter you have to use the shortcut alt+ret or possibly the less convenient key sequence esc followed by ret.
I say, this is a problem, because my terminal emulator of choice is the XTerm and, on many Linux distributions, the shortcut alt+ret is not passed to the application but it is directly used by the XTerm in which IPython is running, to toggle the screen-fullness of the said terminal (#ThomasDickey, xterm's mantainer and co-author pointed out that, by default, xterm doesn't care to send to the application the modifier bit on Enter even when one unbinds the Fullscreen action).
For this reason I'd like to modify at least this specific IPython key binding.
I've found instructions (sort of) for the previouos versions, the readline based ones, of IPython that do not apply to the new, 5.0 version.
What I would need are instructions that lead me to find, in IPython's user documentation, the names of the possible actions that I can bind, the names of the shortcuts to bind with the actions and the procedure to follow to configure a new key binding.
Failing to have this type of canonical answer, I may be happy with a recipe to accomplish this specific keybinding, with the condition that the recipe still works in IPython 6.0
You could change xterm's configuration.
xterm is configurable (and documented). In the xterm manual, the Default Key Bindings section shows the default binding for this key:
Alt <Key>Return:fullscreen() \n\
You can suppress that binding in more than one way:
using the omitTranslation resource to suppress the feature
setting the fullscreen resource to never
However, just suppressing it will not make it send something interesting (xterm ignores the modifier for Enter). Setting a translation resource works, e.g., in your $HOME/.Xdefaults file:
*VT100*translations: #override \n\
Alt <Key>Return: string("\033[27;3;13~")
The ctrl+j or ctrl+m keyboard shortcuts are validating the entry.
Modifying keyboard shortcuts in configuration when using prompt_toolkit is not (yet) possible; though it is pretty easy if you install IPython from source. If you look at the file IPython/terminal/shortcuts.py you will see that it contains the various logic; in particular you will find:
# Ctrl+J == Enter, seemingly
registry.add_binding(Keys.ControlJ,
filter=(HasFocus(DEFAULT_BUFFER)
& ~HasSelection()
& insert_mode
))(newline_or_execute_outer(shell))
This bind CtrlJ (enter) to the function newline_or_execute_outer which is responsible for adding new lines; it's define later in the file. In particular if you press enter twice at the end of a block of code, it should execute the block without the need to use any other shortcuts.
Strip the logic that adds new lines:
def execute_outer(shell):
def execute(event):
"""When the user presses return, insert a newline or execute the code."""
b = event.current_buffer
# some logic to also dismiss the completer
b.accept_action.validate_and_handle(event.cli, b)
return execute
Bind it around line 20-something:
registry.add_binding(Keys.ControlE,
filter=(HasFocus(DEFAULT_BUFFER)
& ~HasSelection()
& insert_mode
))(execute_outer(shell))
And enjoy. If you are unhappy with the documentation we welcome help; For example, taking the gist of the answers there and contributing them back. It is a bit hurtful to read harsh comments when we do say in release notes:
New terminal interface
The overhaul of the terminal interface will probably cause a range of minor
issues for existing users. This is inevitable for such a significant
change, and we’ve done our best to minimise these issues. Some changes that
we’re aware of, with suggestions on how to handle them:
IPython no longer uses readline configuration (~/.inputrc). We hope that
the functionality you want (e.g. vi input mode) will be available by
configuring IPython directly (see Terminal IPython options). If something’s
missing, please file an issue.
...
Helping actually improving IPython to have configurable keybinding with actions name is also appreciated, so then you will be able to answer your own question.
Related
I am creating CLI app for Unix terminal using click module. So I see two ways how I can display data:
print(data) and click.echo(data)
What is difference between them and what should I use?
Please, read at least quickstart of library before using it. The answer is in the third part of quickstart.
If you use click click.echo() is preferred because:
Click attempts to support both Python 2 and Python 3 the same way and to be very robust even when the environment is misconfigured. Click wants to be functional at least on a basic level even if everything is completely broken.
What this means is that the echo() function applies some error correction in case the terminal is misconfigured instead of dying with an UnicodeError.
As an added benefit, starting with Click 2.0, the echo function also has good support for ANSI colors. It will automatically strip ANSI codes if the output stream is a file and if colorama is supported, ANSI colors will also work on Windows. See ANSI Colors for more information.
If you don’t need this, you can also use the print() construct / function.
When reading a book or just coding on terminal/IDLE it's common to make typo, forgot brace or comma etc. After I got error and all what I wrote before is lost.
Then I have to write down code again..
Is there any way/option to return back all what write before and just edit mistake and continue to code?
In Idle (at least my version, Python 2.7.10 on windows), you can simply copy paste your code. In the python interpreter, you can't afaik, however you can use the up/down arrow keys to recall lines you previously "submitted" (i.e. typed and pressed enter).
If I understood correctly, IDLE is a GUI (graphical user interface - a visual representation of a program rather just through text) made to have a bit more features for programming in Python. You can use IDLE interactively, like in Terminal (a.k.a command line), or use it to write your script rather than in a separate text editor. Then once you save your script/program you can do neat things like run it directly from IDLE. There's nothing more special about the Terminal, you just have to do some more work.
Furthermore, all the code you have written on your GUI is on the cache memory which is used in system to store information recently accessed by a processor. So, I suggest you write again your code you can't recover them without saving.
To avoid these kind of problems use Git!
Git is a version control system that is used for software development and other version control tasks.
IDLE's Shell window is statement rather that line oriented. One can edit any line of a statement before submitting it for execution. After executing, one may recall any statement by either a) placing the cursor anywhere on the statement and hitting Enter, or b) using the history-next and history-prev actions. On Windows, these are bound, by default, to Alt-p and Alt-p. To check on your installation, Select Options => IDLE preferences on the menu. In the dialog, select the Keys tab. Under Custom Key Bindings, find the 'histor-xyz' actions in the alphabetical list.
For short, one-off scripts, I have a scratch file called tem.py. Since I use it often, it is usually accessible via File => Recent files.
I read that CTRL+P is the auto completion short cut in VI, but the recommendation given by the auto completion doesn't make that much sense to me.
Say from the re package there is a method called findall. Eclipse could recommend that method when I do CTRL+Space:
But When I tried the auto completion in VI, it could not find the findall method. the only recommendation seems like a command that I have typed before which has nothing to do with the re module.
Can Anyone give me some hints what is the auto completion story behind the CTRL+P in VI and how could I tune it up so it would be as good as Eclipse's auto completion.
(Every time I doubt the power of VI, the truth is always that it is me who lack the power to discover the beauty of VI)
Thanks!
In vim <C-p> is not the only completion shortcut available. Omni completion defined for python should be called with <C-x><C-o>, then use <C-n>/<C-p> to select variants. There are more completion types, all start with <C-x>, see :h ins-completion.
It is still better to use some third-party plugin (like jedi-vim or klen/python-mode) to get python completion as they are smarter. Note that at least klen/python-mode will not redefine <C-p>. They redefine <C-x><C-o> by setting 'omnifunc' option.
Without any additional modules, vim's autocompletion only searches the current file for occurences of the string you've started typing, regardless of whether it makes sense. If you use the tags file, via ctags or other, you're able to use strings across a variety of files, rather than just the current buffer.
Is there a emacs plugin which lists all the methods in the module in a side pane.
I am looking for a plugin which has keyboard shortcuts to show/hide all the methods in python module file currently opened.
I suggest using elpy.
C-c C-o runs elpy-occur-definitions which creates a new buffer with a list of all the class and function signatures.
You can navigate the list using C-n and C-p.
The mode works with next-error-follow minor mode.
So C-c C-f inside the buffer enables jumping to the class or function definition selected.
Here's an example of the contents of that buffer:
8 matches for "^ *\(def\|class\) " in buffer: leveling_utils.py
11:def leveling(episodes_with_potential_associations_by_member):
26:def _apply_leveling(sorted_episodes):
41:def _set_non_chronic_associations(episode):
73:def _apply_sub_to_procedural_association(assoc):
94:def _set_chronic_associations(episode):
102:def _set_associations_for_self(episode):
118:def _set_to_actual(association):
122:def _log_actual_associations(member, leveled_episodes):
By the way, it has many other useful features that to me, make it a necessary addition to python-mode.
For the first question, use M-xspeed-bar, like Alex suggested.
For the second, enable hs-minor-mode, M-xhs-minor-mode, and use C-cC-#C-S-h to hide all methods, and C-cC-#C-S-s to show.
You can look to ECB (it's better to take my fork of it, as it's adapted to fresh Emacs & CEDET) - it can display information about source code fetching it from Semantic (CEDET subpackage) or via imenu (for languages that aren't supported by Semantic).
Speedbar (included into GNU Emacs) can also show a list of top level objects, but doesn't show differences between imports, functions of other top-level stuff
For me, the easiest and most convenient method to quickly lookup methods is the command helm-occur (C-x c M-s o). You start typing the name of the method you want to jump to and suggestions start popping in as you type. Then you hit enter to select the one you want and your cursor jumps right there in the code. Helm-occur wasn't strictly written for this purpose, but works quite well that way.
Speedbar is good, and another nice alternative is helm-imenu. I've bind several keys to access it quicky from different contexts and use it most of the time
I just made a little chat CLI-application that works pretty fine actually!
Unfortunately, when one types a message and receives other's messages at the same time, both interlacing... Which renders quite awful:
elton: Hey!
john: how are you doing?
fine anjohn: still not to bed?!
d john: haha
you?elton: fine and you?
I'm looking for a way to avoid this kind of problem. Such as "reserving" the last line for user-input or process some actions when data are received to recalculate the position of user-input.
After some research I found that I shall retrieve each character one by one with getch(). So that I can check regularly if a new message is waiting to be displayed and handle this case.
But if I use getch() I have to redefine manually basic actions (such as backspace, move left and right...), some characters take more than one byte. In brief, it's unusable.
As far as I can tell, you have a few options here. Normally just calling getch you're running the terminal in what's called "cooked" mode. This means that the terminal just displays characters in the order they arrive, nothing too special. However you run in to race conditions as you've discovered.
Option 1: you read things in one character at a time, buffering the entire line. When a new line arrives and you want to print it out, you'd have to (a) grab hold of some kind of print mutex (internal to the program), (b) clear out the current line (print '\r[space][space][space]...\r'), (c) print the incoming line + '\n', and (d) restore the previous buffer to the screen (via print) and unlock the mutex.
This gets ugly. Fast. As you discovered, there's no line editing support or anything fancy. The only good thing about this approach is that it'll probably work in about 99% of terminals.
Option 2: you put the terminal in to raw mode. In this mode, you have complete control over the terminal, but you lose very basic functionality (e.g. typing a key won't display it unless you manually output it). You would still have to manually implement things like navigation, but at least it would work. This method is probably the most flexible and give you the most control, however it's very difficult to work like this, which is why they invented...
Option 3: you use ncurses (or a similar terminal library). The concepts are a little difficult, but FAR easier to learn than doing things in pure raw mode. Editing and windowing (or as you put it, reserving a line) are built-in. The interface can be much prettier than you'd get from cooked mode.
EDIT I'm talking a lot about *nix terminals here, most of which doesn't apply for Windows.
The usual way to do this kind of thing is by writing a "console-mode GUI" instead of a pure CLI.
For example, you can very easily create a very simple interface with a ROWS-2xCOLS output window, a 1xCOLS divider or mode line, and a 1xCOLS input window—as seen in things like IRC clients, emacs, etc. For example:
Or you could do a split view, with a ROWS/2xCOLS window for the other person/people's chat, and a ROWS/2xCOLS window below that for the user's current and previous messages, as seen in most of the early Unix chat programs.
Or something fancy with windows all over the place that pop up and go away as appropriate, as some modern IRC clients do.
Python has curses support built-in—but not on Windows. If you want a cross-platform solution, or a Windows-only solution, see curses-like library from cross-platform console app in python, and the answer is probably there.
Here's a screenshot from the IRC client BitchX, to give you an idea of what's possible without too much work: