* "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-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
* 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
* 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).