Marking/highlighting text temporarily

Marking/highlighting text temporarily

[Vikas Rawal]

I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with.

What could be an the easy way of doing it?

Vikas

Re: Marking/highlighting text temporarily

[Thomas S. Dye]

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

> I am revising a long book manuscript, and would like to mark parts of
> text (not just the headlines) just to remind myself that these need to
> be dealt with.
>
> What could be an the easy way of doing it?
>
> Vikas

Bookmarks?

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Marking/highlighting text temporarily

[Marcin Borkowski]

On 2015-04-24, at 08:42, Thomas S. Dye <tsd@tsdye.com> wrote:

> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>
>> I am revising a long book manuscript, and would like to mark parts of
>> text (not just the headlines) just to remind myself that these need to
>> be dealt with.
>>
>> What could be an the easy way of doing it?
>
> Bookmarks?

No - Bookmark+, with bookmarks that are /highlighted/!

> hth,
> Tom

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Marking/highlighting text temporarily

[Glyn Millington]

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

> I am revising a long book manuscript, and would like to mark parts of
> text (not just the headlines) just to remind myself that these need to
> be dealt with.
>
> What could be an the easy way of doing it?

Just insert something like 'XXXX' [1]at each place.  The usual Emacs search
will take you through them in order.  Delete when the fix has been made.


hth


Glyn

Footnotes: 
[1]  Easier than typing in FIXME !

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

> I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with.
>
> What could be an the easy way of doing it?

I use footnotes for this sort of thing, but don't find it very ideal.

I've occasionally thought of a link type that operates more like the
comment feature of Word Processors That Shall Not Be Named. So you'd do
the following:


Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
lobortis eget, lacus. [[Sed diam. Praesent fermentum tempor tellus.
Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at
pede. Etiam vel neque nec dui dignissim bibendum.]][#:I hear all this
isn't really Latin, but who am I to say?]] Vivamus id enim. Phasellus
neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.


I'm making up the "#:" syntax, but you see what I mean. The comment
would disappear, the text would be highlighted somehow, and perhaps it
could even be exported to a proper comment in ODT, and turned into
a custom container/environment in other export backends. HTML tooltips,
marginpars, etc.

Just a thought.

Eric

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>
>> I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with.
>>
>> What could be an the easy way of doing it?
>
> I use footnotes for this sort of thing, but don't find it very ideal.
>
> I've occasionally thought of a link type that operates more like the
> comment feature of Word Processors That Shall Not Be Named. So you'd do
> the following:
>
>
> Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non
> orci commodo lobortis. Proin neque massa, cursus ut, gravida ut,
> lobortis eget, lacus. [[Sed diam. Praesent fermentum tempor tellus.
> Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at
> pede. Etiam vel neque nec dui dignissim bibendum.]][#:I hear all this
> isn't really Latin, but who am I to say?]] Vivamus id enim. Phasellus
> neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus.
> Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat.
>
>
> I'm making up the "#:" syntax, but you see what I mean. The comment
> would disappear, the text would be highlighted somehow, and perhaps it
> could even be exported to a proper comment in ODT, and turned into
> a custom container/environment in other export backends. HTML tooltips,
> marginpars, etc.

Allow me to agree with myself further: I do a lot of translation, and
handle temporary notes-to-self with footnotes. I'd much rather use the
above syntax to wrap questionable passages and put the original text in
the comment. That way I can even share it usefully with editors during
the publishing process. That would probably mean ODT/Doc, but how sexy
would it be to turn in a PDF with marginpar notes?

E

Re: Marking/highlighting text temporarily

[Fabrice Niessen]

Vikas Rawal wrote:
> I am revising a long book manuscript, and would like to mark parts of
> text (not just the headlines) just to remind myself that these need to
> be dealt with.
>
> What could be an the easy way of doing it?

Inserting `XXX' which are automatically highlighted in red?

See "Highlight FIXME notes" in
https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el for
an example.

Best regards,
Fabrice

-- 
Fabrice Niessen
Leuven, Belgium
http://www.pirilampo.org/

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Friday, 24 Apr 2015 at 11:49, Vikas Rawal wrote:
> I am revising a long book manuscript, and would like to mark parts of
> text (not just the headlines) just to remind myself that these need to
> be dealt with.
>
> What could be an the easy way of doing it?

I use inline tasks for this.  If you are exporting to PDF via LaTeX, the
following LaTeX definition for inline tasks is quite useful:

#+begin_src emacs-lisp
  (setq org-inlinetask-export-templates
        '((latex "%s\\footnote{%s\\\\ %s}\\marginpar{\\fbox{\\thefootnote}}"
                 '((unless
                       (eq todo "")
                     (format "\\fbox{\\textsc{%s%s}}" todo priority))
                   heading content))))
#+end_src

This uses footnotes to put the task information into the document and
uses a little margin note to indicate that a TODO task is present in the
text.

I've removed the templates for other export targets from this variable
to keep the email short.

HTH,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-951-g2f58e3

Re: Marking/highlighting text temporarily

[Marcin Borkowski]

On 2015-04-24, at 09:40, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> On Friday, 24 Apr 2015 at 11:49, Vikas Rawal wrote:
>> I am revising a long book manuscript, and would like to mark parts of
>> text (not just the headlines) just to remind myself that these need to
>> be dealt with.
>>
>> What could be an the easy way of doing it?
>
> I use inline tasks for this.  If you are exporting to PDF via LaTeX, the
> following LaTeX definition for inline tasks is quite useful:
>
> #+begin_src emacs-lisp
>   (setq org-inlinetask-export-templates
>         '((latex "%s\\footnote{%s\\\\ %s}\\marginpar{\\fbox{\\thefootnote}}"
>                  '((unless
>                        (eq todo "")
>                      (format "\\fbox{\\textsc{%s%s}}" todo priority))
>                    heading content))))
> #+end_src
>
> This uses footnotes to put the task information into the document and
> uses a little margin note to indicate that a TODO task is present in the
> text.

Why use footnotes when you can use todonotes?

https://www.ctan.org/pkg/todonotes

It can even make a list-of-todo-notes.  See also

http://tex.stackexchange.com/questions/9796/how-to-add-todo-notes for
more options.

> HTH,
> eric

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Friday, 24 Apr 2015 at 09:58, Marcin Borkowski wrote:

[...]

> Why use footnotes when you can use todonotes?

Good question!

It's personal preference: I prefer footnotes as I am often using narrow
margins and anything more than a boxed footnote number is too
much...  However, it is trivial to change the export template to use
todonotes if that's what Vikas prefers.

The key message I was trying to get across is the use inlinetasks to
leverage the capabilities of org for TODO management.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-951-g2f58e3

Re: Marking/highlighting text temporarily

[Vikas Rawal]

> 
> [...]
> 
>> Why use footnotes when you can use todonotes?
> 
> Good question!
> 
> It's personal preference: I prefer footnotes as I am often using narrow
> margins and anything more than a boxed footnote number is too
> much...  However, it is trivial to change the export template to use
> todonotes if that's what Vikas prefers.
> 
> The key message I was trying to get across is the use inlinetasks to
> leverage the capabilities of org for TODO management.
> 


Thanks all. It has been lovely to see all the various solutions on offer. I thought I was posting a lame query, and was feeling a little sheepish when I first sent it. But it has been nice to see these various approaches, with their little ingenuities.

Wonderful org friends, thank you once again.

Vikas

Re: Marking/highlighting text temporarily

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Inspired by this conversation, I hacked up this functional comment link:

http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/

It has a custom link type that exports in html and latex, and when you
click on it, it asks if you want to delete the comment.

John

-----------------------------------
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


On Fri, Apr 24, 2015 at 5:38 PM, Vikas Rawal <
vikaslists@agrarianresearch.org> wrote:

> >
> > [...]
> >
> >> Why use footnotes when you can use todonotes?
> >
> > Good question!
> >
> > It's personal preference: I prefer footnotes as I am often using narrow
> > margins and anything more than a boxed footnote number is too
> > much...  However, it is trivial to change the export template to use
> > todonotes if that's what Vikas prefers.
> >
> > The key message I was trying to get across is the use inlinetasks to
> > leverage the capabilities of org for TODO management.
> >
>
>
> Thanks all. It has been lovely to see all the various solutions on offer.
> I thought I was posting a lame query, and was feeling a little sheepish
> when I first sent it. But it has been nice to see these various approaches,
> with their little ingenuities.
>
> Wonderful org friends, thank you once again.
>
> Vikas
>

[-- Attachment #2: Type: text/html, Size: 2296 bytes --]

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Inspired by this conversation, I hacked up this functional comment
> link:
>
> http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>
>
> It has a custom link type that exports in html and latex, and when you
> click on it, it asks if you want to delete the comment. 
>
> John

Awesome! I was half expecting to get around to this myself, half hoping
someone else would do it :)

I've saved the code, and am already using it in a new short story
translation. If I come up with any substantial improvements, I'll
mention them here.

Thanks very much!

Eric

Re: Marking/highlighting text temporarily

[Vikas Rawal]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]


> On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> 
> Inspired by this conversation, I hacked up this functional comment link:
> 
> http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ <http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/>
> 
> It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. 
> 

Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed.

Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else).

Thanks,

Vikas

[-- Attachment #2: Type: text/html, Size: 1650 bytes --]

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Vikas Rawal <vikaslists@agrarianresearch.org> writes:

>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>     wrote:
>
>     Inspired by this conversation, I hacked up this functional comment
>     link:
>
>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>     
>
>     It has a custom link type that exports in html and latex, and when
>     you click on it, it asks if you want to delete the comment. 
>
> Nice. One small issue is that when I highlight a text and add comment
> to it, and then delete the comment, one space following the last word
> is removed.
>
> Also, it would be good to make the comment stand out in LaTeX (and
> other) exports, preferably by pushing it to the margin (so it does not
> move everything else).

Hang on a bit, I'm wasting my afternoon expanding this...

Eric

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>
>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>     wrote:
>>
>>     Inspired by this conversation, I hacked up this functional comment
>>     link:
>>
>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>     
>>
>>     It has a custom link type that exports in html and latex, and when
>>     you click on it, it asks if you want to delete the comment. 
>>
>> Nice. One small issue is that when I highlight a text and add comment
>> to it, and then delete the comment, one space following the last word
>> is removed.
>>
>> Also, it would be good to make the comment stand out in LaTeX (and
>> other) exports, preferably by pushing it to the margin (so it does not
>> move everything else).
>
> Hang on a bit, I'm wasting my afternoon expanding this...

Okay, this is as far as I got today. I changed some behavior from John's
implementation: when following the links, it seemed like displaying the
comment text would be more useful than deleting it -- I think many of us
have "delete-org-link" functions lying around. I also couldn't get the
add-comment thing to work, as it complained when there was no region, so
I changed how that works.

Lastly, I spent most of my time learning how tabular list mode works,
and haven't actually tested the export. Will save that for tomorrow.
Otherwise, here's the introduction from the Commentary. Comments and
suggestions very welcome!



Provides a new link type for Org that allows you to create comments
on arbitrary chunks of text.  The link prefix is "comment:".

Add comments with `org-comment-add-comment'.  Following the link
will display the text of the comment in a pop-up buffer.  The
buffer is in special-mode, hit "q" to dismiss it.

Call `org-comment-display-comments' to see all comments in a buffer.

See the `org-comment-[backend]-export-style' options for ways to
format comments in export.

TODO:

1. Better export customization options.
2. What does the ODT comment XML look like?
3. More functions in the display comment buffer: copy as
kill... what else?
4. More functions in the comments list buffer, to display, pop to,
delete, and edit comment text.
5. Is it possible to have multi-line filled tabular list items?
Long comments are not very useful if you can't see the whole thing.
5. Allow multiple comment list buffers attached to different Org
buffers.
6. Maybe a minor mode for ease of manipulating comments?



[-- Attachment #2: org-comment.el --]
[-- Type: application/emacs-lisp, Size: 7673 bytes --]

Re: Marking/highlighting text temporarily

[John Kitchin]

Very nice start!

- make comment links a different color/face
(e.g. https://github.com/jkitchin/org-ref/blob/master/org-ref.el#L360)

otherwise, I think item 4 is the most important one on the todo list. We
are writing lots of papers this year, so this will be a really helpful tool!

Eric Abrahamsen writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>
>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>     wrote:
>>>
>>>     Inspired by this conversation, I hacked up this functional comment
>>>     link:
>>>
>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>
>>>
>>>     It has a custom link type that exports in html and latex, and when
>>>     you click on it, it asks if you want to delete the comment.
>>>
>>> Nice. One small issue is that when I highlight a text and add comment
>>> to it, and then delete the comment, one space following the last word
>>> is removed.
>>>
>>> Also, it would be good to make the comment stand out in LaTeX (and
>>> other) exports, preferably by pushing it to the margin (so it does not
>>> move everything else).
>>
>> Hang on a bit, I'm wasting my afternoon expanding this...
>
> Okay, this is as far as I got today. I changed some behavior from John's
> implementation: when following the links, it seemed like displaying the
> comment text would be more useful than deleting it -- I think many of us
> have "delete-org-link" functions lying around. I also couldn't get the
> add-comment thing to work, as it complained when there was no region, so
> I changed how that works.
>
> Lastly, I spent most of my time learning how tabular list mode works,
> and haven't actually tested the export. Will save that for tomorrow.
> Otherwise, here's the introduction from the Commentary. Comments and
> suggestions very welcome!
>
>
>
> Provides a new link type for Org that allows you to create comments
> on arbitrary chunks of text.  The link prefix is "comment:".
>
> Add comments with `org-comment-add-comment'.  Following the link
> will display the text of the comment in a pop-up buffer.  The
> buffer is in special-mode, hit "q" to dismiss it.
>
> Call `org-comment-display-comments' to see all comments in a buffer.
>
> See the `org-comment-[backend]-export-style' options for ways to
> format comments in export.
>
> TODO:
>
> 1. Better export customization options.
> 2. What does the ODT comment XML look like?
> 3. More functions in the display comment buffer: copy as
> kill... what else?
> 4. More functions in the comments list buffer, to display, pop to,
> delete, and edit comment text.
> 5. Is it possible to have multi-line filled tabular list items?
> Long comments are not very useful if you can't see the whole thing.
> 5. Allow multiple comment list buffers attached to different Org
> buffers.
> 6. Maybe a minor mode for ease of manipulating comments?

--
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

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Very nice start!
>
> - make comment links a different color/face
> (e.g. https://github.com/jkitchin/org-ref/blob/master/org-ref.el#L360)

Ah, nice -- too bad there's no built-in way to specify a face for link
types. This looks like it will do nicely, though!

> otherwise, I think item 4 is the most important one on the todo list. We
> are writing lots of papers this year, so this will be a really helpful tool!

Cool, I'll start with that, then.

I also thought of a command that would take what's in the tabulated list
buffer and convert it into an Org-mode buffer, with the text/comment
pairs in a two-column table. Then the user could export that buffer into
some other format and share a "comments sheet" with other people.

A bit at a time...

Eric

> Eric Abrahamsen writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>
>>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>>     wrote:
>>>>
>>>>     Inspired by this conversation, I hacked up this functional comment
>>>>     link:
>>>>
>>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>>
>>>>
>>>>     It has a custom link type that exports in html and latex, and when
>>>>     you click on it, it asks if you want to delete the comment.
>>>>
>>>> Nice. One small issue is that when I highlight a text and add comment
>>>> to it, and then delete the comment, one space following the last word
>>>> is removed.
>>>>
>>>> Also, it would be good to make the comment stand out in LaTeX (and
>>>> other) exports, preferably by pushing it to the margin (so it does not
>>>> move everything else).
>>>
>>> Hang on a bit, I'm wasting my afternoon expanding this...
>>
>> Okay, this is as far as I got today. I changed some behavior from John's
>> implementation: when following the links, it seemed like displaying the
>> comment text would be more useful than deleting it -- I think many of us
>> have "delete-org-link" functions lying around. I also couldn't get the
>> add-comment thing to work, as it complained when there was no region, so
>> I changed how that works.
>>
>> Lastly, I spent most of my time learning how tabular list mode works,
>> and haven't actually tested the export. Will save that for tomorrow.
>> Otherwise, here's the introduction from the Commentary. Comments and
>> suggestions very welcome!
>>
>>
>>
>> Provides a new link type for Org that allows you to create comments
>> on arbitrary chunks of text.  The link prefix is "comment:".
>>
>> Add comments with `org-comment-add-comment'.  Following the link
>> will display the text of the comment in a pop-up buffer.  The
>> buffer is in special-mode, hit "q" to dismiss it.
>>
>> Call `org-comment-display-comments' to see all comments in a buffer.
>>
>> See the `org-comment-[backend]-export-style' options for ways to
>> format comments in export.
>>
>> TODO:
>>
>> 1. Better export customization options.
>> 2. What does the ODT comment XML look like?
>> 3. More functions in the display comment buffer: copy as
>> kill... what else?
>> 4. More functions in the comments list buffer, to display, pop to,
>> delete, and edit comment text.
>> 5. Is it possible to have multi-line filled tabular list items?
>> Long comments are not very useful if you can't see the whole thing.
>> 5. Allow multiple comment list buffers attached to different Org
>> buffers.
>> 6. Maybe a minor mode for ease of manipulating comments?
>
> --
> 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

Re: Marking/highlighting text temporarily

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 4708 bytes --]

This might be a case where having a link type that supports attributes
would come in handy. Then you could use these like PDF comments. In the
list of PDF comments in Adobe Acrobat for example, there is a checkbox you
can use to check them off when you are done with one. Of course, you have
to store that state somewhere! I think the pdf comment also stores the
author, and maybe other information too like the date and time it was
created.

John

-----------------------------------
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


On Mon, Apr 27, 2015 at 2:13 AM, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
> > Very nice start!
> >
> > - make comment links a different color/face
> > (e.g. https://github.com/jkitchin/org-ref/blob/master/org-ref.el#L360)
>
> Ah, nice -- too bad there's no built-in way to specify a face for link
> types. This looks like it will do nicely, though!
>
> > otherwise, I think item 4 is the most important one on the todo list. We
> > are writing lots of papers this year, so this will be a really helpful
> tool!
>
> Cool, I'll start with that, then.
>
> I also thought of a command that would take what's in the tabulated list
> buffer and convert it into an Org-mode buffer, with the text/comment
> pairs in a two-column table. Then the user could export that buffer into
> some other format and share a "comments sheet" with other people.
>
> A bit at a time...
>
> Eric
>
> > Eric Abrahamsen writes:
> >
> >> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> >>
> >>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
> >>>
> >>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu
> >
> >>>>     wrote:
> >>>>
> >>>>     Inspired by this conversation, I hacked up this functional comment
> >>>>     link:
> >>>>
> >>>>
> http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
> >>>>
> >>>>
> >>>>     It has a custom link type that exports in html and latex, and when
> >>>>     you click on it, it asks if you want to delete the comment.
> >>>>
> >>>> Nice. One small issue is that when I highlight a text and add comment
> >>>> to it, and then delete the comment, one space following the last word
> >>>> is removed.
> >>>>
> >>>> Also, it would be good to make the comment stand out in LaTeX (and
> >>>> other) exports, preferably by pushing it to the margin (so it does not
> >>>> move everything else).
> >>>
> >>> Hang on a bit, I'm wasting my afternoon expanding this...
> >>
> >> Okay, this is as far as I got today. I changed some behavior from John's
> >> implementation: when following the links, it seemed like displaying the
> >> comment text would be more useful than deleting it -- I think many of us
> >> have "delete-org-link" functions lying around. I also couldn't get the
> >> add-comment thing to work, as it complained when there was no region, so
> >> I changed how that works.
> >>
> >> Lastly, I spent most of my time learning how tabular list mode works,
> >> and haven't actually tested the export. Will save that for tomorrow.
> >> Otherwise, here's the introduction from the Commentary. Comments and
> >> suggestions very welcome!
> >>
> >>
> >>
> >> Provides a new link type for Org that allows you to create comments
> >> on arbitrary chunks of text.  The link prefix is "comment:".
> >>
> >> Add comments with `org-comment-add-comment'.  Following the link
> >> will display the text of the comment in a pop-up buffer.  The
> >> buffer is in special-mode, hit "q" to dismiss it.
> >>
> >> Call `org-comment-display-comments' to see all comments in a buffer.
> >>
> >> See the `org-comment-[backend]-export-style' options for ways to
> >> format comments in export.
> >>
> >> TODO:
> >>
> >> 1. Better export customization options.
> >> 2. What does the ODT comment XML look like?
> >> 3. More functions in the display comment buffer: copy as
> >> kill... what else?
> >> 4. More functions in the comments list buffer, to display, pop to,
> >> delete, and edit comment text.
> >> 5. Is it possible to have multi-line filled tabular list items?
> >> Long comments are not very useful if you can't see the whole thing.
> >> 5. Allow multiple comment list buffers attached to different Org
> >> buffers.
> >> 6. Maybe a minor mode for ease of manipulating comments?
> >
> > --
> > 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 6913 bytes --]

Re: Marking/highlighting text temporarily

[Marcin Borkowski]

On 2015-04-27, at 12:27, John Kitchin <jkitchin@andrew.cmu.edu> wrote:

> This might be a case where having a link type that supports attributes
> would come in handy. Then you could use these like PDF comments. In the
> list of PDF comments in Adobe Acrobat for example, there is a checkbox you
> can use to check them off when you are done with one. Of course, you have
> to store that state somewhere! I think the pdf comment also stores the
> author, and maybe other information too like the date and time it was
> created.

I think that Adobe Reader also sends it to the NSA. ;-)

> John

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-04-27, at 12:27, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>
>> This might be a case where having a link type that supports attributes
>> would come in handy. Then you could use these like PDF comments. In the
>> list of PDF comments in Adobe Acrobat for example, there is a checkbox you
>> can use to check them off when you are done with one. Of course, you have
>> to store that state somewhere! I think the pdf comment also stores the
>> author, and maybe other information too like the date and time it was
>> created.
>
> I think that Adobe Reader also sends it to the NSA. ;-)

I will provide a special org-comment-nsa-export-function option, to help
you convey your "comments" directly to the place where it matters.

Re: Marking/highlighting text temporarily

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Emacs anticipated this need and can help formulate comments specifically
for the NSA :)
https://www.gnu.org/software/emacs/manual/html_node/emacs/Mail-Amusements.html

John

-----------------------------------
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


On Mon, Apr 27, 2015 at 8:37 AM, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> > On 2015-04-27, at 12:27, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> >
> >> This might be a case where having a link type that supports attributes
> >> would come in handy. Then you could use these like PDF comments. In the
> >> list of PDF comments in Adobe Acrobat for example, there is a checkbox
> you
> >> can use to check them off when you are done with one. Of course, you
> have
> >> to store that state somewhere! I think the pdf comment also stores the
> >> author, and maybe other information too like the date and time it was
> >> created.
> >
> > I think that Adobe Reader also sends it to the NSA. ;-)
>
> I will provide a special org-comment-nsa-export-function option, to help
> you convey your "comments" directly to the place where it matters.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Emacs anticipated this need and can help formulate comments
> specifically for the NSA :)
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Mail-Amusements.html

Well that's pretty amazing.

> On Mon, Apr 27, 2015 at 8:37 AM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>
>
>     Marcin Borkowski <mbork@mbork.pl> writes:
>
>     > On 2015-04-27, at 12:27, John Kitchin <jkitchin@andrew.cmu.edu>
>     wrote:
>     >
>     >> This might be a case where having a link type that supports
>     attributes
>     >> would come in handy. Then you could use these like PDF
>     comments. In the
>     >> list of PDF comments in Adobe Acrobat for example, there is a
>     checkbox you
>     >> can use to check them off when you are done with one. Of
>     course, you have
>     >> to store that state somewhere! I think the pdf comment also
>     stores the
>     >> author, and maybe other information too like the date and time
>     it was
>     >> created.
>     >
>     > I think that Adobe Reader also sends it to the NSA. ;-)
>
>     I will provide a special org-comment-nsa-export-function option,
>     to help
>     you convey your "comments" directly to the place where it matters.

Re: Marking/highlighting text temporarily

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Hi Eric,

I added some functions in the attachment. they colorize the comments,
add an org-comment menu to the org-menu, and some functions for pop to
and delete comments from the list mode, and a hydra for commands to
insert comments. Do you want to get this up on github to facilitate
developing it?

Eric Abrahamsen writes:

> Eric Abrahamsen

[-- Attachment #2: org-comment.el --]
[-- Type: application/emacs-lisp, Size: 11184 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2812 bytes --]

 <eric@ericabrahamsen.net> writes:
>
>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>
>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>     wrote:
>>>
>>>     Inspired by this conversation, I hacked up this functional comment
>>>     link:
>>>
>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>
>>>
>>>     It has a custom link type that exports in html and latex, and when
>>>     you click on it, it asks if you want to delete the comment.
>>>
>>> Nice. One small issue is that when I highlight a text and add comment
>>> to it, and then delete the comment, one space following the last word
>>> is removed.
>>>
>>> Also, it would be good to make the comment stand out in LaTeX (and
>>> other) exports, preferably by pushing it to the margin (so it does not
>>> move everything else).
>>
>> Hang on a bit, I'm wasting my afternoon expanding this...
>
> Okay, this is as far as I got today. I changed some behavior from John's
> implementation: when following the links, it seemed like displaying the
> comment text would be more useful than deleting it -- I think many of us
> have "delete-org-link" functions lying around. I also couldn't get the
> add-comment thing to work, as it complained when there was no region, so
> I changed how that works.
>
> Lastly, I spent most of my time learning how tabular list mode works,
> and haven't actually tested the export. Will save that for tomorrow.
> Otherwise, here's the introduction from the Commentary. Comments and
> suggestions very welcome!
>
>
>
> Provides a new link type for Org that allows you to create comments
> on arbitrary chunks of text.  The link prefix is "comment:".
>
> Add comments with `org-comment-add-comment'.  Following the link
> will display the text of the comment in a pop-up buffer.  The
> buffer is in special-mode, hit "q" to dismiss it.
>
> Call `org-comment-display-comments' to see all comments in a buffer.
>
> See the `org-comment-[backend]-export-style' options for ways to
> format comments in export.
>
> TODO:
>
> 1. Better export customization options.
> 2. What does the ODT comment XML look like?
> 3. More functions in the display comment buffer: copy as
> kill... what else?
> 4. More functions in the comments list buffer, to display, pop to,
> delete, and edit comment text.
> 5. Is it possible to have multi-line filled tabular list items?
> Long comments are not very useful if you can't see the whole thing.
> 5. Allow multiple comment list buffers attached to different Org
> buffers.
> 6. Maybe a minor mode for ease of manipulating comments?

--
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

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Hi Eric,
>
> I added some functions in the attachment. they colorize the comments,
> add an org-comment menu to the org-menu, and some functions for pop to
> and delete comments from the list mode, and a hydra for commands to
> insert comments. Do you want to get this up on github to facilitate
> developing it?

Oh great! Thanks a lot. We are duplicating effort a bit here (but only a
bit, I'd also written display/delete functions for the list buffer), so
yes, it would be good to coordinate development. 

I suppose it depends a bit on where this is going to end up: I'm
assuming either org/contrib/lisp, or else as an Elpa package. I don't
see much difference, except in terms of accessibility to contributors --
I don't have access to the Org repo, but putting it there might get more
contributors on balance. As a package only I would have direct access.
What do you think?

The hydra thing is interesting -- I wasn't aware of that package. Better
not to require it unconditionally though, right?

Thanks,
Eric

> Eric Abrahamsen writes:
>
>> Eric Abrahamsen
>
>
>  <eric@ericabrahamsen.net> writes:
>>
>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>
>>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>>     wrote:
>>>>
>>>>     Inspired by this conversation, I hacked up this functional comment
>>>>     link:
>>>>
>>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>>
>>>>
>>>>     It has a custom link type that exports in html and latex, and when
>>>>     you click on it, it asks if you want to delete the comment.
>>>>
>>>> Nice. One small issue is that when I highlight a text and add comment
>>>> to it, and then delete the comment, one space following the last word
>>>> is removed.
>>>>
>>>> Also, it would be good to make the comment stand out in LaTeX (and
>>>> other) exports, preferably by pushing it to the margin (so it does not
>>>> move everything else).
>>>
>>> Hang on a bit, I'm wasting my afternoon expanding this...
>>
>> Okay, this is as far as I got today. I changed some behavior from John's
>> implementation: when following the links, it seemed like displaying the
>> comment text would be more useful than deleting it -- I think many of us
>> have "delete-org-link" functions lying around. I also couldn't get the
>> add-comment thing to work, as it complained when there was no region, so
>> I changed how that works.
>>
>> Lastly, I spent most of my time learning how tabular list mode works,
>> and haven't actually tested the export. Will save that for tomorrow.
>> Otherwise, here's the introduction from the Commentary. Comments and
>> suggestions very welcome!
>>
>>
>>
>> Provides a new link type for Org that allows you to create comments
>> on arbitrary chunks of text.  The link prefix is "comment:".
>>
>> Add comments with `org-comment-add-comment'.  Following the link
>> will display the text of the comment in a pop-up buffer.  The
>> buffer is in special-mode, hit "q" to dismiss it.
>>
>> Call `org-comment-display-comments' to see all comments in a buffer.
>>
>> See the `org-comment-[backend]-export-style' options for ways to
>> format comments in export.
>>
>> TODO:
>>
>> 1. Better export customization options.
>> 2. What does the ODT comment XML look like?
>> 3. More functions in the display comment buffer: copy as
>> kill... what else?
>> 4. More functions in the comments list buffer, to display, pop to,
>> delete, and edit comment text.
>> 5. Is it possible to have multi-line filled tabular list items?
>> Long comments are not very useful if you can't see the whole thing.
>> 5. Allow multiple comment list buffers attached to different Org
>> buffers.
>> 6. Maybe a minor mode for ease of manipulating comments?
>
> --
> 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

Re: Marking/highlighting text temporarily

[John Kitchin]

Eric Abrahamsen writes:

> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> Hi Eric,
>>
>> I added some functions in the attachment. they colorize the comments,
>> add an org-comment menu to the org-menu, and some functions for pop to
>> and delete comments from the list mode, and a hydra for commands to
>> insert comments. Do you want to get this up on github to facilitate
>> developing it?
>
> Oh great! Thanks a lot. We are duplicating effort a bit here (but only a
> bit, I'd also written display/delete functions for the list buffer), so
> yes, it would be good to coordinate development.
>
> I suppose it depends a bit on where this is going to end up: I'm
> assuming either org/contrib/lisp, or else as an Elpa package. I don't
> see much difference, except in terms of accessibility to contributors --
> I don't have access to the Org repo, but putting it there might get more
> contributors on balance. As a package only I would have direct access.
> What do you think?

I think on github you can give others direct access, or respond to pull
requests. Either way works.

>
> The hydra thing is interesting -- I wasn't aware of that package. Better
> not to require it unconditionally though, right?

You could make this conditional if hydra is installed. It is
sufficiently simple that you could leave it out too.

>
> Thanks,
> Eric
>
>> Eric Abrahamsen writes:
>>
>>> Eric Abrahamsen
>>
>>
>>  <eric@ericabrahamsen.net> writes:
>>>
>>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>>
>>>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>>>     wrote:
>>>>>
>>>>>     Inspired by this conversation, I hacked up this functional comment
>>>>>     link:
>>>>>
>>>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>>>
>>>>>
>>>>>     It has a custom link type that exports in html and latex, and when
>>>>>     you click on it, it asks if you want to delete the comment.
>>>>>
>>>>> Nice. One small issue is that when I highlight a text and add comment
>>>>> to it, and then delete the comment, one space following the last word
>>>>> is removed.
>>>>>
>>>>> Also, it would be good to make the comment stand out in LaTeX (and
>>>>> other) exports, preferably by pushing it to the margin (so it does not
>>>>> move everything else).
>>>>
>>>> Hang on a bit, I'm wasting my afternoon expanding this...
>>>
>>> Okay, this is as far as I got today. I changed some behavior from John's
>>> implementation: when following the links, it seemed like displaying the
>>> comment text would be more useful than deleting it -- I think many of us
>>> have "delete-org-link" functions lying around. I also couldn't get the
>>> add-comment thing to work, as it complained when there was no region, so
>>> I changed how that works.
>>>
>>> Lastly, I spent most of my time learning how tabular list mode works,
>>> and haven't actually tested the export. Will save that for tomorrow.
>>> Otherwise, here's the introduction from the Commentary. Comments and
>>> suggestions very welcome!
>>>
>>>
>>>
>>> Provides a new link type for Org that allows you to create comments
>>> on arbitrary chunks of text.  The link prefix is "comment:".
>>>
>>> Add comments with `org-comment-add-comment'.  Following the link
>>> will display the text of the comment in a pop-up buffer.  The
>>> buffer is in special-mode, hit "q" to dismiss it.
>>>
>>> Call `org-comment-display-comments' to see all comments in a buffer.
>>>
>>> See the `org-comment-[backend]-export-style' options for ways to
>>> format comments in export.
>>>
>>> TODO:
>>>
>>> 1. Better export customization options.
>>> 2. What does the ODT comment XML look like?
>>> 3. More functions in the display comment buffer: copy as
>>> kill... what else?
>>> 4. More functions in the comments list buffer, to display, pop to,
>>> delete, and edit comment text.
>>> 5. Is it possible to have multi-line filled tabular list items?
>>> Long comments are not very useful if you can't see the whole thing.
>>> 5. Allow multiple comment list buffers attached to different Org
>>> buffers.
>>> 6. Maybe a minor mode for ease of manipulating comments?
>>
>> --
>> 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

--
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

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Eric Abrahamsen writes:
>
>> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>>
>>> Hi Eric,
>>>
>>> I added some functions in the attachment. they colorize the comments,
>>> add an org-comment menu to the org-menu, and some functions for pop to
>>> and delete comments from the list mode, and a hydra for commands to
>>> insert comments. Do you want to get this up on github to facilitate
>>> developing it?
>>
>> Oh great! Thanks a lot. We are duplicating effort a bit here (but only a
>> bit, I'd also written display/delete functions for the list buffer), so
>> yes, it would be good to coordinate development.
>>
>> I suppose it depends a bit on where this is going to end up: I'm
>> assuming either org/contrib/lisp, or else as an Elpa package. I don't
>> see much difference, except in terms of accessibility to contributors --
>> I don't have access to the Org repo, but putting it there might get more
>> contributors on balance. As a package only I would have direct access.
>> What do you think?
>
> I think on github you can give others direct access, or respond to pull
> requests. Either way works.

Sure, but even if it's on Github, there's still the question of how we
make it available to users. That will probably influence how we handle
development. If it's in contrib, for instance, it probably just makes
more sense for people to send patches to this list.

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.

Thanks!
Eric

>>
>> The hydra thing is interesting -- I wasn't aware of that package. Better
>> not to require it unconditionally though, right?
>
> You could make this conditional if hydra is installed. It is
> sufficiently simple that you could leave it out too.
>
>>
>> Thanks,
>> Eric
>>
>>> Eric Abrahamsen writes:
>>>
>>>> Eric Abrahamsen
>>>
>>>
>>>  <eric@ericabrahamsen.net> writes:
>>>>
>>>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>>>
>>>>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>>>>     wrote:
>>>>>>
>>>>>>     Inspired by this conversation, I hacked up this functional comment
>>>>>>     link:
>>>>>>
>>>>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>>>>
>>>>>>
>>>>>>     It has a custom link type that exports in html and latex, and when
>>>>>>     you click on it, it asks if you want to delete the comment.
>>>>>>
>>>>>> Nice. One small issue is that when I highlight a text and add comment
>>>>>> to it, and then delete the comment, one space following the last word
>>>>>> is removed.
>>>>>>
>>>>>> Also, it would be good to make the comment stand out in LaTeX (and
>>>>>> other) exports, preferably by pushing it to the margin (so it does not
>>>>>> move everything else).
>>>>>
>>>>> Hang on a bit, I'm wasting my afternoon expanding this...
>>>>
>>>> Okay, this is as far as I got today. I changed some behavior from John's
>>>> implementation: when following the links, it seemed like displaying the
>>>> comment text would be more useful than deleting it -- I think many of us
>>>> have "delete-org-link" functions lying around. I also couldn't get the
>>>> add-comment thing to work, as it complained when there was no region, so
>>>> I changed how that works.
>>>>
>>>> Lastly, I spent most of my time learning how tabular list mode works,
>>>> and haven't actually tested the export. Will save that for tomorrow.
>>>> Otherwise, here's the introduction from the Commentary. Comments and
>>>> suggestions very welcome!
>>>>
>>>>
>>>>
>>>> Provides a new link type for Org that allows you to create comments
>>>> on arbitrary chunks of text.  The link prefix is "comment:".
>>>>
>>>> Add comments with `org-comment-add-comment'.  Following the link
>>>> will display the text of the comment in a pop-up buffer.  The
>>>> buffer is in special-mode, hit "q" to dismiss it.
>>>>
>>>> Call `org-comment-display-comments' to see all comments in a buffer.
>>>>
>>>> See the `org-comment-[backend]-export-style' options for ways to
>>>> format comments in export.
>>>>
>>>> TODO:
>>>>
>>>> 1. Better export customization options.
>>>> 2. What does the ODT comment XML look like?
>>>> 3. More functions in the display comment buffer: copy as
>>>> kill... what else?
>>>> 4. More functions in the comments list buffer, to display, pop to,
>>>> delete, and edit comment text.
>>>> 5. Is it possible to have multi-line filled tabular list items?
>>>> Long comments are not very useful if you can't see the whole thing.
>>>> 5. Allow multiple comment list buffers attached to different Org
>>>> buffers.
>>>> 6. Maybe a minor mode for ease of manipulating comments?
>>>
>>> --
>>> 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
>
> --
> 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

Re: Marking/highlighting text temporarily

[Rasmus]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Would this be eligible?

Not that my .02€ are worth much, but I think the idea of inline notes is
good, but I don't think it should be done using links.  See e.g. the
discussion on citation which introduced a [cite:⋯] command.  A [comment:⋯]
command would also IMO make much more sense than [[comment:X][Y]] as was
allowed last time I read your patch (in the weekend, I think).

On inclusion in contrib I think you can put anything org-ish there.  It's
better if the copyright is cleared in case we want to make it part of
core, but it's not necessary.  There's little difference between core and
contrib as neither are included in Emacs and thus are hard to rely on.

Since you use cl-lib (last I checked) it could not be part of Org before
8.4.

Cheers,
Rasmus

-- 
A page of history is worth a volume of logic

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Rasmus <rasmus@gmx.us> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Would this be eligible?
>
> Not that my .02€ are worth much, but I think the idea of inline notes is
> good, but I don't think it should be done using links.  See e.g. the
> discussion on citation which introduced a [cite:⋯] command.  A [comment:⋯]
> command would also IMO make much more sense than [[comment:X][Y]] as was
> allowed last time I read your patch (in the weekend, I think).

Wow, I just went back and looked at the cite thread. That was
bewildering. I don't see a direct connection here, though -- cite was
needed for very specific academic purposes, with very clearly-defined
needs. Comment is much floppier: good for anything from notes-to-self,
to notes-to-editor, to notes-to-no-one.

*None* of the complexity is in the format itself: if you unloaded
org-comment, the comment links would be perfectly human-readable. All of
the complexity is in helper functions for manipulating them. I suppose
it would be possible to define some non-link syntax for them, but why do
that when the link syntax works perfectly well?

> On inclusion in contrib I think you can put anything org-ish there.  It's
> better if the copyright is cleared in case we want to make it part of
> core, but it's not necessary.  There's little difference between core and
> contrib as neither are included in Emacs and thus are hard to rely on.
>
> Since you use cl-lib (last I checked) it could not be part of Org before
> 8.4.

Ah, that's a good point. cl-lib isn't necessary, just convenient, and
could be removed.

Thanks,
Eric

Re: Marking/highlighting text temporarily

[Rasmus]

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> *None* of the complexity is in the format itself: if you unloaded
> org-comment, the comment links would be perfectly human-readable. All of
> the complexity is in helper functions for manipulating them. I suppose
> it would be possible to define some non-link syntax for them, but why do
> that when the link syntax works perfectly well?

Because [[comment:X][Y]] is displayed (by default) as "Y" which can be
misleading as X and Y grow out of sync.  Perhaps I'm wrong, but I see no
point in "Y" for a comment.  Further, nasty stuff is sometimes applied to
X such as escaping spaces.  In addition, export filters cannot easily be
pointed to links (you'd have to make a check on the type of link), and you
need a bit more hassle to map over them with org-element etc.  Again,
that's just my opinion so feel free to ignore it!

> Ah, that's a good point. cl-lib isn't necessary, just convenient, and
> could be removed.

It's only a concern if you want to advocate for including this in Org 8.3.

Cheers,
Rasmus

-- 
Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!

Re: Marking/highlighting text temporarily

[John Kitchin]

Rasmus writes:

> Hi Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> *None* of the complexity is in the format itself: if you unloaded
>> org-comment, the comment links would be perfectly human-readable. All of
>> the complexity is in helper functions for manipulating them. I suppose
>> it would be possible to define some non-link syntax for them, but why do
>> that when the link syntax works perfectly well?
>
> Because [[comment:X][Y]] is displayed (by default) as "Y" which can be
> misleading as X and Y grow out of sync.  Perhaps I'm wrong, but I see no
> point in "Y" for a comment.  Further, nasty stuff is sometimes applied to
> X such as escaping spaces.  In addition, export filters cannot easily be
> pointed to links (you'd have to make a check on the type of link), and you
> need a bit more hassle to map over them with org-element etc.  Again,
> that's just my opinion so feel free to ignore it!

I would mostly use comments in a transient way during an editing
process. e.g. I expect my students to delete my comments after they have
addressed them, otherwise, they are out of sync. The only point of Y in
the syntax above is to attach the comment to the text as opposed to just
having an inline comment.

There could be reasons to want super good export, but my main use case
is in collaborative editing of org-source, and i would expect in the
final version for there to be no remaining comments. There are still
reasons to have annotations present, e.g. as tooltips, or file
attachments in exported content though, so your point is a good one that
funny things may happen with a link type solution.

>
>> Ah, that's a good point. cl-lib isn't necessary, just convenient, and
>> could be removed.
>
> It's only a concern if you want to advocate for including this in Org 8.3.
>
> Cheers,
> 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

Re: Marking/highlighting text temporarily

[John Kitchin]

Eric Abrahamsen writes:

> Rasmus <rasmus@gmx.us> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Would this be eligible?
>>
>> Not that my .02€ are worth much, but I think the idea of inline notes is
>> good, but I don't think it should be done using links.  See e.g. the
>> discussion on citation which introduced a [cite:⋯] command.  A [comment:⋯]
>> command would also IMO make much more sense than [[comment:X][Y]] as was
>> allowed last time I read your patch (in the weekend, I think).
>
> Wow, I just went back and looked at the cite thread. That was
> bewildering. I don't see a direct connection here, though -- cite was
> needed for very specific academic purposes, with very clearly-defined
> needs. Comment is much floppier: good for anything from notes-to-self,
> to notes-to-editor, to notes-to-no-one.
>
> *None* of the complexity is in the format itself: if you unloaded
> org-comment, the comment links would be perfectly human-readable. All of
> the complexity is in helper functions for manipulating them. I suppose
> it would be possible to define some non-link syntax for them, but why do
> that when the link syntax works perfectly well?

The only reason I can see (coming from someone who uses links liberally
for other purposes ;) is just to avoid the hacks required to get extra
functionality, e.g. as you alluded to applying different faces, storing
additional information (author, timestamp, etc...), avoiding a need to
add a link type-checking for collecting comments (although, this is not
a very difficult step).

On the link side, they work perfectly well for the simplest kind of
comment, and because of that, there is a working prototype already. But,
I think extending it beyond this will require the hackery described
above. I don't have a sense if it is more work than defining a new
syntax, or the long term maintenance costs of that approach. For me, it
is work I already know how to do. I admit though, that does not mean it
is better than a new syntax ;)

Maybe a study of the cite syntax code would clarify the differences. Can
anyone point me to a code repository where we could read that code?

>
>> On inclusion in contrib I think you can put anything org-ish there.  It's
>> better if the copyright is cleared in case we want to make it part of
>> core, but it's not necessary.  There's little difference between core and
>> contrib as neither are included in Emacs and thus are hard to rely on.
>>
>> Since you use cl-lib (last I checked) it could not be part of Org before
>> 8.4.
>
> Ah, that's a good point. cl-lib isn't necessary, just convenient, and
> could be removed.
>
> Thanks,
> 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

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> 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.


Regards,

-- 
Nicolas Goaziou

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> 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

Re: Marking/highlighting text temporarily

[Rasmus]

Hi,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Just to be clear, you think it fits into the category of
> incubation-prior-to-core?

I think inlinetasks/comments that are actually *inline* would be nice!

> 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.

See my other post.  In addition you'd need to be able to turn them off via

    #+OPTIONS: annotations:nil
    
> I'll admit I have dreamed of a syntax that looks like: [[body text to
> annotate][TODO:Look this up on the internet:@work]].

I don't like the example.  The ordering is weird.  Do the first and the
second bracket need to be tied together?  Or would something like this
work:

      body text to annotate [todo@work: Look this up on the internet]

Or 

    [todo@work: Look this up on the internet]{body text to annotate}
    [todo@work look this up on the internet: body text to annotate]

—Rasmus

-- 
With monopolies the cake is a lie!

Re: Marking/highlighting text temporarily

[Eric S Fraga]

Hello all,

I have been following this whole thread with great interest, having
posted very early on the use of inline tasks as a solution for the OP.

I use inline tasks a lot for both annotations and for TODO tasks when
writing papers.  I like the link syntax proposed but would much prefer
something that includes tasks as well as comments.

What is missing, by the way, with the proposed link based comment syntax
that inline tasks give is the ability to find them quickly within a
(large) document.  Maybe I missed this functionality in what has been
proposed.  Inline tasks are easy to find using C-c / t...

And to add to yet another element of the discussion, I have no problem
with the [[comment:X][Y]] in the sense of X being hidden in normal view.

Back to your regular programming :)

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64

Re: Marking/highlighting text temporarily

[John Kitchin]

Eric S Fraga writes:

> Hello all,
>
> I have been following this whole thread with great interest, having
> posted very early on the use of inline tasks as a solution for the OP.
>
> I use inline tasks a lot for both annotations and for TODO tasks when
> writing papers.  I like the link syntax proposed but would much prefer
> something that includes tasks as well as comments.
>
> What is missing, by the way, with the proposed link based comment syntax
> that inline tasks give is the ability to find them quickly within a
> (large) document.  Maybe I missed this functionality in what has been
> proposed.  Inline tasks are easy to find using C-c / t...

There is in org-comment a command `org-comment-display-comments' which
will generate a buffer you can see all the comments in, and from that
pop to a comment, delete it, etc...

>
> And to add to yet another element of the discussion, I have no problem
> with the [[comment:X][Y]] in the sense of X being hidden in normal view.
>
> Back to your regular programming :)
>
> thanks,
> 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

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Wednesday, 29 Apr 2015 at 10:00, John Kitchin wrote:

[...]

> There is in org-comment a command `org-comment-display-comments' which
> will generate a buffer you can see all the comments in, and from that
> pop to a comment, delete it, etc...

Ah, thanks.  That's good.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Rasmus <rasmus@gmx.us> writes:

> Hi,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Just to be clear, you think it fits into the category of
>> incubation-prior-to-core?
>
> I think inlinetasks/comments that are actually *inline* would be nice!
>
>> 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.
>
> See my other post.  In addition you'd need to be able to turn them off via
>
>     #+OPTIONS: annotations:nil
>     
>
>> I'll admit I have dreamed of a syntax that looks like: [[body text to
>> annotate][TODO:Look this up on the internet:@work]].
>
> I don't like the example.  The ordering is weird.  Do the first and the
> second bracket need to be tied together?  Or would something like this
> work:
>
>       body text to annotate [todo@work: Look this up on the internet]
>
> Or 
>
>     [todo@work: Look this up on the internet]{body text to annotate}
>     [todo@work look this up on the internet: body text to annotate]

Okay, so you're basically proposing taking this to a much higher level.
I'm totally in favor, in principle, and don't actually care too much
what the actual syntax looks like. I do think it would be important to
specify the text being annotated, so your first example above wouldn't
be too ideal. The others I'd be happy with.

As the veteran of several small projects that have died of mission
creep, I still wouldn't mind keeping org-comments (I do think it should
be renamed org-annotate) as-is, and letting the "real" inline todo
project progress separately.

Eric

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote:

[...]

> Yup, "annotation mechanism" is about right. Just to be clear, you think
> it fits into the category of incubation-prior-to-core?

[...]

> Now I wish we'd named it org-annotate.

Is it too late?  Simple refactoring of the code?

I find org-annotate more expressive of its purpose and doesn't conflict
with e.g. org-toggle-comment...
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote:
>
> [...]
>
>> Yup, "annotation mechanism" is about right. Just to be clear, you think
>> it fits into the category of incubation-prior-to-core?
>
> [...]
>
>> Now I wish we'd named it org-annotate.
>
> Is it too late?  Simple refactoring of the code?
>
> I find org-annotate more expressive of its purpose and doesn't conflict
> with e.g. org-toggle-comment...

No, it's definitely not too late. Depending on the outcome of this whole
conversation, I'd like to rename it.

Re: Marking/highlighting text temporarily

[John Kitchin]

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 <mail@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> Eric Abrahamsen <eric@ericabrahamsen.net> 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

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Yup, "annotation mechanism" is about right. Just to be clear, you think
> it fits into the category of incubation-prior-to-core?

I think so.

> If anyone thinks that this mechanism warrants actual new Org syntax, I'd
> be happy to work on implementing that.

I also think a new syntax is needed. But, please, let's keep it as
simple as possible.


Regards,

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Yup, "annotation mechanism" is about right. Just to be clear, you think
>> it fits into the category of incubation-prior-to-core?
>
> I think so.
>
>> If anyone thinks that this mechanism warrants actual new Org syntax, I'd
>> be happy to work on implementing that.
>
> I also think a new syntax is needed. But, please, let's keep it as
> simple as possible.

We're just talking about annotations-plus-metadata here, right? Not
actual in-text TODOs?

From what I can tell, rasmus seems to be proposing an in-text TODO,
while John's headed in the direction of replicating Track Changes
functionality. I've definitely wanted some sort of a track changes
equivalent in Org, but we'd want to be careful about this.

Assuming we're just talking about annotations on steriods, here are some
things I'd personally like to have:

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).
2. Plain annotation: just a chunk of free-form paragraph text that is
   attached to the buffer text.
3. Replacement text: an alternate version of the buffer text; this could
   be the basis of track changes stuff.
4. Timestamps
5. Custom highlighting
6. Full element status: this would allow parsing of the various
   properties, and more fully-featured export options.
7. "Author" metadata would probably be unnecessary with full access to
   the export channels, but it might still be desirable.
8. Options-line switches to export with annotation, export without
   annotation, and export using replacement text.

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.

Eric

Re: Marking/highlighting text temporarily

[Rasmus]

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

     [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).

—Rasmus

-- 
A clever person solves a problem. A wise person avoids it

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Thursday, 30 Apr 2015 at 11:58, Rasmus wrote:

[...]

>> 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

I'm 100% with you on this.

One of the most important aspects of org is that it is all text and
existing and powerful revision control systems can be used with any org
file.  Let's not go down the "everything including the kitchen sink"
approach as we'll do everything badly and nothing well (i.e. end up with
an MS Word look-a-like...).

Let's keep things simple.

Anyway, that's my opinion.  Obviously, nobody is going to force me to
use org-annotate for tracking changes but my concern is feature creep
leading to a mess...

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64

Re: Marking/highlighting text temporarily

[John Kitchin]

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

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Rasmus <rasmus@gmx.us> 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
>
>      [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

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> 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

Re: Marking/highlighting text temporarily

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> 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!

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

> 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.

We can implement a function in org-annotate.el to remove an annotation.
You don't need to do it by hand.

> But note that I am more interested in an inline noting/todo functionality
> as opposed to annotation functionality.

Inline noting is


    Text[@:1][@]

  * Annotations

  [@:1:] My note.

I don't know what is a TODO functionality since you suggest to not make
it appear in the agenda.

> 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.

Again, not with proper tooling, e.g, remote editing like footnotes.

Regards,

Re: Marking/highlighting text temporarily

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> But note that I am more interested in an inline noting/todo functionality
>> as opposed to annotation functionality.
>
> Inline noting is
>
>
>     Text[@:1][@]
>
>   * Annotations
>
>   [@:1:] My note.

My guess would be that most notes are short.  For such notes, but not
necessarily for longer notes, [@:NOTE] would be more convenient.  Though I
don't know what the "@" signifies.  I think whatever is the value of
#+TODO makes more sense as prefixes.

I don't think it would be easy to convince coauthors of documents, who are
not using Emacs, that this is something "easy" to use.  I guess not many
people do XML in Nano or Notepad, since keeping track of opening and
closing tags is a pain.

Formatting tags, e.g. *, are somehow natural and shorter.  Blocks are
"easy" to see.

> I don't know what is a TODO functionality since you suggest to not make
> it appear in the agenda.

E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]".  I
don't need that in my agenda.

>> 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.
>
> Again, not with proper tooling, e.g, remote editing like footnotes.

But this is a change to the *format*, not its principal editor.

—Rasmus

-- 
Er du tosset for noge' lårt!

Re: Marking/highlighting text temporarily

[Eric S Fraga]

On Monday, 18 May 2015 at 15:16, Rasmus wrote:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

[...]

>> I don't know what is a TODO functionality since you suggest to not make
>> it appear in the agenda.
>
> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]".  I
> don't need that in my agenda.

Exactly.  I use inlinetasks a lot for file local TODO items that are not
meant to appear in my agenda.  They are notes for things I need to do,
typically, to finish a paper.  Being able to "C-c / t" to find them all
easily is great.  I would expect the same functionality from any
replacement.

In terms of format, I also dislike opening and closing tags except for
short formatting uses.  I would prefer [COMMENT: this is very
interesting] and [TODO: I need to update this].  Or even [[TODO:...]] to
be less worried about running into problems with text use of [...].  But
I think that's already been dismissed...

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062

Re: Marking/highlighting text temporarily

[Rasmus]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Monday, 18 May 2015 at 15:16, Rasmus wrote:
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>> I don't know what is a TODO functionality since you suggest to not make
>>> it appear in the agenda.
>>
>> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]".  I
>> don't need that in my agenda.
>
> Exactly.  I use inlinetasks a lot for file local TODO items that are not
> meant to appear in my agenda.  They are notes for things I need to do,
> typically, to finish a paper.  Being able to "C-c / t" to find them all
> easily is great.  I would expect the same functionality from any
> replacement.

Would it be bad if I admit I have no idea how to use sparse trees?  The
remind me of Vim, except in Vim i eventually figured out that I could quit
it via :q.

I would probably use occur or a restricted agenda.

I would want inlinetodos in my "global"/usual agenda.

> In terms of format, I also dislike opening and closing tags except for
> short formatting uses.  I would prefer [COMMENT: this is very
> interesting] and [TODO: I need to update this].  Or even [[TODO:...]] to
> be less worried about running into problems with text use of [...].

I think [[TODO:]] is a link...

Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

Rasmus <rasmus@gmx.us> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Monday, 18 May 2015 at 15:16, Rasmus wrote:
>>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>>> I don't know what is a TODO functionality since you suggest to not make
>>>> it appear in the agenda.
>>>
>>> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]".  I
>>> don't need that in my agenda.
>>
>> Exactly.  I use inlinetasks a lot for file local TODO items that are not
>> meant to appear in my agenda.  They are notes for things I need to do,
>> typically, to finish a paper.  Being able to "C-c / t" to find them all
>> easily is great.  I would expect the same functionality from any
>> replacement.
>
> Would it be bad if I admit I have no idea how to use sparse trees?  The
> remind me of Vim, except in Vim i eventually figured out that I could quit
> it via :q.
>
> I would probably use occur or a restricted agenda.
>
> I would want inlinetodos in my "global"/usual agenda.
>
>> In terms of format, I also dislike opening and closing tags except for
>> short formatting uses.  I would prefer [COMMENT: this is very
>> interesting] and [TODO: I need to update this].  Or even [[TODO:...]] to
>> be less worried about running into problems with text use of [...].
>
> I think [[TODO:]] is a link...

We're coming back around to the beginning of the conversation!

I still think we started off talking about two different things. One is
a replacement for inlinetasks that's actually inline. The other is an
annotation system that could be used for collaboration, and might be
taking aim at Track Changes in some way. It looks like we've gone off in
the inlinetasks direction.

I'll admit that what I really want is an honest-to-goodness
first-class-citizen inline TODO. Something attached to a specific run of
text, that has a TODO keyword and tags. Probably scheduling? Probably
not properties, I don't know. Personally I'd prefer that the contents of
the TODO were hidden (a la links), because (like Eric F) I would use
this for notes on pieces of writing, and having big ugly chunks of
highlighted spaghetti in the middle of a paragraph makes it hard to
write.

How technically difficult would that be? If it slows down agenda
creation too badly, maybe we could have a user option that defaults to
skipping inline todos in agenda creation.

I was lukewarm about Nicolas' earlier syntax proposal because it simply
doesn't seem distinct enough from footnotes.

Just some random reactions,
Eric

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

> My guess would be that most notes are short.  For such notes, but not
> necessarily for longer notes, [@:NOTE] would be more convenient.

This is very limited: you cannot write two paragraphs in your note.

> Though I don't know what the "@" signifies. 

AnnoTate?

> I think whatever is the value of #+TODO makes more sense as prefixes.

You turn every annotation into a task. Again, this is very restrictive.

> I don't think it would be easy to convince coauthors of documents, who are
> not using Emacs, that this is something "easy" to use.  I guess not many
> people do XML in Nano or Notepad, since keeping track of opening and
> closing tags is a pain.

My sole focus is Emacs users, tho.

> Formatting tags, e.g. *, are somehow natural and shorter.  Blocks are
> "easy" to see.
>
>> I don't know what is a TODO functionality since you suggest to not make
>> it appear in the agenda.
>
> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]".  I
> don't need that in my agenda.

Since you're talking about "TODO functionality", what features would
this share with regular tasks, defined with headlines or inlinetasks?

> But this is a change to the *format*, not its principal editor.

Do you think tables are particularly nice to write if you work outside
of Org mode? There is no clause about being easy to edit from Nano in
Org.

Anyway, we're speaking of two different things, e.g., I think it's
important to be able to mark exactly which part of the document you're
annotating. [TODO: ...] cannot do that.


Regards,

Re: Marking/highlighting text temporarily

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> My guess would be that most notes are short.  For such notes, but not
>> necessarily for longer notes, [@:NOTE] would be more convenient.
>
> This is very limited: you cannot write two paragraphs in your note.

Fine whit me.  For that I I have inlinetasks.

>> Though I don't know what the "@" signifies. 
>
> AnnoTate?

I did not see that coming.  That's a "meh" from me :)

>> I think whatever is the value of #+TODO makes more sense as prefixes.
>
> You turn every annotation into a task. Again, this is very restrictive.

I don't think so, e.g.

#+TODO: DISCUSS DISAGREE | RESOLVED DROPPED

And judging from the manual people are doing much more complicated stuff
than that (my usage is pretty simple).

> Since you're talking about "TODO functionality", what features would
> this share with regular tasks, defined with headlines or inlinetasks?

The tags.  They are notes related to say a sentence, so you put a note at
the end of a sentence.  Spatial TODOs.

> Anyway, we're speaking of two different things, e.g., I think it's
> important to be able to mark exactly which part of the document you're
> annotating.

I agree they are different.

> [TODO: ...] cannot do that.

Its virtues are compactness, being similar to a list, being C-k friendly,
and, IMO, more intuitive.

–Rasmus

-- 
There are known knowns; there are things we know that we know

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

> Fine whit me.  For that I I have inlinetasks.

Then it cannot even replace inlinetasks.

> The tags.  They are notes related to say a sentence, so you put a note at
> the end of a sentence.  Spatial TODOs.

I still don't get it, sorry.

> Its virtues are compactness, being similar to a list, being C-k friendly,
> and, IMO, more intuitive.

But, IMO, totally useless for general annotations.

This probably means they shouldn't share the same syntax. Note I'm all
for replacing inlinetasks with something else (i.e., change syntax),
albeit this is no simple task.

However, that was not my proposal.


Regards,

Re: Marking/highlighting text temporarily

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> Fine whit me.  For that I I have inlinetasks.
>
> Then it cannot even replace inlinetasks.

Is that a goal?

>> Its virtues are compactness, being similar to a list, being C-k friendly,
>> and, IMO, more intuitive.
>
> But, IMO, totally useless for general annotations.

I think "totally useless" stretching it.  Two examples.

   [@:1] My sentence on foo [@] and something else

   * Annotations
     [@:1:Nicolas] Remember to refer to bar


     #+TODO: Notes/Nicolas
     My sentence on foo [Notes/Nicolas: Remember to refer to bar] and
     something else.

The latter is less precise, but I would still prefer it.  I guess you
could add references to an endnote for long notes, which would bring it
closer to killing org-inlinetasks.

> This probably means they shouldn't share the same syntax. Note I'm all
> for replacing inlinetasks with something else (i.e., change syntax),
> albeit this is no simple task.

I don't particularly care for them either.

—Rasmus

-- 
This space is left intentionally blank

Re: Marking/highlighting text temporarily

[Eric S Fraga]

Hi all,

Actually, having pondered this whole annotation and task business while
heading home after work on the train, I think all I would like is a
simple annotation scheme with no need for tasks etc.  We have plenty of
support for tasks with headlines.  What we don't have is simple
annotations.

I use inlinetasks for annotations yet these are clumsy, as we have seen.

What the notation for annotations should be I leave to others,
especially those that might implement something.  However, it should
allow for hiding of annotations while editing an org buffer, it should
be possible to list all annotations (sparse tree functionality), to jump
from one to the next and it should provide the hooks for exporting in
various ways, with customisable formatting.

Just my 2¢ worth.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1147-g0e5069.dirty

Re: Marking/highlighting text temporarily

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> Then it cannot even replace inlinetasks.
>
> Is that a goal?

It should be. 

We don't need another syntax for something that does almost the same
thing as an inlinetask but, yet, isn't one. Inline todo/inlinetasks,
there can only be one.

> I think "totally useless" stretching it.  Two examples.
>
>    [@:1] My sentence on foo [@] and something else
>
>    * Annotations
>      [@:1:Nicolas] Remember to refer to bar
>
>
>      #+TODO: Notes/Nicolas
>      My sentence on foo [Notes/Nicolas: Remember to refer to bar] and
>      something else.
>
> The latter is less precise, but I would still prefer it.  I guess you
> could add references to an endnote for long notes, which would bring it
> closer to killing org-inlinetasks.

I think you are missing my point. 

My goal is to be able to /mark/ a very specific part of the document
(ranging from a word to a whole section). Your syntax cannot achieve
that, because you need two markers, one at the beginning and one at the
end of the area you need to mark. This is a dead-end.

Also, I don't want to clutter the document with annotations, hence
moving them to a specific section, while retaining a minimal syntax in
the document.

No matter how much you like it, your syntax isn't general enough for
annotations. This is understandable, since you're after inline TODO, not
annotations.

Regards,

Re: Marking/highlighting text temporarily

[Eric Abrahamsen]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Hi Eric,
>
> I added some functions in the attachment. they colorize the comments,
> add an org-comment menu to the org-menu, and some functions for pop to
> and delete comments from the list mode, and a hydra for commands to
> insert comments. Do you want to get this up on github to facilitate
> developing it?

Okay, either way, it's on Github now:

https://github.com/girzel/org-comment.git

I didn't realize you could use markers as ids in tabular list mode, that
made things a lot easier. I've removed the hydra stuff for now, and also
am not automatically turning on the highlighting. I'm still considering
a minor mode or something, or at least install it as an Org mode hook.

Eric

> Eric Abrahamsen writes:
>
>> Eric Abrahamsen
>
>
>  <eric@ericabrahamsen.net> writes:
>>
>>> Vikas Rawal <vikaslists@agrarianresearch.org> writes:
>>>
>>>>     On 25-Apr-2015, at 6:22 am, John Kitchin <jkitchin@andrew.cmu.edu>
>>>>     wrote:
>>>>
>>>>     Inspired by this conversation, I hacked up this functional comment
>>>>     link:
>>>>
>>>>     http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/
>>>>
>>>>
>>>>     It has a custom link type that exports in html and latex, and when
>>>>     you click on it, it asks if you want to delete the comment.
>>>>
>>>> Nice. One small issue is that when I highlight a text and add comment
>>>> to it, and then delete the comment, one space following the last word
>>>> is removed.
>>>>
>>>> Also, it would be good to make the comment stand out in LaTeX (and
>>>> other) exports, preferably by pushing it to the margin (so it does not
>>>> move everything else).
>>>
>>> Hang on a bit, I'm wasting my afternoon expanding this...
>>
>> Okay, this is as far as I got today. I changed some behavior from John's
>> implementation: when following the links, it seemed like displaying the
>> comment text would be more useful than deleting it -- I think many of us
>> have "delete-org-link" functions lying around. I also couldn't get the
>> add-comment thing to work, as it complained when there was no region, so
>> I changed how that works.
>>
>> Lastly, I spent most of my time learning how tabular list mode works,
>> and haven't actually tested the export. Will save that for tomorrow.
>> Otherwise, here's the introduction from the Commentary. Comments and
>> suggestions very welcome!
>>
>>
>>
>> Provides a new link type for Org that allows you to create comments
>> on arbitrary chunks of text.  The link prefix is "comment:".
>>
>> Add comments with `org-comment-add-comment'.  Following the link
>> will display the text of the comment in a pop-up buffer.  The
>> buffer is in special-mode, hit "q" to dismiss it.
>>
>> Call `org-comment-display-comments' to see all comments in a buffer.
>>
>> See the `org-comment-[backend]-export-style' options for ways to
>> format comments in export.
>>
>> TODO:
>>
>> 1. Better export customization options.
>> 2. What does the ODT comment XML look like?
>> 3. More functions in the display comment buffer: copy as
>> kill... what else?
>> 4. More functions in the comments list buffer, to display, pop to,
>> delete, and edit comment text.
>> 5. Is it possible to have multi-line filled tabular list items?
>> Long comments are not very useful if you can't see the whole thing.
>> 5. Allow multiple comment list buffers attached to different Org
>> buffers.
>> 6. Maybe a minor mode for ease of manipulating comments?
>
> --
> 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

Re: Marking/highlighting text temporarily

[Eric S Fraga]

John,

thanks for this.  Very nice.  And I can use my preferred LaTeX
annotation with it easily.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64

Re: Marking/highlighting text temporarily

[Marcin Borkowski]

On 2015-04-24, at 08:19, Vikas Rawal <vikaslists@agrarianresearch.org> wrote:

> I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with.
>
> What could be an the easy way of doing it?

Well, it seems that the thread went somewhere else (completely), but it
just occured to me that you might want Bookmark+ (in case nobody
mentioned it).  You have normal Emacs bookmarks but on Drew-steroids,
among others you can /highlight/ all bookmarks in a buffer.  (And AFAIR
you can have a dedicated bookmark file for e.g. one project, so that you
effectively have "categories" of bookmarks.)

> Vikas

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Marking/highlighting text temporarily

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 2015-05-18 23:42, Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-04-24, at 08:19, Vikas Rawal <vikaslists@agrarianresearch.org> wrote:
>
>> I am revising a long book manuscript, and would like to mark parts of text
>> (not just the headlines) just to remind myself that these need to be dealt
>> with.
>>
>> What could be an the easy way of doing it?
>
> Well, it seems that the thread went somewhere else (completely), but it
> just occured to me that you might want Bookmark+ (in case nobody
> mentioned it).  You have normal Emacs bookmarks but on Drew-steroids,
> among others you can /highlight/ all bookmarks in a buffer.  (And AFAIR
> you can have a dedicated bookmark file for e.g. one project, so that you
> effectively have "categories" of bookmarks.)

Is it possible to collaborate using this? I guess you would need one
bookmark file per project, and add that file to the repository …

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]