comint-history isn't read from or written to history files

[nverno]

When entering an sbt mode, the history file isn't loaded. When switching between submodes, the history isn't saved. It might be nice to have a hook that runs when switching between submodes.

[hvesalai]

Infact, comint is reading the history. It might be reading the wrong one. See also #61 #81

And it should not write any history, that should be sbt:s task.

[nverno]

Of course, your're right it is reading the history files. But it's current behaviour isn't great. If you switch to a console, type some commands, then switch back to sbt console all of the history from both submodes is lost. How would sbt know when to write history? In its current state, no history is written to either sbt or console history files AFAICT. In shell-mode history is written in a process-sentinel. It seems to me that a hook would be useful when changing submodes so users could apply things like comint-write-input-ring

[hvesalai]

Hmm... the problem seems to be that where old versions of sbt did write the history upon changing modes, current sbt does not do that when running inside emacs. I suspect something to do with jline.

You can make the following test:

• run sbt to start sbt shell
• run the consoleQuick command
• type :history to show command history
• evaluate "somethingrandomhere" to insert a new even into the history
• ensure the line has been stored to history by running the :history command

Do the test both inside and outside emacs.

On my current setup nothing is recorded when run from within emacs. This is not how it was when I developed the mode and to me it is a bug in sbt that we must get fixed. @fommil

[hvesalai]

Never the less, the sbt-mode must not be made to write any files. It should just read the history and it shall be sbt:s job to record actions and store them

[fommil]

I've never been able to get history to work properly. It'd be really good to get this fixed, I spent some time looking into it last year and failed. There is an sbt option to set the location of the history file so we can't necessarily assume the location.

[hvesalai]

Yeah, the history missing has bothered me also for some time, but haven't had time to look into it. Here is a draft for a better history

1) make sure sbt actually records it (now it doesn't -- as I pointed out above)

2)

• option A: read the location of the history file for each type of mode and load it when the mode is changed... the real challange here is subprojects. subproject1/console has different history than subproject2/console, also executing project subproject1 in sbt shell changes history.

• option B: when the mode is changed (or project-command executed), issue a command to list the history and load it from sbt output. I.e. in console you would execute :history and capture the output.

I'd go for option B. Much less hassle with the files.

[fommil]

this is what remains of my "notes to self" in my global sbt config

// causes weird problems with clean
//historyPath := Some((baseDirectory in ThisBuild).value / ".history")

[fommil]

oh, you're talking about REPL history. I was talking about the actual sbt history.

[hvesalai]

Both... "REPL" = scala console, "actual sbt" = sbt shell.

[fommil]

if we got this working, having fuzzy search on the history would be such a huge productivity boost.

[nverno]

yea I use repl history as prefix for hippie-expansion in emacs comint modes and it is a huge plus

[hvesalai]

Ok, so one bug squashed as JLine2 was not storing the history when the simple terminal was used. This is now fixed in Jline 2.14.6, which I'm trying to get into all relevant scala and sbt builds

[nverno]

Back when I was looking at this, I thought maybe a possibility of using process-put to store history location when changing projects. I don't know if that would be a useful avenue for you. I think it would benefit a lot from not using comint-prompt-regex so you could take advantage of other comint features like jumping between prompts. But, that would probably require some pretty major changes (something akin to ESS where you would wait for the process).

[hvesalai]

fixed in 9fe1e8807c22cc1dc56a6233e000969518907f4d