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

Reepca commented 7 years ago

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?

larsbrinkhoff commented 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?

larsbrinkhoff commented 7 years ago

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.

larsbrinkhoff commented 7 years ago

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.

larsbrinkhoff commented 7 years ago

Fixed the EMACS thing too.

Reepca commented 7 years ago

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?

larsbrinkhoff commented 7 years ago

Right, there's a hard-coded 0.4 second delay from sending a request to the Forth, to getting the answer. I haven't put a lot of effort into that.
C-c C-k is only defined in forth-mode. I'm in the habit of typing bye in the forth buffer to end the session. But of course, C-c C-k could be made to work there too.
I'm not going to do anything elaborate about the EMACS environment variable right now. You can set the makefile variable on the make commandline like so: make EMACS=foo.
That garbage looks like VT100 control codes. Are you using Gforth with readline editing? I suppose it would be reasonable to filter out all control codes.

Reepca commented 7 years ago

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.

larsbrinkhoff commented 7 years ago

Pushed fixes for C-c C-k, and completion slowness.

larsbrinkhoff commented 7 years ago

Also now removes terminal escape sequences.

I'm closing this now. Feel free to open new issues if there are any more problems.

Reepca commented 7 years ago

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.

larsbrinkhoff commented 7 years ago

Great, thanks!

larsbrinkhoff commented 7 years ago

I'm now turning off terminal attributes in backend/gforth.el.

larsbrinkhoff / forth-mode

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