From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: Marking/highlighting text temporarily Date: Mon, 18 May 2015 11:57:21 +0200 Message-ID: <87d21yw6m6.fsf@pank.eu> 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> <873837gyn9.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuHqD-0000ZN-QA for emacs-orgmode@gnu.org; Mon, 18 May 2015 06:00:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YuHq9-0005NI-FX for emacs-orgmode@gnu.org; Mon, 18 May 2015 06:00:09 -0400 Received: from plane.gmane.org ([80.91.229.3]:41042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuHq9-0005L6-5v for emacs-orgmode@gnu.org; Mon, 18 May 2015 06:00:05 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YuHq7-0007U9-8R for emacs-orgmode@gnu.org; Mon, 18 May 2015 12:00:03 +0200 Received: from tsn85-159-237-4.dyn.nltelcom.net ([85.159.237.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 May 2015 12:00:03 +0200 Received: from rasmus by tsn85-159-237-4.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 May 2015 12:00:03 +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 Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> We're just talking about annotations-plus-metadata here, right? Not >> actual in-text TODOs? > > I'm not convinced in-text TODOs would be interesting, because they would > make building the agenda an order of magnitude slower. IMO you need not. But perhaps I'm extrapolating from my use-case. I guess it would be inconsistent not to include it. > My concerns about syntax are: > > - it should not cripple readability of the document > - it needs to mark both objects (inline) and elements, even multiple > elements (e.g., two paragraphs) > > In particular, the last point is difficult to handle for the parser. > Indeed, any syntax is either contained in a paragraph or stops one, so > this syntax should be a bit "outside" the parser. > > Anyway, here we go for another proposal. > > In-text markers: > > [@:ID]...[@] While we have opening and closing tags for formatting (e.g. bold), I dislike the above. It seems like asking for trouble; it would seem one could easily loose track and delete one end of the tag and not the other. IOW: [@:ID1]... [@:ID2]...[@]...[@] seems like asking for trouble as I could easily delete an opening pair. But note that I am more interested in an inline noting/todo functionality as opposed to annotation functionality. Also, for annotation, would it not be annoying, in review session say, to have the notes so "far away" from the text? Perhaps not with the right helping tools. —Rasmus > ID is expected to be unique, and consists of alphanumeric characters > only. Markers are allowed anywhere standard syntax is (e.g., paragraphs, > verse blocks, table cells, captions, parsed keyword). > > Both makers have to be found within the same section, i.e, one cannot > annotate across headlines. Annotations can be nested but cannot > partially overlap. > > From the parser point of view, Element can recognize such markers, but > will not be able to "associate" them since they exist above structure of > the document. > > One important limitation is that example or source blocks cannot be > annotated, Therefore I also suggest creating a new affiliated keyword, > > #+ANNOTATE: ID > > which will annotate the whole element it is applied to. > > Some examples: > > [@:1]Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod > tempor incididunt ut labore et [@:2]dolore magna[@] aliqua. > > Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi > ut aliquip ex ea commodo consequat.[@] > > #+ANNOTATE: foo > #+BEGIN_SRC emacs-lisp > (+ 1 1) > #+END_SRC > > Then references are collected in a dedicated section, much like > footnotes (e.g., `org-annotation-section'), although it cannot be nil. > > Annotations start at column 0 > > [@:ID:AUTHOR-ID] OTHER-AUTHOR-ID > CONTENTS > > where: > > - ID obviously refers to in-text markers' ID, > > - AUTHOR-ID consists of word and blank characters only. If empty, it > may default to `user-login-name'. > > - OTHER-AUTHOR-ID is also optional. It is meant for empty contents. > During export, it could be possible to select annotation from > a single source, e.g., > > #+OPTIONS: @:student1 > > - CONTENTS consists of either comments and non-comments. Any > non-comment is considered as data to replace (if in-text markers are > not sticked to each other), or insert (when they are) during export. > > Comments will be displayed as a conversation thread by a special > function in "org-annotate.el". > > This syntax allows to copy annotation from another author, e.g. > > [@:1:teacher] > # This is wrong, it should be "foo". > foo > > [@:1:student1] teacher > > [@:2:teacher] > # Please reformulate. > > [@:2:student1] > # What about "bar"? > bar > > Timestamps, if needed, can be inserted in comments. > > WDYT? -- Enough with the bla bla!