From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Some projects Date: Sun, 25 Oct 2015 23:03:52 +0000 Message-ID: <877fmazh2f.fsf@gmail.com> References: <87wpub9jts.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqUKa-0007jl-08 for emacs-orgmode@gnu.org; Sun, 25 Oct 2015 19:04:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqUKU-00061T-U3 for emacs-orgmode@gnu.org; Sun, 25 Oct 2015 19:04:03 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:36555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqUKU-00061P-LB for emacs-orgmode@gnu.org; Sun, 25 Oct 2015 19:03:58 -0400 Received: by wicfx6 with SMTP id fx6so91489027wic.1 for ; Sun, 25 Oct 2015 16:03:57 -0700 (PDT) In-Reply-To: <87wpub9jts.fsf@nicolasgoaziou.fr> 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: Nicolas Goaziou , Org Mode List Hi Nicolas, Thanks for writing this up. It is important to think about, and ultimately solve, all the issues you raise. 2015ko urriak 25an, Nicolas Goaziou-ek idatzi zuen: >=20 > Hello, >=20 > 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. >=20 >=20 > * Features >=20 > ** Citations >=20 > Development apparently stopped for some reason. We have a citation > syntax for Org in wip-cite and some work done in wip-cite-awe and > probably elsewhere. >=20 > I think we could at least provide features defined in Org Ref using the > new syntax (minus hydra/helm related functions). >=20 > We don't need a silver bullet. Just something with a non-empty user > base, and extensible. In any case, the work done so far shouldn't be > wasted. I was working on this rather intensively at one time, but I had to stop because other aspects of life intruded. I have just been coming back towards a situation where I can imagine myself having some (still small, but non-zero) chunks of time to devote to working on org. So I hope I will be able to pick this back up, but (regrettably) I=E2=80=99m not able to make any promises. Based on my recollection, here=E2=80=99s what the problems were when I stop= ped: - The only =E2=80=9Coff the shelf=E2=80=9D-capable citation processing libr= ary that we found last time is in Haskell, which introduced some difficulties for distributing the resulting tool. I know some projects (e.g. git-annex) are written in Haskell and distributed as static binaries for windows/mac/linux/etc. We=E2=80=99d need to figure out how = to do this, or find another citation processing library in an easier-to-distribute language. (I should say, all the work on the external tool was done by Richard Lawrence; I worked on the exporter for the citation syntax including the interface with an external tool.) - There is a difference between citations as done by latex/bibtex/etc., and those done in every other format (handled through CSL). Assuming latex users want to keep their native processing rather than delegating to CSL, we need to solve the myriad small inconsistencies between these two tools. I think this is an area where it=E2=80=99s impo= rtant to get things right: users of citations generally have exacting requirements. =E2=80=9CApproximately Chicago-style=E2=80=9D or =E2=80=9C= almost MLA=E2=80=9D aren=E2=80=99t worth anything. When I start working again I will take your words about silver bullets to heart, and come up with something that covers at least basic use cases for users who can compile a haskell program themselves. We can expand from there. (I should also say, if someone else is interested in working on this please don=E2=80=99t hesitate to jump right in. I will help you however I = can!) >=20 > ** Annotations >=20 > It would be nice to allow annotating text in Org. I already made > a proposal for that feature a few months ago, without much success. > Anyway, I'd like to implement it, in a simplified form. For the record, > the idea is to use some markup for beginning and end of an annotation, > e.g., >=20 > [@:id].....[@] >=20 > and store text within a dedicated section, >=20 > * Annotations >=20 > [@:id] ... >=20 > Like footnotes, you could easily browse remotely annotations at point. > However, they would be, at least at the beginning, completely ignored > during export. >=20 > ** Backslash escaping >=20 > Allowing to escape some symbols in plain text (e.g., emphasis markers, > square brackets...) would remove a limitation in verbatim/code objects. > As a small benefit, it would also permit to implement mid-word markup: > b*o*ld. >=20 > There are some gotchas, however. >=20 > * Important fixes >=20 > ** Cache >=20 > 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. >=20 > Also, it needs to do better analysis in order to prevent those > corruptions. This is obviously the hardest part. >=20 > Again, an efficient cache can give us a better fontification mechanism, > since Org syntax is not regular. >=20 > ** Link hexification >=20 > There are currently some subtle inconsistencies in link handling. See > for example `org-make-link-string'. At the risk of being a bit of an anarchist, I think this is somewhere we could benefit from throwing backward compatibility out the window, at least for brainstorming purposes. The link-hexification bug threads I=E2=80=99ve read give the impression of watching someone try to add one mo= re level onto a teetering house of cards. It would be great if someone could take inventory of the uses of links in org, and then try to design a solid syntax that works for them from scratch. We=E2=80=99d wait to worry about implementation until having a well-engineered design. (To give an example of what I have in mind, it may turn out that hexification, borrowed from HTML/HTTP, is not even the best technical solution to our actual problem, whatever it is.) >=20 > ** Use lexical binding everywhere >=20 > This is the easiest part: add appropriate cookie at the beginning of the > file and fix resulting compiler warnings. There are also a lot of places that org uses dynamic variables to pass information around. It would be good to eliminate these as much as possible, since lexical binding allows generating more efficient bytecode for lexically bound variable access (including function arguments, AFAIK). This is a further project to what you describe, of course. >=20 > ** Find a solution for orgstruct minor mode >=20 > 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). >=20 > 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. FWIW, this gets a +1 from me. I=E2=80=99ve lost count of the number of tim= es I=E2=80=99ve started to make some =E2=80=9Cobvious=E2=80=9D minor improvement to some or= g function, only to have to discard the effort after 15 minutes when realizing that supporting orgstruct mode makes it impossible to actually carry through the change. Thanks again, --=20 Aaron Ecay