In Jupyter Notebooks you can type, for example \alpha and hit the tab key and the \alpha changes into α. This is a pretty cool feature. Unfortunately, it doesn't work in the jupyter-lab editor. Any reason why that doesn't work? Or do I need to set a preference somewhere?
if you type $\alpha$ it will be rendered as the greek letter thanks to latex
Although the answer of #joelostblom works fine, you can simply install the LaTeXStrings Julia package to enable the \alpha [tab] feature without needing to spawn an IPython kernel.
using Pkg
Pkg.add("LaTeXStrings")
This feature is provided by the IPython kernel, not the Jupyter Notebook. The kernel provides TAB completion by looking up the latex (or latex-like) symbol in this dictionary (originally from Julia) and then inserts its value (the corresponding Unicode character). As such, there needs to be an active IPython kernel to provide the TAB completion (here is the PR that added the functionality to IPython in case you want to read more about it).
An IPython kernel is automatically started with the notebook and used when running cells, but this is not the case when editing a text file (which is also why there is no TAB completion for other things such as imports, etc). You can start one manually by right clicking inside a Python text file and selecting "Create console for editor". After that autocompletion works just as in the notebook, including Greek latex symbols.
Related
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220
When using ipython in a console interactive session, pressing tab will generate autocompletions, but always generate an additional space character after the text. Can I change this behavior and make the autocompletion only generate the remaining text for the word?
This is a known and still-active bug Issue42
IPython's history-search-backward feature is one of my favorite features. history-search-backward allows you to type part of a command and then search backward through your readline history for commands that began with that part of the command. By default (I believe) these are bound to UpArrow or Ctrl+P and DownArrow or Ctrl+N (for backward and forward respectively).
They are not working for me. Instead they just go linearly through my history instead of taking into account the characters I've already typed to (allgedly) filter my history.
I'm running IPython 0.13.2 (with Python 2 and 3) on Arch Linux from within XTerm.
If I hit Escape, Ctrl+P, then UpArrow and DownArrow work exactly as I want them to.
Additionally if I change my ipython_config.py to include
c.TerminalInteractiveShell.readline_parse_and_bind = ['"\\e[B": history-search-forward', '"\\e[A": history-search-backward']
then I can just do Escape UpArrow for the desired behaviour. (Here's the rest of my config file.)
Ctrl+V UpArrow produces ^[[A as I expect. I have the python readline library installed (which seems to fix common problems with macs running IPython).
I have these lines in my .bashrc
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
and they work exactly as I want them to within bash.
I have no idea what else to try next, so I've come here. Please help, I hope I've included enough information and done enough research.
The culprit was set keymap vi set in my .inputrc. I removed that and IPython history went back to what I expected. Thanks to #Thomas K!
Context
Have some transcript files from terminal interaction, obtained using traditional Unix command "script".
Those transcripts contain lots of control character (like backspace when editing shell commands), and lots of color code sequences as result of running various commands. Occasionally, even colorful full-terminal (ncurses-based) applications like "emacs -nw" or "aptitude" were run.
At program runtime, TERM environment variable was set as "xterm".
Need 1: read (more or less solved)
I need to read those files again and sometimes copy-paste some small parts.
The trouble is : while one color change here and there is not so much of a problem, their actual density makes the output barely readable. Worse, edited command lines (with cursor jumps and edited words) are completely unreadable.
"Okay" solution
Browse through files using e.g. "less -r". Paging forward in the same terminal setup reproduces the various color and character style.
But many other features come out more or less broken, e.g. search backwards produces jumbled terminal output, often have to pres "Ctrl-L" to clean thing up.
Need 2: editing
My preferred editor is emacs. Some people have had a similar situation when running the shell inside emacs, e.g. Something wrong with Emacs shell.
Here is not the same situation. Examples of differences: here we don't have to run an actual shell, but we need to move cursor freely like in usual editing.
Editing here means easily open such a transcript file in editor and then:
at all times through editing, see character changes (color, attributes) as conveyed by the terminal codes
(optional) some character that are neighbour on the terminal grid but are separated in file by some control characters would have a visual hint about this
ability to insert some text,
delete sections,
use all editor features like search/replace etc.
copy & paste to & from file (including to external programs, which would receive just plain text)
in my wildest dreams, some kind of "flatten" action, like select a sequence with a heavily edited command line and replace it with a simple series of characters as if it was typed in one run. "Visual hints" mentioned above would disappear.
Type Alt-: to evaluate something in the minibuffer. Evaluate (ansi-color-apply-on-region (point-min) (point-max)) and it will convert ansi color codes to be font colors.
I am using emacs 23.2 on Ubuntu 10.04 & Windows XP along with cedet extention. Cedet seems to work fine but I could not select the file using mouse. Rather I need to use the Key press to select the file from cedet (placed at left side)..
how to do file selection using mouse with emacs cedet? Any clue shall be appreciated...
CEDET is a collection of features, so I'm not sure specifically which one you're talking about, but are you left-clicking or middle-clicking the mouse? The middle mouse button is more commonly bound to an 'open file' command in Emacs modes.
In any case, you can always use C-h m to list the help for the active major mode in a buffer, along with any minor modes. Key bindings are frequently listed in this help text.
Finally, as you know a working key binding, you can trivially find out what else is bound to the same command: C-h k <working binding> will tell you which command that key is bound to, as well as any other bindings for the same command. If there are no other bindings that are to your liking, then you can always define your own.