Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28

[Kyle Meyer]

Joseph Mingrone writes:

> On Fri, 2020-07-17 at 01:41, Kyle Meyer  wrote:
[...]
>> I'll plan to apply it in a day or two unless there are objections.
>
> So far so good here.  It fixes the errors running 28.0.50 (85eaa83 from
> 2020-07-16) and the latest org-mode-contrib.

Thanks for testing.  Pushed (b2b587387).

Re: [BUG] incorrect (and slow) indentation of logbook entries

[Matt Lundin]

Matt Lundin  writes:

> Commit e3b79ad2bf7ab7b91c0ad2b8383d639bfe154ce7 from Feb. 9, 2020 (Allow
> a new value for `org-adapt-indentation') introduced a bug that causes
> logbooks to be incorrectly indented when promoting an entry. As a
> result, there are also significant slowdowns when promoting and demoting
> an entry with hundreds of logbook entries.

I did some more investigation and think the bug may lie deeper. The
commit above changed the functions used in org-fixup-indentation. Prior
to the commit org-fixup-indentation called org-indent-line on each line
within a LOGBOOK. Now it calls org-indent-region on the entire LOGBOOK.
So the problems seem to lie in org-indent-region.

To test this, I manually called org-indent-region on a region containing
a LOGBOOK. I saw the same indentation problems and slowness as I
reported in the previous email. Here are the profiling results from
calling org-indent-region on a LOGBOOK containing 303 lines (mix of
notes, clock drawers, state changes):

org-indent-region 303 
20.374798015  0.0672435578
org-element-at-point  655 
6.7059473859  0.0102380876
org-element--parse-to 654 
6.6907969839  0.0102305764
org-element--current-element  36791   
6.3040008640  0.0001713462
org-element--list-struct  3372
3.6317395729  0.0010770283
org--get-expected-indentation 355 
3.004313850.0084628559
org-element-clock-parser  2738
0.7868292469  0.0002873737
org-element-item-parser   29700   
0.7527248339  2.534...e-05
org-element-timestamp-parser  2738
0.7245477349  0.0002646266
org-parse-time-string 5476
0.6267072680  0.0001144461
org-element--collect-affiliated-keywords  4026
0.2572965799  6.390...e-05
org-element-drawer-parser 654 
0.1057650070  0.0001617201
org-element-plain-list-parser 3372
0.0736009140  2.182...e-05
org-get-limited-outline-regexp9063
0.0575772250  6.352...e-06
org-at-heading-p  8083
0.0267149439  3.305...e-06
org-element--cache-put36791   
0.0176797030  4.805...e-07
org-element-paragraph-parser  327 
0.011128276   3.403...e-05

[BUG] incorrect (and slow) indentation of logbook entries

[Matt Lundin]

Commit e3b79ad2bf7ab7b91c0ad2b8383d639bfe154ce7 from Feb. 9, 2020 (Allow
a new value for `org-adapt-indentation') introduced a bug that causes
logbooks to be incorrectly indented when promoting an entry. As a
result, there are also significant slowdowns when promoting and demoting
an entry with hundreds of logbook entries.

For instance, when running org-promote-subtree on an entry with 300+
entries, elp-profiling showed that org-indent-region is called 305 times
for a total of 29.4 seconds.

org-indent-region305 29.465412747  0.0966079106

By contrast, prior to the above commit (e3b79ad) org-promote-subtree
calls org-indent-region only 2 times on the same subtree:

org-indent-region2   0.006902560.00345128

I haven't included the full logbook here for obvious reasons. But to
reproduce the indentation bug, promote the following entry with
org-promote-subtree:

--8<---cut here---start->8---
** TODO Do this
   SCHEDULED: <2020-07-18 Sat .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2020-07-18 Sat 11:14]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2020-07-17 Fri 23:59]
   - State "DONE"   from "NOW"[2020-07-16 Thu 10:19]
   CLOCK: [2020-07-16 Thu 09:22]--[2020-07-16 Thu 10:19] =>  0:57
   - State "DONE"   from "NOW"[2020-07-13 Mon 15:11]
   CLOCK: [2020-07-13 Mon 14:52]--[2020-07-13 Mon 15:11] =>  0:19
   - State "DONE"   from "NOW"[2020-07-12 Sun 14:44]
   CLOCK: [2020-07-12 Sun 14:09]--[2020-07-12 Sun 14:44] =>  0:35
   - State "DONE"   from "TODO"   [2020-07-10 Fri 16:07]
   - State "DONE"   from "NOW"[2020-07-07 Tue 13:30]
   CLOCK: [2020-07-07 Tue 13:21]--[2020-07-07 Tue 13:30] =>  0:09
   - State "DONE"   from "NOW"[2020-07-06 Mon 09:32]
   :END:
--8<---cut here---end--->8---

After calling org-promote-subtree, notice that the first CLOCK entry and
all subsequent entries are incorrectly indented:

--8<---cut here---start->8---
* TODO Do this
  SCHEDULED: <2020-07-18 Sat .+1d>
  :PROPERTIES:
  :LAST_REPEAT: [2020-07-18 Sat 11:14]
  :END:
  :LOGBOOK:
  - State "DONE"   from "TODO"   [2020-07-17 Fri 23:59]
  - State "DONE"   from "NOW"[2020-07-16 Thu 10:19]
CLOCK: [2020-07-16 Thu 09:22]--[2020-07-16 Thu 10:19] =>  0:57
- State "DONE"   from "NOW"[2020-07-13 Mon 15:11]
CLOCK: [2020-07-13 Mon 14:52]--[2020-07-13 Mon 15:11] =>  0:19
- State "DONE"   from "NOW"[2020-07-12 Sun 14:44]
CLOCK: [2020-07-12 Sun 14:09]--[2020-07-12 Sun 14:44] =>  0:35
- State "DONE"   from "TODO"   [2020-07-10 Fri 16:07]
- State "DONE"   from "NOW"[2020-07-07 Tue 13:30]
CLOCK: [2020-07-07 Tue 13:21]--[2020-07-07 Tue 13:30] =>  0:09
- State "DONE"   from "NOW"[2020-07-06 Mon 09:32]
  :END:
--8<---cut here---end--->8---

Best,

Matt

Could Babel honor spreadsheet formulas?

[Uwe Brauer]

Hello 

The orgtbl-join package honors spreadsheet as the following example
shows

#+NAME: TA
| Name  | col1 | col2 |
|---+--+--|
| User1 |2 |2 |

#+NAME: TB
| Name  | col3 |
|---+--|
| User1 |4 |

#+NAME: Result
#+BEGIN: join :mas-table "TA" :mas-column "Name" :ref-table "TB" :ref-column 
"Name"
| Name  | col1 | col2 | col3 |   |
|---+--+--+--+---|
| User1 |2 |2 |4 | 8 |
#+TBLFM: $5=vsum($2..$4);f1
#+END:


So whenever you actualize TA, the table Results will be upgraded.

Unfortunately this package only allow you to add columns not rows. 

In order to add rows the following code can be used 
#+begin_src elisp :var table1=TA  :var table2=TB  :colnames t
(append table1 table2  )
#+end_src

Restulting in 

#+RESULTS:
| User1 | 2 | 2 |
| User1 | 4 |   |
However when I modify this to 

#+Name: New
#+RESULTS:
| User1 | 2 | 2 | 4 |
| User1 | 4 |   | 4 |
#+TBLFM: $4=vsum($2..$3);f1

And upgrade one of the table, execute the babel code, the spreadsheet
formula is gone.

So could babel somehow respect the spreadsheet formula?

Regards

Uwe Brauer 

Support for simultaneous running clocks?

[Carlo Tambuatco]

I don't know if anyone has suggested or is working on the ability for org
mode to
keep track of multiple running clocks simultaneously. I'd like the ability
to keep
track of, for example, how long something takes to compile while I keep
track of
how long I am working on some other project task at the same time.

Re: Search for an entry expands parent

[Kyle Meyer]

Gt Uit writes:

> Updates since my last email:
> - Sometimes the first C-s yields intended result (minimal), with
> subsequent C-s searches expanding all entries.
> - I tried on Emacs 28.0.50 and am getting the same results.
> - I tried with emacs -Q and isearch minimal behaves properly!
> - I tried a live distribution (Linux Mint 20 Ulyana, same
> distribution I am currently using) and isearch minimal behaves
> properly.
> - I tried the following without any success:
> + Remove all emacs related packages and reinstall emacs (via apt)
> + Install emacs from snap.
>  
> Now that I have narrowed down the bug to be something local to my
> current installation please advise on how to debug/resolve.

Something that might give you a clue about what's going on is stepping
through org-show-set-visibility, comparing what happens when it works as
expected and what happens when it doesn't.  If you haven't used Edebug
before, take a look at its node in the Elisp manual:
(info "(elisp)Edebug")

Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]

[Christian Hemminghaus]

Hello everyone,

I ran into an error message while composing structured text with
org-mode using org-inline-tasks. The error appears when moving around
inline tasks in my document.

Here is the example:

# # BEGIN EXAMPLE

This is a paragraph in my document.
It may contain multiple lines.

*** TODO Inline Task
*** END

This is another paragraph.
May be multiline aswell.

And a third paragraph.
May be multiline aswell.

# # END EXAMPLE

Putting the cursor on "Inline Task" and hitting org-metadown should (at
least in my opinion) swap the inline task with the second paragraph and
hence produce the following:

# # BEGIN EXAMPLE

This is a paragraph in my document.
It may contain multiple lines.

This is another paragraph.
May be multiline aswell.

*** TODO Inline Task
*** END

And a third paragraph.
May be multiline aswell.

# # END EXAMPLE

But instead it produces:

# # BEGIN EXAMPLE

This is a paragraph in my document.
It may contain multiple lines.

*** END

This is another paragraph.
May be multiline aswell.

And a third paragraph.
May be multiline aswell.

*** TODO Inline Task

# # END EXAMPLE

Together with an error message:

org-show-children: Invalid regexp: "Invalid content of \\{\\}"

As swapping paragraphs with inline tasks works the other way around, I
think that this is a bug. Since I am not much familiar with elisp, I
would appreciate a hint how to fix this bug.

Best regards,
Christian

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-09-16
Package: Org mode version 9.3.6 (9.3.6-elpa @
/home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)

Re: Search for an entry expands parent

[Gt Uit]

- all   17.07.2020, 07:56, "Gt Uit" :  17.07.2020, 01:42, "Kyle Meyer" :Gt Uit writes:  I recently upgraded to org mode version 9.3.6 and the following behavior was introduced: When I search for an entry using C-s, all the parent entries and sub-entries are expanded and stay expanded. Find in https://imgur.com/a/vzEU1zp screenshots of the newly introduced behavior and expected/old behavior.An image is helpful, and some may follow that link, but it's also usefulto include example Org content and a set of steps to reproduce thebehavior you're describing. Based on that link, something like--8<---cut here---start->8---* A** Bsome text** Ctarget search--8<---cut here---end--->8---And then, with all content folded, 'C-s target'.With the default settings in Org 9, the result is* A** B...** Ctarget searchI believe you want the visibility to be like this:* A...** Ctarget searchYou can customize this behavior through org-show-context-detail. Itsounds like you'd prefer `minimal':(setf (alist-get 'isearch org-show-context-detail)  'minimal)Hello,   Thanks a lot for the prompt and helpful response. I added the above snippet to the .emacs file and restarted. Did a describe-variable and got the following:"org-show-context-detail is a variable defined in ‘org.el’.Its value is((agenda . local)(bookmark-jump . lineage)(isearch . minimal)(default . ancestors))"  However, doing a search still expands all the entries. I downgraded to orgmode v 9.3.1 and still got the same results. I tried on a fresh emacs instance with the only entry in it being setting the  org-show-context-detail isearch to minimal and still got the same results (search expands all entries).   Is it possible that this is a bug? I'd like to note that I am using emacs  v26.3 . Gt Uit Updates since my last email:- Sometimes the first C-s yields intended result (minimal), withsubsequent C-s searches expanding all entries.- I tried on Emacs 28.0.50 and am getting the same results.- I tried with emacs -Q and isearch minimal behaves properly!- I tried a live distribution (Linux Mint 20 Ulyana, samedistribution I am currently using) and isearch minimal behavesproperly.- I tried the following without any success:+ Remove all emacs related packages and reinstall emacs (via apt)+ Install emacs from snap. Now that I have narrowed down the bug to be something local to mycurrent installation please advise on how to debug/resolve. Gt Uit

Re: c-y inserts after entry

[tbanelwebmin]

I get the expected behavior in Emacs 27.0.90

* x
asd fnjkasn dkfjan ksdjfn kajsdfn
* kill this whole header line and insert before caret
^ajsdf kasdn kfjasnd jkfan ksdfn
what i expect is that it is inserted above caret
what occurs is it gets inserted below
* z


Le 18/07/2020 à 01:18, Samuel Wales a écrit :
> in recent maint in emacs 25.
>
> * x
> asd fnjkasn dkfjan ksdjfn kajsdfn
> ^ajsdf kasdn kfjasnd jkfan ksdfn
> * kill this whole header line and insert before caret
> what i expect is that it is inserted above caret
> what occurs is it gets inserted below
> * z
>
> this is surprising because i expected plain text behavior for yanking.
>
> note that i might or might not want plain text behavior for inserting
> a new header.
>
> i have a nagging feeling i am missing a NEWS item here.
>