Re: Using lexical-binding

2021-02-24 Thread Kyle Meyer
Stefan Monnier writes:

>> It looks like add-to-diary-list became an obsolete alias for
>> diary-add-to-list in Emacs 23.1 and was removed in Emacs 25.1,
>> specifically 3f65970414 (Remove calendar code obsolete since at least
>> version 23.1, 2014-10-05).
>
> Ah, thanks for tracking it down, so I guess we can drop this altogether.
> And we can also drop the `condition-case` in `org-diary-default-entry`
> because that change in calling convention is even older than the change
> of name from `add-to-diary-list` to `diary-add-to-list`.

Yes, sounds good.  Done in Org's 0b117f72a.



Re: Using lexical-binding

2021-02-24 Thread Kyle Meyer
Stefan Monnier writes:

> Since I'm not using it, I can't really test the result in any meaningful
> way.  Furthermore, just like `calendar.el`, it relies on dynamic scoping
> and `eval` in all kinds of ways, so it's very difficult to be sure the
> result is "sufficiently similar" to the old behavior not to break some
> funky use somewhere out there.

I probably don't use many fancy agenda features, but I do work regularly
from it.  Running with these changes throughout today, I didn't notice
any issues.  Within the next few days, I'll try to test some non-default
settings and more obscure features that I don't use as part of my normal
workflow, and see if I can find any problems.

I'll also push the current changes to scratch/sm/agenda-lexical with the
hope that others will test and report back.



Re: Bug: org-clone-subtree-with-time-shift invalid interval when using hours [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]

2021-02-24 Thread Kyle Meyer
Kyle Meyer writes:

> I'm guessing h was left off for this command because it didn't seem too
> useful.  But something like below should work (untested), and I don't
> see any particular reason to not support h.
>
> diff --git a/lisp/org.el b/lisp/org.el

Added tests and pushed (15c738545).



Can no longer org-set-link-parameters with "fuzzy" link types

2021-02-24 Thread Adam Sneller
I have a function that searches for broken fuzzy links in org-mode and applies 
org-warning face to anything it finds:

(org-link-set-parameters
"fuzzy"
:face (lambda (path)
(let ((org-link-search-inhibit-query t))
(if (condition-case nil
(save-excursion
(save-match-data
(org-link-search path (point) t)))
(error nil))
'org-link 'org-warning

In 9.4.4 this patch breaks this:

https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba

Is there some other recommended way to get this done as of 9.4.4?

Thanks,

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited


Re: state of the art in org-mode tables e.g. join, etc

2021-02-24 Thread John Kitchin
Thanks for the link! It looks like some useful functions there. It would
be nice to integrate some of those with the rich output of a Jupyter
kernel so you could get native org tables automatically in org-mode.

Derek Feichtinger  writes:

> Hi John,
>
> I invested time some years ago in preparing babel examples, and a lot of
> the description went into using tables. The most detailed documents I
> had for elisp and python.
>
> In order to be productive, e.g. for producing all kinds of scientific
> graphs, but also for doing the finances and planning for our scientific
> computing section I ended up the same as you with mostly going to python
> and leveraging Pandas. I think all of us end up using ":colnames no" as
> the most convenient solution.
>
> https://github.com/dfeich/org-babel-examples/blob/master/python3/python3-babel.org
>
> (especially look at the Pandas section 10)
>
> In that file I also tangle a python library "orgbabelhelper" that is
> available in Conda and PyPi. I mainly use that to work with my tables.
>
> Best regards
> Derek


--
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



[Patch] Update previews correctly with color changes

2021-02-24 Thread Yuri Lensky
The hash computed for LaTeX previews did not actually take into account the
true foreground/background text color, so org would not refresh previews
when themes change.


0001-lisp-org.el-Update-previews-correctly-when-color-chn.patch
Description: Binary data


Re: Turning off all indentation in 9.4.4

2021-02-24 Thread TRS-80

On 2021-02-16 23:30, Kyle Meyer wrote:

TRS-80 writes:

Unfortunately, unless I am doing something wrong, none of these 
options

seem to really restore the previous behavior.  I have set
~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes
to column 0.  However, unfortunately, TAB now no longer jumps to the
indentation level of the previous block (for example, so I can insert 
a

code block or other block structure into a plain list at the correct
level).


I think you're talking about the following behavior.

  * a
  foo

With org-adapt-indentation at nil (or the new headline-data value), foo
doesn't get indented.  This behavior is not new to 9.4.  If you try 
with

9.3.8 and org-adapt-indentation is set to nil, it also will not indent.
Step through org--get-expected-indentation to see how the different
values of org-adapt-indentation are handled.

So, if I'm reading your preferences correctly, it sounds like you want
just the first suggestion in the above snippet, leaving
org-adapt-indentation at its default value:

  (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))


OK, I just did eval-expression (M-:) with (electric-indent-local-mode
-1) in an Orgmode buffer.  After very brief testing, it does indeed seem
to return the desired behavior.  So thanks a lot for that tip!

In the same timeframe, I have also noticed my Logbook entries not being
indented (when changing TODO states) which I think was also brought
about by this change (or rather, my changes to org-adapt-indentation).
I am not sure if I should make a separate thread about that, or not?

Cheers,
TRS-80