From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Some projects Date: Mon, 26 Oct 2015 10:20:26 -0700 Message-ID: <87lhap5yxx.fsf@ericabrahamsen.net> References: <87wpub9jts.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlRv-0001be-56 for emacs-orgmode@gnu.org; Mon, 26 Oct 2015 13:20:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqlRq-0005r6-Ak for emacs-orgmode@gnu.org; Mon, 26 Oct 2015 13:20:47 -0400 Received: from plane.gmane.org ([80.91.229.3]:45899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlRp-0005qE-Uq for emacs-orgmode@gnu.org; Mon, 26 Oct 2015 13:20:42 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZqlRn-0000vo-Ls for emacs-orgmode@gnu.org; Mon, 26 Oct 2015 18:20:39 +0100 Received: from c-76-28-195-250.hsd1.wa.comcast.net ([76.28.195.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Oct 2015 18:20:39 +0100 Received: from eric by c-76-28-195-250.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Oct 2015 18:20:39 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Hello, > > I'd like to see some features moving forward, and some important issues > fixed, hopefully, in the next months. I'm sharing them here so that > anyone interested can help. > [...] > * Important fixes > > ** Cache > > The cache needs to be fixed. Its underlying implementation probably > needs to be changed, too. At the moment, it uses an AVL tree, which > isn't much tolerant and results in a freeze whenever the cache is > corrupted. Shifting to text properties could improve the situation. I think we'll have to leave this one to you! [...] > ** Find a solution for orgstruct minor mode > > Org struct is really different from Org. It prevents Org from using > better algorithms for outline navigation (see discussion about > `org-show-children' on this list). > > I think Org struct should be removed from "org.el" (and org-footnote > ...) and added in its own library. It should also be built on top of > Outline mode instead of Org mode. Org, OTOH, should remove dependencies > on Outline mode and implement better navigation functions. > > I have the feeling that Org struct will need to be rewritten almost from > scratch in the process. I've tried more than once over the past couple of years to attack orgstruct mode, and been defeated every time. Largely because indentation/filling is so damn complicated (too many layers of indirection for my little brain), and orgstruct added yet another layer of indirection on top of that. I think a rewrite would not be a bad thing, and would be happy to participate. [...] Nicolas Goaziou writes: [...] > The full proposal was at > but it didn't get > much positive feedback. Therefore I suggested a simplified version, with > a single author. I may have been one of the lukewarm responders at the time, but now I can't quite remember why. This looks good to me, and I'd like to pitch in. I'm also +1 for inline annotations. > Also, there is > > https://github.com/girzel/org-annotate > > which is even simpler. I'll be happy to rename/remove this repo when the time comes, to avoid confusion! The one thing I like about the package (indeed, it's what the bulk of the code actually does) is the ability to "pop up" a single annotation's text in a small, easily-dismissed special-mode buffer. Also, to display all of a buffer's annotations in a tabulated-list pop-up buffer, where you can easily jump to/edit/delete the various annotations. Obviously Org footnotes (and future annotations) have jump there/jump back capability, but for some reason I feel much more comfortable with this style of browsing. If other people like this I could adapt the existing code to work "on top of" footnotes and the future annotations syntax, and that could be the whole point of the library. The base code could remain entirely ignorant of the extra stuff. ------ These new features aside, is there any need to do any fundamental refactoring? I mostly mean altering existing Org libraries to use the element framework, stuff like that... Eric