[O] org-babel-expand-src-block behavior

[Ken Mankoff]

Hi,

I've just learned about =org-babel-expand-src-block= (from [1]) which seems 
like an improvement over =org-edit-special=, because variables are expanded.

But I notice two issues with it, and I'm wondering if these are intentional or 
bugs, or if there are work-arounds.

First, the buffer is read-only (which someone else claims is a bug [2]), and 
second, if I make changes and then exit the expanded block (via C-') without 
saving, the changes are lost. If I enter =org-edit-special= and exit w/o 
saving, the changes are propagated back to the buffer.

Cheers,

  -k.

Org version:
Org mode version 9.0.9 (9.0.9-68-g492420-elpaplus @ 
/Users/mankoff/.emacs.d/elpa/org-plus-contrib-20170807/)


[1] 
https://emacs.stackexchange.com/questions/34821/pass-variable-from-src-block-to-org-edit-src-code

[2] 
https://emacs.stackexchange.com/questions/29368/org-babel-noweb-expansion-when-sending-c-c-buffer-to-python-shell

Re: [O] Escaping links

[Fabrice Popineau]

2017-08-11 19:31 GMT+02:00 John Kitchin :

> Could you put some magic at the beginning of the string that indicates it
> is encoded?
>
>
For my own needs, yes I could probably define a handler for my special kind
of abbreviations.

I have a too small number of such files, so I renamed them.

I mainly wanted to have an update (thanks Nicolas) on the current status
about this escape thing
in case I missed something.

Regards,

Fabrice

Re: [O] [PATCH] lisp/org.el: make org-open-at-point handle parens in encoded urls correctly

[Marc Ihm]

Am 11.08.2017 um 18:10 schrieb Nicolas Goaziou:

Hello,

Marc Ihm  writes:


the attached patch changes org-open-at-point in org.el:

Currently, when opening an url the function org-open-at-point uses the
variable path, which is the result of applying org-link-unescape on
the original url. Thus, all special chars like '() "' etc. which were
originally encoded like %20%28 etc. are reverted to their clear text
form. This worked for me in most cases, but gives me errors when my
url contains encoded chars like '()', i.e. %28%29.

The submitted patch fixes this by simply using the original url with
all special chars still encoded.

Please consider applying it, if fit.


Thank you.

The problem here is that Org could introduce additional percent-encoding
upon creating a link. This additional layer needs to be removed before
opening the link.

I think there's a deeper issue to solve here. Your patch is likely to
move the problem elsewhere.

Regards,



Hi Nicolas,

well the code which I tried to patch is indeed convoluted and changing 
things might indeed have side effects; so I keep this fix for myself and 
see how it behaves on the long run :-)


Thanx for explaining !

regards
Marc

Re: [O] Bug: Marking repeated tasks with two tags as DONE causes problems

[Colin Baxter]

> "Nicolas" == Nicolas Goaziou  writes:

Nicolas> I still cannot reproduce it.

Nicolas> Does the very recent
Nicolas> 10b1cfb0317274a91500562a2872f2626160f079 fix this?

Things seem ok for me too. I had a separate issue with empty tags
appearing in habits, which I discovered was due to my settings of the
variables org-habit-graph-column, org-habit-preceding-days,
org-habit-following-days being too far from the defaults of 40, 21, 7
respectively.

Thank you very much for all your efforts and time.

Best wishes,

Colin.

-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] Escaping links

[John Kitchin]

Could you put some magic at the beginning of the string that indicates it
is encoded?

On Fri, Aug 11, 2017 at 8:15 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Fabrice Popineau  writes:
>
> > Are links to a file whose name already holds (url-)escaped chars
> supported?
> >
> > If I have a directory named "c:/temp/foo bar/"
> > and files in this directory named
> > foo.txt
> > foo bar.txt
> > foo%2Fbar.txt
> >
> > I can create links in an Org buffer by using `insert' but I find the
> > situation a bit confusing.
> >
> > #+LINK: temp file:c:/temp/%s
> >
> > 1. [[temp:foo bar/foo bar.txt]]
> > 2. [[temp:foo%20bar/foo bar.txt]]
> > 3. [[temp:foo bar/foo%20bar.txt]]
> > 4. [[temp:foo%20bar/foo%20bar.txt]]
> >
> >
> > All of these links seem to work the same way.
> >
> > 5. [[temp:foo bar/foo%2Fbar.txt]]
> > 6. [[temp:foo bar/foo%252Fbar.txt]]
> > 7. [[temp:foo%20bar/foo%252Fbar.txt]]
> >
> > Link 5 does not work.
> >
> > Link 6 and 7 do work: as long as I press enter on the link, I visit the
> > file.
> >
> > Unfortunately, if I edit these links with 'C-c C-l', doing nothing
> > (return), Org replaces the escaped chars and unescape them.
> >
> > I have grabbed files whose name hold such %2F %3A and so on escaped
> chars.
> > Do I have any option to make a link point at them or should I rename
> > them?
>
> You might get around it by not using link abbreviation.
>
> Anyway, the core problem here is that:
>
>   1. Org uses percent escaping to get around its own limitations (e.g., no
>  square brackets allowed in a link);
>   2. it's not possible to know if a string is percent-encoded or not;
>   3. percent-encoding is not idempotent.
>
> Using a different escaping mechanism to solve 1 and never ever
> percent-decode an URL could put an end to the link mess.
>
> Finding an escaping mechanism that also solves 2 is yet to be done.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
> --
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

Re: [O] iCalendar export and missed deadlines.

[Nicolas Goaziou]

Hello,

Michaël Cadilhac  writes:

> Is there a way to change this behavior so that the item is duplicated
> as long as it's not DONE?

I don't think so.

> If not, where is a good starting point in ox-icalendar.el to hack this
> in?

`org-icalendar-entry' dispatches a headline (ENTRY), to various workers
(e.g., `org-icalendar--vevent'). I would start from there.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] lisp/org.el: make org-open-at-point handle parens in encoded urls correctly

[Nicolas Goaziou]

Hello,

Marc Ihm  writes:

> the attached patch changes org-open-at-point in org.el:
>
> Currently, when opening an url the function org-open-at-point uses the
> variable path, which is the result of applying org-link-unescape on
> the original url. Thus, all special chars like '() "' etc. which were
> originally encoded like %20%28 etc. are reverted to their clear text
> form. This worked for me in most cases, but gives me errors when my
> url contains encoded chars like '()', i.e. %28%29.
>
> The submitted patch fixes this by simply using the original url with
> all special chars still encoded.
>
> Please consider applying it, if fit.

Thank you.

The problem here is that Org could introduce additional percent-encoding
upon creating a link. This additional layer needs to be removed before
opening the link.

I think there's a deeper issue to solve here. Your patch is likely to
move the problem elsewhere.

Regards,

-- 
Nicolas Goaziou

Re: [O] remove TODO state in agenda view

[Adam Porter]

Julien Cubizolles  writes:

> That's also what it does. It's only a minor annoyance I just noticed
> because I'm in the process of cleaning long overdue tasks, but it would
> be nice if B t could use the same dialog.

Agreed!  :)

Re: [O] Can't remove deadline or schedule in bulk mode

[Adam Porter]

Kyle Meyer  writes:

> Since you have the git repo set up and have a good/bad range, you can use
> git bisect to find the offending commit.
>
> Based on changes that touched org-agenda-bulk-action recently, my guess
> is 4f578a3f7 (org-agenda: Small refactoring, 2017-05-12).  Quickly
> looking at that patch (and not testing), I think ?d's
>
> `(lambda ()
>(let ((org-log-redeadline (and org-log-redeadline 'time)))
>  (org-agenda-deadline arg ,time)))
>
> should s/arg/',arg/.
>
> The code for ?s is similar, so I'd guess you'd hit the same error when
> running C-u B s.

I'm not sure.  I thought so too, at first, but here's the working code
from 9.0.5:

#+BEGIN_SRC elisp
(setq cmd `(eval '(let ((org-log-reschedule
 (and org-log-reschedule 'time)))
(,c1 arg ,time
+#END_SRC

"arg" is not unquoted there.  Also, a very silly test, but in my current
Org 9.0.5 configuration, I evaled the org-agenda-bulk-action function
from master, with the code you quoted, and it works.

Re: [O] Escaping links

[Nicolas Goaziou]

Hello,

Fabrice Popineau  writes:

> Are links to a file whose name already holds (url-)escaped chars supported?
>
> If I have a directory named "c:/temp/foo bar/"
> and files in this directory named
> foo.txt
> foo bar.txt
> foo%2Fbar.txt
>
> I can create links in an Org buffer by using `insert' but I find the
> situation a bit confusing.
>
> #+LINK: temp file:c:/temp/%s
>
> 1. [[temp:foo bar/foo bar.txt]]
> 2. [[temp:foo%20bar/foo bar.txt]]
> 3. [[temp:foo bar/foo%20bar.txt]]
> 4. [[temp:foo%20bar/foo%20bar.txt]]
>
>
> All of these links seem to work the same way.
>
> 5. [[temp:foo bar/foo%2Fbar.txt]]
> 6. [[temp:foo bar/foo%252Fbar.txt]]
> 7. [[temp:foo%20bar/foo%252Fbar.txt]]
>
> Link 5 does not work.
>
> Link 6 and 7 do work: as long as I press enter on the link, I visit the
> file.
>
> Unfortunately, if I edit these links with 'C-c C-l', doing nothing
> (return), Org replaces the escaped chars and unescape them.
>
> I have grabbed files whose name hold such %2F %3A and so on escaped chars.
> Do I have any option to make a link point at them or should I rename
> them?

You might get around it by not using link abbreviation.

Anyway, the core problem here is that:

  1. Org uses percent escaping to get around its own limitations (e.g., no
 square brackets allowed in a link);
  2. it's not possible to know if a string is percent-encoded or not;
  3. percent-encoding is not idempotent.

Using a different escaping mechanism to solve 1 and never ever
percent-decode an URL could put an end to the link mess.

Finding an escaping mechanism that also solves 2 is yet to be done.


Regards,

-- 
Nicolas Goaziou

Re: [O] Can't remove deadline or schedule in bulk mode

[Kyle Meyer]

Julien Cubizolles  writes:

> Adam Porter  writes:
>
>> Julien Cubizolles  writes:
>>
>>> In an agenda buffer, C-u B d should clear the deadline of the entries
>>> marked the way C-u does on a single entry. I think it's what it used to
>>> do some time ago. Instead, I get:
>>>
>>> org-agenda-deadline: Invalid function: 4
>>
>> FWIW, works for me on Org 9.0.5.
>
> Indeed, works for me on Org mode version 9.0.9 (release_9.0.9 @ 
> /usr/share/emacs/26.0.50/lisp/org/)
>
> but not on Org mode version 9.0.9 (release_9.0.9-738-g8ab9a8 @ 
> /home/wilk/git-repositories/org-mode/lisp/)

Since you have the git repo set up and have a good/bad range, you can use
git bisect to find the offending commit.

Based on changes that touched org-agenda-bulk-action recently, my guess
is 4f578a3f7 (org-agenda: Small refactoring, 2017-05-12).  Quickly
looking at that patch (and not testing), I think ?d's

`(lambda ()
   (let ((org-log-redeadline (and org-log-redeadline 'time)))
 (org-agenda-deadline arg ,time)))

should s/arg/',arg/.

The code for ?s is similar, so I'd guess you'd hit the same error when
running C-u B s.

-- 
Kyle

[O] Escaping links

[Fabrice Popineau]

Hi,

Are links to a file whose name already holds (url-)escaped chars supported?

If I have a directory named "c:/temp/foo bar/"
and files in this directory named
foo.txt
foo bar.txt
foo%2Fbar.txt

I can create links in an Org buffer by using `insert' but I find the
situation a bit confusing.

#+LINK: temp file:c:/temp/%s

1. [[temp:foo bar/foo bar.txt]]
2. [[temp:foo%20bar/foo bar.txt]]
3. [[temp:foo bar/foo%20bar.txt]]
4. [[temp:foo%20bar/foo%20bar.txt]]


All of these links seem to work the same way.

5. [[temp:foo bar/foo%2Fbar.txt]]
6. [[temp:foo bar/foo%252Fbar.txt]]
7. [[temp:foo%20bar/foo%252Fbar.txt]]

Link 5 does not work.

Link 6 and 7 do work: as long as I press enter on the link, I visit the
file.

Unfortunately, if I edit these links with 'C-c C-l', doing nothing
(return), Org replaces the escaped chars and unescape them.

I have grabbed files whose name hold such %2F %3A and so on escaped chars.
Do I have any option to make a link point at them or should I rename them?

Regards,

Fabrice

Re: [O] remove TODO state in agenda view

[Julien Cubizolles]

Adam Porter  writes:

> Julien Cubizolles  writes:
>
>> Got it: the problem occurs when trying to clear the TODO state of
>> several entries through a bulk action:
>>
>> * mark several entries
>>
>> * "B t" doesn't offer to clear the TODO state with space like "t" does
>>   on a single entry.
>
> Yes, I guess that's because it uses completing-read to complete the
> tags, instead of using the single-key tag selection.  At least, that's
> how it works for me.

That's also what it does. It's only a minor annoyance I just noticed
because I'm in the process of cleaning long overdue tasks, but it would
be nice if B t could use the same dialog.

Julien.

Re: [O] Can't remove deadline or schedule in bulk mode

[Julien Cubizolles]

Adam Porter  writes:

> Julien Cubizolles  writes:
>
>> In an agenda buffer, C-u B d should clear the deadline of the entries
>> marked the way C-u does on a single entry. I think it's what it used to
>> do some time ago. Instead, I get:
>>
>> org-agenda-deadline: Invalid function: 4
>
> FWIW, works for me on Org 9.0.5.

Indeed, works for me on Org mode version 9.0.9 (release_9.0.9 @ 
/usr/share/emacs/26.0.50/lisp/org/)

but not on Org mode version 9.0.9 (release_9.0.9-738-g8ab9a8 @ 
/home/wilk/git-repositories/org-mode/lisp/)

Julien.

[O] Org-table alignment in Arabic

[jamdrug]

  
  
Dear Sir/Madam,
  
  I am new to this email list about org-mode, first of all thanks to
  all contributors of org-mode. I am here seeking your help
  considering org-table and Arabic text, the issue is described in
  this post of mine sometime ago:
  https://emacs.stackexchange.com/q/30495/2443
  
  Look forward to your feedback. Best Regards. 

  

Re: [O] Bug: Marking repeated tasks with two tags as DONE causes problems

[Josh Moller-Mara]

Nicolas Goaziou  writes:

>
> I still cannot reproduce it.
>
> Does the very recent 10b1cfb0317274a91500562a2872f2626160f079 fix this?
>

Yup. That commit seems to fix it.

Thanks!

Best,
Josh

Re: [O] Bug: Marking repeated tasks with two tags as DONE causes problems

[Colin Baxter]

Dear Josh,
> "Josh" == Josh Moller-Mara  writes:

Josh> Hello,

Josh> I'm starting to encounter a strange, silent problem when
Josh> switching the state of a task with multiple tags. With the
Josh> following minimal example:

Josh> #+STARTUP: logdone #+STARTUP: logdrawer

Josh> * TODO Hello :hi:there: SCHEDULED: <2017-08-11 Fri .+1d>

Josh> Switching The "hello" task from "TODO" to "DONE" should keep
Josh> the task as "TODO", but schedule it in the future. Instead,
Josh> the file ends up looking like:

Josh> #STARTUP: logdone :hi:there:

Josh> #+STARTUP: logdrawer * DONE Hello :hi:there:

Josh>   CLOSED: [2017-08-11 Fri 14:57] SCHEDULED: <2017-08-12 Sat
Josh> .+1d>

Josh> Where the task is marked as "DONE", and weirdly tags are added
Josh> in some of the startup config at the beginning of the file.

This may be related somehow to the problem mentioned in the thread
"Change in appearance of org-todo-keywords". It's good to have your
minimal example.

Best wishes.

-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] Bug: Marking repeated tasks with two tags as DONE causes problems

[Nicolas Goaziou]

Hello,

Colin Baxter  writes:

> Dear Josh,
>> "Josh" == Josh Moller-Mara  writes:
>
> Josh> Hello,
>
> Josh> I'm starting to encounter a strange, silent problem when
> Josh> switching the state of a task with multiple tags. With the
> Josh> following minimal example:
>
> Josh> #+STARTUP: logdone #+STARTUP: logdrawer
>
> Josh> * TODO Hello :hi:there: SCHEDULED: <2017-08-11 Fri .+1d>
>
> Josh> Switching The "hello" task from "TODO" to "DONE" should keep
> Josh> the task as "TODO", but schedule it in the future. Instead,
> Josh> the file ends up looking like:
>
> Josh> #STARTUP: logdone :hi:there:
>
> Josh> #+STARTUP: logdrawer * DONE Hello :hi:there:
>
> Josh>   CLOSED: [2017-08-11 Fri 14:57] SCHEDULED: <2017-08-12 Sat
> Josh> .+1d>
>
> Josh> Where the task is marked as "DONE", and weirdly tags are added
> Josh> in some of the startup config at the beginning of the file.
>
> This may be related somehow to the problem mentioned in the thread
> "Change in appearance of org-todo-keywords". It's good to have your
> minimal example.

I still cannot reproduce it.

Does the very recent 10b1cfb0317274a91500562a2872f2626160f079 fix this?

Regards,

-- 
Nicolas Goaziou

[O] Bug: Marking repeated tasks with two tags as DONE causes problems

[Josh Moller-Mara]

Hello,

I'm starting to encounter a strange, silent problem when switching the
state of a task with multiple tags. With the following minimal example:

#+STARTUP: logdone
#+STARTUP: logdrawer
* TODO Hello :hi:there:
  SCHEDULED: <2017-08-11 Fri .+1d>

Switching The "hello" task from "TODO" to "DONE" should keep the task as
"TODO", but schedule it in the future. Instead, the file ends up looking
like:

#STARTUP: logdone :hi:there:
#+STARTUP: logdrawer
* DONE Hello :hi:there:
  CLOSED: [2017-08-11 Fri 14:57] SCHEDULED: <2017-08-12 Sat .+1d>

Where the task is marked as "DONE", and weirdly tags are added in some
of the startup config at the beginning of the file.

I'm using

Emacs  : GNU Emacs 26.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.5)
 of 2017-01-18
Package: Org mode version 9.0.9 (release_9.0.9-746-g8fa6c0 @ 
/usr/local/share/emacs/site-lisp/org/)

There still seems to be a problem with org-toggle-tag, which is causing
this. I think it has to do with the "replace-match"
again. "org-split-string" doesn't save match data, so "replace-match"
replaces the wrong thing.

Best,
Josh