From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: Marking/highlighting text temporarily Date: Wed, 29 Apr 2015 09:38:29 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnSCE-0003oJ-SY for emacs-orgmode@gnu.org; Wed, 29 Apr 2015 09:38:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnSCA-00014q-AS for emacs-orgmode@gnu.org; Wed, 29 Apr 2015 09:38:38 -0400 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:35488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnSCA-00014L-15 for emacs-orgmode@gnu.org; Wed, 29 Apr 2015 09:38:34 -0400 Received: by qcbii10 with SMTP id ii10so12915063qcb.2 for ; Wed, 29 Apr 2015 06:38:33 -0700 (PDT) In-reply-to: <87mw1r865s.fsf@ericabrahamsen.net> 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 I think it could benefit from a dedicated syntax in the following context: There are different types of annotation you might like, e.g. delete, insert, replace, comment (I am drawing from ideas of annotations in PDF, and the idea of track changes). In multi-author documents you might want to know who wrote the annotation, and when. Finally, you might want some way to mark that the annotation has been "seen". These might be stand-alone or attached to text. To follow something like the cite syntax, here is an example that shows a comment type, author, timestamp, checked status, and content. I have not thought about how these would be displayed much except that you would almost always want an overlay to hide most of this, and show only the important stuff with an appropriate face (e.g. crossout for delete, ^....^ for insert, tooltip for comment, +old text+=new text=, etc... [@annote :type comment :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :content This is just a comment] [@annote :type insert :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :content some new content] [@annote :type delete :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :old-content Some words to delete] [@annote :type replace :author John Kitchin :timestamp [2015-04-29 Wed 9:26AM] :checked nil :old-content This is just a comment :new-content replacement text] Most of this information would be inserted by emacs, not by the author. Eric is right about the functionality provided to create and manipulate these annotations. Maybe some kind of minor mode to enable what could act like track changes, with commands to accept or reject the changes, etc... I would use this a lot with my students in writing papers. Eric Abrahamsen writes: > Nicolas Goaziou writes: > >> Hello, >> >> Eric Abrahamsen writes: >> >>> I'm copying Nicolas -- Nicolas, is there a process for inclusion in >>> contrib? Would this be eligible? I'll just stick it in Elpa, >>> otherwise. >> >> Any package is eligible. >> >> However, contrib/ is from pre-"package.el" days. Nowadays, I tend to >> think it should be used only as an incubator for libraries meant to be >> moved into core. Other libraries should be packaged in ELPA. >> >> I admit I didn't read the thread carefully. IIUC, it seems to be an >> annotation mechanism. If I'm correct, I think it belongs to the first >> category. > > Yup, "annotation mechanism" is about right. Just to be clear, you think > it fits into the category of incubation-prior-to-core? > > If anyone thinks that this mechanism warrants actual new Org syntax, I'd > be happy to work on implementing that. But to be honest, I think it sits > pretty comfortably on top of what's already available. The only slight > awkwardness comes when you'd like a different face for the annotation > links (currently solved with John Kitchin's hi-lock trick), and the fact > that the link export routines don't have access to the exportation > info/plist channels (ie, when exporting an annotation link to ODT, I'd > like to be able to give the annotation an "author" element, but as far > as I know I can't get access to that). These aren't major flaws. > > All that said, I do think this is an important feature that fills a bit > of gap in Org. TODOs are fundamental, but they are discrete entities. > Those of us who use Org for authoring could use a method of decorating > spans of text with pertinent information. As org-comment stands now, the > tabular list buffer serves as a pseudo Agenda for text comments: I have > been using it, for example, as a way of keeping track of translation > problems that I need to resolve. > > I'll admit I have dreamed of a syntax that looks like: [[body text to > annotate][TODO:Look this up on the internet:@work]]. The thought of > plugging that in to the existing Agenda machine is exhausting even to > contemplate, though. > > I know we've got inlinetodos. They bug me, though: the absurd number of > stars (even if they are invisible), and the fact that you're still not > really attaching the TODO to specific text, which is what I want. I know > these aren't reasonable objections, but still. > > Now I wish we'd named it org-annotate. > > I'm done, > Eric -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu