From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Paul W. Rankin" Newsgroups: gmane.emacs.help Subject: Re: Emulating Scrivener's binder feature Date: Wed, 03 Apr 2019 19:59:35 +1000 Message-ID: References: <87y34tk6iw.fsf@mbork.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="204281"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.0; emacs 26.1 Cc: help-gnu-emacs@gnu.org To: Marcin Borkowski Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 12:00:11 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBcgg-000qfo-Jb for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 12:00:06 +0200 Original-Received: from localhost ([127.0.0.1]:47635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBcga-0005uo-2d for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 06:00:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBcgN-0005uf-QF for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 05:59:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBcgM-0001zR-Kc for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 05:59:47 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51141) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBcgM-0001yf-6n for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 05:59:46 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9E892220F1; Wed, 3 Apr 2019 05:59:45 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 03 Apr 2019 05:59:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paulwrankin.com; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; s=fm3; bh=+PerXX6VMfqH8X0TZomxYasMbx Jn/aqZ8tsw1KhInQ8=; b=o5o9kYft4ZfzaKxY6xjuHeBhaBQmfjker00fdFAkLE ynQIitdCaLsSiCMaFetjsdczZef2kPQyN4ErfZY9NimLNFahPFC4qgtd8Fpf4VDo IWrLY7ZuP8h6osxM3NrDCnO7i8f8qMC6reFmgzBnLbgpy/+ggovYrr3ezVFkUOVD p3LvDCTwDZXZoepesyih9OD/GiiF1aPJFbEbizdUdNaHCTzAiwkrIPV4cbu2H6x6 AwuLamqmQN/bS0trJGdAz9V+wfJZudd0OJxLqKSBhk32qcZKdc16yqvTKoE2CvZc pnLDcd8V/PQBSnfWRx8ghMtGatY7lnkR6ISC0mbCmJHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+PerXX 6VMfqH8X0TZomxYasMbxJn/aqZ8tsw1KhInQ8=; b=T8i3owPxhkZv1LEFJ4Dqj2 m3qyg+Eeee+81Zv6fbeTd04nG4TqJFSrhYlW/aOfEyC6twcNDtGiUq19Vt0nmbRh HtMxVyRHZ2jqTDCskwzkwfmXGeeqHgWn7SEjSCAiHP2nQvP5ltAGLJB2eX0UABlz L8FvEH2381V5uz9BQu4hPhUCUaA9k8HUcHIY4P1KORefvL0qNj2TweEAWwP/WgUc hSnB83+DcozyRUTgzebJtePXCpDtRdmCH2Wi4CZZ71BZXt5T78JSxVXVhIqJszCA YrSzNWbR7HiAzU/eQ2yA55DA5DI874n0QY4dqu0NoZfNZ29XFAEfKDYaH9jrOHbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtddvgddvudculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpehffgfhvffujgffkfggtgesthdtredttdertden ucfhrhhomhepfdfrrghulhcuhgdrucftrghnkhhinhdfuceohhgvlhhlohesphgruhhlfi hrrghnkhhinhdrtghomheqnecuffhomhgrihhnpehprghulhifrhgrnhhkihhnrdgtohhm necukfhppeduvddtrddvvddrudefledrvdefjeenucfrrghrrghmpehmrghilhhfrhhomh ephhgvlhhlohesphgruhhlfihrrghnkhhinhdrtghomhenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: Original-Received: from localhost (unknown [120.22.139.237]) by mail.messagingengine.com (Postfix) with ESMTPA id 6391B10380; Wed, 3 Apr 2019 05:59:42 -0400 (EDT) In-reply-to: <87y34tk6iw.fsf@mbork.pl> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.28 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:119862 Archived-At: 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!) -- https://www.paulwrankin.com