I forgot to mention that this change will require existing users to update their config to maintain the default key-bindings. I don't think there's any good way to make the change seamless for them, and creating a warn-on-update setup would definitely be overkill.

I am incredibly torn about this. On the one hand, I agree with you and would like to remove the key bindings. Making org-journal a major mode was a bad idea to begin with, and setting fixed key bindings was equally mis-guided on my part.

However, org-journal has an astonishingly large number of users, many of whom will be caught off-guard by such a change. And in all my years of working on Open Source Software, I have learned that nothing erodes trust like breaking changes. And there is always fallout that we maintainers have to deal with. Angry emails, issues, messages, maintenance overhead, and more.

There have been multiple issues that discussed solutions to this problem already. For example, we might make org-journal into an optional minor mode. In fact, it is entirely unnecessary for org-journal to be a mode at all, it could just be a number of functions and hooks.

At any rate, this problem needs a thoroughly documented, strongly communicated solution that goes deeper than the key bindings themselves. It will in all likelihood require a major version change.

Thus, regretfully, I have to reject this pull request for now. But I invite you to discuss and implement a possible restructuring of org-journal with @cslux and me here or in a new issue.

I understand. I can't think of a better solution for this key-binding problem, so it looks I'm going to have to port your functions into a separate library, then. On the one hand, it would have been nice to maintain org-journal within the ecosystem we're trying to build for Org-roam, but at the same time, I realise that we've been abusing some of the behaviours to make it do our bidding.

I'll make sure to credit you in the future lib.

Thanks for your time, and good luck for the future!

@zaeph I'll add a customizable variable to configure the prefix argument. When it is set to an empty string no bindings will than be configured. By default nothing will change for the user.

@zaeph I'll add a customizable variable to configure the prefix argument. When it is set to an empty string no bindings will than be configured. By default nothing will change for the user.

Splendid! Something à la projectile-command-map would do nicely. I'm still iffy about setting it to C-c j by default, but at least it gives us the possibility to customize it.

Splendid! Something à la projectile-command-map would do nicely. I'm still iffy about setting it to C-c j by default, but at least it gives us the possibility to customize it.

@zaeph I agree, but some users are verylikly used to the current "C-c C-*" key bindings. I didn't change it with @bcb5bb4. You can now set org-journal-prefix-key to an empty string, which means, no default bindings. This variable needs to be set before org-journal gets loaded.

Thanks for taking care of this.

Re:

I understand. I can't think of a better solution for this key-binding problem, so it looks I'm going to have to port your functions into a separate library, then.

org-roam/org-roam/pull/978 is almost finished. Functionally, I've taken a lot of inspiration from org-journal, which I'll mention in the header of the lib. I think you've had a lot of good ideas UX-wise, and I wish I'd found out about you before writing my own implementation for journalling.

Best of luck for the future.