Related
I'm going through SICP course and as recommended installed mit-scheme. I want to use the REPL together with a scheme file. The reason is because I can add scheme code in the file and then run the commands in REPL. What I have works, but the problem is every time I edit the file, I have to quit terminal and reload the file for REPL to see changes.
Is there a way to reload the file easily or some other way for REPL to see changes from the file?
This my setup:
I installed mit-scheme with brew install mit-scheme
I have a local file named code.scm
In terminal, I load the file with mit-scheme --load /Users/name/Desktop/code.scm
Terminal now starts the REPL and everything works. The problem is that if I add new code to the file code.scm, I have to quit terminal and call this again: mit-scheme --load /Users/name/Desktop/code.scm
System details:
macOS Catalina - 10.15.6
Default Mac Terminal app - Version 2.10
MIT/GNU Scheme running under OS X
The text editor I use is Atom - 1.50.0
Question Edit #1 (Based on answer below)
I tried following instructions but this is complicated.
This is what I did:
Run mit-scheme < /Users/Desktop/code.scm
After this I ran mit-scheme --edit to open Edwin. I tried to use the code inside of the code.scm file but it doesn't recognize it. This is the code in code.scm file:
This is what I want to be able to do:
Notice in this picture, I can type a command, press enter and it automatically runs command. However, I want to be able to call (fib 5) and it references the function in code.scm file.
Could someone explain step by step how to do this? It's confusing looking at documentation for scheme websites.
There's actually a built-in load procedure available in the MIT Scheme REPL.
Evaluating
(load "path/to/file.scm")
causes the Scheme file located at path/to/file.scm to be evaluated at the top level (note that the double quotes around the file name are required).
And, as it turns out, this same function can be used to reload a file.
With this in mind, a possible "workflow" might look like this:
Create new source file
Evaluate (load "path/to/file.scm") in the REPL
Edit source file
Evaluate (load "path/to/file.scm") in the REPL
...etc.
Unfortunately, I don't think there is a built-in "reload" procedure.
But...if you find yourself reloading a lot (as I imagine you will), you can always quickly write your own at the beginning of a hacking session:
(define (reload)
(load "path/to/file.scm"))
And then just call (reload) whenever you make a change to your source file.
If you're interesting in using Emacs, I'd say it's worth a shot.
There's a bit of a learning curve, but it's not as steep as it looks up front :)
Also, I cannot recommend the Racket programming language(s) enough.
There is an incredibly straightforward way to set it up for SICP, and it's a much more forgiving environment than Emacs.
Let me know if you are interested and want any help getting started.
You should use emacs with xscheme.el. It works much better.
If you continue as you do, you can also do mit-scheme < code.scm or mit-scheme --edit code.scm and you will also get a *repl* buffer inside edwin.
I recommend you the emacs way, however.
A (load "/path/to/file") command should be available to you within MIT Scheme and the Edwin editor it comes with. However, I would actually recommend that you use Emacs, and use Geiser within that to access both the REPL and to help with scheme file editing. It also makes dealing with various Scheme REPLs such as Chez Scheme, Racket, MIT Scheme, Guile, Chicken, Gambit and Chibi Scheme fairly effortless. The same (load "/path/to/file") command would then be available to you within the REPL running under Geiser, within Emacs, but is generally much more powerful and seamless than when using the "naked" REPL. Emacs is very well tuned to use with Scheme and LISP. Highly recommended.
Evaluate entire buffer: press M-o (M is Alt on Windows). When in source file window, press it. It will evaluate the entire buffer i.e. (re)load the entire source file (without even saving it first). I found it by googling "mit scheme edwin tutorial". Edwin is kind of Emacs itself.
This page says: "C-c C-s when done in a scheme-mode buffer [i.e. Scheme source file window], will switch to the Scheme interaction buffer [i.e. REPL]". i.e. you press C-x C-s to save file, M-o to evaluate (i.e. load), C-c C-s to switch to the REPL.
If you've split your screen with C-x 2 between a source file buffer and the REPL ("interactions buffer"), you can switch between them by pressing C-x o (for "go to the other window").
In Emacs Prelude, I cannot figure out how to create a new file when a file exists that "matches" the name of the file.
In the example screen capture, I am trying to create a file called spawn.exs in a directory that already contains a file called spawn_basic.exs. When I use C-xC-f to create a new file, emacs is matching spawn.exs to spawn_basic.exs and hitting Enter results in opening spawn_basic.exs instead of creating spawn.exs.
I've tried some workarounds (i.e. using touch to create the file) but I'm looking for a simpler solution that would require only one command. If there is not a command to do this, is there a way to disable the file name matching feature in Prelude? I like most everything else about Prelude compared to vanilla Emacs so I would rather not switch back.
In Prelude, C-x C-f is bound to helm-find-files. It's usually
great, but for this case I don't see a good workaround for bypassing
its match (as you've described).
However, ido-find-file has a similarly friendly completion system,
yet offers a nice solution to bypass the completion. When you type
spawn.exs, open by pressing C-j instead of RET. I think Helm
should do this too (instead of treating them the same), so you might
want to submit a feature request (to match Ido's "verbatim entry").
Ido works well as a find-file replacement, and it's recommended over
Helm for simple cases like this
in Mastering Emacs. So you could
remap it with:
(global-set-key (kbd "C-x C-f") 'ido-find-file)
I use Emacs v. 22 (the console version, either remotely with PuTTY or locally with Konsole) as my primary text editor on Linux. It takes a while to load up each time I start it though, probably almost a second, although I never timed it. I tend to open and close Emacs a lot, because I'm more comfortable using the Bash command-line for file/directory manipulation and compiling.
How can I speed up the start-up time?
Others have covered using gnuserve and emacsclient, and I'd suggest compiling within emacs (being able to jump to compilation errors is a win).
But, specifically speeding up the .emacs can be done by:
Byte compiling the .emacs file, which you can do automatically by using this snippet of code
Replacing as many of the (require 'package) statements with autoloaded functionality. This will delay loading of lisp until it's actually required. Using this technique allowed me to speed up my startup from >6 seconds to <1. This takes a little bit of work because not all libraries come properly marked autoload.
Removing code/functionality you no longer use.
Try running emacs with the option --no-site-file to avoid loading unnecessary packages in the site installation site-start.el.
If you are really serious, you can roll your own emacs with your favorite functionality already loaded. This, of course, means it's more involved to make changes to what you have in your .emacs because it's a part of the binary. Follow the link for information on how to use dump-emacs.
Buy a faster computer and/or faster disk.
How to determine what your .emacs loads
Now, how do you find out what your .emacs loads? With the goal to remove the functionality, or to delay it? Check your *Messages* buffer, which contains lines like:
Loading /home/tjackson/.emacs.tjackson.el (source)...
Loading /home/tjackson/installed/emacs/lisp/loaddefs.el (source)...done
Loading /user/tjackson/.elisp/source/loaddefs.el (source)...done
Loading autorevert...done
Loading /home/tjackson/.emacs.tjackson.el (source)...done
If you'll notice, the Loading statements can nest: the first .emacs.tjackson.el ends with ... and the last line shows the .emacs.tjackson.el load is ...done. All those other files are loaded from inside my .emacs.tjackson.el file. All the other loads are atomic.
Note: If you have a large .emacs, it's possible that the *Messages* buffer will lose some of the messages because it only keeps a fixed amount of information. You can add this setting early on to your .emacs to keep all the messages around:
(setq message-log-max t)
Note: It the 'load command will suppress the messages if its fourth argument nomessage is non-nil, so remove any such invocations (or, advise 'load and force the fourth argument to be nil).
In addition to Adam Rosenfield's solution, I recommend to use Emacs in server mode. You may add (server-start) to your dotemacs, and run emacsclient instead of emacs whenever you want to open file in Emacs. That way you have to pay the loading cost of Emacs only once, after then clients pop up immediately.
Edit
You're right, v22 does not create a new frame. Create a shell script that do the trick:
#!/bin/bash
# Argument: filename to open in new Emacs frame
/usr/bin/emacsclient -e '(let ((default-directory "`pwd`/")) (select-frame (make-frame)) (find-file "'$1'"))'
Edit 2
In v24+, you can do emacsclient -c to create a new frame.
Don't close Emacs every time you want to use the shell. Use Ctrl-Z to move Emacs to the background and the fg command in Bash to move it back to the foreground.
A couple of tips:
Use autoloads
Using autoload saves you from loading libraries until you use them.
For example:
(if (locate-library "ediff-trees")
(autoload 'ediff-trees "ediff-trees" "Start an tree ediff" t))
Compile your .emacs
Gives you a slight speed increase although there are pitfalls if you
work with version control and your .emacs is newer than .emacs.elc.
One common trick is:
(defun autocompile nil
"compile itself if ~/.emacs"
(interactive)
(require 'bytecomp)
(let ((dotemacs (file-truename user-init-file)))
(if (string= (buffer-file-name) (file-chase-links dotemacs))
(byte-compile-file dotemacs))))
(add-hook 'after-save-hook 'autocompile)
Learn to love emacs server.
Running emacs as a server means never having to close it down. However
I note your still using emacs22. emacs23 supports multi-tty which makes
it a lot easier to run emacs in one screen session and then bring up
new windows in another terminal. I use emacs to edit mail for my mail
client (mutt) and emacsclient is fantastic for these sort of quick edits.
One of
M-x shell
M-x eshell
M-x term
M-x ansi-term
should meet your command-line needs from within Emacs.
You can also use M-! (aka M-x shell-command) to execute a one-liner without dropping to the shell.
Check your .emacs file to see if you're loading unnecessary packages. Loading packages can take a significant amount of time. For example, you might only want to load the php-mode package if you're editing a PHP file. You can do that by installing a hook procedure, although I'm not certain of the details.
Also make sure that any packages you're loading are compiled (.elc files). You can compile an elisp file by running
emacs -batch -f batch-byte-compile thefile.el
Compiled packages load much faster than uncompiled packages.
"I tend to open and close emacs a lot, because I'm more comfortable using the bash command line for file/directory manipulation and compiling."
You're describing the way an editor like vim is used like. Shoot in&out. Emacs is usually kept open, and mostly all is done from "within it". hiena already answered what would be the correct approach here.
The fastest way is to profile your .emacs. I cut down my load time from >3s to 1s in 5 minutes after I found that 4 particular lines in my .emacs were taking up more than 80% of the load time.
One thing that helped me reduce the load time of my .emacs, in addition to autoload (as others have suggested), is eval-after-load. In the following example, delaying the call to sql-set-product saves you from having to load sql in your .emacs, making the exisiting sql autoloads more effective.
(eval-after-load "sql"
'(progn
(sql-set-product 'mysql)
(setq sql-mysql-options '("-C" "-t" "-f" "-n"))
(setq sql-sqlite-program "sqlite3")
))
Of course, for some packages there will be a hook available that you can do the same thing, but sometimes there isn't, or else this way just proves easier to think about.
Emacs is designed to run "all the time" (or at least for long periods of time), thus starting and stopping Emacs several times during a day is not recommended.
I would suggest using screen. Screen is a terminal multiplexer, giving you an unlimited virtual terminals in one terminal.
After installing simply write "screen emacs" in your terminal. Emacs will start as usual, but pressing "c-a c" (that is press ctrl-a and then c) will open a new virtual terminal. You can get back to emacs by pressing "c-a c-a" (that's two times ctrl-a).
You can even detach from the running screen session, the key sequence is "c-a d".
Re-attach to the session by issuing "screen -R" and you will be back where you left. This enables you to start an emacs session at work, detach, go home, and re-attach from home.
I've been running Emacs like this for months in a row.
Here's the official web site: http://www.gnu.org/software/screen/ but try googling for screen tutorials and howtos
You can use benchmark-init to profile your Emacs startup. It will keep track of what modules are being loaded and how much time is spent on each. The results can be presented either in a tabulated form or as a tree. The tree makes it easier to track who loads what, which can be helpful when you load a package with a lot of dependencies, and the tabulated form helps you quickly find where most of the time is being spent.
Once you have these results try to figure out if all of the modules have to be loaded all the time or if you can perhaps load some of them on-demand. For instance, in my configuration I only load Emacs extensions that are specific to certain modes when that mode is actually activated since most of the time I only use a small subset of them in a session. eval-after-load and mode hooks will be your friends here.
By applying this method my Emacs starts in 3-4 seconds and I have close to 200 extensions installed. Most of the time is spent loading Helm, which I always load since it replaces find-file and other core functions that are always needed, and CEDET, since I use the latest version and it has to be loaded before Emacs tries to load the older built-in version.
Try using the https://github.com/jwiegley/use-package macro to define your package loads and customizations. It handles deferred loading of packages for you, making it relatively easy to get good startup times even in the presence of large numbers of configured packages. I have almost 100 packages referenced in my .emacs, but my startup time is under 2 seconds on Linux, and 2.2s on the Mac.
One thing that others haven't mentioned is to include the elisp libraries you use as part of the dumped Emacs to move the library loading time from Emacs startup to Emacs build. It is not for the faint-hearted, but if you load several libraries in .emacs it could win you a few seconds of startup time.
I had around 120sec start time. I was able to find the fix installing this:
https://github.com/dholm/benchmark-init-el
put on top of your init.el
(let ((benchmark-init.el "~/.emacs.d/el-get/benchmark-init/benchmark-init.el"))
(when (file-exists-p benchmark-init.el)
(load benchmark-init.el)))
then once your emacs started, run:
M-x benchmark-init/show-durations-tree
On my side the problem was 127 secs in tramp-loaddefs
I fixed it by adding
127.0.0.1 host.does.not.exist
to /etc/hosts and that made my startup fast
see more here: https://github.com/emacs-helm/helm/issues/1045
another thing that maybe helpful to you: https://www.emacswiki.org/emacs/ProfileDotEmacs
This doesn't answer the question, but is kind of relevant
I don't know how to make it start faster, but there are a few things I could suggest:
for most things you do on the command line, you can do them in emacs:
compile: M-x compile, then type the command you use
my experience is only with C++, but with g++ you can press C-x ` to jump to lines that the compiler complains about
run shell commands: M-!, dumps output into a buffer
interactive shell: M-x shell
alternatively, you could run emacs like this:
emacs file.ext &
which opens emacs in the background so you can still use the shell ( this works best with putty and X forwarding with something like Xming)
I was trying to solve the same problem, when I came across this question here. I just wanted to add that the problem for me was not because of the load time of emacs lisp packages, but the fact that the host did not have a fully resolved hostname
To check your package load time do
M-x emacs-init-time
For me it was 0.3 seconds, and yet the load time was extremely high.
After changing my hostname correctly, it fixed the problem.
To configure your fully resolved hostname edit /etc/hostname, and /etc/hostsfile with:
127.0.0.1 localhost localhost.localdomain
192.168.0.2 hostname hostname.domain
I would have to check my customization, but there is a package called gnuserve or emacsclient. It migrates a lot so you will have to google for it.
It runs one emacs session in the background. Any further sessions of emacs are essentially just new frames of that session. One advatage is quick startup times for your later sessions.
I've found that terminal emacs does not render the correct colors unless I explicitly set TERM=xterm-256color. I use gnome-terminal, and from what I understand, TERM should be set to gnome-256color. Similarly, I tend to use tmux a lot, which advises against any TERM setting other than screen-256color. Unfortunately, both of those settings (within their respective context - gnome-terminal or tmux) result in emacs having wrong colors, whereas vim displays colors correctly. However, if I export TERM=xterm-256color, the colors work just fine in emacs.
Can anyone explain what's going on, or offer a solution?
Update
Here's what I'm dealing with:
I can get the colors to look correct in the terminal by adding the following to my init.el:
(defun terminal-init-gnome ()
"Terminal initialization function for gnome-terminal."
;; This is a dirty hack that I accidentally stumbled across:
;; initializing "rxvt" first and _then_ "xterm" seems
;; to make the colors work... although I have no idea why.
(tty-run-terminal-initialization (selected-frame) "rxvt")
(tty-run-terminal-initialization (selected-frame) "xterm"))
This feels really, really wrong though. There has to be a logical explanation for this...
P.S.
I have very little knowledge of terminfo and the precise role that $TERM plays in the process of color terminal behavior. If it's safe to always use xterm-256color (even when $TERM "should" be gnome-256color or screen-256color), I'll go with that.
Maybe I'm not understanding something, buy why don't you run emacs like this:
TERM=xterm-256color emacs -nw
This way Emacs has its own TERM setting that you know works. You can also make an alias or wrap this in shell-script.
Terminals are a special type of device. When a process sends special byte sequences (called control sequences) to the terminal, it performs some action (like cursor positioning, change colors, etc).
You can read the ANSI terminal codes to find more detail about control sequences.
But terminals come from 70s, when hardware was limited in its capabilities, and a terminal cannot provide info about its capabilities (ie. which sequences it supports).
$TERM was used to resolve this issue - it allows programs to know what to send to the terminal to get the job done. termcap and terminfo are databases that store info about terminal capabilities for many $TERM names. If your $TERM is not in the db, you must ask an administrator to add it.
All terminal emulators inherit these limitations from old hardware terminals. So they need a properly set $TERM, and the terminfo/termcap DB MUST have data for this terminal. When a virtual terminal starts it sets the $TERM variable for you (and inside programs like bash). If $TERM is not in the terminfo/termcap you can quickly define an alias from $TERM to xterm-256color (you can find examples in the termcap file on how to do that).
This behavior has to do with the logic EMACS uses to determine whether the terminal background is dark or light. Run M-x list-colors-display with TERM set to either xterm-256color or screen-256color and you'll see that the exact same colors are listed. As you pointed out in the comments, the difference in color schemes that you've observed is due to the frame background mode. To see this, with your TERM set to screen-256color, compare the colors in
emacs -Q -nw --eval "(setq frame-background-mode 'light)"
and
emacs -Q -nw --eval "(setq frame-background-mode 'dark)"
The function frame-set-background-mode (in frame.el) checks to see whether the terminal type matches "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)" if it can't deduce the background color otherwise.
Within a running session, you can change the color scheme to 'light by evaluating
(let ((frame-background-mode 'light)) (frame-set-background-mode nil))
I am not that familiar with how emacs handles different terminals exactly. But looking at lisp/term directory in emacs sources, I found out that the existence of a function terminal-init-xxx allows you to add support for different terminals. For example, I've got:
(defun terminal-init-screen ()
"Terminal initialization function for screen."
;; Use the xterm color initialization code.
(xterm-register-default-colors)
(tty-set-up-initial-frame-faces))
in my .emacs, which adds support for screen-256color. You may try defining a similar function for gnome by renaming the above function to terminal-init-gnome.
NOTE: If you are interested, you can try to track down the calls from tty-run-terminal-initialization code. It first gets the terminal type using tty-type function, then looks at certain locations to load a relevant terminal file, then tries to locate the matching terminal-init-xxx function, and finally calls it. It may help you figure out the correct name for gnome-terminal.
It looks like unless your TERM indicates that your terminal has 256 colors, emacs will only use 8. Changing TERM to gnome-256color allowed the color registration functions to work.
There is a way to cheat, after all. When I run gnome-terminal, my terminal is set to xterm by default. Instead of changing TERM variable, it is possible to redirect xterm to another terminal, say, gnome-256color. Simply create the directory $(HOME)/.terminfo/x, then run ln -s /usr/share/terminfo/g/gnome-256color ~/.terminfo/x/xterm. I think this is better than setting TERM manually in .bashrc, because it only redirects a particular terminal to something else. A console login would still leave TERM as linux, and not xterm-256color.
Add this to your ~/.emacs:
(add-to-list 'term-file-aliases
'("st-256color" . "xterm-256color"))
It tells emacs that if it sees TERM=st-256color then it should initialize the terminal as if it had seen TERM=xterm-256color.
Longer answer:
Emacs is showing strange colors because it thinks your terminal can only support 8 colors. In Emacs, run M-x list-colors-display to see the colors it thinks are available. The correct number of colors is detected during terminal-specific initialization. It says, in part:
Each terminal type can have its own Lisp library that Emacs loads when run on that type of terminal.
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term. It has files for xterm, rxvt, screen, etc. but nothing for st. We need to help Emacs find the right initialization file. The documentation further says:
If there is an entry matching TERM in the term-file-aliases association list, Emacs uses the associated value in place of TERM
So that association list is a recommended way to handle unknown terminals. It works without you having to manually override the TERM environment variable.
On ubuntu 10.04 I too had noticed that running emacs -nw inside byobu/tmux/screen was using different colours from emacs -nw in the regular gnome-terminal.
I found that this is because byobu was setting TERM to screen-bce. Then setting TERM to xterm (for me, in the normal gnome-terminal TERM=xterm) gave me the same syntax highlighting when not running through byobu/screen.
So still not sure what the proper solution is.
See also this post:
Emacs Python-mode syntax highlighting
One of my colleagues uses TextPad, and one feature I found really useful is the Auto-Reload. (The feature has been described in this SO quesion: Alternative to TextPad's Prompt to Reload File). Basically, it keeps reloading the file without any prompt from the user, which is really helpful when monitoring log files that are updated in real-time. Is there something similar available for Emacs? If not, can anyone whip up the required elisp magic?
M-x auto-revert-mode
I should add that for log tails, there is the more specific auto-revert-tail-mode, and that if you like it as a general feature (my case), you can turn on global-auto-revert-mode, to revert all buffers. Beware of remote files in that case.
If you want auto-revert to apply everywhere you can also use global-auto-revert-mode. Add
(global-auto-revert-mode 1)
to your .emacs
Here's my preference, FWIW: I do not use auto-revert. Instead, I bind f5 to this command:
(defun revert-buffer-no-confirm ()
"Revert buffer without confirmation."
(interactive) (revert-buffer t t))
Sounds silly, but that simple change makes all of the difference. This is what f5 does anyway on MS Windows, so it's a habit that works in all applications (on Windows).
Note that I do not change (e.g. remap) any bindings for revert-buffer. I use this only when I explicitly want to revert without confirming (which is quite often, in practice).
HTH.