I noticed emacs has a sql-postgres mode. It's a good start, but my needs are very different. I usually have a large SQL file that I am editing and I want to "run" it on the database. I would like to edit my code in Emacs, not PG Admin. However, I am a bit more picky on how I see the results. I would rather not see a new Emacs buffer since Emacs doesn't really do grids that well. I was thinking of popping up some program that could show me the results in a very pretty, interactive view. Maybe something like openoffice or some custom piece of code.
I think the best method is to hack together a makefile that will automatically run the sql file against postgres (which may even allow me to jump to any errors). Then, if the script is successful, possible pipe the results to some program. But which program and how can I get those results to it?
Please let me know if there is a better way. I don't want some commercial software or Windows-only freeware. I'd prefer OpenSource. Any advice?
You could use psql on the command line and set emacs to be your editor of choice. Whenever you type \e in psql, it will open your editor of choice. Grid display + emacs and there's no need to write any code.
Related
I'm coming from VSCode to Neovim, and for the most part I've been able to accommodate/replicate the workflows and functionality I've gotten used to in VSCode in Vim. Right now, I'm stuck on replicating the Link functionality of the VSCode integrated terminal.
This lets you mouse over text like main.py or server.go:50 and ctrl-click to jump to that file or line location in your editor panes. This really helpful for jumping to the locations of compilation errors or test failures from their associated terminal output.
I've searched for existing plugins/solutions for this but haven't found any. Are there any that I've missed? Otherwise, what might be a good approach to scripting this myself?
I'm new to vimscripting, but I'd assume you could do some regex and with knowledge of the current working directory, you could infer the correct filepath to open.
Replicating one editor's workflow in another is not exactly a good idea as the two editors have—supposedly, if not why switch in the first place?—different feature sets or even paradigms. For instance, staying in insert mode all the time in Vim because that's what you are used to would make no sense because Vim derives most of its value from its modality… and you would probably also find examples in the other direction.
Case in point, compiling and jumping to errors in Vim typically doesn't involve the built-in :terminal at all. You are supposed to use the :help quickfix feature, which exists for that very purpose.
See :help 30.1 for a gentle introduction from the user manual.
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 have just started using sqlplus for oracle and it is horrible, I was trying to look for ideas if anyone has any scripts written around sqlplus which stores history and and it works more like an editor.
You might want to consider using YASQL, http://sourceforge.net/projects/yasql/, which is an alternative client written in Perl.
It is pretty neat and covers most of what one would expect from a DB CLI client. It does not support everything sqlplus does, though.
What you want is the extremely handy rlwrap command. It will wrap almost any command and add readline-style command history and editing. It supports, colors, custom completions, and all that jazz. I'm not sure if the link I provided to rlwrap is the "official" source, and compiling it can sometimes be a pain, but your favorite Unix package source should have some version of it available.
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.