Re: [O] Marking/highlighting text temporarily
On 2015-05-18 23:42, Marcin Borkowski mb...@mbork.pl writes: On 2015-04-24, at 08:19, Vikas Rawal vikasli...@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 signature.asc Description: PGP signature
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Then it cannot even replace inlinetasks. Is that a goal? It should be. We don't need another syntax for something that does almost the same thing as an inlinetask but, yet, isn't one. Inline todo/inlinetasks, there can only be one. I think totally useless stretching it. Two examples. [@:1] My sentence on foo [@] and something else * Annotations [@:1:Nicolas] Remember to refer to bar #+TODO: Notes/Nicolas My sentence on foo [Notes/Nicolas: Remember to refer to bar] and something else. The latter is less precise, but I would still prefer it. I guess you could add references to an endnote for long notes, which would bring it closer to killing org-inlinetasks. I think you are missing my point. My goal is to be able to /mark/ a very specific part of the document (ranging from a word to a whole section). Your syntax cannot achieve that, because you need two markers, one at the beginning and one at the end of the area you need to mark. This is a dead-end. Also, I don't want to clutter the document with annotations, hence moving them to a specific section, while retaining a minimal syntax in the document. No matter how much you like it, your syntax isn't general enough for annotations. This is understandable, since you're after inline TODO, not annotations. Regards,
Re: [O] Marking/highlighting text temporarily
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: But note that I am more interested in an inline noting/todo functionality as opposed to annotation functionality. Inline noting is Text[@:1][@] * Annotations [@:1:] My note. My guess would be that most notes are short. For such notes, but not necessarily for longer notes, [@:NOTE] would be more convenient. Though I don't know what the @ signifies. I think whatever is the value of #+TODO makes more sense as prefixes. I don't think it would be easy to convince coauthors of documents, who are not using Emacs, that this is something easy to use. I guess not many people do XML in Nano or Notepad, since keeping track of opening and closing tags is a pain. Formatting tags, e.g. *, are somehow natural and shorter. Blocks are easy to see. I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. E.g. Sentence about BAR [TODO: add reference to FOO and check BAZ]. I don't need that in my agenda. Also, for annotation, would it not be annoying, in review session say, to have the notes so far away from the text? Perhaps not with the right helping tools. Again, not with proper tooling, e.g, remote editing like footnotes. But this is a change to the *format*, not its principal editor. —Rasmus -- Er du tosset for noge' lårt!
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Fine whit me. For that I I have inlinetasks. Then it cannot even replace inlinetasks. The tags. They are notes related to say a sentence, so you put a note at the end of a sentence. Spatial TODOs. I still don't get it, sorry. Its virtues are compactness, being similar to a list, being C-k friendly, and, IMO, more intuitive. But, IMO, totally useless for general annotations. This probably means they shouldn't share the same syntax. Note I'm all for replacing inlinetasks with something else (i.e., change syntax), albeit this is no simple task. However, that was not my proposal. Regards,
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Fine whit me. For that I I have inlinetasks. Then it cannot even replace inlinetasks. Is that a goal? Its virtues are compactness, being similar to a list, being C-k friendly, and, IMO, more intuitive. But, IMO, totally useless for general annotations. I think totally useless stretching it. Two examples. [@:1] My sentence on foo [@] and something else * Annotations [@:1:Nicolas] Remember to refer to bar #+TODO: Notes/Nicolas My sentence on foo [Notes/Nicolas: Remember to refer to bar] and something else. The latter is less precise, but I would still prefer it. I guess you could add references to an endnote for long notes, which would bring it closer to killing org-inlinetasks. This probably means they shouldn't share the same syntax. Note I'm all for replacing inlinetasks with something else (i.e., change syntax), albeit this is no simple task. I don't particularly care for them either. —Rasmus -- This space is left intentionally blank
Re: [O] Marking/highlighting text temporarily
Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 18 May 2015 at 15:16, Rasmus wrote: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. E.g. Sentence about BAR [TODO: add reference to FOO and check BAZ]. I don't need that in my agenda. Exactly. I use inlinetasks a lot for file local TODO items that are not meant to appear in my agenda. They are notes for things I need to do, typically, to finish a paper. Being able to C-c / t to find them all easily is great. I would expect the same functionality from any replacement. Would it be bad if I admit I have no idea how to use sparse trees? The remind me of Vim, except in Vim i eventually figured out that I could quit it via :q. I would probably use occur or a restricted agenda. I would want inlinetodos in my global/usual agenda. In terms of format, I also dislike opening and closing tags except for short formatting uses. I would prefer [COMMENT: this is very interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to be less worried about running into problems with text use of [...]. I think [[TODO:]] is a link... Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: My guess would be that most notes are short. For such notes, but not necessarily for longer notes, [@:NOTE] would be more convenient. This is very limited: you cannot write two paragraphs in your note. Though I don't know what the @ signifies. AnnoTate? I think whatever is the value of #+TODO makes more sense as prefixes. You turn every annotation into a task. Again, this is very restrictive. I don't think it would be easy to convince coauthors of documents, who are not using Emacs, that this is something easy to use. I guess not many people do XML in Nano or Notepad, since keeping track of opening and closing tags is a pain. My sole focus is Emacs users, tho. Formatting tags, e.g. *, are somehow natural and shorter. Blocks are easy to see. I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. E.g. Sentence about BAR [TODO: add reference to FOO and check BAZ]. I don't need that in my agenda. Since you're talking about TODO functionality, what features would this share with regular tasks, defined with headlines or inlinetasks? But this is a change to the *format*, not its principal editor. Do you think tables are particularly nice to write if you work outside of Org mode? There is no clause about being easy to edit from Nano in Org. Anyway, we're speaking of two different things, e.g., I think it's important to be able to mark exactly which part of the document you're annotating. [TODO: ...] cannot do that. Regards,
Re: [O] Marking/highlighting text temporarily
On Monday, 18 May 2015 at 15:16, Rasmus wrote: Nicolas Goaziou m...@nicolasgoaziou.fr writes: [...] I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. E.g. Sentence about BAR [TODO: add reference to FOO and check BAZ]. I don't need that in my agenda. Exactly. I use inlinetasks a lot for file local TODO items that are not meant to appear in my agenda. They are notes for things I need to do, typically, to finish a paper. Being able to C-c / t to find them all easily is great. I would expect the same functionality from any replacement. In terms of format, I also dislike opening and closing tags except for short formatting uses. I would prefer [COMMENT: this is very interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to be less worried about running into problems with text use of [...]. But I think that's already been dismissed... -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: My guess would be that most notes are short. For such notes, but not necessarily for longer notes, [@:NOTE] would be more convenient. This is very limited: you cannot write two paragraphs in your note. Fine whit me. For that I I have inlinetasks. Though I don't know what the @ signifies. AnnoTate? I did not see that coming. That's a meh from me :) I think whatever is the value of #+TODO makes more sense as prefixes. You turn every annotation into a task. Again, this is very restrictive. I don't think so, e.g. #+TODO: DISCUSS DISAGREE | RESOLVED DROPPED And judging from the manual people are doing much more complicated stuff than that (my usage is pretty simple). Since you're talking about TODO functionality, what features would this share with regular tasks, defined with headlines or inlinetasks? The tags. They are notes related to say a sentence, so you put a note at the end of a sentence. Spatial TODOs. Anyway, we're speaking of two different things, e.g., I think it's important to be able to mark exactly which part of the document you're annotating. I agree they are different. [TODO: ...] cannot do that. Its virtues are compactness, being similar to a list, being C-k friendly, and, IMO, more intuitive. –Rasmus -- There are known knowns; there are things we know that we know
Re: [O] Marking/highlighting text temporarily
Hi all, Actually, having pondered this whole annotation and task business while heading home after work on the train, I think all I would like is a simple annotation scheme with no need for tasks etc. We have plenty of support for tasks with headlines. What we don't have is simple annotations. I use inlinetasks for annotations yet these are clumsy, as we have seen. What the notation for annotations should be I leave to others, especially those that might implement something. However, it should allow for hiding of annotations while editing an org buffer, it should be possible to list all annotations (sparse tree functionality), to jump from one to the next and it should provide the hooks for exporting in various ways, with customisable formatting. Just my 2¢ worth. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1147-g0e5069.dirty
Re: [O] Marking/highlighting text temporarily
On 2015-04-24, at 08:19, Vikas Rawal vikasli...@agrarianresearch.org wrote: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? Well, it seems that the thread went somewhere else (completely), but it just occured to me that you might want Bookmark+ (in case nobody mentioned it). You have normal Emacs bookmarks but on Drew-steroids, among others you can /highlight/ all bookmarks in a buffer. (And AFAIR you can have a dedicated bookmark file for e.g. one project, so that you effectively have categories of bookmarks.) Vikas Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 18 May 2015 at 15:16, Rasmus wrote: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. E.g. Sentence about BAR [TODO: add reference to FOO and check BAZ]. I don't need that in my agenda. Exactly. I use inlinetasks a lot for file local TODO items that are not meant to appear in my agenda. They are notes for things I need to do, typically, to finish a paper. Being able to C-c / t to find them all easily is great. I would expect the same functionality from any replacement. Would it be bad if I admit I have no idea how to use sparse trees? The remind me of Vim, except in Vim i eventually figured out that I could quit it via :q. I would probably use occur or a restricted agenda. I would want inlinetodos in my global/usual agenda. In terms of format, I also dislike opening and closing tags except for short formatting uses. I would prefer [COMMENT: this is very interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to be less worried about running into problems with text use of [...]. I think [[TODO:]] is a link... We're coming back around to the beginning of the conversation! I still think we started off talking about two different things. One is a replacement for inlinetasks that's actually inline. The other is an annotation system that could be used for collaboration, and might be taking aim at Track Changes in some way. It looks like we've gone off in the inlinetasks direction. I'll admit that what I really want is an honest-to-goodness first-class-citizen inline TODO. Something attached to a specific run of text, that has a TODO keyword and tags. Probably scheduling? Probably not properties, I don't know. Personally I'd prefer that the contents of the TODO were hidden (a la links), because (like Eric F) I would use this for notes on pieces of writing, and having big ugly chunks of highlighted spaghetti in the middle of a paragraph makes it hard to write. How technically difficult would that be? If it slows down agenda creation too badly, maybe we could have a user option that defaults to skipping inline todos in agenda creation. I was lukewarm about Nicolas' earlier syntax proposal because it simply doesn't seem distinct enough from footnotes. Just some random reactions, Eric
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? I'm not convinced in-text TODOs would be interesting, because they would make building the agenda an order of magnitude slower. IMO you need not. But perhaps I'm extrapolating from my use-case. I guess it would be inconsistent not to include it. My concerns about syntax are: - it should not cripple readability of the document - it needs to mark both objects (inline) and elements, even multiple elements (e.g., two paragraphs) In particular, the last point is difficult to handle for the parser. Indeed, any syntax is either contained in a paragraph or stops one, so this syntax should be a bit outside the parser. Anyway, here we go for another proposal. In-text markers: [@:ID]...[@] While we have opening and closing tags for formatting (e.g. bold), I dislike the above. It seems like asking for trouble; it would seem one could easily loose track and delete one end of the tag and not the other. IOW: [@:ID1]... [@:ID2]...[@]...[@] seems like asking for trouble as I could easily delete an opening pair. But note that I am more interested in an inline noting/todo functionality as opposed to annotation functionality. Also, for annotation, would it not be annoying, in review session say, to have the notes so far away from the text? Perhaps not with the right helping tools. —Rasmus ID is expected to be unique, and consists of alphanumeric characters only. Markers are allowed anywhere standard syntax is (e.g., paragraphs, verse blocks, table cells, captions, parsed keyword). Both makers have to be found within the same section, i.e, one cannot annotate across headlines. Annotations can be nested but cannot partially overlap. From the parser point of view, Element can recognize such markers, but will not be able to associate them since they exist above structure of the document. One important limitation is that example or source blocks cannot be annotated, Therefore I also suggest creating a new affiliated keyword, #+ANNOTATE: ID which will annotate the whole element it is applied to. Some examples: [@:1]Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et [@:2]dolore magna[@] aliqua. Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.[@] #+ANNOTATE: foo #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Then references are collected in a dedicated section, much like footnotes (e.g., `org-annotation-section'), although it cannot be nil. Annotations start at column 0 [@:ID:AUTHOR-ID] OTHER-AUTHOR-ID CONTENTS where: - ID obviously refers to in-text markers' ID, - AUTHOR-ID consists of word and blank characters only. If empty, it may default to `user-login-name'. - OTHER-AUTHOR-ID is also optional. It is meant for empty contents. During export, it could be possible to select annotation from a single source, e.g., #+OPTIONS: @:student1 - CONTENTS consists of either comments and non-comments. Any non-comment is considered as data to replace (if in-text markers are not sticked to each other), or insert (when they are) during export. Comments will be displayed as a conversation thread by a special function in org-annotate.el. This syntax allows to copy annotation from another author, e.g. [@:1:teacher] # This is wrong, it should be foo. foo [@:1:student1] teacher [@:2:teacher] # Please reformulate. [@:2:student1] # What about bar? bar Timestamps, if needed, can be inserted in comments. WDYT? -- Enough with the bla bla!
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: While we have opening and closing tags for formatting (e.g. bold), I dislike the above. It seems like asking for trouble; it would seem one could easily loose track and delete one end of the tag and not the other. IOW: [@:ID1]... [@:ID2]...[@]...[@] seems like asking for trouble as I could easily delete an opening pair. We can implement a function in org-annotate.el to remove an annotation. You don't need to do it by hand. But note that I am more interested in an inline noting/todo functionality as opposed to annotation functionality. Inline noting is Text[@:1][@] * Annotations [@:1:] My note. I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. Also, for annotation, would it not be annoying, in review session say, to have the notes so far away from the text? Perhaps not with the right helping tools. Again, not with proper tooling, e.g, remote editing like footnotes. Regards,
Re: [O] Marking/highlighting text temporarily
Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? I'm not convinced in-text TODOs would be interesting, because they would make building the agenda an order of magnitude slower. My concerns about syntax are: - it should not cripple readability of the document - it needs to mark both objects (inline) and elements, even multiple elements (e.g., two paragraphs) In particular, the last point is difficult to handle for the parser. Indeed, any syntax is either contained in a paragraph or stops one, so this syntax should be a bit outside the parser. Anyway, here we go for another proposal. In-text markers: [@:ID]...[@] ID is expected to be unique, and consists of alphanumeric characters only. Markers are allowed anywhere standard syntax is (e.g., paragraphs, verse blocks, table cells, captions, parsed keyword). Both makers have to be found within the same section, i.e, one cannot annotate across headlines. Annotations can be nested but cannot partially overlap. From the parser point of view, Element can recognize such markers, but will not be able to associate them since they exist above structure of the document. One important limitation is that example or source blocks cannot be annotated, Therefore I also suggest creating a new affiliated keyword, #+ANNOTATE: ID which will annotate the whole element it is applied to. Some examples: [@:1]Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et [@:2]dolore magna[@] aliqua. Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.[@] #+ANNOTATE: foo #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Then references are collected in a dedicated section, much like footnotes (e.g., `org-annotation-section'), although it cannot be nil. Annotations start at column 0 [@:ID:AUTHOR-ID] OTHER-AUTHOR-ID CONTENTS where: - ID obviously refers to in-text markers' ID, - AUTHOR-ID consists of word and blank characters only. If empty, it may default to `user-login-name'. - OTHER-AUTHOR-ID is also optional. It is meant for empty contents. During export, it could be possible to select annotation from a single source, e.g., #+OPTIONS: @:student1 - CONTENTS consists of either comments and non-comments. Any non-comment is considered as data to replace (if in-text markers are not sticked to each other), or insert (when they are) during export. Comments will be displayed as a conversation thread by a special function in org-annotate.el. This syntax allows to copy annotation from another author, e.g. [@:1:teacher] # This is wrong, it should be foo. foo [@:1:student1] teacher [@:2:teacher] # Please reformulate. [@:2:student1] # What about bar? bar Timestamps, if needed, can be inserted in comments. WDYT? -- Nicolas Goaziou
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Hi, Eric Abrahamsen e...@ericabrahamsen.net writes: We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? I don't know. From what I can tell, rasmus seems to be proposing an in-text TODO, I mainly extrapolated from your example. Further, I extrapolated from the notion of org-inlinetasks.el. Since we have one we should try to minimize the distance whilst still keeping syntax as simple as possible, e.g. [comment:] or [TODO-TAG:] (I don't know what the @ operator meant in your previous example). I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Isn't this the job of VC? I'm not sure how we can concisely represent all the needed metadata? Something like [comment: txt :annotation annot :author a :date d :other-properties p] is not accessible for non-Emacs users of the Org format. 1. Annotations attached to arbitrary text in the buffer. The buffer text should be visible, the annotation data invisible (basically the way links work right now). This is a fortification/overlay issue. And I disagree strongly on having invisible parts. 2. Plain annotation: just a chunk of free-form paragraph text that is attached to the buffer text. What do you concretely have in mind here? Can't this be done with an inlinetask at the beginning of the file? Or a noexport heading? 3. Replacement text: an alternate version of the buffer text; this could be the basis of track changes stuff. Is this not the job of VC? 4. Timestamps This seems like the job of e.g. vc-annotate.el, no? 7. Author metadata would probably be unnecessary with full access to the export channels, but it might still be desirable. What John was talking about was for collaboration. When you export John's notes on your machine how can it know it's from John if not set explicitly? In any case, I think it could be too verbose. Sidenote: In collaborated papers I simply use prefix R: and K: in inlinetasks. That's all I can think of, just trying to get the ball rolling. I don't have any opinions about actual syntax, though something with curly braces might be nice. Nothing with curly braces is nice :) I think I have something much less ambitious in mind, as I'm perfectly happy with only spanning a subset of org-inlinetasks.el. Disregarding date and generalizing replacement text to annotation, which could be set to replace with a keyword, you could perhaps have something like one of these: [comment/Property:annotation; text] [comment/TODO-TAG@author: annotation; text] [comment/Property: annotation] [TODO-TAG/Property@Author: annotation; text] [comment/Property: annotation] - Of course the / and @ operators are optional. - I'm not sure what Property would be. - Author could also be @work as in your previous example. - Perhaps calculating TODO-TAGS on a document basis is a can of worms. - I would be happier with having text before annotation, but that makes it weird when you have no text attached (for inline tasks not associated to a piece of text). Hmm, it looks like we've maybe got too many ideas bouncing around at the same time. I would love to have more inline inlinetodos -- ie, full-citizen TODOs that are attached to a run of buffer text, not headlines themselves. Call them in-text todos, maybe. I would also love to have collaborative editing in Org, and I agree that something based on VC would be most ideal (word-mode diffs could solve many of the problems there). Those two things seem pretty separate, though, and to be honest either one is way more than I can handle on my own. Tying in-text TODOs into the whole Agenda process seems like an awful lot of work. Also, I've never so much as glanced at the VC code. What seems most likely is I'll first fill out org-annotate and put it in Elpa, and then maybe we can have a slower conversation about what other directions to go in. Org-annotate will probably just stay what it is (it's very simple, and does what it says on the tin), but maybe we'll get a clearer sense of the various things people want, and it can be superseded at some point. On the VC side, how hard would it be to make a pseudo VC backend where, if you have an org file called some_file.org (for example), the backend looked for files in the same directory called some_file.org.XYZ.patch, and applied those patch files in a visible way to the Org file when you viewed it? With the whole apply/reject thing built in? Anyway... small, realistic steps seem like the best approach. Eric
Re: [O] Marking/highlighting text temporarily
Hi, Eric Abrahamsen e...@ericabrahamsen.net writes: We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? I don't know. From what I can tell, rasmus seems to be proposing an in-text TODO, I mainly extrapolated from your example. Further, I extrapolated from the notion of org-inlinetasks.el. Since we have one we should try to minimize the distance whilst still keeping syntax as simple as possible, e.g. [comment:] or [TODO-TAG:] (I don't know what the @ operator meant in your previous example). I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Isn't this the job of VC? I'm not sure how we can concisely represent all the needed metadata? Something like [comment: txt :annotation annot :author a :date d :other-properties p] is not accessible for non-Emacs users of the Org format. 1. Annotations attached to arbitrary text in the buffer. The buffer text should be visible, the annotation data invisible (basically the way links work right now). This is a fortification/overlay issue. And I disagree strongly on having invisible parts. 2. Plain annotation: just a chunk of free-form paragraph text that is attached to the buffer text. What do you concretely have in mind here? Can't this be done with an inlinetask at the beginning of the file? Or a noexport heading? 3. Replacement text: an alternate version of the buffer text; this could be the basis of track changes stuff. Is this not the job of VC? 4. Timestamps This seems like the job of e.g. vc-annotate.el, no? 7. Author metadata would probably be unnecessary with full access to the export channels, but it might still be desirable. What John was talking about was for collaboration. When you export John's notes on your machine how can it know it's from John if not set explicitly? In any case, I think it could be too verbose. Sidenote: In collaborated papers I simply use prefix R: and K: in inlinetasks. That's all I can think of, just trying to get the ball rolling. I don't have any opinions about actual syntax, though something with curly braces might be nice. Nothing with curly braces is nice :) I think I have something much less ambitious in mind, as I'm perfectly happy with only spanning a subset of org-inlinetasks.el. Disregarding date and generalizing replacement text to annotation, which could be set to replace with a keyword, you could perhaps have something like one of these: [comment/Property:annotation; text] [comment/TODO-TAG@author: annotation; text] [comment/Property: annotation] [TODO-TAG/Property@Author: annotation; text] [comment/Property: annotation] - Of course the / and @ operators are optional. - I'm not sure what Property would be. - Author could also be @work as in your previous example. - Perhaps calculating TODO-TAGS on a document basis is a can of worms. - I would be happier with having text before annotation, but that makes it weird when you have no text attached (for inline tasks not associated to a piece of text). —Rasmus -- A clever person solves a problem. A wise person avoids it
Re: [O] Marking/highlighting text temporarily
On Thursday, 30 Apr 2015 at 11:58, Rasmus wrote: [...] I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Isn't this the job of VC? I'm not sure how we can concisely represent all the needed metadata? Something like I'm 100% with you on this. One of the most important aspects of org is that it is all text and existing and powerful revision control systems can be used with any org file. Let's not go down the everything including the kitchen sink approach as we'll do everything badly and nothing well (i.e. end up with an MS Word look-a-like...). Let's keep things simple. Anyway, that's my opinion. Obviously, nobody is going to force me to use org-annotate for tracking changes but my concern is feature creep leading to a mess... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Rasmus writes: Hi, Eric Abrahamsen e...@ericabrahamsen.net writes: We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? I don't know. From what I can tell, rasmus seems to be proposing an in-text TODO, I mainly extrapolated from your example. Further, I extrapolated from the notion of org-inlinetasks.el. Since we have one we should try to minimize the distance whilst still keeping syntax as simple as possible, e.g. [comment:] or [TODO-TAG:] (I don't know what the @ operator meant in your previous example). I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Isn't this the job of VC? I'm not sure how we can concisely represent all the needed metadata? Something like VC does not do this well for written text. Most VC were designed for code, and are line oriented. In written text, you can have an entire paragraph on a single line, and most VC do not show changes by sentence, for example. There are some ways to get different kinds of diffs, but none of them work well in my opinion. Students get track changes, and for collaborative editing of text, it is pretty great. [comment: txt :annotation annot :author a :date d :other-properties p] is not accessible for non-Emacs users of the Org format. 1. Annotations attached to arbitrary text in the buffer. The buffer text should be visible, the annotation data invisible (basically the way links work right now). This is a fortification/overlay issue. And I disagree strongly on having invisible parts. 2. Plain annotation: just a chunk of free-form paragraph text that is attached to the buffer text. What do you concretely have in mind here? Can't this be done with an inlinetask at the beginning of the file? Or a noexport heading? inlinetasks do not have the same semantic meaning as comments and annotations. They can serve a purpose similar to this, I agree. but, it doesn't make sense to me to consider having an annotation type for inline comments, and a separate type for this plain annotation. How would you differentiate a real task from a plain annotation? 3. Replacement text: an alternate version of the buffer text; this could be the basis of track changes stuff. Is this not the job of VC? No. VC has a role in it, but current tools do not do this well enough to be solutions. 4. Timestamps This seems like the job of e.g. vc-annotate.el, no? 7. Author metadata would probably be unnecessary with full access to the export channels, but it might still be desirable. What John was talking about was for collaboration. When you export John's notes on your machine how can it know it's from John if not set explicitly? In any case, I think it could be too verbose. Sidenote: In collaborated papers I simply use prefix R: and K: in inlinetasks. That's all I can think of, just trying to get the ball rolling. I don't have any opinions about actual syntax, though something with curly braces might be nice. Nothing with curly braces is nice :) I think I have something much less ambitious in mind, as I'm perfectly happy with only spanning a subset of org-inlinetasks.el. Disregarding date and generalizing replacement text to annotation, which could be set to replace with a keyword, you could perhaps have something like one of these: [comment/Property:annotation; text] [comment/TODO-TAG@author: annotation; text] [comment/Property: annotation] [TODO-TAG/Property@Author: annotation; text] [comment/Property: annotation] - Of course the / and @ operators are optional. - I'm not sure what Property would be. - Author could also be @work as in your previous example. - Perhaps calculating TODO-TAGS on a document basis is a can of worms. - I would be happier with having text before annotation, but that makes it weird when you have no text attached (for inline tasks not associated to a piece of text). —Rasmus -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Regards, -- Nicolas Goaziou
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@andrew.cmu.edu writes: Eric Abrahamsen writes: John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? Because [[comment:X][Y]] is displayed (by default) as Y which can be misleading as X and Y grow out of sync. Perhaps I'm wrong, but I see no point in Y for a comment. Further, nasty stuff is sometimes applied to X such as escaping spaces. In addition, export filters cannot easily be pointed to links (you'd have to make a check on the type of link), and you need a bit more hassle to map over them with org-element etc. Again, that's just my opinion so feel free to ignore it! Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. It's only a concern if you want to advocate for including this in Org 8.3. Cheers, Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). Wow, I just went back and looked at the cite thread. That was bewildering. I don't see a direct connection here, though -- cite was needed for very specific academic purposes, with very clearly-defined needs. Comment is much floppier: good for anything from notes-to-self, to notes-to-editor, to notes-to-no-one. *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. Thanks, Eric
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. But to be honest, I think it sits pretty comfortably on top of what's already available. The only slight awkwardness comes when you'd like a different face for the annotation links (currently solved with John Kitchin's hi-lock trick), and the fact that the link export routines don't have access to the exportation info/plist channels (ie, when exporting an annotation link to ODT, I'd like to be able to give the annotation an author element, but as far as I know I can't get access to that). These aren't major flaws. All that said, I do think this is an important feature that fills a bit of gap in Org. TODOs are fundamental, but they are discrete entities. Those of us who use Org for authoring could use a method of decorating spans of text with pertinent information. As org-comment stands now, the tabular list buffer serves as a pseudo Agenda for text comments: I have been using it, for example, as a way of keeping track of translation problems that I need to resolve. I'll admit I have dreamed of a syntax that looks like: [[body text to annotate][TODO:Look this up on the internet:@work]]. The thought of plugging that in to the existing Agenda machine is exhausting even to contemplate, though. I know we've got inlinetodos. They bug me, though: the absurd number of stars (even if they are invisible), and the fact that you're still not really attaching the TODO to specific text, which is what I want. I know these aren't reasonable objections, but still. Now I wish we'd named it org-annotate. I'm done, Eric
Re: [O] Marking/highlighting text temporarily
Hi,
Eric Abrahamsen e...@ericabrahamsen.net writes:
Just to be clear, you think it fits into the category of
incubation-prior-to-core?
I think inlinetasks/comments that are actually *inline* would be nice!
If anyone thinks that this mechanism warrants actual new Org syntax, I'd
be happy to work on implementing that. But to be honest, I think it sits
pretty comfortably on top of what's already available. The only slight
awkwardness comes when you'd like a different face for the annotation
links (currently solved with John Kitchin's hi-lock trick), and the fact
that the link export routines don't have access to the exportation
info/plist channels (ie, when exporting an annotation link to ODT, I'd
like to be able to give the annotation an author element, but as far
as I know I can't get access to that). These aren't major flaws.
See my other post. In addition you'd need to be able to turn them off via
#+OPTIONS: annotations:nil
I'll admit I have dreamed of a syntax that looks like: [[body text to
annotate][TODO:Look this up on the internet:@work]].
I don't like the example. The ordering is weird. Do the first and the
second bracket need to be tied together? Or would something like this
work:
body text to annotate [todo@work: Look this up on the internet]
Or
[todo@work: Look this up on the internet]{body text to annotate}
[todo@work look this up on the internet: body text to annotate]
—Rasmus
--
With monopolies the cake is a lie!
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Cheers, Rasmus -- A page of history is worth a volume of logic
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? I think so. If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. I also think a new syntax is needed. But, please, let's keep it as simple as possible. Regards,
Re: [O] Marking/highlighting text temporarily
Hello all, I have been following this whole thread with great interest, having posted very early on the use of inline tasks as a solution for the OP. I use inline tasks a lot for both annotations and for TODO tasks when writing papers. I like the link syntax proposed but would much prefer something that includes tasks as well as comments. What is missing, by the way, with the proposed link based comment syntax that inline tasks give is the ability to find them quickly within a (large) document. Maybe I missed this functionality in what has been proposed. Inline tasks are easy to find using C-c / t... And to add to yet another element of the discussion, I have no problem with the [[comment:X][Y]] in the sense of X being hidden in normal view. Back to your regular programming :) thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
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 m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm copying Nicolas -- Nicolas, is there a process for inclusion in contrib? Would this be eligible? I'll just stick it in Elpa, otherwise. Any package is eligible. However, contrib/ is from pre-package.el days. Nowadays, I tend to think it should be used only as an incubator for libraries meant to be moved into core. Other libraries should be packaged in ELPA. I admit I didn't read the thread carefully. IIUC, it seems to be an annotation mechanism. If I'm correct, I think it belongs to the first category. Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. But to be honest, I think it sits pretty comfortably on top of what's already available. The only slight awkwardness comes when you'd like a different face for the annotation links (currently solved with John Kitchin's hi-lock trick), and the fact that the link export routines don't have access to the exportation info/plist channels (ie, when exporting an annotation link to ODT, I'd like to be able to give the annotation an author element, but as far as I know I can't get access to that). These aren't major flaws. All that said, I do think this is an important feature that fills a bit of gap in Org. TODOs are fundamental, but they are discrete entities. Those of us who use Org for authoring could use a method of decorating spans of text with pertinent information. As org-comment stands now, the tabular list buffer serves as a pseudo Agenda for text comments: I have been using it, for example, as a way of keeping track of translation problems that I need to resolve. I'll admit I have dreamed of a syntax that looks like: [[body text to annotate][TODO:Look this up on the internet:@work]]. The thought of plugging that in to the existing Agenda machine is exhausting even to contemplate, though. I know we've got inlinetodos. They bug me, though: the absurd number of stars (even if they are invisible), and the fact that you're still not really attaching the TODO to specific text, which is what I want. I know these aren't reasonable objections, but still. Now I wish we'd named it org-annotate. I'm done, Eric -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen writes: Rasmus ras...@gmx.us writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Would this be eligible? Not that my .02€ are worth much, but I think the idea of inline notes is good, but I don't think it should be done using links. See e.g. the discussion on citation which introduced a [cite:⋯] command. A [comment:⋯] command would also IMO make much more sense than [[comment:X][Y]] as was allowed last time I read your patch (in the weekend, I think). Wow, I just went back and looked at the cite thread. That was bewildering. I don't see a direct connection here, though -- cite was needed for very specific academic purposes, with very clearly-defined needs. Comment is much floppier: good for anything from notes-to-self, to notes-to-editor, to notes-to-no-one. *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? The only reason I can see (coming from someone who uses links liberally for other purposes ;) is just to avoid the hacks required to get extra functionality, e.g. as you alluded to applying different faces, storing additional information (author, timestamp, etc...), avoiding a need to add a link type-checking for collecting comments (although, this is not a very difficult step). On the link side, they work perfectly well for the simplest kind of comment, and because of that, there is a working prototype already. But, I think extending it beyond this will require the hackery described above. I don't have a sense if it is more work than defining a new syntax, or the long term maintenance costs of that approach. For me, it is work I already know how to do. I admit though, that does not mean it is better than a new syntax ;) Maybe a study of the cite syntax code would clarify the differences. Can anyone point me to a code repository where we could read that code? On inclusion in contrib I think you can put anything org-ish there. It's better if the copyright is cleared in case we want to make it part of core, but it's not necessary. There's little difference between core and contrib as neither are included in Emacs and thus are hard to rely on. Since you use cl-lib (last I checked) it could not be part of Org before 8.4. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. Thanks, Eric -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Eric S Fraga writes: Hello all, I have been following this whole thread with great interest, having posted very early on the use of inline tasks as a solution for the OP. I use inline tasks a lot for both annotations and for TODO tasks when writing papers. I like the link syntax proposed but would much prefer something that includes tasks as well as comments. What is missing, by the way, with the proposed link based comment syntax that inline tasks give is the ability to find them quickly within a (large) document. Maybe I missed this functionality in what has been proposed. Inline tasks are easy to find using C-c / t... There is in org-comment a command `org-comment-display-comments' which will generate a buffer you can see all the comments in, and from that pop to a comment, delete it, etc... And to add to yet another element of the discussion, I have no problem with the [[comment:X][Y]] in the sense of X being hidden in normal view. Back to your regular programming :) thanks, eric -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote: [...] Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? [...] Now I wish we'd named it org-annotate. Is it too late? Simple refactoring of the code? I find org-annotate more expressive of its purpose and doesn't conflict with e.g. org-toggle-comment... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Rasmus writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: *None* of the complexity is in the format itself: if you unloaded org-comment, the comment links would be perfectly human-readable. All of the complexity is in helper functions for manipulating them. I suppose it would be possible to define some non-link syntax for them, but why do that when the link syntax works perfectly well? Because [[comment:X][Y]] is displayed (by default) as Y which can be misleading as X and Y grow out of sync. Perhaps I'm wrong, but I see no point in Y for a comment. Further, nasty stuff is sometimes applied to X such as escaping spaces. In addition, export filters cannot easily be pointed to links (you'd have to make a check on the type of link), and you need a bit more hassle to map over them with org-element etc. Again, that's just my opinion so feel free to ignore it! I would mostly use comments in a transient way during an editing process. e.g. I expect my students to delete my comments after they have addressed them, otherwise, they are out of sync. The only point of Y in the syntax above is to attach the comment to the text as opposed to just having an inline comment. There could be reasons to want super good export, but my main use case is in collaborative editing of org-source, and i would expect in the final version for there to be no remaining comments. There are still reasons to have annotations present, e.g. as tooltips, or file attachments in exported content though, so your point is a good one that funny things may happen with a link type solution. Ah, that's a good point. cl-lib isn't necessary, just convenient, and could be removed. It's only a concern if you want to advocate for including this in Org 8.3. Cheers, Rasmus -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
On Wednesday, 29 Apr 2015 at 10:00, John Kitchin wrote: [...] There is in org-comment a command `org-comment-display-comments' which will generate a buffer you can see all the comments in, and from that pop to a comment, delete it, etc... Ah, thanks. That's good. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? I think so. If anyone thinks that this mechanism warrants actual new Org syntax, I'd be happy to work on implementing that. I also think a new syntax is needed. But, please, let's keep it as simple as possible. We're just talking about annotations-plus-metadata here, right? Not actual in-text TODOs? From what I can tell, rasmus seems to be proposing an in-text TODO, while John's headed in the direction of replicating Track Changes functionality. I've definitely wanted some sort of a track changes equivalent in Org, but we'd want to be careful about this. Assuming we're just talking about annotations on steriods, here are some things I'd personally like to have: 1. Annotations attached to arbitrary text in the buffer. The buffer text should be visible, the annotation data invisible (basically the way links work right now). 2. Plain annotation: just a chunk of free-form paragraph text that is attached to the buffer text. 3. Replacement text: an alternate version of the buffer text; this could be the basis of track changes stuff. 4. Timestamps 5. Custom highlighting 6. Full element status: this would allow parsing of the various properties, and more fully-featured export options. 7. Author metadata would probably be unnecessary with full access to the export channels, but it might still be desirable. 8. Options-line switches to export with annotation, export without annotation, and export using replacement text. That's all I can think of, just trying to get the ball rolling. I don't have any opinions about actual syntax, though something with curly braces might be nice. Eric
Re: [O] Marking/highlighting text temporarily
Rasmus ras...@gmx.us writes:
Hi,
Eric Abrahamsen e...@ericabrahamsen.net writes:
Just to be clear, you think it fits into the category of
incubation-prior-to-core?
I think inlinetasks/comments that are actually *inline* would be nice!
If anyone thinks that this mechanism warrants actual new Org syntax, I'd
be happy to work on implementing that. But to be honest, I think it sits
pretty comfortably on top of what's already available. The only slight
awkwardness comes when you'd like a different face for the annotation
links (currently solved with John Kitchin's hi-lock trick), and the fact
that the link export routines don't have access to the exportation
info/plist channels (ie, when exporting an annotation link to ODT, I'd
like to be able to give the annotation an author element, but as far
as I know I can't get access to that). These aren't major flaws.
See my other post. In addition you'd need to be able to turn them off via
#+OPTIONS: annotations:nil
I'll admit I have dreamed of a syntax that looks like: [[body text to
annotate][TODO:Look this up on the internet:@work]].
I don't like the example. The ordering is weird. Do the first and the
second bracket need to be tied together? Or would something like this
work:
body text to annotate [todo@work: Look this up on the internet]
Or
[todo@work: Look this up on the internet]{body text to annotate}
[todo@work look this up on the internet: body text to annotate]
Okay, so you're basically proposing taking this to a much higher level.
I'm totally in favor, in principle, and don't actually care too much
what the actual syntax looks like. I do think it would be important to
specify the text being annotated, so your first example above wouldn't
be too ideal. The others I'd be happy with.
As the veteran of several small projects that have died of mission
creep, I still wouldn't mind keeping org-comments (I do think it should
be renamed org-annotate) as-is, and letting the real inline todo
project progress separately.
Eric
Re: [O] Marking/highlighting text temporarily
Eric S Fraga e.fr...@ucl.ac.uk writes: On Wednesday, 29 Apr 2015 at 20:34, Eric Abrahamsen wrote: [...] Yup, annotation mechanism is about right. Just to be clear, you think it fits into the category of incubation-prior-to-core? [...] Now I wish we'd named it org-annotate. Is it too late? Simple refactoring of the code? I find org-annotate more expressive of its purpose and doesn't conflict with e.g. org-toggle-comment... No, it's definitely not too late. Depending on the outcome of this whole conversation, I'd like to rename it.
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen writes: John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
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 e...@ericabrahamsen.net wrote: John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
On 2015-04-27, at 12:27, John Kitchin jkitc...@andrew.cmu.edu wrote: This might be a case where having a link type that supports attributes would come in handy. Then you could use these like PDF comments. In the list of PDF comments in Adobe Acrobat for example, there is a checkbox you can use to check them off when you are done with one. Of course, you have to store that state somewhere! I think the pdf comment also stores the author, and maybe other information too like the date and time it was created. I think that Adobe Reader also sends it to the NSA. ;-) John Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Marcin Borkowski mb...@mbork.pl writes: On 2015-04-27, at 12:27, John Kitchin jkitc...@andrew.cmu.edu wrote: This might be a case where having a link type that supports attributes would come in handy. Then you could use these like PDF comments. In the list of PDF comments in Adobe Acrobat for example, there is a checkbox you can use to check them off when you are done with one. Of course, you have to store that state somewhere! I think the pdf comment also stores the author, and maybe other information too like the date and time it was created. I think that Adobe Reader also sends it to the NSA. ;-) I will provide a special org-comment-nsa-export-function option, to help you convey your comments directly to the place where it matters.
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@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 e...@ericabrahamsen.net wrote: Marcin Borkowski mb...@mbork.pl writes: On 2015-04-27, at 12:27, John Kitchin jkitc...@andrew.cmu.edu wrote: This might be a case where having a link type that supports attributes would come in handy. Then you could use these like PDF comments. In the list of PDF comments in Adobe Acrobat for example, there is a checkbox you can use to check them off when you are done with one. Of course, you have to store that state somewhere! I think the pdf comment also stores the author, and maybe other information too like the date and time it was created. I think that Adobe Reader also sends it to the NSA. ;-) I will provide a special org-comment-nsa-export-function option, to help you convey your comments directly to the place where it matters.
Re: [O] Marking/highlighting text temporarily
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 e...@ericabrahamsen.net wrote: Marcin Borkowski mb...@mbork.pl writes: On 2015-04-27, at 12:27, John Kitchin jkitc...@andrew.cmu.edu wrote: This might be a case where having a link type that supports attributes would come in handy. Then you could use these like PDF comments. In the list of PDF comments in Adobe Acrobat for example, there is a checkbox you can use to check them off when you are done with one. Of course, you have to store that state somewhere! I think the pdf comment also stores the author, and maybe other information too like the date and time it was created. I think that Adobe Reader also sends it to the NSA. ;-) I will provide a special org-comment-nsa-export-function option, to help you convey your comments directly to the place where it matters.
Re: [O] Marking/highlighting text temporarily
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 org-comment.el Description: application/emacs-lisp e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
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 e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Okay, this is as far as I got today. I changed some behavior from John's implementation: when following the links, it seemed like displaying the comment text would be more useful than deleting it -- I think many of us have delete-org-link functions lying around. I also couldn't get the add-comment thing to work, as it complained when there was no region, so I changed how that works. Lastly, I spent most of my time learning how tabular list mode works, and haven't actually tested the export. Will save that for tomorrow. Otherwise, here's the introduction from the Commentary. Comments and suggestions very welcome! Provides a new link type for Org that allows you to create comments on arbitrary chunks of text. The link prefix is comment:. Add comments with `org-comment-add-comment'. Following the link will display the text of the comment in a pop-up buffer. The buffer is in special-mode, hit q to dismiss it. Call `org-comment-display-comments' to see all comments in a buffer. See the `org-comment-[backend]-export-style' options for ways to format comments in export. TODO: 1. Better export customization options. 2. What does the ODT comment XML look like? 3. More functions in the display comment buffer: copy as kill... what else? 4. More functions in the comments list buffer, to display, pop to, delete, and edit comment text. 5. Is it possible to have multi-line filled tabular list items? Long comments are not very useful if you can't see the whole thing. 5. Allow multiple comment list buffers attached to different Org buffers. 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@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? org-comment.el Description: application/emacs-lisp
Re: [O] Marking/highlighting text temporarily
John, thanks for this. Very nice. And I can use my preferred LaTeX annotation with it easily. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
Vikas Rawal vikasli...@agrarianresearch.org writes: On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@andrew.cmu.edu wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). Hang on a bit, I'm wasting my afternoon expanding this... Eric
Re: [O] Marking/highlighting text temporarily
Vikas Rawal vikasli...@agrarianresearch.org writes: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? Vikas Bookmarks? hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Marking/highlighting text temporarily
On Friday, 24 Apr 2015 at 09:58, Marcin Borkowski wrote: [...] Why use footnotes when you can use todonotes? Good question! It's personal preference: I prefer footnotes as I am often using narrow margins and anything more than a boxed footnote number is too much... However, it is trivial to change the export template to use todonotes if that's what Vikas prefers. The key message I was trying to get across is the use inlinetasks to leverage the capabilities of org for TODO management. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-951-g2f58e3
Re: [O] Marking/highlighting text temporarily
On 2015-04-24, at 09:40, Eric S Fraga e.fr...@ucl.ac.uk wrote:
On Friday, 24 Apr 2015 at 11:49, Vikas Rawal wrote:
I am revising a long book manuscript, and would like to mark parts of
text (not just the headlines) just to remind myself that these need to
be dealt with.
What could be an the easy way of doing it?
I use inline tasks for this. If you are exporting to PDF via LaTeX, the
following LaTeX definition for inline tasks is quite useful:
#+begin_src emacs-lisp
(setq org-inlinetask-export-templates
'((latex %s\\footnote{%s %s}\\marginpar{\\fbox{\\thefootnote}}
'((unless
(eq todo )
(format \\fbox{\\textsc{%s%s}} todo priority))
heading content
#+end_src
This uses footnotes to put the task information into the document and
uses a little margin note to indicate that a TODO task is present in the
text.
Why use footnotes when you can use todonotes?
https://www.ctan.org/pkg/todonotes
It can even make a list-of-todo-notes. See also
http://tex.stackexchange.com/questions/9796/how-to-add-todo-notes for
more options.
HTH,
eric
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Re: [O] Marking/highlighting text temporarily
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 vikasli...@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
Re: [O] Marking/highlighting text temporarily
John Kitchin jkitc...@andrew.cmu.edu writes: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. John Awesome! I was half expecting to get around to this myself, half hoping someone else would do it :) I've saved the code, and am already using it in a new short story translation. If I come up with any substantial improvements, I'll mention them here. Thanks very much! Eric
Re: [O] Marking/highlighting text temporarily
On 25-Apr-2015, at 6:22 am, John Kitchin jkitc...@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
Re: [O] Marking/highlighting text temporarily
Vikas Rawal vikasli...@agrarianresearch.org writes: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? I use footnotes for this sort of thing, but don't find it very ideal. I've occasionally thought of a link type that operates more like the comment feature of Word Processors That Shall Not Be Named. So you'd do the following: Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. [[Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum.]][#:I hear all this isn't really Latin, but who am I to say?]] Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. I'm making up the #: syntax, but you see what I mean. The comment would disappear, the text would be highlighted somehow, and perhaps it could even be exported to a proper comment in ODT, and turned into a custom container/environment in other export backends. HTML tooltips, marginpars, etc. Just a thought. Eric
Re: [O] Marking/highlighting text temporarily
Eric Abrahamsen e...@ericabrahamsen.net writes: Vikas Rawal vikasli...@agrarianresearch.org writes: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? I use footnotes for this sort of thing, but don't find it very ideal. I've occasionally thought of a link type that operates more like the comment feature of Word Processors That Shall Not Be Named. So you'd do the following: Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. [[Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum.]][#:I hear all this isn't really Latin, but who am I to say?]] Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. I'm making up the #: syntax, but you see what I mean. The comment would disappear, the text would be highlighted somehow, and perhaps it could even be exported to a proper comment in ODT, and turned into a custom container/environment in other export backends. HTML tooltips, marginpars, etc. Allow me to agree with myself further: I do a lot of translation, and handle temporary notes-to-self with footnotes. I'd much rather use the above syntax to wrap questionable passages and put the original text in the comment. That way I can even share it usefully with editors during the publishing process. That would probably mean ODT/Doc, but how sexy would it be to turn in a PDF with marginpar notes? E
Re: [O] Marking/highlighting text temporarily
Vikas Rawal vikasli...@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 '' [1]at each place. The usual Emacs search will take you through them in order. Delete when the fix has been made. hth Glyn Footnotes: [1] Easier than typing in FIXME !
Re: [O] Marking/highlighting text temporarily
Vikas Rawal wrote: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? Inserting `XXX' which are automatically highlighted in red? See Highlight FIXME notes in https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el for an example. Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] Marking/highlighting text temporarily
On Friday, 24 Apr 2015 at 11:49, Vikas Rawal wrote:
I am revising a long book manuscript, and would like to mark parts of
text (not just the headlines) just to remind myself that these need to
be dealt with.
What could be an the easy way of doing it?
I use inline tasks for this. If you are exporting to PDF via LaTeX, the
following LaTeX definition for inline tasks is quite useful:
#+begin_src emacs-lisp
(setq org-inlinetask-export-templates
'((latex %s\\footnote{%s %s}\\marginpar{\\fbox{\\thefootnote}}
'((unless
(eq todo )
(format \\fbox{\\textsc{%s%s}} todo priority))
heading content
#+end_src
This uses footnotes to put the task information into the document and
uses a little margin note to indicate that a TODO task is present in the
text.
I've removed the templates for other export targets from this variable
to keep the email short.
HTH,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-951-g2f58e3
Re: [O] Marking/highlighting text temporarily
On 2015-04-24, at 08:42, Thomas S. Dye t...@tsdye.com wrote: Vikas Rawal vikasli...@agrarianresearch.org writes: I am revising a long book manuscript, and would like to mark parts of text (not just the headlines) just to remind myself that these need to be dealt with. What could be an the easy way of doing it? Bookmarks? No - Bookmark+, with bookmarks that are /highlighted/! hth, Tom Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Marking/highlighting text temporarily
[...] 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
