Fossil User Forum

Enhanced fossil_text_editor() function changes default behaviour
Login

Enhanced fossil_text_editor() function changes default behaviour

Enhanced fossil_text_editor() function changes default behaviour

(1) By psbob (ps_bob) on 2025-03-17 11:08:01 [source]

It looks like as of fc60e444, fossil now selects a default text editor to write commit comments even if the EDITOR and VISUAL environment variables have not been set. I can't see a way to force the original interactive command line comment input - is this intentional?

I realise my use case may not be common, but I use fossil in a terminal window inside neovim and would prefer to avoid nested editors if possible. If there is a way to force the original interactive behaviour could someone let me know?

Already considered:

  • Setting the fossil 'editor' setting to 0/none. Error message when trying to commit as fossil tries to find an editor named '0' or 'none'.
  • Running neovim as a server and setting it up to open new commit comments as a new buffer in the original instance. Seems like overkill for this but it is an option.
  • Using the '-m' flag in commit comments. This is probably what I should be doing, however the interactive input gives a very useful summary of files changed before entering a comment which I have got used to as a final check, and the '-m' flag does not allow this.

Thanks

(2) By Stephan Beal (stephan) on 2025-03-17 11:28:31 in reply to 1 [link] [source]

I can't see a way to force the original interactive command line comment input - is this intentional?

Yes. Per the commit message:

Enhance the fossil_text_editor() function so that it looks for common text editor names if it does not find a user-specified preference.

"User-specified preference," in your case, means EDITOR or VISUAL.

If there is a way to force the original interactive behaviour could someone let me know?

There's not currently such a thing. You always have the option of passing a message using -m ....

but I use fossil in a terminal window inside neovim and would prefer to avoid nested editors if possible

How has it worked previously in that setup? Certainly(?) that can't behave sensibly when no -m ... is passed in?

Using the '-m' flag in commit comments. This is probably what I should be doing,

Indeed :).

the interactive input gives a very useful summary of files changed before entering a comment which I have got used to as a final check, and the '-m' flag does not allow this.

Running "fossil status" will give you that same information. FWIW, my local alias for that is "fst" (when the "stash" command was added, "st" became an ambiguous short form for "status").

All that said...

Perhaps we could add:

$ fossil ci -mc "..."

where "mc" = commit message with confirmation. It would show the "status" output, the entered message, and prompt for y/n to continue. (Noting that changes made in other consoles while waiting on y/n could effectively invalidate that status.)

:-?

(3) By Richard Hipp (drh) on 2025-03-17 12:08:03 in reply to 1 [link] [source]

Does check-in 20250317120442 resolve your problem? You can make the editor setting or set your VISUAL or EDITOR environment variables to some value that Fossil considers to be false (choices: "off", "no", "false", or "0") and it reverts to the old-style interactive entry.

(4) By psbob (ps_bob) on 2025-03-17 12:27:22 in reply to 3 [link] [source]

I've just tested that check-in and it works perfectly - thank you!