Making Beancount Mode Great (I mean, Minor) Again

104 views
Skip to first unread message

TRS-80

unread,
Jul 18, 2020, 5:53:20 PM7/18/20
to bean...@googlegroups.com
I finally got around to giving the "new" beancount.el major mode a
try. I am a daily user of org-mode since years, and therefore many of
org-mode keybindings are very, very well trained muscle memory by now.
So much that I am really struggling with beancount-mode as major +
outline-mode as minor. I have already re-bound a few common things as
suggested, but can't help but wondering how many more things I will
need to keep re-binding before I will feel comfortable again.

So I started thinking the other way. How to make org-mode to be the
major mode, and beancount a minor mode again? Once upon a time I had
started toying around writing my own very basic mode, and I dabble in
elisp more and more, so I started looking into beancount.el.

Then I started thinking, there must have been some trade-off, or
reason for making it into a major mode? Is there some functionality
that can only be gained by major mode status? Such deep understanding
is certainly beyond my wizard level presently, so I thought better
stop there and just ask before I get in too deep.

Regards,

TRS-80

Ben Blount

unread,
Jul 18, 2020, 6:00:22 PM7/18/20
to bean...@googlegroups.com
You could fetch the older version of the beancount emacs plugin out of the git history and use it instead. For the non software engineer one way to do that is to browse to the file on github, and click "blame" (line by line history). You can see the comment about major mode was updated here, and we've found the point where that changed. Then we can take that commit hash 0c6a8863e5080a6b01d6ae31f92c67c3ed940f11, and get the parent commit by suffixing it with ^ or ~1. Leads us here:  https://github.com/beancount/beancount/blob/0c6a8863e5080a6b01d6ae31f92c67c3ed940f11%5E/editors/emacs/beancount.el. You can download that and you'll have the emacs plugin as it used to be.  

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0ef9e6fb9d389940e5a86682ad24c000%40isnotmyreal.name.

TRS-80

unread,
Jul 18, 2020, 6:33:30 PM7/18/20
to bean...@googlegroups.com
> On 2020-07-18 18:00, Ben Blount wrote:
>
> You could fetch the older version of the beancount emacs plugin out of
> the git history and use it instead. For the non software engineer one
> way to do that is to browse to the file on github, and click "blame"
> (line by line history). You can see the comment about major mode was
> updated here [1], and we've found the point where that changed. Then
> we can take that commit hash 0c6a8863e5080a6b01d6ae31f92c67c3ed940f11,
> and get the parent commit by suffixing it with ^ or ~1. Leads us here:
>
> https://github.com/beancount/beancount/blob/0c6a8863e5080a6b01d6ae31f92c67c3ed940f11%5E/editors/emacs/beancount.el.
> You can download that and you'll have the emacs plugin as it used to
> be.

I appreciate the fast reply and the help, Ben. Looking at the history
of beancount.el [0] confirms my suspicion that there have been quite a
lot of other improvements in the meantime, in addition to just
changing from minor to major mode. I suppose I was hoping for some
insight from one or more of the people involved. And if I am lucky,
perhaps even learn something about major vs minor modes that I did not
know before.

TRS-80

[0]
https://github.com/beancount/beancount/commits/master/editors/emacs/beancount.el

Daniele Nicolodi

unread,
Jul 18, 2020, 6:52:52 PM7/18/20
to bean...@googlegroups.com
On 18/07/2020 15:53, TRS-80 wrote:
> I finally got around to giving the "new" beancount.el major mode a
> try. I am a daily user of org-mode since years, and therefore many of
> org-mode keybindings are very, very well trained muscle memory by now.
> So much that I am really struggling with beancount-mode as major +
> outline-mode as minor. I have already re-bound a few common things as
> suggested, but can't help but wondering how many more things I will
> need to keep re-binding before I will feel comfortable again.

I am an user of org-mode myself and I am also who promoted beancount to
a major mode. There aren't many org-mode keybindings that make sense in
an beancount buffer other than the ones used for headlines tree
navigation. What else are you missing? Also, note that org-mode is (at
least in spirit) and extension of outline-mode, of which
outline-minor-mode is the minor mode incarnation. Thus, it is fairly
easy to map functionality between the two. Please refer to the
outline-minor-mode documentation.

What are you missing? beancount.el already has some code to augment
outline-minor-mode to make it behave more like org-mode. If there are
other desirable (reasonable) features I don't exclude we can add them.

> So I started thinking the other way. How to make org-mode to be the
> major mode, and beancount a minor mode again? Once upon a time I had
> started toying around writing my own very basic mode, and I dabble in
> elisp more and more, so I started looking into beancount.el.
>
> Then I started thinking, there must have been some trade-off, or
> reason for making it into a major mode? Is there some functionality
> that can only be gained by major mode status? Such deep understanding
> is certainly beyond my wizard level presently, so I thought better
> stop there and just ask before I get in too deep.

As far as I know there aren't any fundamental limitations of what can be
done in a minor mode vs a major mode. The issue is that a minor mode
inherits all the "setup" performed by the major mode. In the case of
org-mode and beancount as a minor mode it was very hard (or impossible)
to adapt org-mode features to what is desired in a benacount buffer.
Completion is a notable example, electric indentation is another.

Overall I think the current design is much nicer, both from a conceptual
and user point of view and from a code point of view. However, as it as
been already pointed out, the old beancount minor mode code is preserved
in the git history and released with a open source license. If you like
it more, you are free to use it and improve upon it. Just, please, if
you release it, do that under a name that makes it clear that it is a
distinct project.

Best,
Dan

Ben Blount

unread,
Jul 18, 2020, 6:53:05 PM7/18/20
to bean...@googlegroups.com
Sometimes folks will put the reasoning behind a change in the commit message or pull request. Unfortunately, in this case that context wasn't included. I did a search on the mailing list archives, here's a thread that discusses the reasoning:  https://groups.google.com/g/beancount/c/B1YA2n7r8SE/m/Z0lAQxAKCQAJ
TLDR: better completion support.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

Daniele Nicolodi

unread,
Jul 18, 2020, 7:12:00 PM7/18/20
to bean...@googlegroups.com
On 18/07/2020 16:52, Ben Blount wrote:
> Sometimes folks will put the reasoning behind a change in the commit
> message or pull request. Unfortunately, in this case that context wasn't
> included. I did a search on the mailing list archives, here's a
> thread that discusses the reasoning: 
> https://groups.google.com/g/beancount/c/B1YA2n7r8SE/m/Z0lAQxAKCQAJ
> TLDR: better completion support.

Ben, I would advise you to do not refer to the work of other in these
dismissive terms. The reasons to make beancount into a major mode were
discussed at length on the mailing list (not only in the thread you
found) and in the merge request on Bitbucket, whicha has however been
lost with the migration to Github.

If you don't like beancoount as a major mode, you are free to do not use
it, to use the old code, write your own, minor mode, or anything else
that makes you feel better. However, it would be more productive for you
to report the functionality you would like to be implemented in the
beancount emacs mode, rather than air vague non circumstantiate
criticism on the mailing list.

Best,
Dan

Ben Blount

unread,
Jul 18, 2020, 7:26:43 PM7/18/20
to bean...@googlegroups.com
I apologize for the way my comment came across. My intent was to describe how I go about researching context on an open source project when I'm wondering why something was done a particular way. I am deeply grateful for all the efforts of open source contributors who lovingly built so many of the tools I use. Thanks for the pointer about the merge requests on bitbucket.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

TRS-80

unread,
Jul 18, 2020, 8:11:22 PM7/18/20
to bean...@googlegroups.com
> On 2020-07-18 18:52, Daniele Nicolodi wrote:
>
> What else are you missing?

Typical navigation stuff, like up to parent (and on and on), which I
suppose is just a matter of re-binding whatever command(s) from
outline-mode. I guess I just need to dig into those docs some more.

> What are you missing? beancount.el already has some code to augment
> outline-minor-mode to make it behave more like org-mode. If there are
> other desirable (reasonable) features I don't exclude we can add them.

I did notice beancount-outline-cycle for instance. Nice touch. :)

One thing I was missing was org-cycle-separator-lines, I did not find
any analogue in outline-mode yet (in fairness, I have not yet begun to
really study outline-mode yet, either).

Since you asked, I thought about it and fill-paragraph was another
thing I couldn't seem to get to work, either. This is not related to
org-mode though of course. And I probably would not even have noticed
if I was just entering transactions as opposed to setting up a new set
of books and thus had some longer comments near the top of the file.

> The issue is that a minor mode inherits all the "setup" performed by
> the major mode. In the case of org-mode and beancount as a minor
> mode it was very hard (or impossible) to adapt org-mode features to
> what is desired in a benacount buffer. Completion is a notable
> example, electric indentation is another.

These were exactly the answers I was looking for. Thanks!

> Overall I think the current design is much nicer, both from a
> conceptual
> and user point of view and from a code point of view.

I was hoping you might reply and share your insights, as these were
exactly what I was looking for. I really appreciate it. You seem to
be much more familiar with the issues at hand (and codebase) than
myself, and therefore I will take your recommendations.

I was more trying to scout out which would be the less hassle way
forward between re-mapping (an as yet unknown) number of commands from
outline-mode vs the alternative which was floated in the OP. It
sounds now like the former option not so bad after all, so that is the
way I will proceed for now.

> However, as it as been already pointed out, the old beancount minor
> mode code is preserved in the git history and released with a open
> source license. If you like it more, you are free to use it and
> improve upon it.

I have no intention to do any such thing. :) If anything, I hope to
become familiar enough with the work you have already done to one day
be able to make some of my own useful contributions back to it.

Cheers!

TRS-80

Martin Blais

unread,
Jul 18, 2020, 9:44:38 PM7/18/20
to Beancount
I don't remember the details, what I do remember is that Stefan said to me it would be better as a minor mode along with a bunch of rationale, and that registered, and then someone did it, and so IIRC I just waved at it and let it happen; all I can remember, frankly. Like TRS-80, I did feel a bit outside my binding habits at first, but then added some bindings of my own. You can find out what I use here:
https://github.com/beancount/beancount/blob/master/etc/emacsrc
this gets sourced from my .emacs.

(Over the 25 years I've known Stefan, there's not a single time that I challenged him over computer matters that I wasn't in the wrong. I wisened up now and I just do whatever he says.)


--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

Daniele Nicolodi

unread,
Jul 18, 2020, 11:35:39 PM7/18/20
to bean...@googlegroups.com
On 18/07/2020 18:11, TRS-80 wrote:
>> On 2020-07-18 18:52, Daniele Nicolodi wrote:
>>
>> What else are you missing?
>
> Typical navigation stuff, like up to parent (and on and on), which I
> suppose is just a matter of re-binding whatever command(s) from
> outline-mode. I guess I just need to dig into those docs some more.

If you look at the key bindings for org-mode, you see that C-c C-u (the
keybinding from org-mode I think you are referring to) is bound to
outline-up-heading. This is one of those cases in which org-mode uses
the underlying outline-mode, thus the function to call with
outline-minor-mode active is the same.

As for the keybinding, you can bind it C-c C-u or you can set
outline-minor-mode-prefix to C-c and get all the outline commands with a
nicer prefix that the default C-c @. See the documentation
https://www.gnu.org/software/emacs/manual/html_node/emacs/Outline-Mode.html

>> What are you missing? beancount.el already has some code to augment
>> outline-minor-mode to make it behave more like org-mode. If there are
>> other desirable (reasonable) features I don't exclude we can add them.
>
> I did notice beancount-outline-cycle for instance. Nice touch. :)

The idea would be to fold that into outline-mode itself, but I haven't
had time to double check attribution: I stole part of the implementation
from somewhere else (also with GPLv2 or later license) and GNU requires
assigning copyright to FSF, thus it is a bit of a nuisance...

> One thing I was missing was org-cycle-separator-lines, I did not find
> any analogue in outline-mode yet (in fairness, I have not yet begun to
> really study outline-mode yet, either).

I don't think there is anything similar in outline(-minor)-mode. I
consider it a minor visualization nicety, and I am not missing it at
all, thus I am not going to work on it.

> Since you asked, I thought about it and fill-paragraph was another
> thing I couldn't seem to get to work, either. This is not related to
> org-mode though of course. And I probably would not even have noticed
> if I was just entering transactions as opposed to setting up a new set
> of books and thus had some longer comments near the top of the file.

I don't think this is implemented indeed. It looks useful. I'll add it
to the TODO list. I'll also be happy to review a patch implementing it,
of course.

> I was more trying to scout out which would be the less hassle way
> forward between re-mapping (an as yet unknown) number of commands from
> outline-mode vs the alternative which was floated in the OP. It
> sounds now like the former option not so bad after all, so that is the
> way I will proceed for now.

As I written above, have a look at outline-minor-mode-prefix, it may be
less typing than re-binding many functions. I don't think there are
beancount keybindings that would conflict. However, I don't do that
myself, so you have to double check.

Cheers,
Dan
Reply all
Reply to author
Forward
0 new messages