From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Marking/highlighting text temporarily Date: Fri, 08 May 2015 12:19:06 +0200 Message-ID: <873837gyn9.fsf@nicolasgoaziou.fr> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqfLm-0007Do-D5 for emacs-orgmode@gnu.org; Fri, 08 May 2015 06:17:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqfLl-00085K-DL for emacs-orgmode@gnu.org; Fri, 08 May 2015 06:17:46 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:43702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqfLl-00082Z-0q for emacs-orgmode@gnu.org; Fri, 08 May 2015 06:17:45 -0400 In-Reply-To: <87pp6m5qy4.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Thu, 30 Apr 2015 09:45:55 +0800") 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: Eric Abrahamsen Cc: emacs-orgmode@gnu.org 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. 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]...[@] 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? -- Nicolas Goaziou