Emacs, Geiser and Chez Scheme with transcript-on - emacs

I am working my way through Dybvig's "The Scheme Programming Language" book. I am using Chez Scheme 9.4.1 as my REPL. I am running said REPL within Emacs using Geiser. Chez Scheme has a transcript-on function that records the input and output of the REPL into a text file, which I find useful. By running this however within Emacs and Geiser, I am however getting also a running "commentary" from Geiser that renders the text file output unnecessarily verbose and cumbersome since it includes the very verbose Geiser output. e.g.
> (geiser:eval '#f '(geiser:autodoc '(1 1)))
((result "()") (output . ""))
> (geiser:eval '#f '(geiser:autodoc '(2 1)))
((result "()") (output . ""))
> (geiser:eval '#f '(geiser:autodoc '(3 1)))
((result "()") (output . ""))
> (geiser:eval '#f '(geiser:autodoc '(1)))
((result "()") (output . ""))
> (geiser:eval '#f '(geiser:autodoc '(1 1)))
((result "()") (output . ""))
How do I restrict the output going to the text file to just the "read" and "print" input and output of the REPL without the unnecessary Geiser "commentary", while still getting the benefits of running it within Emacs and Geiser?

I'm not an expert in Geiser or Scheme, but I am familiar with lisp in emacs. I suspect that you won't be able to filter out the information that way- Geiser's requests for information are being entered at the same REPL as yours, it's just the emacs interface does not display them.
However, Geiser is probably just using an emacs buffer to display the REPL, and like any other text buffer you should be able to copy its contents to a file pretty easily. If you get good at configuring emacs, it shouldn't be difficult to automate the procedure- emacs is pretty good at that sort of thing.

Related

Execute Scala code from within Emacs

Scala REPL is great for short expressions, but multi-line expressions are difficult to edit, especially if there some syntax error somewhere, it requires reissuing the statements line by line.
On the other hand Emacs scala-mode2 looks nice, it would be awesome if I could just select a region of the buffer and send it to Scala REPL, and see the results in a minibuffer.
Is this possible? Googling didn't produce any positive answer.
or do you think this would be an useful feature?
If I were to implement this, what would be the best approach? I was thinking that I could just have a Scala REPL running in the background and interacting with it via std in/out from Emacs.
Just in case anyone is interested, the below Emacs script will evaluate the region in the Scala REPL.
(defun eval-scala (start end)
(interactive (list (point) (mark)))
;; start scala if it hasn't started yet
(unless (get-process "scala-repl")
(let ((process-connection-type nil)) ; use a pipe
(start-process "scala-repl" "*scala*" "scala"))
(set-buffer "*scala*")
(special-mode)
)
;; execute
(process-send-region "scala-repl" start end)
(process-send-string "scala-repl" "\n")
;;display buffer
(display-buffer
(get-buffer "*scala*")
'((display-buffer-reuse-window
display-buffer-pop-up-window
display-buffer-pop-up-frame)
(reusable-frames . 0)
(window-height . 8) (window-width . nil)
)
)
)
Bind the above eval-scala function to your preferred short-cut key, e.g.
(global-set-key (kbd "C-e") 'eval-scala)

Reading a character without requiring the Enter button pressed

read-line and read-char both require you press Enter key after typing something. Is there any mechanism in Common Lisp that would allow the program to continue upon the press of any single character immediately, without requiring the additional step of pressing Enter?
I'm trying to build a quick, dynamic text input interface for a program so users can quickly navigate around and do different things by pressing numbers or letters corresponding to onscreen menus. All the extra presses of the Enter key seriously interrupt the workflow. This would also be similar to a "y/n" type of interrogation from a prompt, where just pressing "y" or "n" is sufficient.
I am using SBCL, if that makes a difference. Perhaps this is implementation specific, as I tried both examples on this page and it does not work (I still need to press Enter); here's the first one:
(defun y-or-n ()
(clear-input *standard-input*)
(loop as dum = (format t "Y or N for yes or no: ")
as c = (read-char)
as q = (and (not (equal c #\n)) (not (equal c #\y)))
when q do (format t "~%Need Y or N~%")
unless q return (if (equal c #\y) 'yes 'no)))
read-char doesn't require you to press enter. E.g.,
CL-USER> (with-input-from-string (x "hello")
(print (read-char x)))
#\h
Similarly, if you send some input into SBCL from the command line, it will be read without a newline:
$ echo -n hello | sbcl --eval "(print (read-char))"
…
#\h
After reading and printing #\h, SBCL saw the ello:
*
debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD
"initial thread" RUNNING
{1002979011}>:
The variable ELLO is unbound.
I think this is enough to confirm that it's not that read-char needs a newline, but rather that the buffering of the input is the problem. I think this is the same problem (or non-problem) that's described in a comp.lang.lisp thread from 2008: Re: A problem with read-char. The user asks:
Is it possible to make read-char behave like getch in С when working
with interactive stream (standard-input)? In SBCL read-char wants
"enter" key to unhang from REPL, in C getchar returns immediately
after user press key on keyboard. Probably is possible to run code
that uses read-char with direct console access, aside REPL?
There were four responses (see the thread index to get to all of them). These explain why this behavior is observed (viz., that the Lisp process isn't getting raw input from the terminal, but rather buffered input). Pascal Bourguignon described the problem, and a way to handle this with CLISP (but doesn't provide all that much help, aside from the usual good advice) about working around this in SBCL:
The difference is that curses puts the terminal in raw mode to be able
to receive the characters from the keyboard one at a time, instead of
leaving the terminal in cooked mode, where the unix driver bufferize
lines and handles backspace, amongst other niceties.
…
Now, I don't know about SBCL, (check the manual of SBCL). I only have
the Implementation Notes of CLISP loaded in my wetware. In CLISP you
can use the EXT:WITH-KEYBOARD macro (while the basic output features
of curses are provided by the SCREEN package).
Rob Warnock's response included some workaround code for CMUCL that might or might not work for SBCL:
I once wrote the following for CMUCL for an application that wanted
to be able to type a single character response to a prompt without
messing up the terminal screen:
(defun read-char-no-echo-cbreak (&optional (stream *query-io*))
(with-alien ((old (struct termios))
(new (struct termios)))
(let ((e0 (unix-tcgetattr 0 old))
(e1 (unix-tcgetattr 0 new))
(bits (logior tty-icanon tty-echo tty-echoe
tty-echok tty-echonl)))
(declare (ignorable e0 e1)) ;[probably should test for error here]
(unwind-protect
(progn
(setf (slot new 'c-lflag) (logandc2 (slot old 'c-lflag) bits))
(setf (deref (slot new 'c-cc) vmin) 1)
(setf (deref (slot new 'c-cc) vtime) 0)
(unix-tcsetattr 0 tcsadrain new)
(read-char stream))
(unix-tcsetattr 0 tcsadrain old)))))
SBCL has probably diverged considerably from CMUCL in this area, but
something similar should be doable with SBCL. Start by looking in the
SB-UNIX or maybe the SB-POSIX packages...
User vippstar's response provided a link to what might be the most portable solution
Since you want to do something that might not be portable to a
microcontroller (but the benifit is the much more enhanced UI), use a
non-standard library, such as CL-ncurses.
Adding another answer to point out the existence of this tutorial: cl-charms crash course, by Daniel "jackdaniel" Kochmański. Disabling buffering is related to how the terminal is configured, and cl-charms is a library that exploit the ncurses C library to configure the terminal for interactive usage.
I found cl-charms, which seems to be a fork of the abandoned cl-curses. However, the included example program charms-paint uses 100 % CPU to run the trivial paint application. The problem seems to be that the main loop busy-waits for input.
You could use the trivial-raw-io library to read a single character without pressing Enter. Usage: (trivial-raw-io:read-char). It works on SBCL, CCL, CMUCL, and CLISP on Linux, and should work on other Unix-like operating systems as well. The library has only one simple dependency (the alexandria library), and it is licensed under the BSD 2-clause license.
I've struggled recently with the same issue and I ended up solving it simply by using FFI to interact with termios and disable canonical mode. Essentially that what's mentioned in #JoshuaTaylor's response. I couldn't get that code to work with SBCL, for whatever reason, so I made a few changes. Here is the complete working code (only tested with SBCL):
(define-alien-type nil
(struct termios
(c_iflag unsigned-long)
(c_oflag unsigned-long)
(c_cflag unsigned-long)
(c_lflag unsigned-long)
(c_cc (array unsigned-char 20))
(c_ispeed unsigned-long)
(c_ospeed unsigned-long)))
(declaim (inline tcgetattr))
(define-alien-routine "tcgetattr" int
(fd int)
(term (* (struct termios))))
(declaim (inline tcsetattr))
(define-alien-routine "tcsetattr" int
(fd int)
(action int)
(term (* (struct termios))))
(defun read-single-byte (&optional (s *standard-input*))
(with-alien ((old (struct termios))
(new (struct termios)))
(let ((e0 (tcgetattr 0 (addr old)))
(e1 (tcgetattr 0 (addr new)))
(n-lflag (slot new 'c_lflag)))
(declare (ignorable e0 e1))
(unwind-protect
(progn
(setf (ldb (byte 1 8) n-lflag) 0) ; disables canonical mode
(setf (ldb (byte 1 3) n-lflag) 0) ; disables echoing input char
(setf (slot new 'c_lflag) n-lflag)
(tcsetattr 0 0 (addr new))
(read-byte s))
(tcsetattr 0 0 (addr old))))))
Simply interfacing with termios should do the trick, there is no need for external libraries. You can find on termios's man page more information (https://man7.org/linux/man-pages/man3/termios.3.html), but essentially it's when the terminal is in canonical mode (ICANON) that it needs to wait for a line delimiter before the contents of the buffer become available. I hope this helps!

How to avoid pop-up of *Async Shell Command* buffer in Emacs?

My ~/.emacs contains the following settings for opening certain files with certain applications (Ubuntu 12.10; Emacs 24):
(setq dired-guess-shell-alist-user
'(("\\.pdf\\'" "okular ? &")
("\\.djvu\\'" "okular ? &")
("\\.mp3\\'" "vlc ? &")
("\\.mp4\\'" "vlc ? &")
))
When I navigate to a .pdf in dired-mode and hit !, it opens the .pdf in Okular, but the dired-buffer is split into two parts, the second one now being a useless *Async Shell Command* buffer containing content like
okular(25393)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25393)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25393)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25393)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
How can I prevent this buffer from being opened? (except for, maybe, if there was an error and this information is useful).
I found related questions here and here, but they seem to deal with specific commands executed asynchronously, instead of the *Async Shell Command* in general (if possible, I would like to change the behaviour in general for asynchronous processes, not only for certain file types)
Found this here:
(call-process-shell-command "okular&" nil 0)
Works for me. No stderr gobbledygook.
The question was asked in 2012, and at the time of my writing, the most recent answer is dated 2015. Now, in 2017, I can say that the answer is simple:
(add-to-list 'display-buffer-alist
(cons "\\*Async Shell Command\\*.*" (cons #'display-buffer-no-window nil)))
I am piggybacking off of user1404316's answer, but here is another generic way to achieve the desired outcome.
(defun async-shell-command-no-window
(command)
(interactive)
(let
((display-buffer-alist
(list
(cons
"\\*Async Shell Command\\*.*"
(cons #'display-buffer-no-window nil)))))
(async-shell-command
command)))
I'm not entirely sure about doing it for asynchronous processes in general, but for anything that goes through async-shell-command, this should work:
(defadvice async-shell-command (around hide-async-windows activate)
(save-window-excursion
ad-do-it))
Sadly there is no good way to avoid this buffer as it's called directly by 'shell-command' function ('async-shell-command' is just a wrapper).
So, a much better way is to replace 'async-shell-command' with 'start-process'.
You should start process with 'set-process-sentinel' to detect the moment when process emits 'exit signal. Then kill process.
A slightly more complicated incantation should get you what you want. Just use a shell command like: (okular ? >& /dev/null &).
I haven't tested this with okular, but I can do M-! ((echo foo; sleep 10; echo bar) >& /dev/null &) and Emacs returns immediately without creating a new buffer.
I solved the problem, using this method:
;list of programs, corresponding to extensions
(setq alist-programs
'(("pdf" ."okular")
("djvu" . "okular")
("mp3" . "xmms")))
(defun my-run-async-command (command file)
"Run a command COMMAND on the file asynchronously.
No buffers are created"
(interactive
(let ((file (car (dired-get-marked-files t current-prefix-arg))))
(list
;last element of alist-programs, contains COMMAND
(cdr
(assoc
(file-name-extension file)
alist-programs))
file)))
;begin of function body
(if command ;command if not nil?
(start-process "command" nil command file)
)
)
;attach function to <f2> key
(add-hook 'dired-mode-hook
(lambda ()
(define-key dired-mode-map (kbd "<f2>") 'my-run-async-command)))
The suggestions to use start-process are ok if he is running a distinct program on the path of course. But if you want run some shell command in a specific directory (eg your project directory) then simply quell the popup - you frequently want the buffer but just dont want it jumping up in your face. eg I run a webserver and I want to see the output, just not now...
(use-package php-mode
:config
(add-to-list 'display-buffer-alist
(cons "\\*Symfony Web Server\\*.*" (cons #'display-buffer-no-window nil)))
(defun php-mode-webserver-hook ()
(if (projectile-project-root) (let ((default-directory (projectile-project-root)))
(unless (get-buffer "*Symfony Web Server*" )
(async-shell-command "bin/console server:run" "*Symfony Web Server*")))))
:hook (php-mode . php-mode-webserver-hook))

How can I distinguish scheme dialects in org-babel code blocks?

Evaluating this code (C-c C-c):
#+begin_src scheme
(andmap + '(1 2 3) '(4 5 6))
#+end_src
leads to the following babel error:
ERROR: Unbound variable: andmap
The cause: babel evaluated the code with Guile instead of Racket. How can I tell Babel to execute code using Racket, not Guile?
http://terohasu.net/blog/2011-09-08-on-racket-support-in-emacs-org-mode.html describes a way:
When configuring Emacs to set things up I wasn’t familiar with Babel
or any of the solutions for evaluating Scheme code under Emacs for
that matter. After some looking at Babel and Inferior
Lisp,
I didn’t manage to configure Babel to invoke Racket for evaluating a
code listing. Instead I resorted to replacing the Babel code for
Scheme support (in the ob-scheme.el) with basically just the following
code:
(defun org-babel-execute:scheme (body params)
(let* ((tangle (cdr (assoc :tangle params)))
(script-file
(if (string-equal tangle "no")
(org-babel-temp-file "org-babel-" ".rkt")
tangle)))
(with-temp-file script-file
(insert body))
(let* ((pn (org-babel-process-file-name script-file))
(cmd (format "racket -u %s" pn)))
(message cmd)
(shell-command-to-string cmd)
)))
This solution creates a new Racket instance for every evaluation, and
hence is not as efficient as an Inferior Lisp based solution (or
similar), but it works, is more straightforward, avoids Racket issues
such as specifying the correct module context for evaluating the code,
and the evaluation context is always “clean” as a new Racket instance
is used.

How do I make emacs render mathematical combining characters in font-lock mode?

I am trying to get emacs to properly render mathematical combining characters such the diaeresis, over bar, etc in font-lock mode. The goal is to be able to write something mathematical like x_dot and have it be displayed as "ẋ", or x_bar as "x̄".
This is what I have so far, and it mostly works.
(font-lock-add-keywords
nil
`(("\\<\\(\\w\\)\\(_dot\\)\\>"
(0 (progn (compose-region (match-beginning 1) (match-end 2)
(concatenate 'string (match-string 1) " ̇" )) nil)))))
BUT: I see a visual artifact character just before the composed character. Test this out by writing "x_dot" or something similar in the *scratch* buffer after executing the above.
This artifact comes and goes like a phantom. This behavior doesn't occur when composing normal characters like "o" and "-", as in the following example.
(font-lock-add-keywords
nil
`(("\\<\\(\\w\\)\\(_dash\\)\\>"
(0 (progn (compose-region (match-beginning 1) (match-end 2)
(concatenate 'string (match-string 1) "-" )) nil)))))
And then typing in "x_dash" somewhere.
What is going on?
For what it's worth, your first example works fine without artifacts in my bleeding-edge Emacs on OS X. You're probably seeing a rendering quirk specific to your platform's emacs UI and/or font library. If you post more information about the Emacs you're running, people more expert than me might be able to confirm the issue.