From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: Marking/highlighting text temporarily
Date: Thu, 30 Apr 2015 09:45:52 -0400 [thread overview]
Message-ID: <m2a8xpn2zz.fsf@johns-air.wv.cc.cmu.edu> (raw)
In-Reply-To: <877fsux7i5.fsf@gmx.us>
Rasmus writes:
> Hi,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> 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
VC does not do this well for written text. Most VC were designed for
code, and are line oriented. In written text, you can have an entire
paragraph on a single line, and most VC do not show changes by sentence,
for example. There are some ways to get different kinds of diffs, but
none of them work well in my opinion. Students "get" track changes, and
for collaborative editing of text, it is pretty great.
>
> [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?
inlinetasks do not have the same semantic meaning as comments and
annotations. They can serve a purpose similar to this, I agree. but, it
doesn't make sense to me to consider having an annotation type for
inline comments, and a separate type for this plain annotation. How
would you differentiate a real task from a plain annotation?
>
>> 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?
No. VC has a role in it, but current tools do not do this well enough to
be solutions.
>
>> 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).
>
> —Rasmus
--
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
next prev parent reply other threads:[~2015-04-30 13:46 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal
2015-04-24 6:42 ` Thomas S. Dye
2015-04-24 7:53 ` Marcin Borkowski
2015-04-24 7:05 ` Glyn Millington
2015-04-24 7:13 ` Eric Abrahamsen
2015-04-24 7:19 ` Eric Abrahamsen
2015-04-24 7:38 ` Fabrice Niessen
2015-04-24 7:40 ` Eric S Fraga
2015-04-24 7:58 ` Marcin Borkowski
2015-04-24 8:48 ` Eric S Fraga
2015-04-24 21:38 ` Vikas Rawal
2015-04-25 0:52 ` John Kitchin
2015-04-25 1:34 ` Eric Abrahamsen
2015-04-25 4:13 ` Vikas Rawal
2015-04-25 7:47 ` Eric Abrahamsen
2015-04-25 9:08 ` Eric Abrahamsen
2015-04-26 18:14 ` John Kitchin
2015-04-27 6:13 ` Eric Abrahamsen
2015-04-27 10:27 ` John Kitchin
2015-04-27 11:11 ` Marcin Borkowski
2015-04-27 12:37 ` Eric Abrahamsen
2015-04-27 12:58 ` John Kitchin
2015-04-27 13:06 ` Eric Abrahamsen
2015-04-27 23:35 ` John Kitchin
2015-04-28 2:28 ` Eric Abrahamsen
2015-04-28 19:32 ` John Kitchin
2015-04-29 8:41 ` Eric Abrahamsen
2015-04-29 9:57 ` Rasmus
2015-04-29 12:14 ` Eric Abrahamsen
2015-04-29 12:31 ` Rasmus
2015-04-29 13:57 ` John Kitchin
2015-04-29 13:52 ` John Kitchin
2015-04-29 10:39 ` Nicolas Goaziou
2015-04-29 12:34 ` Eric Abrahamsen
2015-04-29 12:51 ` Rasmus
2015-04-29 13:21 ` Eric S Fraga
2015-04-29 14:00 ` John Kitchin
2015-04-29 14:42 ` Eric S Fraga
2015-04-29 14:54 ` Eric Abrahamsen
2015-04-29 13:16 ` Eric S Fraga
2015-04-29 14:56 ` Eric Abrahamsen
2015-04-29 13:38 ` John Kitchin
2015-04-29 21:51 ` Nicolas Goaziou
2015-04-30 1:45 ` Eric Abrahamsen
2015-04-30 9:58 ` Rasmus
2015-04-30 11:32 ` Eric S Fraga
2015-04-30 13:45 ` John Kitchin [this message]
2015-05-03 13:33 ` Eric Abrahamsen
2015-05-08 10:19 ` Nicolas Goaziou
2015-05-18 9:57 ` Rasmus
2015-05-18 11:48 ` Nicolas Goaziou
2015-05-18 13:16 ` Rasmus
2015-05-18 15:44 ` Eric S Fraga
2015-05-18 16:31 ` Rasmus
2015-05-18 20:49 ` Eric Abrahamsen
2015-05-18 15:50 ` Nicolas Goaziou
2015-05-18 16:25 ` Rasmus
2015-05-18 16:56 ` Nicolas Goaziou
2015-05-18 17:28 ` Rasmus
2015-05-18 18:36 ` Eric S Fraga
2015-05-19 8:14 ` Nicolas Goaziou
2015-04-28 10:48 ` Eric Abrahamsen
2015-04-25 9:04 ` Eric S Fraga
2015-05-18 21:42 ` Marcin Borkowski
2015-05-28 10:52 ` Alan Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2a8xpn2zz.fsf@johns-air.wv.cc.cmu.edu \
--to=jkitchin@andrew.cmu.edu \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).