[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emulating Scrivener's binder feature

From: Paul W. Rankin
Subject: Re: Emulating Scrivener's binder feature
Date: Wed, 03 Apr 2019 19:59:35 +1000
User-agent: mu4e 1.0; emacs 26.1

On Tue, Apr 02 2019, Marcin Borkowski wrote:
Quick question: why not use Org-mode syntax for the binder file? I.e.,
make each file a headline, and metadata its properties.  You'd get
reordering for free, and maybe other stuff could be useful, like column
view maybe.  Also, it would be usable outside Emacs, since there are
many Org syntax parsers out there.

Just my 2 cents,

That's a valuable 2 cents. Although I don't think that org-mode's outline structure would work well the same time as file-path structure, this got me really thinking about the fundamental route I'd take to make this...

There are two ways to go: a buffer that visits a text file on disk and manipulates the properties of the text (like org-mode), or a special-mode buffer that constructs text based on a lisp object (like bookmarks).

If the .binder file should be human-readable it makes sense to visit a file, but I'm beginning to think this is not the best way. When a user attempts to navigate from one binder file to another, which should be acheivable from any binder file, not just from the binder buffer, I'd need to find and parse the binder buffer each time (and make sure it's the correct project!). I'd rather have a lisp variable, whereby the binder buffer and any visited binder files rely on that variable instead. So now I'm thinking this variable really might be best stored in .dir-locals.el... hmmm.

Thanks :)

p.s. I actually find org-mode's subtree reordering code to be overly complicated (i.e. It kills the current subtree from the buffer, then when inserting it in the appropriate place, it needs a whole bunch of extra properties about the subtree to appropriately reconstruct it and place the point. When I implemented similar subtree reordering in fountain-mode, instead when the user moves a subtree up, I just kill the preceding subtree and reinsert it below the current one -- way easier!)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]