Closed Reepca closed 7 years ago
You probably had imenu
loaded when it worked, and now you don't.
I pushed a fix. Does it work for you?
The second issue is because the EMACS
environment variable is set to t
. Are you running a shell inside Emacs? I do that too, and get the same message.
I think GitHub issues are fine. Another option would be email. I sometimes hang out on IRC (irc.nocrew.org, #nocrew), but that's more unreliable.
Fixed the EMACS thing too.
C-M-i now works, though it's still rather slow - it seems to cause a fair bit of lag while the Completions buffer is showing (try entering text during it), and there's a bit of a delay between pressing C-M-i and having the completions buffer appear / having the word completed. Also, C-M-i doesn't work in the Forth Interaction buffer (it just yields "no match" for everything). Is C-c C-k supposed to work in the buffer with the Forth source, or just in the interactive buffer?
I didn't realize Emacs set that environment variable when using a shell inside it. That explains a lot. I'm not too familiar with makefiles, but is there a way to have it verify at set-time that the environment variable represents something accessible in PATH? That seems like the best way I can think of to determine if the value EMACS is set to is supposed to be an overriding option or some irrelevant thing.
The weird garbage-seeming text is back, but it only seems to happen when redefining something - defining for the first time will work fine (minibuffer):
: woot ." woot woot" ; ok ok
But on trying to redefine it I get this:
: woot ." woot woot" ; [0;34;49m terminal:3:3: redefined woot[0;39;49m ok
I tried it out in a shell, and it looks like what I'm seeing is actually a color code thing. Apparently the minibuffer handles those differently than Shell buffers do. Gforth likes to print out the "redefined" message in blue I guess. Is there a way to make the minibuffer handle colored text properly? Do we want it to?
bye
in the forth buffer to end the session. But of course, C-c C-k could be made to work there too.make EMACS=foo
.Currently C-c C-k only works for me in the forth buffer, not in the forth-mode buffer - it says it's undefined in the forth-mode buffer. I would assume I'm using gforth with readline editing - the usual readline editing commands work in a plain old terminal, anyway. I can't find any documentation about how to disable that without recompiling.
The problem isn't with the delay, it's with this slowness that happens whenever you try typing after completing. Here's an example: gforth has 5 words starting with find
. Supposing I type in "fin" and complete, it'll go to find
. Then, supposing I want to use find-name, I would type up to "find-na" and complete. But typing those three characters is really slow. It happens any time you complete a word and then continue typing without pressing space (but the slowness stops when you change buffers and then come back for some reason).
Make is now working fine.
Pushed fixes for C-c C-k, and completion slowness.
Also now removes terminal escape sequences.
I'm closing this now. Feel free to open new issues if there are any more problems.
Either github's UI is bugging out or it didn't get closed, I'll go ahead and do that. The completion is nice and smooth now, works great! I just had to remember to rerun make to update stale .elc files. And I can confirm that the color codes are being filtered out properly from gforth.
Great, thanks!
I'm now turning off terminal attributes in backend/gforth.el
.
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?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?