Re: [O] how do I search state change dates?

[Michael Welle]

Hello,

"Christopher W. Ryan"  writes:

> This looks promising. However, the example at the link you referenced
> seems to have its state changes inside a LOGBOOK property drawer. My
> state changes are not inside a drawer. See excerpt below.
the shown code should be able to deal with both situations, but it's not
much tested without drawers. It's just...


> To change the
> state, say from TODO to READING, I use C-c C-t and then can choose one
> of my pre-specified states.  Should I put my state changes in a LOGBOOK
> drawer? If so, how does that work?
... that using drawers is my personal preference. I think it looks
cleaner. I have tasks with pages full of state data. It's nice to be
able to fold the drawer and hide the data. The behaviour can be changed
by setting the variable org-log-into-drawer.

Regards
hmw

Re: [O] org-open-line inconsistent treatment of marking characters '#' and '*'

[Tony E . Bennett]

Nicolas Goaziou  writes:

> Tony E. Bennett  writes:
>
>> org-open-line replicates the table marking character '#' (if present) into
>> the new table line but does not do the same for '*'.


> OK, I applied the change in maint. However, I tend to think we should
> not copy any special marker at all, since we don't check if we're in
> a special column anyway.

Thank you Nicolas for adding the '*' treatment.

How would org verify column 1 is a special column beyond just checking for
[#*$] which it does already ?

-- 
--tony

Re: [O] how do I search state change dates?

[Christopher W. Ryan]

This looks promising. However, the example at the link you referenced
seems to have its state changes inside a LOGBOOK property drawer. My
state changes are not inside a drawer. See excerpt below.  To change the
state, say from TODO to READING, I use C-c C-t and then can choose one
of my pre-specified states.  Should I put my state changes in a LOGBOOK
drawer? If so, how does that work?

** DONE Responsible Men  :fiction:BUlibrary:
   - State "DONE"   from "READING"[2018-11-18 Sun 23:17]
   - State "READING"from "TODO"   [2018-11-04 Sun 23:17]
   :PROPERTIES:
   :AUTHORLNAME: Schwarzschild
   :AUTHORFNAME: Edward
   :ISBN: 156512409X
   :END:

Thanks.

--Chris Ryan

Michael Welle wrote:
> Hello,
> 
> "Christopher W. Ryan"  writes:
> 
>> I try to keep track of books I want to read, and when I eventually read
>> them.  I use TODO keyword for books I intend to read, and I change the
>> state to READING and then DONE, as appropriate. Each state change gets a
>> date/time stamp.
> at [0] you will find a bit of code (org-task-dump-logs.el) that
> retrieves all the log data for a given task. Maybe that is helpful if
> you extend it with a loop that iterates over all tasks of a file.
> 
> Regards
> hmw
> 
> [0] https://www.c0t0d0s0.de/otdl/otdl.html
> 

Re: [O] agenda view help - viewing all time entries for a tag

[Kyle Meyer]

[sorry for the slow response]

Jeff Filipovits  writes:

> Say I have a calendar file which is in the following format:
>
> * description of deadline:client1:
> DEADLINE: <2018-10-28 Tue>
>
> * a meeting :client1:
> <2018-11-1 Thu 10:00>
>
>  I would like to be able to view all headlines and time entries associated
> with a particular tag, and to have that information visible in an agenda
> buffer, and for the entries to appear in chronological order along with the
> associated dates
>
> [...]
> 
> It seems like this should be relatively easy to accomplish.

Hmm, I might be missing something obvious, but here’s the best I can
come up with.

First, specify that you want the tag search to sort based on timestamp,
earliest first:

  (add-to-list 'org-agenda-sorting-strategy '(tags timestamp-up))

Then make a custom function that when called on a heading returns the
first timestamp:

  (defun my/org-get-first-timestamp ()
(save-excursion
  (or (and (re-search-forward org-ts-regexp
  (save-excursion (outline-next-heading)
  (point))
  t)
   (match-string 1))
  "")))

(Org might already have a function that would do that, but that seems to
work.)

Now use that function in the agenda prefix for tag searches:

  (add-to-list 'org-agenda-prefix-format '(tags . 
"%-21(my/org-get-first-timestamp) "))

With the example you gave---but changing 2018-11-1 to 2018-11-01 to make
a valid timestamp---‘C-c a m client1’ gives me:

  Headlines with TAGS match: client1
  Press ‘C-u r’ to search again
  2018-10-28 Tuedescription of deadline 
 :client1:
  2018-11-01 Thu 10:00  a meeting   
 :client1:

-- 
Kyle

Re: [O] saving web resources with org

[Kyle Meyer]

"M. P."  writes:

> How can I save a web page or a utube clip with org in some form of organized 
> manner?

I’m not sure, but it might be worth looking into org-board:
https://github.com/scallywag/org-board

-- 
Kyle

Re: [O] How to generate CLOCKSUM property from time ranges?

[Kyle Meyer]

Hello,

[sorry for the late response]

Leo Alekseyev  writes:

> Greetings all,
> I am looking into using `org-invoice` to generate some invoices. It uses
> the CLOCKSUM property, which according to the docs gets auto-generated when
> the clock entries are summed in a subtree.
>
> Concretely, docs say: "CLOCKSUM: The sum of CLOCK intervals in the
> subtree.  ‘org-clock-sum’ must be run first to compute the values in the
> current buffer."  However, `org-clock-sum` is a non-interactive function,
> and evaluating it by hand doesn't do anything for me.
> [...]
> Question: how do I get CLOCKSUM property generated and stored in a subtree
> with timestamps so that org-invoice functions can pick it up?

I haven’t used the CLOCKSUM property (or org-invoice), but my
understanding is that it’s a special property that should not actually
be set in the property drawer: ‘(info "(org)Special properties")’.

Running org-clock-sum doesn’t generate a property drawer, but it does
store the value as a text property.  Say we have this file:

--8<---cut here---start->8---
* TODO things
:LOGBOOK:
CLOCK: [2019-01-12 Sat 17:33]--[2019-01-12 Sat 17:40] =>  0:07
:END:
--8<---cut here---end--->8---

org-invoice retrieves the CLOCKSUM value with org-entry-get.  Here’s
what we get if we run that in the above buffer, before and after calling
org-clock-sum:

  (org-entry-get nil "CLOCKSUM" nil)   ; => nil
  (org-clock-sum)  ; => 7
  (org-entry-get nil "CLOCKSUM" nil)   ; => "0:07"

So, running org-clock-sum (or any function that calls org-clock-sum),
does generate and store a value that org-invoice can use; you just can’t
see it easily.

-- 
Kyle

Re: [O] Bug: clicking on a schedule item no longer pops up org-agenda [9.2 (9.2-elpaplus @ /home/bhepple/.emacs.d/elpa/org-plus-contrib-20181230/)]

[Bob Hepple]

Thanks for the fix - I back-ported it to release_9.2 / 20181230 and it
works fine!!

... and thanks for the hard work of yourself and your team in bringing us
org-mode!!

Cheers


Bob

On Sat, 12 Jan 2019 at 20:50, Nicolas Goaziou 
wrote:

> Hello,
>
> Bob Hepple  writes:
>
> > In a prior version, when I clicked on a SCHEDULED: <...> link, it would
> > popup the org-agenda view. Now (after a M-x package-list-packages U x)
> > it does nothing and displays No link found. Is there a way to restore
> > the old behaviour?
>
> Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] org-table-align function changed, where is the old behavior?

[Craig Luthy]

Hi Nicolas,

emacs version: GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30
orgmode version: Org mode version 9.2 (9.2-elpa @
c:/Users/dad/Dropbox/.emacs.d/elpa/org-20181230/)

I don't know what an ECM is. Need some clarification.

However, regarding the first issue of TAB and RETURN opening the table. I
explained this wrong, and suspect the release was coded up as designed. No
error messages were displayed. But, with further analysis, the expansion
occurs in at least these scenarios:

   - if you delete a row out of the table with 'kill-whole-line
   - insert a row (org-shiftmetadown) then UNDO (undo)
   - it seems that 'undo opens the table in many cases

C-u C-c TAB works as explained.
C-c C-c on the STARTUP keyword works as explained.

This is the table I was experimenting with:

** TABLES (Section 3.1). insert a vertical bar with `\vert'
|---+|
| Key sequence  | description
  |
| <20>  | <48>
 |
|---+|
| M-x table-insert  | tell it # of cols, rows, cell width & height
 |
| M-x table-capture | turn text into a table - asks for delimiter and
other stuff. use ^Q^J for the carriage return. |
| C-u C-c TAB   | narrow all the columns (was C-c C-c)
 |
| C-c TAB   | dynamically narrow column
  |
| C-c - | horizontal line
  |
| C-u C-c - | horizontal line above
  |
| C-c ^ | sort
 |
| C-c + | sum columns
  |
| C-y   | insert total
 |
| M-LEFT\RIGHT  | move column left\right
 |
| M-S-LEFT  | kill column  you're in
 |
| M-S-RIGHT | insert col to right
  |
| M-S-UP| kill row
 |
| M-S-DOWN  | insert row above
 |
| M-x  org-table-import | import TAB-delimited file
  |
| C-c ` | edit truncated text in a separate window.
  |
| C-c \vert | create table from region
 |
| M-x org-table-export  | export TAB-delimited file
  |
| S-RET | copy cell above down to current cell
 |
| junk  | junk
 |
|---+|

Thanks for your help. If I need to create a bug report on the unexpected
column expansion, I suspect that is what an ECM is, could you point to the
right page for sending one?

The release note on these changes could use additional information. I was
able to find this page (https://orgmode.org/Changes.html#orge5c3346) which
helped me initially, but  `C-c C-c' on the STARTUP keyword and  `C-u C-c
C-TAB' mappings you explained to me were missing.

   - explain the new mapping of C-u C-c TAB which does the old format
   behavior.
   - I would have never guessed to do C-c C-c on the STARTUP keyword to
   format everything in the file. Perhaps a reference to that would be
   helpful. To me it seems like an unusual thing to do, so I may have missed
   documentation on this behavior that is found elsewhere.

According to general release note (https://orgmode.org/Changes.html) it
says that editing a column (do you mean a cell?) opens it up and displays
everything. This does not seem to be working for me. "C-`" still works fine
for editing long contents.

Thanks again,
Craig Luthy

On Sat, Jan 12, 2019 at 4:31 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Craig Luthy  writes:
>
> > I create lots of tables in org-mode, many with lots of information and
> long
> > cells. The C-c C-c was heaven because it prettied up my table in one
> > action. If I understand what I have read and am seeing, whenever I TAB or
> > RET all the cells are expanded which creates a scrambled mess that is
> > impossible to navigate because all the rows wrap.
>
> This looks like a bug. Could you provide an ECM?
>
> > Shrinking 1 column at a time with 

Re: [O] org-mode export behavior change in 9.2?

[Haider Rizvi]

"Berry, Charles"  writes:

>> On Jan 11, 2019, at 5:03 PM, Haider Rizvi  wrote:
>> 
>> I've been using literate programming approach with org-babel for a
>> while. I just noticed that with 9.2, when I try to export (c-c c-e h
>> o) an org doc / section, any shell blocks with a named session are
>> executed as it is exporting to html!
>> 
>> I don't think it was this way before?
>
>  
> AFAICS, nothing has changed in the way :session is handled for shell src 
> blocks in a very
> long time.
>
> Perhaps, you had set `:eval never-export' previously, but not now. ??
>
>>  Is there a way to not have it
>> execute each shell block when trying to export.
>
> This seems to work as you would want:
>
> #+begin_src shell :session sh-pcnw3 :eval never-export
> /usr/bin/say something # say it out loud!
> #+end_src
>
>
> If you can identify a release in which the behavior was as you said, it might 
> be possible to
> dig deeper.

Chuck, thanks for responding.

I've never had the never-export set. I'll try to go back and pinpoint
when the change shows up if I can.

Is the difference between named session and without it expected? With
the named session, the block is executed on export, and without it, it
is not executed!

-- 

Re: [O] please read: bug when marking tasks done

[Samuel Wales]

there is a related bug.

when there are multiple repeaters, closing a task with -1 can only
zero the first.

probably it should zero all mutable repeaters.

* MOOT hi
CLOSED: [2019-01-12 Sat 13:54]
<2019-01-13 Sun .+0d>
<2019-01-13 Sun .+1d>
=<2019-01-12 Sat .+1d>=
~<2019-01-12 Sat .+1d>~
hi


On 1/12/19, Samuel Wales  wrote:
> manual> Text in the code and
> verbatim string is not processed for Org mode specific syntax, it is
> exported verbatim.
>
> i assumed that meant /during export/.  it is in the markup section.
>
> thus, someplace in manual, perhaps say that verbatim and code have
> more effects than just export.
>
>
> On 1/12/19, cesar mena  wrote:
>> hello,
>>
>> Nicolas Goaziou  writes:
>>
> Now, we might make its contents by marking them as verbatim, for
> example. E.g.,
>
>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]

 that's not a bad idea, but what about the other way round?

 that is, inactive timestamps with repeaters do not update unless they
 are
 marked as you suggest.  this way current workflows are not affected and
 inactive timestamps can be made to update if requested.
>>>
>>> The other way around is not possible because =...= means "verbatim".
>>> This would be contradictory.
>>
>> i see. i didn't know =...= meant verbatim. so in light of this new
>> knowledge :) your solution makes a lot of sense. i was originally
>> opposed to it because it means current documents will have to change to
>> add =...= but in the end it seems the simplest.
>>
>>> The main question is: what to do with an "inactive time stamp with
>>> repeater".
>>>
>>> The original report, that lead to the incriminated commit, emphasized
>>> the "repeater" part, arguing a repeater should induce the time stamp is
>>> meant to be repeated, notwithstanding its nature.
>>>
>>> You are emphasizing the "inactive" part of it, arguing that anything
>>> inactive should not change dynamically.
>>>
>>> Both arguments can be heard. I agree yours is more conservative. Yet,
>>> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
>>> OP.
>>
>> i'm ok going with the verbatim syntax - rescheduled lines will now look
>> like (w/o the double quotes?):
>>
>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>
>>> I'm trying to keep Org as simple as possible, but different users have
>>> different use cases, and, in some annoying situations like this one,
>>> these use cases conflict.
>>
>> we are ever grateful.
>>
>> best,
>> -cm
>>
>>
>>
>
>
> --
> The Kafka Pandemic: 
>
> The disease DOES progress. MANY people have died from it. And ANYBODY
> can get it at any time.
>
> "You’ve really gotta quit this and get moving, because this is murder
> by neglect." ---
> .
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] Feature request: Allow export to convert broken links to plain text

[Ryan Thompson]

(Apologies for the double post of this email; due to a misconfiguration of
my mailer, I believed my first email hadn't gone through until I remembered
to check the archives.)

On Sat, Jan 12, 2019 at 12:38 PM Ryan Thompson  wrote:

> Hi all,
>
> I have a use case where I'd like for Org Mode to remove broken links
> while preserving their text when exporting. In particular, I'm exporting
> the same file multiple times with different sets of headlines excluded each
> time, and as a result I have to be careful of linking to headlines that
> might not be present in every export. It would be much easier if such links
> could simply be converted back to plain text for that export, while
> remaining as a link for any exports that *do* include the target headline.
> None of the existing settings do quite what I want. The "mark" option comes
> closest. I basically want "mark" but without adding any additional text
> around the link's text. Would the developers be willing to merge such a
> feature if I wrote it? I would implement it by adding another possible
> value to "org-export-with-broken-links", perhaps calling it something like
> "unlink" or "strip" (suggestions for a better name welcome). Alternatively,
> I could implement an option to dispatch broken link handling to an
> arbitrary function.
>
> Thanks,
>
> Ryan Thompson
>
>

[O] Feature request: Allow export to convert broken links to plain text

[Ryan Thompson]

Hi all,

I have a use case where I'd like for Org Mode to remove broken links while
preserving their text when exporting. In particular, I'm exporting the same
file multiple times with different sets of headlines excluded each time,
and as a result I have to be careful of linking to headlines that might not
be present in every export. It would be much easier if such links could
simply be converted back to plain text for that export, while remaining as
a link for any exports that *do* include the target headline. None of the
existing settings do quite what I want. The "mark" option comes closest. I
basically want "mark" but without adding any additional text around the
link's text. Would the developers be willing to merge such a feature if I
wrote it? I would implement it by adding another possible value to
"org-export-with-broken-links", perhaps calling it something like "unlink"
or "strip" (suggestions for a better name welcome). Alternatively, I could
implement an option to dispatch broken link handling to an arbitrary
function.

Thanks,

Ryan Thompson

Re: [O] a small bug in ob-lua.el

[Kyle Meyer]

Hello,

Brad Knotwell  writes:

> Hello all--
>
> I've been using the babel integration with Lua and it has a bug worth
> noting--multi-line header argument variables that are tangled to a
> file will be tangled in a way lua doesn't interpret correctly.  To use
> a specific example:
> [...]
> The following trivial patch resolves it and tangles to a file that Lua
> can evaluate:

Thanks for the report and suggested fix.  Could you add a commit message
(and perhaps a test to test-ob-lua.el) and send a patch generated with
'git format-patch'?  More guidelines on contributing are here:
https://orgmode.org/worg/org-contribute.html#org31412be


-- 
Kyle

[O] org-babel-execute-src-block on +#CALL statement?

[Joon Ro]

Hi,

Eventually I would like to batch-run a src block in a command line. While 
investigating it, I found that org-babel-execute-src-block throws "Wrong type 
argument: consp, nil" error when I run it over a #+CALL statement. For example, 
I can run the test src block below but it fails when the cursor is on the 
#+CALL block.

#+NAME: test
#+BEGIN_SRC emacs-lisp
(message "Success")
#+END_SRC

#+RESULTS: test
: Success

#+CALL: test()


I was wondering if this is a bug, and if there is any way I can run #+CALL 
statement (preferably in the batch mode)?

Best,
Joon

Re: [O] please read: bug when marking tasks done

[Samuel Wales]

manual> Text in the code and
verbatim string is not processed for Org mode specific syntax, it is
exported verbatim.

i assumed that meant /during export/.  it is in the markup section.

thus, someplace in manual, perhaps say that verbatim and code have
more effects than just export.


On 1/12/19, cesar mena  wrote:
> hello,
>
> Nicolas Goaziou  writes:
>
 Now, we might make its contents by marking them as verbatim, for
 example. E.g.,

   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>>
>>> that's not a bad idea, but what about the other way round?
>>>
>>> that is, inactive timestamps with repeaters do not update unless they
>>> are
>>> marked as you suggest.  this way current workflows are not affected and
>>> inactive timestamps can be made to update if requested.
>>
>> The other way around is not possible because =...= means "verbatim".
>> This would be contradictory.
>
> i see. i didn't know =...= meant verbatim. so in light of this new
> knowledge :) your solution makes a lot of sense. i was originally
> opposed to it because it means current documents will have to change to
> add =...= but in the end it seems the simplest.
>
>> The main question is: what to do with an "inactive time stamp with
>> repeater".
>>
>> The original report, that lead to the incriminated commit, emphasized
>> the "repeater" part, arguing a repeater should induce the time stamp is
>> meant to be repeated, notwithstanding its nature.
>>
>> You are emphasizing the "inactive" part of it, arguing that anything
>> inactive should not change dynamically.
>>
>> Both arguments can be heard. I agree yours is more conservative. Yet,
>> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
>> OP.
>
> i'm ok going with the verbatim syntax - rescheduled lines will now look
> like (w/o the double quotes?):
>
>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
>> I'm trying to keep Org as simple as possible, but different users have
>> different use cases, and, in some annoying situations like this one,
>> these use cases conflict.
>
> we are ever grateful.
>
> best,
> -cm
>
>
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] org-mode export behavior change in 9.2?

[Berry, Charles]

> On Jan 11, 2019, at 5:03 PM, Haider Rizvi  wrote:
> 
> I've been using literate programming approach with org-babel for a
> while. I just noticed that with 9.2, when I try to export (c-c c-e h
> o) an org doc / section, any shell blocks with a named session are
> executed as it is exporting to html!
> 
> I don't think it was this way before?

 
AFAICS, nothing has changed in the way :session is handled for shell src blocks 
in a very long time. 

Perhaps, you had set `:eval never-export' previously, but not now. ??

>  Is there a way to not have it
> execute each shell block when trying to export.

This seems to work as you would want:

#+begin_src shell :session sh-pcnw3 :eval never-export
/usr/bin/say something # say it out loud!
#+end_src


If you can identify a release in which the behavior was as you said, it might 
be possible to dig deeper.

HTH,

Chuck

Re: [O] Question on org-agenda-custom-commands tags-todo match syntax

[Kyle Meyer]

Niall Dooley  writes:

> (setq org-agenda-custom-commands
> '(("p" "List Non-done projects"
> tags-todo "-CANCELLED+PROJECT/!+TODO")))
>
> My understanding is that in the tags-todo match that entries to the left of
> the "/" are the tags, those to the right are the todo keywords and that you
> use a "+" to indicate a condition should be satisfied and a "-" when it
> should
> not be satisfied. Is this correct?

That sounds right, though I often forget the details of the match syntax
and have to look it up.  It’s described at

   (info "(org)Matching tags and properties")

The "/" syntax you refer to is talked about at the very end of that
page.

> So in the above snippet the search matches headlines with the tag :PROJECT:
> and not :CANCELLED: and a todo keyword of TODO. With this I have the
> following
> questions which I would appreciate if someone could answer.
>
> Is the "+" on the right hand side before the TODO strictly necessary? I've
> seen snippets which have it and others which do not. Perhaps it is only
> necessary between multiple todo keywords on the right hand side?

AFAIU there’s no reason to distinguish between the behavior of "+" and
"-" on the left and right of "/"; they are the same.  The "/" let’s you
avoid the more verbose TODO="BLAH" form.

At any rate, the "+" isn’t strictly necessary, while "-" is.  If you
have multiple items and you use "+", though, "&" can be dropped.
Combining values with "+" isn’t useful on the RHS of "/", however,
because a TODO keyword can have only one state (i.e., it can’t be "TODO"
and "WAITING").

> What is the significance of the "!" on the right hand side? Should it always
> be present? Again, I've seen snippets with it present and others with it
> absent though it is present more often than not. Would it ever appear on
> the left
> hand side?

>From the info page I linked to above:

  Using ‘C-c a M’ or ‘/!’ will not match TODO keywords in a DONE state.

Hope that helps.

-- 
Kyle

Re: [O] please read: bug when marking tasks done

[cesar mena]

hello,

Nicolas Goaziou  writes:

>>> Now, we might make its contents by marking them as verbatim, for
>>> example. E.g.,
>>>
>>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>
>> that's not a bad idea, but what about the other way round?
>>
>> that is, inactive timestamps with repeaters do not update unless they are
>> marked as you suggest.  this way current workflows are not affected and
>> inactive timestamps can be made to update if requested.
>
> The other way around is not possible because =...= means "verbatim".
> This would be contradictory.

i see. i didn't know =...= meant verbatim. so in light of this new
knowledge :) your solution makes a lot of sense. i was originally
opposed to it because it means current documents will have to change to
add =...= but in the end it seems the simplest. 

> The main question is: what to do with an "inactive time stamp with
> repeater".
>
> The original report, that lead to the incriminated commit, emphasized
> the "repeater" part, arguing a repeater should induce the time stamp is
> meant to be repeated, notwithstanding its nature.
>
> You are emphasizing the "inactive" part of it, arguing that anything
> inactive should not change dynamically.
>
> Both arguments can be heard. I agree yours is more conservative. Yet,
> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
> OP.

i'm ok going with the verbatim syntax - rescheduled lines will now look
like (w/o the double quotes?):

  - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]

> I'm trying to keep Org as simple as possible, but different users have
> different use cases, and, in some annoying situations like this one,
> these use cases conflict.

we are ever grateful.

best,
-cm

Re: [O] please read: bug when marking tasks done

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> ok, so "current headline" is taken broadly. but what about the
> deadline/scheduled part? what makes a time stamp "deadline/scheduled"?
> those are the ones that should change as per the doc.

You are right the docstring is inaccurate here. It is not limited to
scheduled and deadlines, but also to plain time stamps. This is an
important feature.

However, this is not related to the commit we're talking about.

> they're plain lists that haven't changed after they've been written. one
> could use them for billing reports etc ...

Of course.

What I mean is Org has no way to know the meaning of the contents, or
what you want to do with them, if you don't put markers or some special
syntax somewhere.

>> Now, we might make its contents by marking them as verbatim, for
>> example. E.g.,
>>
>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
> that's not a bad idea, but what about the other way round?
>
> that is, inactive timestamps with repeaters do not update unless they are
> marked as you suggest.  this way current workflows are not affected and
> inactive timestamps can be made to update if requested.

The other way around is not possible because =...= means "verbatim".
This would be contradictory.

The main question is: what to do with an "inactive time stamp with
repeater".

The original report, that lead to the incriminated commit, emphasized
the "repeater" part, arguing a repeater should induce the time stamp is
meant to be repeated, notwithstanding its nature.

You are emphasizing the "inactive" part of it, arguing that anything
inactive should not change dynamically.

Both arguments can be heard. I agree yours is more conservative. Yet,
I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
OP.

> yes, i see where you're coming from. i like to keep it simple.
>
>   (setq org-for-mere-mortal t)

I'm trying to keep Org as simple as possible, but different users have
different use cases, and, in some annoying situations like this one,
these use cases conflict.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Capture Template With Link Returns Error [9.2 (9.2-elpaplus @ /home/dwrz/.emacs.d/elpa/org-plus-contrib-20181230/)]

[Nicolas Goaziou]

Hello,

david wen riccardi-zhu  writes:

> Hello and thank you. This behavior did appear to be fixed, but it's
> surfaced once again today.

I couldn't reproduce it.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: clicking on a schedule item no longer pops up org-agenda [9.2 (9.2-elpaplus @ /home/bhepple/.emacs.d/elpa/org-plus-contrib-20181230/)]

[Nicolas Goaziou]

Hello,

Bob Hepple  writes:

> In a prior version, when I clicked on a SCHEDULED: <...> link, it would
> popup the org-agenda view. Now (after a M-x package-list-packages U x)
> it does nothing and displays No link found. Is there a way to restore
> the old behaviour?

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Binding org-insert-todo-heading to M-S-RET

[Nicolas Goaziou]

Hello,

Kévin Le Gouguec  writes:

> Here is a very minor gripe I have with org-mode: is there a reason why
> org-insert-todo-heading should be bound to (kbd "M-S-"), rather
> than (kbd "M-S-RET")?
>
> AFAIU, using "" limits the key binding to the actual "⏎"
> function key, while using "RET" makes any key chord that sends the
> "carriage return" character ("⏎" and "C-m") work transparently.
>
> I admit that Alt-Shift-Control-M sounds unwieldy, but my muscle memory
> has become so accustomed to using "C-m" instead of "" that I
> would welcome a change allowing this alternative.
>
> (
> From my understanding of (emacs)Keymaps and (emacs)Named ASCII
> Chars, using "RET" also has the advantage that bindings can work in
> terminals; IIUC terminals translate presses to "⏎" into the "RET"
> control character, so Emacs never knows that "" was pressed.
>
> However in this particular case I don't believe that the argument
> applies, since AFAIK terminals cannot transmit "S-RET" to Emacs.
> "M-RET" works though, precisely because it uses "RET" and not
> "".
> )
>
> Thank you for your time.

Fair enough. I changed a few  to RET in master.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-open-line inconsistent treatment of marking characters '#' and '*'

[Nicolas Goaziou]

Hello,

Tony E. Bennett  writes:

> org-open-line replicates the table marking character '#' (if present) into
> the new table line but does not do the same for '*'.
>
> Since the semantics of '#' and '*' are so similar I expect them to be
> treated identically when opening a new table line.
>
> Within defun org-table-insert-row, changing this line:
>
>  ;; Fix the first field if necessary
>  (when (string-match "^[ \t]*| *[#$] *|" line)
>
> to:
>
>  ;; Fix the first field if necessary
>  (when (string-match "^[ \t]*| *[#*$] *|" line)
>
> gives the expected behavior.
>
> Can this be fixed?

OK, I applied the change in maint. However, I tend to think we should
not copy any special marker at all, since we don't check if we're in
a special column anyway.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-table-align function changed, where is the old behavior?

[Nicolas Goaziou]

Hello,

Craig Luthy  writes:

> I create lots of tables in org-mode, many with lots of information and long
> cells. The C-c C-c was heaven because it prettied up my table in one
> action. If I understand what I have read and am seeing, whenever I TAB or
> RET all the cells are expanded which creates a scrambled mess that is
> impossible to navigate because all the rows wrap.

This looks like a bug. Could you provide an ECM?

> Shrinking 1 column at a time with C-c TAB is a regretful step
> backwards. Why did you change the existing functionality. I would have
> rather seen that retained and a new option to do narrowing one column
> at a time.
>
> I have played with '#+STARTUP: align shrink' but it does not seem to work
> when I open the buffer. It may work if I open the file for the first time,
> but that is not what I normally do. I hit many files and just leave the
> buffers around.

I think you need to use `C-c C-c' on the STARTUP keyword.

> Now that you have changed the way org-table-align works, could you also add
> a "new" feature that works like the originall C-c C-c did and format the
> column widths in one motion.

This behaviour is bound to `C-u C-c C-TAB'.

Regards,

-- 
Nicolas Goaziou

[O] Question on org-agenda-custom-commands tags-todo match syntax

[Niall Dooley]

Firstly, I've searched online and even posted to both the emacs and orgmode
subreddits but to no avail.

Consider the following snippet:

(setq org-agenda-custom-commands
'(("p" "List Non-done projects"
tags-todo "-CANCELLED+PROJECT/!+TODO")))

My understanding is that in the tags-todo match that entries to the left of
the "/" are the tags, those to the right are the todo keywords and that you
use a "+" to indicate a condition should be satisfied and a "-" when it
should
not be satisfied. Is this correct?

So in the above snippet the search matches headlines with the tag :PROJECT:
and not :CANCELLED: and a todo keyword of TODO. With this I have the
following
questions which I would appreciate if someone could answer.

Is the "+" on the right hand side before the TODO strictly necessary? I've
seen snippets which have it and others which do not. Perhaps it is only
necessary between multiple todo keywords on the right hand side?

What is the significance of the "!" on the right hand side? Should it always
be present? Again, I've seen snippets with it present and others with it
absent though it is present more often than not. Would it ever appear on
the left
hand side?

Thank you.