* Marking/highlighting text temporarily
@ 2015-04-24 6:19 Vikas Rawal
2015-04-24 6:42 ` Thomas S. Dye
` (5 more replies)
0 siblings, 6 replies; 65+ messages in thread
From: Vikas Rawal @ 2015-04-24 6:19 UTC (permalink / raw)
To: org-mode mailing list
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
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal @ 2015-04-24 6:42 ` Thomas S. Dye 2015-04-24 7:53 ` Marcin Borkowski 2015-04-24 7:05 ` Glyn Millington ` (4 subsequent siblings) 5 siblings, 1 reply; 65+ messages in thread From: Thomas S. Dye @ 2015-04-24 6:42 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:42 ` Thomas S. Dye @ 2015-04-24 7:53 ` Marcin Borkowski 0 siblings, 0 replies; 65+ messages in thread From: Marcin Borkowski @ 2015-04-24 7:53 UTC (permalink / raw) To: Vikas Rawal, org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal 2015-04-24 6:42 ` Thomas S. Dye @ 2015-04-24 7:05 ` Glyn Millington 2015-04-24 7:13 ` Eric Abrahamsen ` (3 subsequent siblings) 5 siblings, 0 replies; 65+ messages in thread From: Glyn Millington @ 2015-04-24 7:05 UTC (permalink / raw) To: emacs-orgmode 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 ! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal 2015-04-24 6:42 ` Thomas S. Dye 2015-04-24 7:05 ` Glyn Millington @ 2015-04-24 7:13 ` Eric Abrahamsen 2015-04-24 7:19 ` Eric Abrahamsen 2015-04-24 7:38 ` Fabrice Niessen ` (2 subsequent siblings) 5 siblings, 1 reply; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-24 7:13 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 7:13 ` Eric Abrahamsen @ 2015-04-24 7:19 ` Eric Abrahamsen 0 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-24 7:19 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal ` (2 preceding siblings ...) 2015-04-24 7:13 ` Eric Abrahamsen @ 2015-04-24 7:38 ` Fabrice Niessen 2015-04-24 7:40 ` Eric S Fraga 2015-05-18 21:42 ` Marcin Borkowski 5 siblings, 0 replies; 65+ messages in thread From: Fabrice Niessen @ 2015-04-24 7:38 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal ` (3 preceding siblings ...) 2015-04-24 7:38 ` Fabrice Niessen @ 2015-04-24 7:40 ` Eric S Fraga 2015-04-24 7:58 ` Marcin Borkowski 2015-05-18 21:42 ` Marcin Borkowski 5 siblings, 1 reply; 65+ messages in thread From: Eric S Fraga @ 2015-04-24 7:40 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 7:40 ` Eric S Fraga @ 2015-04-24 7:58 ` Marcin Borkowski 2015-04-24 8:48 ` Eric S Fraga 0 siblings, 1 reply; 65+ messages in thread From: Marcin Borkowski @ 2015-04-24 7:58 UTC (permalink / raw) To: Vikas Rawal, org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 7:58 ` Marcin Borkowski @ 2015-04-24 8:48 ` Eric S Fraga 2015-04-24 21:38 ` Vikas Rawal 0 siblings, 1 reply; 65+ messages in thread From: Eric S Fraga @ 2015-04-24 8:48 UTC (permalink / raw) To: Marcin Borkowski; +Cc: org-mode mailing list, Vikas Rawal 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 8:48 ` Eric S Fraga @ 2015-04-24 21:38 ` Vikas Rawal 2015-04-25 0:52 ` John Kitchin 0 siblings, 1 reply; 65+ messages in thread From: Vikas Rawal @ 2015-04-24 21:38 UTC (permalink / raw) To: Eric S Fraga; +Cc: org-mode mailing list > > [...] > >> 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 21:38 ` Vikas Rawal @ 2015-04-25 0:52 ` John Kitchin 2015-04-25 1:34 ` Eric Abrahamsen ` (2 more replies) 0 siblings, 3 replies; 65+ messages in thread From: John Kitchin @ 2015-04-25 0:52 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 0:52 ` John Kitchin @ 2015-04-25 1:34 ` Eric Abrahamsen 2015-04-25 4:13 ` Vikas Rawal 2015-04-25 9:04 ` Eric S Fraga 2 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-25 1:34 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 0:52 ` John Kitchin 2015-04-25 1:34 ` Eric Abrahamsen @ 2015-04-25 4:13 ` Vikas Rawal 2015-04-25 7:47 ` Eric Abrahamsen 2015-04-25 9:04 ` Eric S Fraga 2 siblings, 1 reply; 65+ messages in thread From: Vikas Rawal @ 2015-04-25 4:13 UTC (permalink / raw) To: John Kitchin, org-mode mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 4:13 ` Vikas Rawal @ 2015-04-25 7:47 ` Eric Abrahamsen 2015-04-25 9:08 ` Eric Abrahamsen 0 siblings, 1 reply; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-25 7:47 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 7:47 ` Eric Abrahamsen @ 2015-04-25 9:08 ` Eric Abrahamsen 2015-04-26 18:14 ` John Kitchin 2015-04-27 23:35 ` John Kitchin 0 siblings, 2 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-25 9:08 UTC (permalink / raw) To: emacs-orgmode [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 9:08 ` Eric Abrahamsen @ 2015-04-26 18:14 ` John Kitchin 2015-04-27 6:13 ` Eric Abrahamsen 2015-04-27 23:35 ` John Kitchin 1 sibling, 1 reply; 65+ messages in thread From: John Kitchin @ 2015-04-26 18:14 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-26 18:14 ` John Kitchin @ 2015-04-27 6:13 ` Eric Abrahamsen 2015-04-27 10:27 ` John Kitchin 0 siblings, 1 reply; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-27 6:13 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 6:13 ` Eric Abrahamsen @ 2015-04-27 10:27 ` John Kitchin 2015-04-27 11:11 ` Marcin Borkowski 0 siblings, 1 reply; 65+ messages in thread From: John Kitchin @ 2015-04-27 10:27 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 10:27 ` John Kitchin @ 2015-04-27 11:11 ` Marcin Borkowski 2015-04-27 12:37 ` Eric Abrahamsen 0 siblings, 1 reply; 65+ messages in thread From: Marcin Borkowski @ 2015-04-27 11:11 UTC (permalink / raw) To: emacs-orgmode@gnu.org 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 11:11 ` Marcin Borkowski @ 2015-04-27 12:37 ` Eric Abrahamsen 2015-04-27 12:58 ` John Kitchin 0 siblings, 1 reply; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-27 12:37 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 12:37 ` Eric Abrahamsen @ 2015-04-27 12:58 ` John Kitchin 2015-04-27 13:06 ` Eric Abrahamsen 0 siblings, 1 reply; 65+ messages in thread From: John Kitchin @ 2015-04-27 12:58 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 12:58 ` John Kitchin @ 2015-04-27 13:06 ` Eric Abrahamsen 0 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-27 13:06 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 9:08 ` Eric Abrahamsen 2015-04-26 18:14 ` John Kitchin @ 2015-04-27 23:35 ` John Kitchin 2015-04-28 2:28 ` Eric Abrahamsen 2015-04-28 10:48 ` Eric Abrahamsen 1 sibling, 2 replies; 65+ messages in thread From: John Kitchin @ 2015-04-27 23:35 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 23:35 ` John Kitchin @ 2015-04-28 2:28 ` Eric Abrahamsen 2015-04-28 19:32 ` John Kitchin 2015-04-28 10:48 ` Eric Abrahamsen 1 sibling, 1 reply; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-28 2:28 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-28 2:28 ` Eric Abrahamsen @ 2015-04-28 19:32 ` John Kitchin 2015-04-29 8:41 ` Eric Abrahamsen 0 siblings, 1 reply; 65+ messages in thread From: John Kitchin @ 2015-04-28 19:32 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-28 19:32 ` John Kitchin @ 2015-04-29 8:41 ` Eric Abrahamsen 2015-04-29 9:57 ` Rasmus 2015-04-29 10:39 ` Nicolas Goaziou 0 siblings, 2 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-29 8:41 UTC (permalink / raw) To: emacs-orgmode; +Cc: Nicolas Goaziou 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 8:41 ` Eric Abrahamsen @ 2015-04-29 9:57 ` Rasmus 2015-04-29 12:14 ` Eric Abrahamsen 2015-04-29 10:39 ` Nicolas Goaziou 1 sibling, 1 reply; 65+ messages in thread From: Rasmus @ 2015-04-29 9:57 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 9:57 ` Rasmus @ 2015-04-29 12:14 ` Eric Abrahamsen 2015-04-29 12:31 ` Rasmus 2015-04-29 13:52 ` John Kitchin 0 siblings, 2 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-29 12:14 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:14 ` Eric Abrahamsen @ 2015-04-29 12:31 ` Rasmus 2015-04-29 13:57 ` John Kitchin 2015-04-29 13:52 ` John Kitchin 1 sibling, 1 reply; 65+ messages in thread From: Rasmus @ 2015-04-29 12:31 UTC (permalink / raw) To: emacs-orgmode 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ä! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:31 ` Rasmus @ 2015-04-29 13:57 ` John Kitchin 0 siblings, 0 replies; 65+ messages in thread From: John Kitchin @ 2015-04-29 13:57 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:14 ` Eric Abrahamsen 2015-04-29 12:31 ` Rasmus @ 2015-04-29 13:52 ` John Kitchin 1 sibling, 0 replies; 65+ messages in thread From: John Kitchin @ 2015-04-29 13:52 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 8:41 ` Eric Abrahamsen 2015-04-29 9:57 ` Rasmus @ 2015-04-29 10:39 ` Nicolas Goaziou 2015-04-29 12:34 ` Eric Abrahamsen 1 sibling, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-04-29 10:39 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 10:39 ` Nicolas Goaziou @ 2015-04-29 12:34 ` Eric Abrahamsen 2015-04-29 12:51 ` Rasmus ` (3 more replies) 0 siblings, 4 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-29 12:34 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:34 ` Eric Abrahamsen @ 2015-04-29 12:51 ` Rasmus 2015-04-29 13:21 ` Eric S Fraga 2015-04-29 14:54 ` Eric Abrahamsen 2015-04-29 13:16 ` Eric S Fraga ` (2 subsequent siblings) 3 siblings, 2 replies; 65+ messages in thread From: Rasmus @ 2015-04-29 12:51 UTC (permalink / raw) To: emacs-orgmode 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! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:51 ` Rasmus @ 2015-04-29 13:21 ` Eric S Fraga 2015-04-29 14:00 ` John Kitchin 2015-04-29 14:54 ` Eric Abrahamsen 1 sibling, 1 reply; 65+ messages in thread From: Eric S Fraga @ 2015-04-29 13:21 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 13:21 ` Eric S Fraga @ 2015-04-29 14:00 ` John Kitchin 2015-04-29 14:42 ` Eric S Fraga 0 siblings, 1 reply; 65+ messages in thread From: John Kitchin @ 2015-04-29 14:00 UTC (permalink / raw) To: Eric S Fraga; +Cc: emacs-orgmode, Rasmus 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 14:00 ` John Kitchin @ 2015-04-29 14:42 ` Eric S Fraga 0 siblings, 0 replies; 65+ messages in thread From: Eric S Fraga @ 2015-04-29 14:42 UTC (permalink / raw) To: John Kitchin; +Cc: emacs-orgmode, Rasmus 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:51 ` Rasmus 2015-04-29 13:21 ` Eric S Fraga @ 2015-04-29 14:54 ` Eric Abrahamsen 1 sibling, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-29 14:54 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:34 ` Eric Abrahamsen 2015-04-29 12:51 ` Rasmus @ 2015-04-29 13:16 ` Eric S Fraga 2015-04-29 14:56 ` Eric Abrahamsen 2015-04-29 13:38 ` John Kitchin 2015-04-29 21:51 ` Nicolas Goaziou 3 siblings, 1 reply; 65+ messages in thread From: Eric S Fraga @ 2015-04-29 13:16 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 13:16 ` Eric S Fraga @ 2015-04-29 14:56 ` Eric Abrahamsen 0 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-29 14:56 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:34 ` Eric Abrahamsen 2015-04-29 12:51 ` Rasmus 2015-04-29 13:16 ` Eric S Fraga @ 2015-04-29 13:38 ` John Kitchin 2015-04-29 21:51 ` Nicolas Goaziou 3 siblings, 0 replies; 65+ messages in thread From: John Kitchin @ 2015-04-29 13:38 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 12:34 ` Eric Abrahamsen ` (2 preceding siblings ...) 2015-04-29 13:38 ` John Kitchin @ 2015-04-29 21:51 ` Nicolas Goaziou 2015-04-30 1:45 ` Eric Abrahamsen 3 siblings, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-04-29 21:51 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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, ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-29 21:51 ` Nicolas Goaziou @ 2015-04-30 1:45 ` Eric Abrahamsen 2015-04-30 9:58 ` Rasmus 2015-05-08 10:19 ` Nicolas Goaziou 0 siblings, 2 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-30 1:45 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-30 1:45 ` Eric Abrahamsen @ 2015-04-30 9:58 ` Rasmus 2015-04-30 11:32 ` Eric S Fraga ` (2 more replies) 2015-05-08 10:19 ` Nicolas Goaziou 1 sibling, 3 replies; 65+ messages in thread From: Rasmus @ 2015-04-30 9:58 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-30 9:58 ` Rasmus @ 2015-04-30 11:32 ` Eric S Fraga 2015-04-30 13:45 ` John Kitchin 2015-05-03 13:33 ` Eric Abrahamsen 2 siblings, 0 replies; 65+ messages in thread From: Eric S Fraga @ 2015-04-30 11:32 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-30 9:58 ` Rasmus 2015-04-30 11:32 ` Eric S Fraga @ 2015-04-30 13:45 ` John Kitchin 2015-05-03 13:33 ` Eric Abrahamsen 2 siblings, 0 replies; 65+ messages in thread From: John Kitchin @ 2015-04-30 13:45 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-30 9:58 ` Rasmus 2015-04-30 11:32 ` Eric S Fraga 2015-04-30 13:45 ` John Kitchin @ 2015-05-03 13:33 ` Eric Abrahamsen 2 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-05-03 13:33 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-30 1:45 ` Eric Abrahamsen 2015-04-30 9:58 ` Rasmus @ 2015-05-08 10:19 ` Nicolas Goaziou 2015-05-18 9:57 ` Rasmus 1 sibling, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-05-08 10:19 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-08 10:19 ` Nicolas Goaziou @ 2015-05-18 9:57 ` Rasmus 2015-05-18 11:48 ` Nicolas Goaziou 0 siblings, 1 reply; 65+ messages in thread From: Rasmus @ 2015-05-18 9:57 UTC (permalink / raw) To: emacs-orgmode 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! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 9:57 ` Rasmus @ 2015-05-18 11:48 ` Nicolas Goaziou 2015-05-18 13:16 ` Rasmus 0 siblings, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-05-18 11:48 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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, ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 11:48 ` Nicolas Goaziou @ 2015-05-18 13:16 ` Rasmus 2015-05-18 15:44 ` Eric S Fraga 2015-05-18 15:50 ` Nicolas Goaziou 0 siblings, 2 replies; 65+ messages in thread From: Rasmus @ 2015-05-18 13:16 UTC (permalink / raw) To: emacs-orgmode 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! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 13:16 ` Rasmus @ 2015-05-18 15:44 ` Eric S Fraga 2015-05-18 16:31 ` Rasmus 2015-05-18 15:50 ` Nicolas Goaziou 1 sibling, 1 reply; 65+ messages in thread From: Eric S Fraga @ 2015-05-18 15:44 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 15:44 ` Eric S Fraga @ 2015-05-18 16:31 ` Rasmus 2015-05-18 20:49 ` Eric Abrahamsen 0 siblings, 1 reply; 65+ messages in thread From: Rasmus @ 2015-05-18 16:31 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 16:31 ` Rasmus @ 2015-05-18 20:49 ` Eric Abrahamsen 0 siblings, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-05-18 20:49 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 13:16 ` Rasmus 2015-05-18 15:44 ` Eric S Fraga @ 2015-05-18 15:50 ` Nicolas Goaziou 2015-05-18 16:25 ` Rasmus 1 sibling, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-05-18 15:50 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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, ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 15:50 ` Nicolas Goaziou @ 2015-05-18 16:25 ` Rasmus 2015-05-18 16:56 ` Nicolas Goaziou 0 siblings, 1 reply; 65+ messages in thread From: Rasmus @ 2015-05-18 16:25 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 16:25 ` Rasmus @ 2015-05-18 16:56 ` Nicolas Goaziou 2015-05-18 17:28 ` Rasmus 0 siblings, 1 reply; 65+ messages in thread From: Nicolas Goaziou @ 2015-05-18 16:56 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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, ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 16:56 ` Nicolas Goaziou @ 2015-05-18 17:28 ` Rasmus 2015-05-18 18:36 ` Eric S Fraga 2015-05-19 8:14 ` Nicolas Goaziou 0 siblings, 2 replies; 65+ messages in thread From: Rasmus @ 2015-05-18 17:28 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 17:28 ` Rasmus @ 2015-05-18 18:36 ` Eric S Fraga 2015-05-19 8:14 ` Nicolas Goaziou 1 sibling, 0 replies; 65+ messages in thread From: Eric S Fraga @ 2015-05-18 18:36 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 17:28 ` Rasmus 2015-05-18 18:36 ` Eric S Fraga @ 2015-05-19 8:14 ` Nicolas Goaziou 1 sibling, 0 replies; 65+ messages in thread From: Nicolas Goaziou @ 2015-05-19 8:14 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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, ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-27 23:35 ` John Kitchin 2015-04-28 2:28 ` Eric Abrahamsen @ 2015-04-28 10:48 ` Eric Abrahamsen 1 sibling, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2015-04-28 10:48 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-25 0:52 ` John Kitchin 2015-04-25 1:34 ` Eric Abrahamsen 2015-04-25 4:13 ` Vikas Rawal @ 2015-04-25 9:04 ` Eric S Fraga 2 siblings, 0 replies; 65+ messages in thread From: Eric S Fraga @ 2015-04-25 9:04 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal ` (4 preceding siblings ...) 2015-04-24 7:40 ` Eric S Fraga @ 2015-05-18 21:42 ` Marcin Borkowski 2015-05-28 10:52 ` Alan Schmitt 5 siblings, 1 reply; 65+ messages in thread From: Marcin Borkowski @ 2015-05-18 21:42 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Marking/highlighting text temporarily 2015-05-18 21:42 ` Marcin Borkowski @ 2015-05-28 10:52 ` Alan Schmitt 0 siblings, 0 replies; 65+ messages in thread From: Alan Schmitt @ 2015-05-28 10:52 UTC (permalink / raw) To: Marcin Borkowski; +Cc: org-mode mailing list, Vikas Rawal [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2015-05-28 10:52 UTC | newest] Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-24 6:19 Marking/highlighting text temporarily Vikas Rawal 2015-04-24 6:42 ` Thomas S. Dye 2015-04-24 7:53 ` Marcin Borkowski 2015-04-24 7:05 ` Glyn Millington 2015-04-24 7:13 ` Eric Abrahamsen 2015-04-24 7:19 ` Eric Abrahamsen 2015-04-24 7:38 ` Fabrice Niessen 2015-04-24 7:40 ` Eric S Fraga 2015-04-24 7:58 ` Marcin Borkowski 2015-04-24 8:48 ` Eric S Fraga 2015-04-24 21:38 ` Vikas Rawal 2015-04-25 0:52 ` John Kitchin 2015-04-25 1:34 ` Eric Abrahamsen 2015-04-25 4:13 ` Vikas Rawal 2015-04-25 7:47 ` Eric Abrahamsen 2015-04-25 9:08 ` Eric Abrahamsen 2015-04-26 18:14 ` John Kitchin 2015-04-27 6:13 ` Eric Abrahamsen 2015-04-27 10:27 ` John Kitchin 2015-04-27 11:11 ` Marcin Borkowski 2015-04-27 12:37 ` Eric Abrahamsen 2015-04-27 12:58 ` John Kitchin 2015-04-27 13:06 ` Eric Abrahamsen 2015-04-27 23:35 ` John Kitchin 2015-04-28 2:28 ` Eric Abrahamsen 2015-04-28 19:32 ` John Kitchin 2015-04-29 8:41 ` Eric Abrahamsen 2015-04-29 9:57 ` Rasmus 2015-04-29 12:14 ` Eric Abrahamsen 2015-04-29 12:31 ` Rasmus 2015-04-29 13:57 ` John Kitchin 2015-04-29 13:52 ` John Kitchin 2015-04-29 10:39 ` Nicolas Goaziou 2015-04-29 12:34 ` Eric Abrahamsen 2015-04-29 12:51 ` Rasmus 2015-04-29 13:21 ` Eric S Fraga 2015-04-29 14:00 ` John Kitchin 2015-04-29 14:42 ` Eric S Fraga 2015-04-29 14:54 ` Eric Abrahamsen 2015-04-29 13:16 ` Eric S Fraga 2015-04-29 14:56 ` Eric Abrahamsen 2015-04-29 13:38 ` John Kitchin 2015-04-29 21:51 ` Nicolas Goaziou 2015-04-30 1:45 ` Eric Abrahamsen 2015-04-30 9:58 ` Rasmus 2015-04-30 11:32 ` Eric S Fraga 2015-04-30 13:45 ` John Kitchin 2015-05-03 13:33 ` Eric Abrahamsen 2015-05-08 10:19 ` Nicolas Goaziou 2015-05-18 9:57 ` Rasmus 2015-05-18 11:48 ` Nicolas Goaziou 2015-05-18 13:16 ` Rasmus 2015-05-18 15:44 ` Eric S Fraga 2015-05-18 16:31 ` Rasmus 2015-05-18 20:49 ` Eric Abrahamsen 2015-05-18 15:50 ` Nicolas Goaziou 2015-05-18 16:25 ` Rasmus 2015-05-18 16:56 ` Nicolas Goaziou 2015-05-18 17:28 ` Rasmus 2015-05-18 18:36 ` Eric S Fraga 2015-05-19 8:14 ` Nicolas Goaziou 2015-04-28 10:48 ` Eric Abrahamsen 2015-04-25 9:04 ` Eric S Fraga 2015-05-18 21:42 ` Marcin Borkowski 2015-05-28 10:52 ` Alan Schmitt
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).