larsbrinkhoff/forth-mode

Wants to be the SLIME of Forth

Programming language mode for Forth.

Features in progress:

• Recognises definitions and moves by balanced expressions.
• Interact with a Forth session: enter commands, load files, evalutate expressions.
• Display stack comment when moving the cursor over a word.
• Edit block files.
• Tab completion.
• Query a running Forth about words, search order, etc.

Installation

MELPA:

M-x package-install forth-mode

Manual:

git clone http://github.com/larsbrinkhoff/forth-mode DIR

# Add to .emacs
(add-to-list 'load-path "DIR")
(require 'forth-mode)
(require 'forth-block-mode)
(require 'forth-interaction-mode)

Usage

To enable Forth major mode, type M-x forth-mode. The file extensions .f, .fs, .fth, and .4th are recognised automatically.

To start an interactive Forth session, type M-x run-forth.

Key bindings:

• C-M-a, C-M-e - beginning / end of colon definition.
• C-M-f, C-M-b - forward / backward expression (not very useful yet).
• C-M-h - mark colon definition.
• C-c C-l - load file.
• C-c C-r - evaluate region.
• C-c C-k - kill interactive Forth.
• M-TAB, C-M-i - complete-symbol.

forth-mode's Issues

Backend initialisation

The backend files are loaded with require, so the initialisation code is not run if a new session is started.

Interactive way to tell version of forth-mode

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?

User-Forth interaction

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.

Forth implementation backends

When invoking run-forth, identify the implementation. Preferably automatically from the initial banner text.

Add backends for some useful Forths.

Add support for symbol completion

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.

Add support for xref

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.

Input gets echoed three times

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.

Taging a Release

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?

error in process filter: Required feature `gforth' was not provided

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.

pushnew doesn't exist in freshly installed emacs

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.

*forth messages*

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*.

Lookup words in Forth standard

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

wrong type argument stringp nill error with forth-load-file under mingw32 (msys2) and lbforth

1. from within (spac)emacs I load up a file in the lbforth home directory (e.g. INSTALL).

2. I then load up lib/bench.fth.

3. I execute run-forth (M-x run-forth, or SPC SPC run-forth)

4. tell it I want to use lbforth ("forth" executable)

5. I verify its running by typing "words"

6. I switch back to bench.fth with C-x o

7. I do C-c C-l to "load" the current buffer into forth.

8. 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:

System Info 💻

• OS: windows-nt
• Emacs: 25.1.1
• Spacemacs: 0.200.9
• Spacemacs branch: master (rev. 8e1af145)
• Graphic display: t
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

(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)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES

C-c C-e echoes in minibuffer only

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.

No feedback for forth-load-file

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.

Deprecation of `cl`

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?

let: Symbol's function definition is void: imenu--make-index-alist

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?

Add imenu support

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"))

Terminal device personality reset

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

ElDoc

Rewrite forth-stack-comments-mode to use ElDoc.

Wrong type argument: processp, nil

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.

Messed up fontification

Things like : foo" ; are wrongly fontified because the foo" is wrongly considered as string opener.

Escape sequences in comint output

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

Lisp-Forth communication

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.

Terminal escape sequences

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.

Switch between Forth program and Forth interpreter

@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)

C-c C-r is undefined, forth-eval-region produces strange output?

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?

Start Forth process with shell script

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.

Nameclashes with gforth.el

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.

broken forth-see with freeforth/spacemacs

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)

Problematic syntax class for ( and \

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.

Automated tests

There should be automated tests.

Smoke test? Unit tests? Integration tests?

SwiftForth oddness

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

Automated build

There should be an automated build:

• byte-compile all files
• build ELPA package
• check for errors and warnings