From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Marking/highlighting text temporarily Date: Sun, 03 May 2015 21:33:09 +0800 Message-ID: <87oam1zsyy.fsf@ericabrahamsen.net> References: <87a8xyrn39.fsf@pinto.chemeng.ucl.ac.uk> <87bnieufde.fsf@mbork.pl> <87zj5xewsp.fsf@pinto.chemeng.ucl.ac.uk> <87iockmyxy.fsf@ericabrahamsen.net> <87bnicshhc.fsf@ericabrahamsen.net> <87r3r57zre.fsf@ericabrahamsen.net> <87lhhb2uot.fsf@ericabrahamsen.net> <87oam7p6a7.fsf@nicolasgoaziou.fr> <87mw1r865s.fsf@ericabrahamsen.net> <878udahabq.fsf@nicolasgoaziou.fr> <87pp6m5qy4.fsf@ericabrahamsen.net> <877fsux7i5.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1You1Y-0006Ln-Md for emacs-orgmode@gnu.org; Sun, 03 May 2015 09:33:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1You1T-0005Gy-L3 for emacs-orgmode@gnu.org; Sun, 03 May 2015 09:33:36 -0400 Received: from plane.gmane.org ([80.91.229.3]:36387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1You1T-0005Gf-AL for emacs-orgmode@gnu.org; Sun, 03 May 2015 09:33:31 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1You1O-0008LT-T8 for emacs-orgmode@gnu.org; Sun, 03 May 2015 15:33:27 +0200 Received: from 114.248.23.63 ([114.248.23.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 May 2015 15:33:26 +0200 Received: from eric by 114.248.23.63 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 May 2015 15:33:26 +0200 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 Rasmus writes: > Hi, > > Eric Abrahamsen writes: > >> We're just talking about annotations-plus-metadata here, right? Not >> actual in-text TODOs? > > I don't know. > >> From what I can tell, rasmus seems to be proposing an in-text TODO, > > I mainly extrapolated from your example. Further, I extrapolated from the > notion of org-inlinetasks.el. Since we have one we should try to minimize > the distance whilst still keeping syntax as simple as possible, > e.g. [comment:] or [TODO-TAG:] (I don't know what the "@" operator meant > in your previous example). > >> I've definitely wanted some sort of a track changes equivalent in Org, >> but we'd want to be careful about this. > > Isn't this the job of VC? I'm not sure how we can concisely represent all > the needed metadata? Something like > > [comment: txt :annotation annot :author a :date d :other-properties p] > > is not "accessible" for non-Emacs users of the Org format. > >> 1. Annotations attached to arbitrary text in the buffer. The buffer text >> should be visible, the annotation data invisible (basically the way >> links work right now). > > This is a fortification/overlay issue. And I disagree strongly on having > invisible parts. > >> 2. Plain annotation: just a chunk of free-form paragraph text that is >> attached to the buffer text. > > What do you concretely have in mind here? Can't this be done with an > inlinetask at the beginning of the file? Or a noexport heading? > >> 3. Replacement text: an alternate version of the buffer text; this could >> be the basis of track changes stuff. > > Is this not the job of VC? > >> 4. Timestamps > > This seems like the job of e.g. vc-annotate.el, no? > >> 7. "Author" metadata would probably be unnecessary with full access to >> the export channels, but it might still be desirable. > > What John was talking about was for collaboration. When you export John's > notes on your machine how can it know it's from John if not set > explicitly? In any case, I think it could be too verbose. Sidenote: In > collaborated papers I simply use prefix "R:" and "K:" in inlinetasks. > >> That's all I can think of, just trying to get the ball rolling. I don't >> have any opinions about actual syntax, though something with curly >> braces might be nice. > > Nothing with curly braces is nice :) > > I think I have something much less ambitious in mind, as I'm perfectly > happy with only spanning a subset of org-inlinetasks.el. Disregarding > date and generalizing replacement text to "annotation", which could be set > to "replace" with a keyword, you could perhaps have something like one of > these: > > > [comment/Property:annotation; text] > [comment/TODO-TAG@author: annotation; text] > [comment/Property: annotation] > > [TODO-TAG/Property@Author: annotation; text] > [comment/Property: annotation] > > - Of course the / and @ operators are optional. > - I'm not sure what "Property" would be. > - Author could also be @work as in your previous example. > - Perhaps calculating TODO-TAGS on a document basis is a can of worms. > - I would be happier with having text before annotation, but that makes it > weird when you have no text attached (for inline tasks not associated to > a piece of text). Hmm, it looks like we've maybe got too many ideas bouncing around at the same time. I would love to have "more inline" inlinetodos -- ie, full-citizen TODOs that are attached to a run of buffer text, not headlines themselves. Call them in-text todos, maybe. I would also love to have collaborative editing in Org, and I agree that something based on VC would be most ideal (word-mode diffs could solve many of the problems there). Those two things seem pretty separate, though, and to be honest either one is way more than I can handle on my own. Tying in-text TODOs into the whole Agenda process seems like an awful lot of work. Also, I've never so much as glanced at the VC code. What seems most likely is I'll first fill out org-annotate and put it in Elpa, and then maybe we can have a slower conversation about what other directions to go in. Org-annotate will probably just stay what it is (it's very simple, and does what it says on the tin), but maybe we'll get a clearer sense of the various things people want, and it can be superseded at some point. On the VC side, how hard would it be to make a pseudo VC backend where, if you have an org file called some_file.org (for example), the backend looked for files in the same directory called some_file.org.XYZ.patch, and "applied" those patch files in a visible way to the Org file when you viewed it? With the whole apply/reject thing built in? Anyway... small, realistic steps seem like the best approach. Eric