larsbrinkhoff / forth-mode Goto Github PK
View Code? Open in Web Editor NEWWants to be the SLIME of Forth
License: GNU General Public License v3.0
Wants to be the SLIME of Forth
License: GNU General Public License v3.0
Title is the message I get in the Messages buffer upon typing "du" and then C-M-i. Have latest git version of forth-mode.
Emacs version:
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2016-04-17 on lgw01-04, modified by Debian
My .emacs file ends in
(pushnew "/home/reepca/.emacs.d/manual-stuff/forth-mode/" load-path)
(require 'forth-mode)
(require 'forth-block-mode)
(require 'forth-interaction-mode)
The weird part is that I distinctly remember it working last night. A bit slow/unresponsive, but working. I don't remember what I did though :~/
On a slightly different note, make
fails on my system (should probably be a separate issue, but meh). Apparently EMACS contains "t" for some reason instead of the executable name?
t -Q --batch --load build.el
make: t: Command not found
Makefile:5: recipe for target 'all' failed
make: *** [all] Error 127
This is an issue that has appeared before on my system though, if I recall when building gforth it said "checking for emacs... t". I'm on Ubuntu 16.04 in case that helps nail down why it's acting this way. The way I solved it previously was to just hard-code the name in the makefile, but I'd like to find out what's up with this. I'm using GNU Make 4.1.
I don't really know where else to ask this - is there a place I could converse more directly instead of having to make an issue for everything?
from within (spac)emacs I load up a file in the lbforth home directory (e.g. INSTALL).
I then load up lib/bench.fth.
I execute run-forth (M-x run-forth, or SPC SPC run-forth)
tell it I want to use lbforth ("forth" executable)
I verify its running by typing "words"
I switch back to bench.fth with C-x o
I do C-c C-l to "load" the current buffer into forth.
I get this stack trace in the debugger:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("�[?[0-9;]*[a-z]" nil 0)
forth-scrub(nil t)
forth-load-file("c:/msys64/home/kevin/0work/lbForth/lib/bench.fth")
funcall-interactively(forth-load-file "c:/msys64/home/kevin/0work/lbForth/lib/bench.fth")
call-interactively(forth-load-file nil nil)
command-execute(forth-load-file)
And this message from windows:
(helm ranger auto-completion better-defaults themes-megapack emacs-lisp git markdown org
(shell :variables shell-default-height 30 shell-default-position 'bottom)
syntax-checking version-control)
I clone the latest spacemacs (master or develop branch doesn't matter)
I enable forth mode either with dotspacemacs-additional-packages or package-list-packages
I install freeforth, copy the 'ff' or 'ff.exe' program into my path (e.g. /usr/local/bin)
I edit the ff.ff file near where "equ" is defined to add proper aliases "include=needs" and "help=see" thusly:
\ need these for emacs forth-mode C-c C-l and C-c C-s
needs` ' alias include`
help` ' alias see`
I bring up a forth program, do M-x forth-mode
Put the cursor on a forth word like "constant"
Hit C-s
It asks me for which forth executable, and I answer 'ff'
It brings up the help screen for "constant" in a forth buffer
I hit 'q' to exit it.
I do the C-s again and
error in process filter: Wrong type argument: markerp, nil
It seems like it works again if I delete both the forth AND the see buffers.
What would be the best behavior IMO would be for it to just send the message "see 'word'" to the currently running forth process, OR when I hit "q" just delete ALL the buffers that were created to facilitate the display of the help rather than merely bury them or leave them open.
Also, it would be nice if it would return the screen configuration to the exact same as it was when I hit 'q.' right now it leaves it split with the empty see buffer.
Also, as an aside, it might be nice to have a key to flip back and forth between the forth interpreter and the forth program you're editing like geiser does with C-z I think. Even the above behavior of finding the forth process, running the help command there, if its not in a visible buffer, either splitting the currently visible one and then displaying the help there until 'q' is hit, or just flipping the whole window to the forth process displaying the help (not read only, and in interactive mode so you can try tinkering with that word you just got help on) then having the C-z to flip back manually (probably having the selection of these two behaviors on a configuration variable would be ideal)
For packages to be installable from MELPA Stable, a commit has to be tagged in the git repository. Therefore I would want to ask if it would be possible to tag a commit that could be considered "stable", for us MELPA Stable users?
When invoking run-forth
, identify the implementation. Preferably automatically from the initial banner text.
Add backends for some useful Forths.
When I start Emacs like so:
touch /tmp/x.fs
emacs -Q -nw -L /scratch/forth/forth-mode/ -l forth-interaction-mode -eval '(progn (setq forth-executable "swiftforth") (setq process-coding-system-alist (quote (("swiftforth" . raw-text-dos)))) (run-forth))'
then type "include /tmp/x.fs" in the *forth*
buffer, I get this:
SwiftForth i386-Linux 3.6.3 29-Jun-2016
include /tmp/x.fs
include /t File not found
I initially wanted something like SLIME. But perhaps it's not quite the right model for interacting with Forth.
In the Lisp mode, every function can be redefined which affects the rest of the program immediately.
But this isn't the case in Forth. Maybe it's better to embrace a model which embraces the stack-like nature of the Forth dictionary. Definitions can be pushed to the dictionary, and popped later.
@vigilancetech-com wrote in #66:
it might be nice to have a key to flip back and forth between the forth interpreter and the forth program you're editing like geiser does with C-z I think. Even the above behavior of finding the forth process, running the help command there, if its not in a visible buffer, either splitting the currently visible one and then displaying the help there until 'q' is hit, or just flipping the whole window to the forth process displaying the help (not read only, and in interactive mode so you can try tinkering with that word you just got help on) then having the C-z to flip back manually (probably having the selection of these two behaviors on a configuration variable would be ideal)
There should be automated tests.
Smoke test? Unit tests? Integration tests?
It would be nice to have a communication protocol between Lisp and Forth. Something in the vein of swank.
But maybe Forth itself is almost enough for this. Just extended with some implementation-specific words.
It would be nide to have a command that prints the version installed. I'm volunteering to do that.
The repo has no tags, so I'd say the version string could be like yyyy.mm.dd.hhhhhhh
, where
yyyy.mm.dd
would be the data of last commit, and hhhhhhh
the truncated hash of the last commit. The string would be determined during build. If the packageis build out of the git tree, then the string would be yyyy.mm.dd.unknown
, where yyyy.mm.dd
would be the date of compilation.
Any objections?
There should be an automated build:
Emacs 28.2
shows warnings for packages depending on cl
, since cl
has been deprecated. According to other threads, for example kiwanami/emacs-epc#35 the replacement is cl-lib
.
Would it be feasible to make the switch to avoid the deprecation warnings and possible later breakage of forth-mode?
Things like : foo" ;
are wrongly fontified because the foo"
is wrongly considered as string opener.
Here is an idea: create a shell script that can start all Forths with uniform command line arguments.
E.g.: runforth.sh --kind gforth gf --load foo.fth --eval bye
This way we could pass the filename of the backend code as command line argument instead of having to look for patterns in the banner (which is kinda brittle).
Such a script would of course also be useful for other uses, unrelated to Emacs.
Maybe you can add a command to browse the description of a word in the Forth standard
like this one:
https://github.com/ellerh/dpans.el/blob/master/dpans.el
Pretty straightforward, I installed from MELPA using package-install, made a file ("playing-around.fs"), which correctly opened in Forth block mode. I typed out a definition, selected it, pressed C-c C-r, and received in the message bar "C-c C-r is undefined". I then typed M-x forth-eval-region RET and it worked (although there were some nonprintable characters in the message bar, and some stuff that reminded me a bit of the garbage I would get in a C program when I forget to add a null terminator to a string). It looked like this:
: woot ." woot woot!" cr ;�����������������������������: woot ." woot woot!" cr ;�����������������������������: woot ." woot woot!" cr ; �[0;34;49m
terminal:4:3: redefined woot�[0;39;49m ok
(the unprintable characters were represented as ^H in emacs). It seems to be inconsistent, though - sometimes I'll get a bunch of the ^H characters and sometimes I'll get a single ^[ but the rest of the printable garbage (or at least, stuff that doesn't mean much to me) stays there.
Emacs version (the one that is in Ubuntu 16.04's repositories):
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2016-04-17 on lgw01-04, modified by Debian
Gforth version: 0.7.9_20160901
Anything else I can add to help?
SwiftForth seems to reset the device personality on errors:
SwiftForth i386-Linux 3.6.3 29-Jun-2016
'personality @ . 134554011 ok
include swiftforth.fth ok
'personality @ . 134756820 ok
abort
'personality @ . 134554011 ok
The backend files are loaded with require
, so the initialisation code is not run if a new session is started.
In the installation instructions when it says:
(pushnew "DIR" load-path)
(require 'forth-mode)
(require 'forth-block-mode)
(require 'forth-interaction-mode)
I get an error about pushnew not existing in a fresh emacs installation. cl-pushnew does appear to exist however.
If I split an emacs frame in two windows, having a forth program (example.f
) in one window and the other window having the Forth interaction buffer, *forth*
, I'd expect that, if I press C-c C-e in the first window (after a Forth expression), the output would be echoed in the interaction buffer, but it goes to the minibuffer only. But the information in the minibuffer vanishes quickly, and it would be nice to have it also printed in the interacion buffer for later analysis and use.
My initial idea was that *forth*
is for user interaction, and that responses when running interactive Forth commands should go somewhere else.
This "somewhere else" could be a *forth messages*
buffer. If a message is only a few lines, it could also be copied to the echo area.
I'm not sure if this is a good idea, or if it's better to mix everything inside *forth*
.
forth-load-file
doesn't hides the output of the subprocess which makes it rather diffucult to tell what is going on.
I think it should insert the output in the *forth*
buffer and make sure that the *forth*
buffer is visible.
In order to add imenu support, all that needs to be done is to set imenu-generic-expression
to a set of matchers that are able to detect the form of a function definition.
Once that has been written, adding the following will use this to provide speedbar support:
(with-eval-after-load 'speedbar
(speedbar-add-supported-extension ".fs"))
If I start a fresh gforth session with M-x run-forth and type 2 RET
, the buffer then looks like this:
Gforth 0.7.9_20180726, Copyright (C) 1995-2017 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
2
22 ok
It had been echoing twice for awhile - not too terrible, at least it's not asymmetric. For what it's worth, I'm using emacs 26.1 and the latest gforth git checkout. forth-mode installed from MELPA.
SwiftForth emits, e.g. when using see
, the escape sequence ^[[6n
and then waits. Apparently CSI 6n
tells the terminal emulator to report the cursor position. I don't know how to disable this on the SwiftForth side, so maybe Emacs should handle a few of the standard escape sequences. This might also allow us to introduce some custom escape sequences for the communcation with the subprocess.
Just added this to my doom emacs and am getting ANSI escape sequences in the comint output:
Gforth 0.7.9_20220127
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors'
Copyright © 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
�7
�7<0> | order: Forth Forth Root Forth �8
in particular: ^[7
and ^[8
. My install is just straight forward use-package
(but hooked into Doom's package system):
(use-package! forth-mode
:defer t
:config
(set-repl-handler! 'forth-mode 'forth-mode-switch-to-output-buffer)
(set-lookup-handlers! 'forth-mode
:documentation #'forth-spec-lookup-2012)
(setq forth-executable "gforth")
(map! :after forth-mode
:map forth-mode-map
:localleader
"," #'run-forth
"." #'forth-eval-last-expression-display-output
"u" #'forth-eval-last-expression
"'" #'forth-load-file
"r" #'forth-eval-region
"s" #'forth-see
"S" #'forth-switch-to-output-buffer
"e" #'forth-eval-defun
"R" #'forth-restart
"H" #'forth-spec-lookup-1994
"h" #'forth-spec-lookup-2012
))
From reading the source I would have expected forth-scrub
to filter these out but that doesn't seem to be the case. I do use:
(add-to-list 'comint-output-filter-functions 'ansi-color-process-output)
to process the sequences for other modes but this does not work for forth-interactive-mode
I think the idea to set the syntax class of (
to "<1"
is problematic, because it doesn't work well for words like (LOCAL)
. The same problem for \
which can also be part of normal word names like a\b
.
Whoever wrote gforth.el seems to think that Emacs' syntax tables aren't of much use for Forth and instead highlights comments "manually". (Admidettly, the highlighting and indentation of gforth.el is only half bad. The implementation is weird, though.)
Maybe a compromise between syntax tables and an custom syntax-propertize-function
to fix the corner cases would work better.
Rewrite forth-stack-comments-mode
to use ElDoc.
Message in title appears when running M-x run-forth and entering "gforth" when prompted for a forth executable. In *Messages* I also get "error in process filter: forth-interaction-preoutput-filter: Required feature `gforth' was not provided" right before that.
Using latest Melpa (just did package-list-packages, U x to upgrade everything). Not sure when the problem started.
Additionally, C-c C-r produces the message "No current process. See variable `forth-process-buffer'". The weird part about all of this is that the *forth* buffer gets opened and the process is successfully started - I can enter commands and stuff and see output - but there's no startup message initially, just a blank buffer (whether that's intended or not).
gforth --version produces "gforth 0.7.9_20160923 amd64". I'm using Emacs 24.5.1. Forth-mode version 20161201.113 according to package-list-packages.
I don't know much about how xref providers are implemented, but the starting point is the variable xref-backend-functions
which should return an xref backend that is able to find symbols in the current runtime.
To implement symbol completion, set the variable completion-at-point-functions
to a list of completion functions (usually only one):
(setq-local completion-at-point-functions '(forth-mode-expand-symbol))
The behaviour of the symbol expansion function is described in the documentation for the variable completion-at-point-functions
.
I'm not sure if this is a real or only a percieved problem, but on Debian the gforth package installs
gforth.el in /usr/share/emacs/site-lisp/gforth
. So it may not be wise to have another gforth.el somewhere else.
Hi,
I'm trying to execute a Forth source in Ubuntu 16.04 using Gforth.
When I issue : C-c C-l
It asks for "Forth executable: ", then I type "gforth", and it opens an empty buffer/window with the aforementioned error message.
Am I doing something wrong?
Thanks in advance.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.