I'm trying to replicate the main example for the embedded use of emacs calc. (https://www.gnu.org/software/emacs/manual/html_node/calc/Embedded-Mode-Overview.html) So I have the line ln(ln(x)) with an empty line before and after.
But as result of C-x * e I get: calc-embedded: Variable binding depth exceeds max-specpdl-size.
I'm using GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2022-01-24, modified by Debian under Ubuntu jammy. I tried in org-mode and in *scratch*.
max-specpld-size is 1840. That should be enough.
Any suggestion on how to make embedded calc work?
I was able to recreate the same error by activating calc-embedded in a scratch buffer and killing that buffer. Then, when opening a new scratch buffer and trying to start calc-embedded, the calc-embedded-info array is populated with bad buffers and it goes into infinite recursion.
So, to fix it I set the info to nil: (setq calc-embedded-info nil), to start from a clean slate.
I think this should normally be handled by the kill-buffer-query-functions hook, but I'm not sure this is set in calc-embedded.
Related
I've been fooling around with comint-mode lately and I'm noticing some weird behaviors. Its very poorly documented, so I'm wondering if anyone has any insight on this.
In some modes, comint-send-string causes whatever is sent to be inserted into the comint buffer and then sent to the associated process, whereas in others, the input is send directly to the process without being placed into the buffer. For example, do run-python with the new (24.3) python.el and then do (comint-send-string "*Python*" "x=3\n"), the string x=3 is inserted into the buffer and then executed. If you do M-x shell, however, and then (comint-send-string "*shell*" "x=3\n"), no text is inserted into the buffer, the input is simply sent to the shell process directly to be executed.
Does anyone know why this difference in behavior exists or how I can change it?
I observe identical behavior on linux (emacs-version == "24.3.50.7", both GUI and emacs -Q -nw): neither
(comint-send-string "*Python*" "x=3\n")
nor
(comint-send-string "*shell*" "x=3\n")
insert anything in the comint buffer (i.e., the next prompt appears
right after the previous prompt - without even a newline between them).
I eventually figured it out. For some reason the system python on OSX causes this behavior, installing python from homebrew fixed it.
Emacs version I am using:
GNU Emacs 22.2.1 (i386-redhat-linux-gnu, GTK+ Version 2.12.9)
Invoking gdb from emacs breaks the horizontal scrolling in emacs windows. I invoke gdb by entering M-x gdb and then accept the default (only adding name of my binary at the end, e.g.):
gdb --annotate=3 unittest
At some point after the debugger is invoked (not immediately), the automatic horizontal scrolling no longer works.
By automatic horizontal scrolling I mean that the expected behaviour is: follow the cursor, shifting the viewport left or right when necessary. For example: when the cursor is positioned at the end of a long line (say column 200) the viewing area of the window is moved to the right, such that column 200 is visible. If I then press 'Home' and the cursor jumps to beginning of line - the window also follows it and I can see the left-most column of the buffer.
Pasting my entire .emacs file here is probably a bad idea so I just searched for entries related to hscroll:
(custom-set-variables
'(column-number-mode t)
'(cua-mode t nil (cua-base))
'(hscroll-global-mode t nil (hscroll))
'(hscroll-margin 5)
'(hscroll-mode-name " ")
'(hscroll-snap-threshold 30)
'(indent-tabs-mode nil)
...
... but I can attach it here or email it if anyone thinks it is needed...
Hope someone knows how to fix this as coz it's a real pain - every time I use the debugger I need to restart emacs... I am pretty sure this problem was not present in version 20....
I use GNU/Emacs for Erlang programming. I compile my code by issuing C-c C-k. When I call compile, Emacs opens a new buffer (Erlang). It's half the size of the original window. How can I control the size of this buffer?
Thank you.
You could try:
(setq compilation-window-height 15)
I'm not sure how Erlang mode does the window splitting. Generally speaking though, the main frame is split into 2 windows vertically using split-window-vertically which takes a SIZE argument to control the size of the window (check the documentation for further details). You can see if your erlang compilation command uses this and try wrapping/advising it.
Occasionally when I'm compiling, I have to scroll up my compilation buffer to see the details of an error. At this point, emacs stops "following" my compilation buffer, i.e., scrolling to automatically display new output.
I'm using Aqumacs on OS X. Any idea how I can "reattach" or re encourage the compilation buffer to follow again?
Regards,
Chris
Put in your ~/.emacs file
;; Compilation output
(setq compilation-scroll-output t)
or even
(setq compilation-scroll-output 'first-error)
to make it scroll to the first error.
Try using M-x auto-revert-tail-mode or M-x auto-revert-mode. Taken from official documentation:
One use of Auto-Revert mode is to
“tail” a file such as a system log, so
that changes made to that file by
other programs are continuously
displayed. To do this, just move the
point to the end of the buffer, and it
will stay there as the file contents
change. However, if you are sure that
the file will only change by growing
at the end, use Auto-Revert Tail mode
instead (auto-revert-tail-mode). It is
more efficient for this. Auto-Revert
Tail mode works also for remote files.
So, as Chmouel already noted, just moving point to end of buffer will also work.
I am not sure about aquamacs but for me (Emacs 23/Debian) I just go in the compilation window and place my cursor at the end of the window which will attach and follow (you can go to another window and it will still follow).
When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.