Re: Feature request: "task table" (similar to clock table)

[Ihor Radchenko]

Marcin Borkowski  writes:

>> If you have interest, going through org-colview.el code would be
>> helpful. It is a bit messy and deserves more cleaning and commenting.
>
> Since org-colview is pretty long, I decided to look into the manual
> instead.  But I couldn't make the column view to do what I wanted, i.e.,
> count the TODO, DONE etc. items in various subtrees.  (What I want is
> more or less "select status, count(*) group by status" for every level-1
> tree.)  And I don't see the equivalent of "count()" among the possible
> "summary types": https://orgmode.org/manual/Column-attributes.html.

You will likely need to implement a new summary type and add it to
org-columns-summary-types

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2022-12-26, at 09:26, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>>> https://orgmode.org/manual/Capturing-column-view.html
>>> https://orgmode.org/manual/Column-attributes.html
>>
>> Good point, I forgot about those.  But: is it possible for the column
>> view to just include the summary (like "100 headlines, including 10
>> TODOs and 30 DONEs"), without the headlines themselves?
>
> AFAIK, no. But it just boils down to keeping the top-level item with
> summary columns.
>
> If you have interest, going through org-colview.el code would be
> helpful. It is a bit messy and deserves more cleaning and commenting.

Since org-colview is pretty long, I decided to look into the manual
instead.  But I couldn't make the column view to do what I wanted, i.e.,
count the TODO, DONE etc. items in various subtrees.  (What I want is
more or less "select status, count(*) group by status" for every level-1
tree.)  And I don't see the equivalent of "count()" among the possible
"summary types": https://orgmode.org/manual/Column-attributes.html.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: missing from the manual - move commands

[Peter Mao]

On Mon, Dec 26, 2022 at 7:03 AM Max Nikulin  wrote:

> On 24/12/2022 09:43, Peter Mao wrote:
> > The following commands are missing from the manual!
> >
> > org-forward-element
> > org-backward-element
>
> I think, the manual was written with assumption that Emacs users are
> familiar with C-up, M-{, C-down, M-} keystrokes.
>
Not everyone uses all of the motion commands.  I've been using emacs since
v18, and forward-paragraph and backward-paragraph have never been part of
my repertoire.

In addition, M-right and M-left, which I have used a lot outside of org,
for decades, behave differently in org, so the existence of motion commands
that are common in emacs (outside of org) do not guarantee an equivalent
inside of org.  BTW, I think M-f and M-b are better anyways, but decades of
muscle memory die hard.

Peter

'C-c a s' sometimes gives as result the END of an inelinetask

[Alain . Cochard]

Here is a minimal example: file debug2.org which contains

   * foo
   *** inlt
   ininlt
   *** END
   bar

I run

   emacs -Q -l ~/.emacs

where .emacs contains only

   (require 'org-inlinetask)

and which gives

   GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
   3.24.30, cairo version 1.17.4) of 2021-08-07
   Org mode version 9.4.4 (release_9.4.4 @
   /usr/share/emacs/27.2/lisp/org/)

Then I do

   M-x org-agenda  < s bar 

and I see

   Search words: bar
   Press ‘[’, ‘]’ to add/sub word, ‘{’, ‘}’ to add/sub regexp, ‘C-u r’ for a 
fresh search
 debug2: END


I get the same thing with

   emacs

which gives

   Org mode version 9.5.5 (9.5.5-g8ef620 @
   /home/cochard/.emacs.d/elpa/org-9.5.5/)


Finally, with

   emacs -Q -l ~/.emacs.git

where .emacs.git contains only

   (add-to-list 'load-path "~/Org/Coch-git/org-mode/lisp")
   (require 'org-inlinetask)

and which gives

   Org mode version 9.6 (release_9.6-145-gfd162e.dirty @
   /home/cochard/Org/Coch-git/org-mode/lisp/)

then the cursor gets stuck in the minibuffer after the 2nd  above
(hence, no result).




-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

[BUG] org-block face not working for "non-default" languages

[duskhorn]

This works perfectly!
I get both fixed pitch and syntax highlight!
Thank you so much for your work, Ihor!

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Jean Louis]

* Ihor Radchenko  [2022-12-26 13:05]:
> In any case, breaking the way existing menu works is not something we
> can do without proposing a fallback.
> https://bzg.fr/en/the-software-maintainers-pledge/

I have never said anything about "breaking the way existing menu
works".

The concept offered does not "break anything". If you mean key
bindings, then retain key bindings. That is a choice. That was not
part of the concept. I have defined the concept well and expressed me
clear with points one by one.

If you mean formatting of the text, how it looks like, then retain
formatting of text. That is choice. That is not part of the offered
concept. 

The concept is about usability related to non-blocking interface and
mouse usage, speed and easy, and not about changing keybindings or
formatting of text.

> > QUESTION: You said that improvement to Org should be backwards
> > compatible, but what exactly and specifically you mean in this case?
> 
> It means that we need to either keep the old menu code around and
> provide an option to switch to it, or, better, implement the new menu
> code in such a way that it does not change the current menu layouts and
> bindings.

Good that you say that.

I never talked about changing key bindings and menu layout, so that is
something you may keep.

> > The solution I have offered to you is the concept. Not the package.
> 
> > In that concept, by observing the code, you could see that it is
> > possible:
> > ...
> > So what exactly has to be backwards compatiable?
> > Is there anything you think it can't be made backwards compatible?
> 
> Layout mostly.
> I do not think that you can re-create the existing menu layout if you
> use Org buffer as menu.

I can do, I see no problem there.

What changes is that the menu would become liberated, non-blocking,
and that user may use mouse to turn off/on the necessary options, and
may move away from the Org Export buffer to other buffers and come
back, no need to re-invoke and re-invoke the export buffer over and
over again. It can remain on left side, right side, and by using mouse
or keys it can export so many times faster than the existing ordinary
org dispatch interface.

So I guess we have misunderstanding, you think of layout and key
bindings, and me I think of non-blocking interface.

QUESTION: Should I now add the ordinary layout and keybindings and
show you how it works?

>From your side I expect that you tell me how do you use Org functions
to discover new exports as to see how to automatically include such.

> > ediff -- function `read-char-exclusive' is not inside and I have
> > options which I can use without Emacs being blocked. I can switch from
> > frame to frame, I can inspect every key.
> 
> I found these packages by searching the latest Emacs master.
> read-char-exclusive is inside all of them.

OK, but it is not related to the problem explained by original poster,
and that was explained by me in past.

DEFINITION OF PROBLEM:

Problem is related to blocking interface and lack of usability: user
cannot use keys to freely move inside of buffer and select options,
cannot switch buffers, need to re-invoke the org export dispatcher
each time for each export, and cannot use mouse.

> In any case, I do not see much point arguing about this.
> As I said, I am not against improving the menus in principle. We just
> have constrains on how we can improve the existing menus.

You have defined constraints to be the formatting (layout) and key
bindings.

Is there anything else?

I believe there is something in org that recognizes various export
options and implements menu, is it? 

> > Instead of talking of the burden, why not tackle accessibility and
> > then let other people tell about needed accessibility (they tell but
> > due to burden is difficult to follow) and make it so that it is
> > non-blocking interface.
> 
> Can you please elaborate on the second paragraph? I feel that I am
> missing the point you wanted to explain there.

You may read the original post about the lack of usability (this is
correct word I wanted to use instead of accessibility). You should not
by using "burden" prevent people to freely say what they think about
usability. And problems of maintenance are there many, I am sure, and
it takes your time -- but such problems need not be expressed on this
list for purpose not to prevent people reporting and improving Org.

Person working in significant position in university complained about
it. I am confident that professor has reason related to usability and
that is what has to be discussed. 

Subject of discussion is not the burden in maintenance, make it
different thread and ask people to contribute and delegate your tasks
to other contributors. Promote contributing widely over website. 

The actual problem is there at hand, it is well defined.

> >> 1. Your package is introducing a new formatting for menus and new
> >>interaction paradigm. This is not backwards-compatible.
> >
> > The concept of 

Re: CSV agenda export formats some day and month values as single digits

[Max Nikulin]

On 26/12/2022 17:34, Ihor Radchenko wrote:

Max Nikulin writes:

(let ((calendar-date-display-form calendar-iso-date-display-form))

...

The reason I suggest using the default value is that
`calendar-iso-date-display-form' is a defcustom.


Thank you, I did not noticed that it is a user option. I should think 
more on this. If a user has a reason to override the ISO format, perhaps 
it should be respected in some way.

Re: missing from the manual - move commands

[Max Nikulin]

On 24/12/2022 09:43, Peter Mao wrote:

The following commands are missing from the manual!

org-forward-element
org-backward-element


I think, the manual was written with assumption that Emacs users are 
familiar with C-up, M-{, C-down, M-} keystrokes.



These two should be mentioned in the manual in section 2.3 "Motion"


A as person for whom Emacs is almost solely a note taking application 
(thanks to Org), I do not mind. Perhaps the relevant section from Emacs 
should be mentioned as well.


Someone should take the challenge to extend the info "(org) Motion" 
section in a way informative for novices and not boring for experienced 
Emacs users and to emphasize difference of (maybe familiar) shortcuts 
from the fundamental mode.

Re: bug#59882: Multiple versions of Org in load-path problem

[Max Nikulin]

On 26/12/2022 18:01, Ihor Radchenko wrote:

Ihor Radchenko writes:

1. ~/Git/with-emacs.sh/with-emacs.sh -e emacs-27 -O -- -l org

I was finally able to reproduce using emacs-26.

Maybe your Emacs 27 is older than mine? I have GNU Emacs 27.2


Debian stable and Ubuntu LTS have Emacs-27.1 only, so I am testing 
1:27.1+1-3ubuntu5


Following the with-emacs.sh script I have tried

mkdir /tmp/emcs
emacs --quick --eval '(setq user-emacs-directory "/tmp/emcs/")' --eval 
'(setq user-init-file "/tmp/emcs/init.el")' -l package --eval '(setq 
package-user-dir "/tmp/emcs/elpa/")' --eval '(package-initialize)' 
--eval '(package-refresh-contents)' -l org


I had no problem to select Org-9.6 from the buffer generated by 
`list-packages'. Compilation errors and the error during next startup 
are the same as I reported before.


I found just single commit to lisp/emacs-lisp/package.el between 
emacs-27.1 and emacs-27.2:


1fc9de4b81c 2020-10-30 19:20:24 -0700 Glenn Morris: Improve 
reproducibility of generated -pkg.el files


So I am still surprised that you can not reproduce the issue.

Re: bug#59882: Multiple versions of Org in load-path problem

[Ihor Radchenko]

Ihor Radchenko  writes:

> 1. ~/Git/with-emacs.sh/with-emacs.sh -e emacs-27 -O -- -l org

I was finally able to reproduce using emacs-26.

Maybe your Emacs 27 is older than mine? I have GNU Emacs 27.2

I also tried with Emacs 28. Not able to reproduce.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: CSV agenda export formats some day and month values as single digits

[Ihor Radchenko]

Max Nikulin  writes:

> On 26/12/2022 16:23, Ihor Radchenko wrote:
>> 
>> Fixed on bugfix now.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c79aedec
>
> I have never heard about `calendar-date-display' before so I am curious 
> under which circumstances the following will not work:
>
> (let ((calendar-date-display-form calendar-iso-date-display-form))

Your variant should also work, and it is more concise. Could you make it
into a patch? But not using the variable. Rather, the default value.

The reason I suggest using the default value is that
`calendar-iso-date-display-form' is a defcustom. There is no reason why
agenda export should depend on changed custom setting here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: CSV agenda export formats some day and month values as single digits

[Max Nikulin]

On 26/12/2022 16:23, Ihor Radchenko wrote:


Fixed on bugfix now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c79aedec


I have never heard about `calendar-date-display' before so I am curious 
under which circumstances the following will not work:


(let ((calendar-date-display-form calendar-iso-date-display-form))

Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Ihor Radchenko]

Jean Louis  writes:

>> > That is not first complaint, right? I would say it is obvious that
>> > such interface is not user friendly. 
>> 
>> Yes and no. Some users do not like it. Some users prefer the existing
>> one. Conclusion: even if we implement something better, it should be
>> backwards compatible.
>
> Remember, one cannot prefer something without having a choice! 
>
> User preferring existing functions have basically more or less how
> many choices? One. So that is why they "prefer" it. 

I vaguely recall some people voicing against new menu frameworks in the
past. That's why I said that some people prefer the existing one.

In any case, breaking the way existing menu works is not something we
can do without proposing a fallback.
https://bzg.fr/en/the-software-maintainers-pledge/

> QUESTION: You said that improvement to Org should be backwards
> compatible, but what exactly and specifically you mean in this case?

It means that we need to either keep the old menu code around and
provide an option to switch to it, or, better, implement the new menu
code in such a way that it does not change the current menu layouts and
bindings.

> The solution I have offered to you is the concept. Not the package.

> In that concept, by observing the code, you could see that it is
> possible:
> ...
> So what exactly has to be backwards compatiable?
> Is there anything you think it can't be made backwards compatible?

Layout mostly.
I do not think that you can re-create the existing menu layout if you
use Org buffer as menu.

>> >> This is because we use `read-char-exclusive'.
>> >
>> > Don't use what is blocking Emacs. Apart from Org mode I have never
>> > seen a package that blocks Emacs that I cannot even inspect keys.
>> 
>> gnus, reftex, ediff.
>> (I do not mean that we should not improve Org in this regard)
>
> gnus -- does not have that function inside, but how I remember me of
> using Gnus, it never blocked the Emacs user interface, anything I used
> allowed me to switch to other buffers. Thus I cannot see the
> similarity to blocking user-unfriendly org-export-dispatch interface.
>
> reftex -- function is inside, but when invoked it does not block the
> Emacs user interface. I cannot see similarity to the blocking Org
> Export interface.
>
> ediff -- function `read-char-exclusive' is not inside and I have
> options which I can use without Emacs being blocked. I can switch from
> frame to frame, I can inspect every key.

I found these packages by searching the latest Emacs master.
read-char-exclusive is inside all of them.

In any case, I do not see much point arguing about this.
As I said, I am not against improving the menus in principle. We just
have constrains on how we can improve the existing menus.

>> There is code prototype down in the thread.
>> https://list.orgmode.org/orgmode/am9pr09mb49770f57f33859770649c7c896...@am9pr09mb4977.eurprd09.prod.outlook.com/
>
> I have downloaded org-select.el and tried demo1, demo2, demo3, and
> that is what we are talking about. It does the job well.

Yup. The discussion hanged at trying to write the existing menus with
that package. If someone™ volunteers to finish that part, it will be
welcome.

>> Thanks for the effort, but I'm afraid that it is not something we
>> want in Org core from maintenance perspective. Would be welcome as a
>> third-party package though.
>
> If you are the one among few responsible to modify Org and figure out
> how and where to modify it, then I understand it is large burden on
> you. 
>
> Instead of talking of the burden, why not tackle accessibility and
> then let other people tell about needed accessibility (they tell but
> due to burden is difficult to follow) and make it so that it is
> non-blocking interface.

Can you please elaborate on the second paragraph? I feel that I am
missing the point you wanted to explain there.

>> 1. Your package is introducing a new formatting for menus and new
>>interaction paradigm. This is not backwards-compatible.
>
> The concept of non-blocking interface was obviously offered by Arthur
> Miller and now by me.

In the video, you are using Org mode commands inside menu, which is a
new concept for me.

> Almost 11 years ago, January 5th 2012, Nicolas Goaziou added those new
> functions like org-export-dispatch how I see it in the commit
> aeb1ee1c662cd2243c17cc99f6205a15fb3d9283.
>
> For 11 years Org Mode remained same, using blocking Org Export
> functions.
>
> No mouse? One cannot even switch buffer?
>
> Strange and weird to me.
>
> When user comes complaining think that there are other 100 users
> complaining. 

I did not say that your concern is not a valid concern.
I only objected the concrete concept prototype you provided.
As I said, the ideal would be using transient for menus.

> With the publicly expressed attitude "it is burden for us" -- of
> course people will not even complain. 

I think you get me wrongly. "It is a burden" also refers to "lets not
complicate Org code even 

Re: Bash results broken?

[Ihor Radchenko]

Matt  writes:

>   On Sun, 25 Dec 2022 06:23:53 -0500  Ihor Radchenko  wrote --- 
>  > As you see, "%S" have been used previously for non-string results.
>  > I cannot find explanation in git log.
>  > 
>  > That said, I think that it will be more consistent to leave strings
>  > specifically as is. See the attached patch.
>
> That makes sense and works for me.

Applied onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b11abb409

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: CSV agenda export formats some day and month values as single digits

[Ihor Radchenko]

[Adding Org mailing list back to CC]

"David O'Toole"  writes:

> Here is a script and some files that reproduce the issue for me in a fresh
> "emacs -Q".
>
> csv-test.el  --- the test script
> csv-test.org --- the file to pull agenda items from
> csv-test.csv --- the output

Thanks!
Fixed on bugfix now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c79aedec

> GNU Emacs 29.0.60 (build 2, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.33, cairo version 1.16.0) of 2022-12-04
>
> Org mode version 9.6 (release_9.6-3-ga4d38e @
> /usr/local/share/emacs/29.0.60/lisp/org/)
>
>
>
> On Sun, Dec 25, 2022 at 9:37 AM David O'Toole 
> wrote:
>
>> Sure, I'll follow up with steps to reproduce it, and I'll include the
>> output as an attachment.
>>
>> On Sun, Dec 25, 2022 at 7:57 AM Ihor Radchenko 
>> wrote:
>>
>>> "David O'Toole"  writes:
>>>
>>> > CSV export for the agenda is formatting January 1, 2023 as "2023-1-1"
>>> and
>>> > not "2023-01-01".
>>> > The raw output is here: https://pastebin.com/raw/EyN1JbhP
>>>
>>> Could you please provide detailed steps how to obtain the erroneous CSV
>>> output? See https://orgmode.org/manual/Feedback.html#Feedback
>>>
>>> Note that pastebin is not available in all countries. If you can, please
>>> send the code/text right in the email as an attachment. This is more
>>> sustainable for future readers.
>>>
>>> --
>>> Ihor Radchenko // yantar92,
>>> Org mode contributor,
>>> Learn more about Org mode at .
>>> Support Org development at ,
>>> or support my work at 
>>>
>>
> csv-test,Task 1,scheduled,TODO,,2022-12-25,,Scheduled:,,1099,2022-12-25
> csv-test,Task 2,scheduled,TODO,,2022-12-26,,Scheduled:,,1099,2022-12-26
> csv-test,Task 3,scheduled,TODO,,2023-1-1,,Scheduled:,,1099,2023-1-1
> ;; GNU Emacs 29.0.60 (build 2, x86_64-pc-linux-gnu, GTK+ Version
> ;; 3.24.33, cairo version 1.16.0) of 2022-12-04
>
> ;; Org mode version 9.6 (release_9.6-3-ga4d38e @
> ;; /usr/local/share/emacs/29.0.60/lisp/org/)
>
> ;; started with "emacs -Q"
>
> (defun capture-csv ()
>   (save-excursion 
> (with-output-to-string
>   "*csv*"
>   (org-batch-agenda-csv "a"
> org-agenda-span 10
> org-agenda-include-inactive-timestamps t
> org-agenda-skip-timestamp-if-done nil
> org-agenda-show-all-dates t
> org-agenda-skip-scheduled-if-done nil
>
> (setq org-agenda-files '("~/csv-test.org"))
>
> (let ((buffer (get-buffer-create "*csv*")))
>   (switch-to-buffer buffer)
>   (save-window-excursion
> (insert (capture-csv
>
>
>

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-block face not working for "non-default" languages

[Ihor Radchenko]

duskhorn  writes:

> I have set up my org-mode so that I use variable pitch fonts for most of the 
> items and fixed pitch fonts for verbatim and src blocks.
>
> This works as expected for languages babel knows by default, for example 
> emacs-lisp, python and c++.
>
> However, I get variable pitch fonts for when I use an unrecognized language, 
> such as nim (in my case) or R. 

Can you try the attached patch?
>From 16a73725e2f9291f614f5dd6c34b05ac68eebc74 Mon Sep 17 00:00:00 2001
Message-Id: <16a73725e2f9291f614f5dd6c34b05ac68eebc74.1672045049.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 26 Dec 2022 11:55:26 +0300
Subject: [PATCH] org-src.el: Apply common faces even when src block language
 mode is absent

* lisp/org-src.el (org-src-font-lock-fontify-block): Apply
`org-src-block-faces'/`org-block' faces even when no major mode is
available for the src block language.

Reported-by: duskhorn 
Link: https://orgmode.org/list/zCjC9UjXEgJk8kuyi8t2K2XzO3fL7pYWynHhoYWAes9eCA1FkomCY9bss4uKZfBg60M4xUisyDqFWKVMOn1r_XzUVE7gr3ci82MEOLjGIMk=@proton.me
---
 lisp/org-src.el | 154 
 1 file changed, 77 insertions(+), 77 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 7d5f5d543..85262b32a 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -629,83 +629,83 @@ (defun org-src-font-lock-fontify-block (lang start end)
   "Fontify code block between START and END using LANG's syntax.
 This function is called by Emacs' automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
-  (let ((lang-mode (org-src-get-lang-mode lang)))
-(when (fboundp lang-mode)
-  (let ((string (buffer-substring-no-properties start end))
-	(modified (buffer-modified-p))
-	(org-buffer (current-buffer)))
-	(remove-text-properties start end '(face nil))
-	(with-current-buffer
-	(get-buffer-create
-	 (format " *org-src-fontification:%s*" lang-mode))
-	  (let ((inhibit-modification-hooks nil))
-	(erase-buffer)
-	;; Add string and a final space to ensure property change.
-	(insert string " "))
-	  (unless (eq major-mode lang-mode) (funcall lang-mode))
-  (font-lock-ensure)
-	  (let ((pos (point-min)) next)
-	(while (setq next (next-property-change pos))
-	  ;; Handle additional properties from font-lock, so as to
-	  ;; preserve, e.g., composition.
-  ;; FIXME: We copy 'font-lock-face property explicitly because
-  ;; `font-lock-mode' is not enabled in the buffers starting from
-  ;; space and the remapping between 'font-lock-face and 'face
-  ;; text properties may thus not be set.  See commit
-  ;; 453d634bc.
-	  (dolist (prop (append '(font-lock-face face) font-lock-extra-managed-props))
-		(let ((new-prop (get-text-property pos prop)))
-  (when new-prop
-(if (not (eq prop 'invisible))
-		(put-text-property
-		 (+ start (1- pos)) (1- (+ start next)) prop new-prop
-		 org-buffer)
-  ;; Special case.  `invisible' text property may
-  ;; clash with Org folding.  Do not assign
-  ;; `invisible' text property directly.  Use
-  ;; property alias instead.
-  (let ((invisibility-spec
- (or
-  ;; ATOM spec.
-  (and (memq new-prop buffer-invisibility-spec)
-   new-prop)
-  ;; (ATOM . ELLIPSIS) spec.
-  (assq new-prop buffer-invisibility-spec
-(with-current-buffer org-buffer
-  ;; Add new property alias.
-  (unless (memq 'org-src-invisible
-(cdr (assq 'invisible char-property-alias-alist)))
-(setq-local
- char-property-alias-alist
- (cons (cons 'invisible
-			 (nconc (cdr (assq 'invisible char-property-alias-alist))
-'(org-src-invisible)))
-		   (remove (assq 'invisible char-property-alias-alist)
-			   char-property-alias-alist
-  ;; Carry over the invisibility spec, unless
-  ;; already present.  Note that there might
-  ;; be conflicting invisibility specs from
-  ;; different major modes.  We cannot do much
-  ;; about this then.
-  (when invisibility-spec
-(add-to-invisibility-spec invisibility-spec))
-  (put-text-property
-		   (+ start (1- pos)) (1- (+ start next))
-   'org-src-invisible new-prop
-		  

Re: bug#59882: Multiple versions of Org in load-path problem

[Ihor Radchenko]

Max Nikulin  writes:

>> I tried to follow these steps, but unfortunately I am unable to
>> reproduce. Everything works fine using Emacs 27 on my side. Strange.
>
> I tried it once more in a minimal LXC container with Ubuntu-22.04 LTS 
> jammy. This time I even removed the elpa-org-9.5.2 system package, so 
> built-in version of org is really used. So, emacs-27
>
> - emacs -l org
> - M-x list-packages RET
> - / n org RET
> - move cursor to org, install it

On my side, it will give nothing useful: the package list is not updated
and I get:

Package org is built-in.

 Status: Built-In.
Version: 9.4.4
Summary: Export Framework for Org Mode

Detailed steps I tried (with package refresh) using with-emacs.sh [1]:

1. ~/Git/with-emacs.sh/with-emacs.sh -e emacs-27 -O -- -l org
2. M-x package-list-packages RET
3. C-s outline-based RET
4. RET
5. C-x o C-s instal RET
6. RET y
7. The warnings buffer appears, but only contains
   Warning (defvaralias): Overwriting value of ‘org-tab-first-hook’ by aliasing 
to ‘org-cycle-tab-first-hook’

[1] https://github.com/alphapapa/with-emacs.sh

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Feature request: "task table" (similar to clock table)

[Ihor Radchenko]

Marcin Borkowski  writes:

>> https://orgmode.org/manual/Capturing-column-view.html
>> https://orgmode.org/manual/Column-attributes.html
>
> Good point, I forgot about those.  But: is it possible for the column
> view to just include the summary (like "100 headlines, including 10
> TODOs and 30 DONEs"), without the headlines themselves?

AFAIK, no. But it just boils down to keeping the top-level item with
summary columns.

If you have interest, going through org-colview.el code would be
helpful. It is a bit messy and deserves more cleaning and commenting.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2022-12-26, at 09:05, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> I've been using clock tables for some time now, and they are very
>> useful.  However, it has just occurred to me that I'd really appreciate
>> another feature - a "task table".  By this, I mean a table (generated
>> much like a clock table) with a summary of all tasks in a given
>> file/subtree/etc.: how many of them there are, how many are in any
>> state, maybe how many have scheduled times and/or deadlines, how many
>> are past their deadline...
>
> https://orgmode.org/manual/Capturing-column-view.html
> https://orgmode.org/manual/Column-attributes.html

Good point, I forgot about those.  But: is it possible for the column
view to just include the summary (like "100 headlines, including 10
TODOs and 30 DONEs"), without the headlines themselves?

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Feature request: "task table" (similar to clock table)

[Ihor Radchenko]

Marcin Borkowski  writes:

> I've been using clock tables for some time now, and they are very
> useful.  However, it has just occurred to me that I'd really appreciate
> another feature - a "task table".  By this, I mean a table (generated
> much like a clock table) with a summary of all tasks in a given
> file/subtree/etc.: how many of them there are, how many are in any
> state, maybe how many have scheduled times and/or deadlines, how many
> are past their deadline...

https://orgmode.org/manual/Capturing-column-view.html
https://orgmode.org/manual/Column-attributes.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at