* "COMMENT" keyword not properly documented in the manual
@ 2017-01-05 16:31 Alain.Cochard
2017-01-08 23:51 ` Nicolas Goaziou
2017-06-06 15:19 ` multiple agenda views -- sticky agendas?, buffer renaming? Alain.Cochard
0 siblings, 2 replies; 9+ messages in thread
From: Alain.Cochard @ 2017-01-05 16:31 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Alain Cochard
Hello. I am a relatively new org user; I am writing this email after
I spent all morning finding the origin of my problem and searching the
web for an explanation and a solution.
Unaware that "COMMENT" was a specific org string, I had used it at the
beginning of a headline, resulting in biased tag and string searches
('C-c a m' or 'C-c a s'). (I was unlucky: the color of the headline
was the same as the COMMENT's, so I did not notice anything strange.)
I think I finally understood, and found about the
org-agenda-skip-comment-trees variable, but...
But I don't see how I could have avoided the problem. As far as I can
see, the "COMMENT" string only appears in the "Exporting > Comment
lines" subsection of the manual (plus a cryptic part in the "Hacking >
Using the mapping API" appendix). So if one is not yet concerned with
exporting, one does not feel compelled to go into such details...
Besides, it isn't even specified that COMMENTing interferes with
agenda searches.
So it seems to me that something about "COMMENT" should be said at
some place(s) in the "Agenda views" section.
Regards
--
EOST (École et Observatoire des Sciences de la Terre)
IPG (Institut de Physique du Globe) | alain.cochard@unistra.fr
5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44
F-67084 Strasbourg Cedex, France | Fax: +33 (0)3 68 85 01 25
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: "COMMENT" keyword not properly documented in the manual 2017-01-05 16:31 "COMMENT" keyword not properly documented in the manual Alain.Cochard @ 2017-01-08 23:51 ` Nicolas Goaziou 2017-01-10 7:36 ` Alain.Cochard 2017-01-10 20:10 ` Matt Price 2017-06-06 15:19 ` multiple agenda views -- sticky agendas?, buffer renaming? Alain.Cochard 1 sibling, 2 replies; 9+ messages in thread From: Nicolas Goaziou @ 2017-01-08 23:51 UTC (permalink / raw) To: Alain.Cochard; +Cc: emacs-orgmode Hello, Alain.Cochard@unistra.fr writes: > Unaware that "COMMENT" was a specific org string, It is special only at the beginning of a headline (but past TODO keyword and priority cookie, if any). > I had used it at the beginning of a headline, resulting in biased tag > and string searches ('C-c a m' or 'C-c a s'). (I was unlucky: the > color of the headline was the same as the COMMENT's, so I did not > notice anything strange.) I think I finally understood, and found > about the org-agenda-skip-comment-trees variable, but... [...] > So it seems to me that something about "COMMENT" should be said at > some place(s) in the "Agenda views" section. Considering COMMENT is primarily export related, one option would be to make `org-agenda-skip-comment-trees' to nil as a default. In this case, it might not even be necessary to document this variable in the manual. WDYT? -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "COMMENT" keyword not properly documented in the manual 2017-01-08 23:51 ` Nicolas Goaziou @ 2017-01-10 7:36 ` Alain.Cochard 2017-01-10 18:05 ` Samuel Wales 2017-01-13 23:28 ` Nicolas Goaziou 2017-01-10 20:10 ` Matt Price 1 sibling, 2 replies; 9+ messages in thread From: Alain.Cochard @ 2017-01-10 7:36 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, Alain.Cochard Hi, and thanks for the feedback. Nicolas Goaziou writes on Mon 9 Jan 2017 00:51: > > Unaware that "COMMENT" was a specific org string, [...] > > I had used it at the beginning of a headline, resulting in biased tag > > and string searches ('C-c a m' or 'C-c a s'). (I was unlucky: the > > color of the headline was the same as the COMMENT's, so I did not > > notice anything strange.) I think I finally understood, and found > > about the org-agenda-skip-comment-trees variable, but... [...] > > So it seems to me that something about "COMMENT" should be said at > > some place(s) in the "Agenda views" section. > Considering COMMENT is primarily export related, one option would > be to make `org-agenda-skip-comment-trees' to nil as a default. In > this case, it might not even be necessary to document this variable > in the manual. > > WDYT? I was initially tempted to suggest that nil would indeed be a better default for this variable, but in this related post https://lists.gnu.org/archive/html/emacs-orgmode/2013-05/msg00287.html Samuel Wales says that "It defaults to `t' which I think is a good default." Considering the time that you experts spend on endless discussions about what the default value of some variable should be, I'd rather remain agnostic on this one. But unless the use of this variable is obsolete, I feel it has to be documented -- could be as discreet as one sentence in a footnote. Otherwise, with a nil default, even people using the export features would have difficulties to know about it. (More generally, what would be the harm of having some appendix with a list of all customizable variables? Seems to me it could help beginners to learn Org; sure, there is 'C-h v org-<TAB>', but it's not exactly the same for me.) a. -- EOST (École et Observatoire des Sciences de la Terre) IPG (Institut de Physique du Globe) | alain.cochard@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | Fax: +33 (0)3 68 85 01 25 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "COMMENT" keyword not properly documented in the manual 2017-01-10 7:36 ` Alain.Cochard @ 2017-01-10 18:05 ` Samuel Wales 2017-01-13 23:28 ` Nicolas Goaziou 1 sibling, 0 replies; 9+ messages in thread From: Samuel Wales @ 2017-01-10 18:05 UTC (permalink / raw) To: alain.cochard; +Cc: emacs-orgmode, Nicolas Goaziou that was bastien :) On 1/10/17, Alain.Cochard@unistra.fr <Alain.Cochard@unistra.fr> wrote: > Samuel Wales says that -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW. UPDATE 2016-10: home, but not fully free ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "COMMENT" keyword not properly documented in the manual 2017-01-10 7:36 ` Alain.Cochard 2017-01-10 18:05 ` Samuel Wales @ 2017-01-13 23:28 ` Nicolas Goaziou 1 sibling, 0 replies; 9+ messages in thread From: Nicolas Goaziou @ 2017-01-13 23:28 UTC (permalink / raw) To: Alain.Cochard; +Cc: emacs-orgmode Hello, Alain.Cochard@unistra.fr writes: > But unless the use of this variable is obsolete, I feel it has to be > documented -- could be as discreet as one sentence in a footnote. > Otherwise, with a nil default, even people using the export features > would have difficulties to know about it. I dropped a note about in "agenda views" part of the manual. > > (More generally, what would be the harm of having some appendix with a > list of all customizable variables? Seems to me it could help > beginners to learn Org; sure, there is 'C-h v org-<TAB>', but it's not > exactly the same for me.) There is a lot of variables. We cannot possibly document all of them in the manual. However, the best way for a beginnier to discover these options is probably to call "M-x customize-group RET org RET". Regards, -- Nicolas Goaziou 0x80A93738 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "COMMENT" keyword not properly documented in the manual 2017-01-08 23:51 ` Nicolas Goaziou 2017-01-10 7:36 ` Alain.Cochard @ 2017-01-10 20:10 ` Matt Price 1 sibling, 0 replies; 9+ messages in thread From: Matt Price @ 2017-01-10 20:10 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode, Alain.Cochard [-- Attachment #1: Type: text/plain, Size: 1303 bytes --] On Sun, Jan 8, 2017 at 6:51 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Hello, > > Alain.Cochard@unistra.fr writes: > > > Unaware that "COMMENT" was a specific org string, > > It is special only at the beginning of a headline (but past TODO keyword > and priority cookie, if any). > > > I had used it at the beginning of a headline, resulting in biased tag > > and string searches ('C-c a m' or 'C-c a s'). (I was unlucky: the > > color of the headline was the same as the COMMENT's, so I did not > > notice anything strange.) I think I finally understood, and found > > about the org-agenda-skip-comment-trees variable, but... > > [...] > > > So it seems to me that something about "COMMENT" should be said at > > some place(s) in the "Agenda views" section. > > Considering COMMENT is primarily export related, one option would be to > make `org-agenda-skip-comment-trees' to nil as a default. In this case, > it might not even be necessary to document this variable in the manual. > > WDYT? > I'll just say that once I learned about COMMENT -- from the list, not from the manual -- I started using it pretty extensively. Also, the Github org-->html renderer hides COMMENT trees by default. For these reasons, I think the current default is sensible. But yeah, it should be documented. [-- Attachment #2: Type: text/html, Size: 1923 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* multiple agenda views -- sticky agendas?, buffer renaming? 2017-01-05 16:31 "COMMENT" keyword not properly documented in the manual Alain.Cochard 2017-01-08 23:51 ` Nicolas Goaziou @ 2017-06-06 15:19 ` Alain.Cochard 2017-07-03 5:09 ` Bastien 1 sibling, 1 reply; 9+ messages in thread From: Alain.Cochard @ 2017-06-06 15:19 UTC (permalink / raw) To: emacs-orgmode; +Cc: alain.cochard Hello. I want my *Org Agenda* buffer to be open at all times, but I still want to be able to (say) match as many different tags as desired. Googling and searching the archives suggested 2 possible ways: (1) use of sticky agenda views and (2) use 'M-x rename-uniquely'. Use of sticky agendas does not seem to be suited for my need (but maybe I am missing something), while renaming the buffer seems more promising except that it partly fails -- again, maybe I am missing something or there is a bug. (1) Trying with sticky agendas, I do: M-x org-agenda * a M-x make-frame In the newly created frame: M-x org-agenda m some_tag so far, so good. But If, in that same newly created frame, I want to search for another tag, as soon as I do 'M-x org-agenda m', I get the message "Sticky Agenda buffer, use `r' to refresh". Sure, I can refresh, bug cannot search for another tag. Am I doing something wrong? (2) Trying renaming the buffer, I do: M-x org-agenda a M-x rename-uniquely M-x make-frame In the newly created frame: M-x org-agenda m some_tag At this point, the behavior is as I expect in the newly created agenda view: pressing <TAB> on a given line of the agenda view puts the point at the proper place of the proper buffer in the other window. But it does not work that way in the initial agenda view: pressing <TAB> generates the message "Wrong type argument: integer-or-marker-p, nil". Again, am I doing something wrong? Are there other ways of doing what I want? NB: I have used an extremely minimal setup, both with Org version 8.2.10, which is the default for my GNU Emacs 24.5.1 installation, and with Org version 9.0.8-elpa. I have tried with M-x rename-buffer instead of M-x rename-uniquely, but the result is the same. Thank you for any help. Alain -- EOST (École et Observatoire des Sciences de la Terre) IPG (Institut de Physique du Globe) | alain.cochard@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | Fax: +33 (0)3 68 85 01 25 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: multiple agenda views -- sticky agendas?, buffer renaming? 2017-06-06 15:19 ` multiple agenda views -- sticky agendas?, buffer renaming? Alain.Cochard @ 2017-07-03 5:09 ` Bastien 2017-08-22 13:25 ` Alain.Cochard 0 siblings, 1 reply; 9+ messages in thread From: Bastien @ 2017-07-03 5:09 UTC (permalink / raw) To: Alain.Cochard; +Cc: emacs-orgmode Hi Alain, Alain.Cochard@unistra.fr writes: > I want my *Org Agenda* buffer to be open at all times, but I still > want to be able to (say) match as many different tags as desired. > > Googling and searching the archives suggested 2 possible ways: (1) > use of sticky agenda views and (2) use 'M-x rename-uniquely'. "Sticky" agenda buffers means that agenda buffers won't be recreated each time you call M-x org-agenda. I'm not sure this is exactly what you mean by "my *Org Agenda* buffer to be open at all times", is it? Also I'm not sure what is the exact error you are pointing to: can you restate it by saying what you expected from what action, and what you got instead? Thanks, -- Bastien ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: multiple agenda views -- sticky agendas?, buffer renaming? 2017-07-03 5:09 ` Bastien @ 2017-08-22 13:25 ` Alain.Cochard 0 siblings, 0 replies; 9+ messages in thread From: Alain.Cochard @ 2017-08-22 13:25 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Alain.Cochard Bastien writes on Mon 3 Jul 2017 07:09: > Alain.Cochard@unistra.fr writes: > > > I want my *Org Agenda* buffer to be open at all times, but I still > > want to be able to (say) match as many different tags as desired. > > > > Googling and searching the archives suggested 2 possible ways: (1) > > use of sticky agenda views and (2) use 'M-x rename-uniquely'. > "Sticky" agenda buffers means that agenda buffers won't be recreated > each time you call M-x org-agenda. I'm not sure this is exactly what > you mean by "my *Org Agenda* buffer to be open at all times", is it? > > Also I'm not sure what is the exact error you are pointing to: can > you restate it by saying what you expected from what action, and what > you got instead? Hi Bastien, and thank you very much for the feedback. I am sorry for the delay in replying. I now try to explain myself more clearly. Say I have emacs open, with a single frame. If I do M-x org-agenda a I see what I call my "agenda" (not sure this is the proper terminology), in what I assumed was called an "*Org Agenda* buffer" -- I realize now how confusing this could have been, because it seems that all buffers obtained from some 'M-x org-agenda' command are named "Org-agenda." If I now do M-x make-frame I get a 2nd frame. I would like to be able to work with that 2nd frame without modifying the content of the 1st frame. This is what I meant by "my *Org Agenda* buffer to be open at all times" (in the 1st frame in this example). But if, in the 2nd frame, I do M-x org-agenda m tag1 the contents of *both* the 1st and 2nd frames are modified accordingly. I understand this to be normal, but this is not what I want, because my agenda is no longer showing in the 1st frame. I was assuming sticky agendas would produce the behavior I wish, so (starting fresh), I try M-x org-agenda * a then M-x make-frame and, in the 2nd, newly created, frame: M-x org-agenda m tag1 So far, the behavior is as I expect: my agenda is still in the 1st frame while, in the 2nd one, I have the *Org Agenda(m)* buffer, which I can use as expected (typically, put the cursor on some line, press <TAB>, etc.). It is from this point that it appears to me to go wrong; specifically, if I try to do, still in the 2nd frame: M-x org-agenda m tag2 then, as soon as the 'm' is typed, the following message appears in the minibuffer: "Sticky Agenda buffer, use `r' to refresh". But typing 'r' does not do any good. The behavior that I expect is (1) to not see the above mentioned message in the minibuffer, (2) to be able to finish typing 'M-x org-agenda m tag2', (3) have the *Org Agenda(m)* buffer relevant to tag2. In fact, I made progress since my initial email: I had never paid attention to the following message, which appear after the first tag search: Press `C-u r' to search again with new search string I had ignored it because for me it is more convenient to always use the same key combination for a given operation (in this case 'C-c a m' for a tag search). If I do use 'C-u r', then I can indeed perform another tag search (and others afterward), and I can say that the use of a sticky agenda does solve my initial problem! The somehow funny thing is that after this 'C-u r', I can again use 'M-x org-agenda m some_tag'. In fact I cannot use 'M-x org-agenda m some_tag' twice in a row: I have to intermingle it with at least one instance of 'C-u r some_tag'. So I could reformulate my initial email by saying that tag search does not behave the same way whether the agenda is sticky or not: with a non sticky agenda, one may always use 'M-x org-agenda m some_tag' for a tag search whereas this is not possible with a sticky agenda. I hope I could make myself clear this time. Regards, alain -- EOST (École et Observatoire des Sciences de la Terre) IPG (Institut de Physique du Globe) | alain.cochard@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | Fax: +33 (0)3 68 85 01 25 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-08-22 13:26 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-05 16:31 "COMMENT" keyword not properly documented in the manual Alain.Cochard 2017-01-08 23:51 ` Nicolas Goaziou 2017-01-10 7:36 ` Alain.Cochard 2017-01-10 18:05 ` Samuel Wales 2017-01-13 23:28 ` Nicolas Goaziou 2017-01-10 20:10 ` Matt Price 2017-06-06 15:19 ` multiple agenda views -- sticky agendas?, buffer renaming? Alain.Cochard 2017-07-03 5:09 ` Bastien 2017-08-22 13:25 ` Alain.Cochard
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).