I want to use rlwrap with a custom erlang repl.
It works perfectly if I run it as "rlwrap -a myrepl".
The problem is that myrepl has builtin tab completion which gets trampled by rlwrap.
I want to make rlwrap to release the TAB key
You can't use rlwrap's line editing/history and your repl's TAB completion at the same time.
rlwrap provides line editing, history and (very simple) completion for commands that don't have it. A command that has something as fancy as TAB completion shouldn't need rlwrap to do its line editing, should it?
The -a (--always-readline) option is a rather crude way to substitute rlwrap's line editing behaviour for that of your command. It is primarily meant for commands that have a very simple line editor, without e.g. command history
If you want to use the -a option because you prefer rlwrap's fanciness (like persistent history, or coloured prompts) to your command's (like TAB completion), go ahead, but it is impossible to pick some fanciness of one and keep some of the other.
This is the (small) price programs (and their users) have to pay for avoiding the readline library and the GPL license that comes with it.
Hans (rlwrap author)
Edit (April 2017):
In many cases it will be possible to use a filter to restore completion. See A node shell based on readline for an example of this.
Rlwrap is cute. But in Erlang, it only offers persistent history while breaking erl's tab completion.
The fundamental issue is Erlang's erl REPL is just old and busted, and doesn't follow normal *nix conventions. Furthermore, they refuse to fix it because of fear of random, grouchy sysadmins whom can't accept any changes. No amount of rlwrap "duct-tape" hacks can fix a poor UX REPL.
It would be better (though significantly more work) to write a REPL from scratch like pry/ipython/etc. that does configurable color, tab completion, persistent history, paging, CLI observer, plugins, etc.
Rlwrap shines on programs with primitive shells.
Related
I use Eclipse for programming in almost any language. I also like the vim shortcuts for quick editing so I installed vrapper.
The problem is when I write a lot of code, and I just want to undo some little things. It undos a lot of chunks of code back, instead of 2 or 3 little things.
I've found some threads which seem to resolve my issue by using "set noati", but it does nothing. It doesn't matter if I use "Ctrl+Z" or "u" from vim command mode.
Can someone please help me to resolve this issue ?
The set noati seems to be the solution for that (at least was for me and other people in vrapper forums)... simply to update to the latest version of vrapper then you either specific the set noati (no ":" here!) in the ".vrapperrc" (this config file should be placed in your home directory) or you simply run the :set noati command from Eclipse vrapper.
HTH.
Here are two things that might help you.
1) Stay out of insert mode.
The way undo works is in terms of vim commands. So if you change to insert mode and type a hundred words, that counts as a single command. On the other hand, if you press escape every once in a while to get out of insert mode, undo will behave much more pleasantly.
Once you get more familiar with vim, you will want to do less and less in a single insert. So the undo problem will likely be reduced as well.
2) Temporarily disable vrapper via the toolbar icon.
This is an alternative if you absolutely need the default undo behaviour of Eclipse.
I'm an Emacs user trying to learn a software tool that is best run from a terminal. The default set-up to get the most out of that tool is to use xterm for interaction and call Vim for editing. One could simply replace Vim with Emacs in this setup, but then one would spend most of the time working outside of Emacs in an Xterm.
I figured out there is (Multi)Term-mode in Emacs, but it is really hard to find out about its pros and cons. So I have the following questions:
[Without X11]: Why or when would anybody use Emacs (Mutli)Term instead of Console & TMUX (or GNU Screen)?
[With X11] How does Emacs (Multi)Term compare to Xterm?
Obviously speed is one criteria for comparison, but I'm sure there are other.
You'd use Emacs term over tmux/screen if you're more familiar with Emacs and already use it for many other things and/or if you spend more time in Emacs than in the terminal.
Emacs's Term is much less sophisticated and much less reliable than xterm. But it works within Emacs so if you live in Emacs, it might be a good option.
Note that you may also prefer to use Emacs's M-x shell functionality, which gives you a command line without giving you an actual terminal emulator. That means that the commands are edited in Emacs before being sent to the underlying command-line program, so all the usual Emacs editing can be used there (and the history manipulation as well as command completion is performed by Emacs as well, which can be great, or can be disappointing (e.g. if the completion needs info which Emacs does not have)).
After years of experimentation with editors, the fact is I prefer them as minimal as possible. I never use fancy features and the full-feature IDE's become bloated, heavy, and slow. Of course, when I do something that pretty much requires a specific IDE (like Android dev and Eclipse) I have no problems using it. But most of the time, I use gedit for programming.
However, I like many Emacs commands, and I want to use them occasionally. Is there a way to embed Emacs inside of gedit? For instance, I envision pressing alt-q (or whatever combo) and Emacs mode is enabled, and from then on all my key presses in the current tab do Emacs commands. I press alt-q again, and it turns off. This would allow me the best of both worlds. Anything like this exist, or do I need to write this plugin myself?
No.
I've seen discussion of embedding of Emacs in other applications in the past, and the consensus is that even that's not feasible, let alone what you're suggesting.
You'd be better off identifying what gedit does that makes you want to use it instead of Emacs, and extending Emacs to make it do that, too. (There can't be that much --- gedit doesn't do much.) The extra features can just sit there and wait for you, and you'll find it easier to locate and use them if you're comfortable in Emacs-mode already.
(On top of all the other advantages of Emacs, you gain the ability to use the same editor you use in a windowed environment on the terminal --- a huge advantage.)
Or maybe yes . . .
You can use the External Tools plugin of gedit (look for it in Preferences). Add a new command, bind it to the key you want, and use this script:
#!/bin/sh
FILE_NAME=$GEDIT_CURRENT_DOCUMENT_PATH
emacs $FILE_NAME
If you want it to open in the currently-running Emacs, replace emacs with emacsclient, and add the following to your .emacs:
(server-start)
This is kind of backward. Why don't you just use Emacs and stay away from all the extra bells and whistles? It'd probably be easier to coax emacs to emulate gedit than the other way around.
If gedit (a) can be scripted to launch another application with the current file as an argument, and (b) will notice if the file is modified on disk and offer to reload it, then you would have a workaround.
I've never really used PowerShell before, and playing with it a bit, it looks like it uses cmd.exe's style of tab completion (fill in the first likely candidate, and then you can use tab to cycle through other alternatives). I'd much prefer the way e.g. bash works, where if there are multiple candidates, it shows a list of them.
Is there an easy way to turn this on, by any chance?
I have seen this implemented with an add-on called PowerTab (original post). For script editing there are some editors that support this sort of drop down Intellisense. Check out the free PowerGUI editor.
You want PSReadline: https://github.com/lzybkr/psreadline
It includes many completion and shell experiences you might expect from bash, etc.
I'm not sure if this is possible, but does anyone know if I can pipe ESS commands (i.e. evaluate region) to a R process running outside of Emacs? The Emacs terminal hangs up a bit (more often than Apple's terminal) and I'd like to just ditch it, while still using ESS commands. Currently I am doing the less efficient copy and paste technique :-)
Vince
Why not just kill the underlying R process, start a new one and continue the session in the same ESS buffer?
This doesn't answer your specific question and my experience is on Windows, but assuming it's challenging in ESS, I just mention:
There are other IDE's which have no trouble doing this (e.g. Tinn-R, StatET). In particular, for one supported on multiple operating systems, have a look at the StatET plugin for Eclipse. One very nice feature of Eclipse is that not only can you run the commands on a console outside the IDE, but you can also run multiple console sessions at the same time. This allows you to easily compare results side by side.
Needless to say, that's irrelevant if you're comfortable using ESS.