Re: [PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-line

[Daniel Ortmann]

No objections.

On 11/21/22 20:12, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I am happy with whatever you decide.  :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Ihor Radchenko]

"Samuel W. Flint"  writes:

> IR> May I know if you got any reply from FSF?
>
> I'm still waiting for final confirmation.  Having some issues getting
> confirmation from the University.

Thanks for the update. Let us know when the process is done.

Note that universities usually don't have issues with FSF copyright,
maybe unless you are working on a grant related to Emacs/Org
development.

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

Re: [OT] org and diff

[Samuel Wales]

incidentally, if you want empty hunk headers, you can do this at least
in my version of git:

  xfuncname = " "

but idk why it works and i had had it commented out.


On 11/21/22, Samuel Wales  wrote:
> p.s.  hunk header munging does not unmingle [i.e. group changes by org
> header in magit status buffer diffs] :(.  but it is true that what i
> want is some kind of preference given by magit to org entries as
> demarcated by org headings.
>
> idk if what i want is in principle possible or not in standard diff or
> git diff.  that is, idk if they could be patched to accept an arg that
> would allow you to specify that org entries should be preserved if
> possible or something like that.
>
> great to know difftastic can in principle be coded to do what i want,
> however.  so maybe soetime you could tell git to use.
>
> org hunk headers are rather nice looking.  on the other hand, it gets
> the previous header, even if not the parent header.  i think this is
> why i had the impression that git was in principle incapable of org
> hunk header text of the type i wanted.  but hunk header text is not
> something i use a lot.  it's rather nice looking, but in some cases i
> prefer empty hunk headers.
>
> On 11/12/22, Samuel Wales  wrote:
>> i have a very old version of Magit, for reasons I won't get into.
>> Fancier diff settings might be differnet or not available.
>>
>> But something drives me crazy.  Probably not too Org-related, but it
>> might be.  I just want to know why, is all.
>>
>> I have a 24k line org file, and it's not that complex wrt levels.  2
>> or 3 levels with odd stars only.  various types of content.
>>
>> someplace in it, is an entry with a  234-item plain list.  if i try to
>> move this entry, and make no other changes, diff goes insane.  if i
>> try to refile this entry to a different org file, diff similarly goes
>> insane, with the - part.  only that change.
>>
>> ok, what it does is, intersperse or mingle entries.  so suppose i want
>> to stage this one tiny little change, namely moving one entry [the one
>> with the large plain list] to a different location in the same file.
>> even if i move it really distantly.
>>
>> i.e. i want to put the - and the + of the move to the staging area in
>> magit.  unstaged changes should then not have this file in it at all
>> after the staging operations.
>>
>> then, basically, staged changes will have this move.
>>
>> as a user, i want diff to make this two hunks, a big - and a big +.
>> but diff mingles parts of another entry or entries with this list, so
>> that it is scattered all over the diff.  to get the result i want
>> requires tons of intra-hunk stage operations.  at best.
>>
>> so, what aspect of diff or org is triggering this kind of behavior?
>> what is it that diff needs to understand about org, or what minimality
>> etc. settings does it want to create a better diff?
>>
>> i know org has lots of similar lines [e.g. planning headers with
>> scheduled dates that are identical].  but still, this is a nontrivial
>> size org file, with no other changes that i made. diff's insanity
>> still occurs even if i move the entry distantly.
>>
>> i am of course aware of histogram, patience, etc. and that git diff
>> has a few experimental choices of options.  also long ago i read diff
>> manual with its discussion of end of file beg of file and minimality
>> with --minimal and all that stuff.
>>
>> however, here, though, i am mostly interested in specifically what
>> diff's, or git diff's, or magit's, /deal/ is.  in /this/ case.
>>
>> where does it get off doing that?  everything else is the same, so why
>> is it keying on the wrong thing?
>>
>> does it think i made the changes as it presents them, or does it go
>> for some other goal like minimality or speed and not really care what
>> i did?  is it because it e.g. ignores end or beg of file or so?  or is
>> it getting confused by some line?
>>
>> i have of course heard of merge something or others.  which presumably
>> tell diff about the structure of files or so.  like, the fact that the
>> planning line always follows the header.  or perhaps i am imagining
>> this kind of tool.
>>
>> now, whether i can mitigte it is interesting /after/ that.  my
>> paleolithic magit version might not be capable, but still.
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [OT] org and diff

[Samuel Wales]

p.s.  hunk header munging does not unmingle [i.e. group changes by org
header in magit status buffer diffs] :(.  but it is true that what i
want is some kind of preference given by magit to org entries as
demarcated by org headings.

idk if what i want is in principle possible or not in standard diff or
git diff.  that is, idk if they could be patched to accept an arg that
would allow you to specify that org entries should be preserved if
possible or something like that.

great to know difftastic can in principle be coded to do what i want,
however.  so maybe soetime you could tell git to use.

org hunk headers are rather nice looking.  on the other hand, it gets
the previous header, even if not the parent header.  i think this is
why i had the impression that git was in principle incapable of org
hunk header text of the type i wanted.  but hunk header text is not
something i use a lot.  it's rather nice looking, but in some cases i
prefer empty hunk headers.

On 11/12/22, Samuel Wales  wrote:
> i have a very old version of Magit, for reasons I won't get into.
> Fancier diff settings might be differnet or not available.
>
> But something drives me crazy.  Probably not too Org-related, but it
> might be.  I just want to know why, is all.
>
> I have a 24k line org file, and it's not that complex wrt levels.  2
> or 3 levels with odd stars only.  various types of content.
>
> someplace in it, is an entry with a  234-item plain list.  if i try to
> move this entry, and make no other changes, diff goes insane.  if i
> try to refile this entry to a different org file, diff similarly goes
> insane, with the - part.  only that change.
>
> ok, what it does is, intersperse or mingle entries.  so suppose i want
> to stage this one tiny little change, namely moving one entry [the one
> with the large plain list] to a different location in the same file.
> even if i move it really distantly.
>
> i.e. i want to put the - and the + of the move to the staging area in
> magit.  unstaged changes should then not have this file in it at all
> after the staging operations.
>
> then, basically, staged changes will have this move.
>
> as a user, i want diff to make this two hunks, a big - and a big +.
> but diff mingles parts of another entry or entries with this list, so
> that it is scattered all over the diff.  to get the result i want
> requires tons of intra-hunk stage operations.  at best.
>
> so, what aspect of diff or org is triggering this kind of behavior?
> what is it that diff needs to understand about org, or what minimality
> etc. settings does it want to create a better diff?
>
> i know org has lots of similar lines [e.g. planning headers with
> scheduled dates that are identical].  but still, this is a nontrivial
> size org file, with no other changes that i made. diff's insanity
> still occurs even if i move the entry distantly.
>
> i am of course aware of histogram, patience, etc. and that git diff
> has a few experimental choices of options.  also long ago i read diff
> manual with its discussion of end of file beg of file and minimality
> with --minimal and all that stuff.
>
> however, here, though, i am mostly interested in specifically what
> diff's, or git diff's, or magit's, /deal/ is.  in /this/ case.
>
> where does it get off doing that?  everything else is the same, so why
> is it keying on the wrong thing?
>
> does it think i made the changes as it presents them, or does it go
> for some other goal like minimality or speed and not really care what
> i did?  is it because it e.g. ignores end or beg of file or so?  or is
> it getting confused by some line?
>
> i have of course heard of merge something or others.  which presumably
> tell diff about the structure of files or so.  like, the fact that the
> planning line always follows the header.  or perhaps i am imagining
> this kind of tool.
>
> now, whether i can mitigte it is interesting /after/ that.  my
> paleolithic magit version might not be capable, but still.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] LSP support in org-src buffers

[Ihor Radchenko]

João Pedro  writes:

> I think the contextual src block could be split from the LSP
> functionality, since it could be used in other contexts other than
> dealing with language servers. My iteration is not tied to anything in
> particular and simply creates a source buffer with the whole context for
> that tangled file.
>
> Hope this can help you in some way!
>
> [1] https://gist.github.com/bigodel/15599f3c1da23d1008b7d7d4ff8bff77

It looks like you have done something very close to what we are
discussing. Would you be interested to create a patch against Org core
instead of relying on advises?

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

[PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9

[Ihor Radchenko]

Daniel Ortmann  writes:

> I am happy with whatever you decide.  :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

>From ea48cb04301588688f736e9461ebb7824224fe44 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 22 Nov 2022 10:06:24 +0800
Subject: [PATCH] org-babel: Add new :results ignore header argument

* lisp/ob-core.el (org-babel-result-cond): Unconditionally return nil
and suppress all the processing for :results ignore.
(org-babel-common-header-args-w-values):
(org-babel-sha1-hash): Add the new value to know :results value list.
* doc/org-manual.org (Handling):
* etc/ORG-NEWS (New =:results ignore= header argument): Document the
new value.

Reported-by: Daniel Ortmann 
Link: https://orgmode.org/list/87tu2tjary.fsf@localhost
---
 doc/org-manual.org |  8 
 etc/ORG-NEWS   |  8 
 lisp/ob-core.el| 31 ---
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4f877d371..194cabe99 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18482,6 +18482,14 @@ *** Handling
   can still be used when referenced from another code block.
   Usage example: =:results none=.
 
+- =ignore= ::
+
+  Ignore the results completely.  This option is similar to =none=,
+  but no processing is performed on the return value.  Calling the
+  code block programatically (see [[*How to evaluate source code]]) or by
+  reference (see [[*Passing arguments]] and [[*Noweb Reference Syntax]]) will
+  always yield nil.
+
 - =append= ::
 
   Append results to the Org buffer.  Latest results are at the bottom.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 1f79f8ae5..d92cb139a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -373,6 +373,14 @@ value of ~org-babel-clojure-backend~. For example:
 (range 2)
 #+end_src
 
+*** New =:results ignore= header argument
+
+Unlike =:results none=, the return value of code blocks called with
+=:results ignore= header argument is always ~nil~.  Org does not
+attempt to analyze the results and simply returns nil.  This can be
+useful when the code block is used for side effects only but generates
+large outputs that may be slow to analyze for Org.
+
 ** New options
 *** A new option for custom setting ~org-refile-use-outline-path~ to show document title in refile targets
 
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 1259909a0..89d3e104c 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -425,7 +425,7 @@ (defconst org-babel-common-header-args-w-values
 (prologue   . :any)
 (results	. ((file list vector table scalar verbatim)
 		   (raw html latex org code pp drawer link graphics)
-		   (replace silent none append prepend)
+		   (replace silent none ignore append prepend)
 		   (output value)))
 (rownames	. ((no yes)))
 (sep	. :any)
@@ -1345,7 +1345,7 @@ (defun org-babel-sha1-hash (&optional info context)
 		(lambda (a b) (string< (car a) (car b)
 (let* ((rm (lambda (lst)
 		 (dolist (p '("replace" "silent" "none"
-			  "append" "prepend"))
+			  "ignore" "append" "prepend"))
 		   (setq lst (remove p lst)))
 		 lst))
 	   (norm (lambda (arg)
@@ -3282,19 +3282,20 @@ (defmacro org-babel-result-cond (result-params scalar-form &rest table-forms)
   (declare (indent 1) (debug t))
   (org-with-gensyms (params)
 `(let ((,params ,result-params))
-   (if (or (member "scalar" ,params)
-	   (member "verbatim" ,params)
-	   (member "html" ,params)
-	   (member "code" ,params)
-	   (member "pp" ,params)
-	   (member "file" ,params)
-	   (and (or (member "output" ,params)
-			(member "raw",params)
-			(member "org",params)
-			(member "drawer" ,params))
-		(not (member "table" ,params
-	   ,scalar-form
-	 ,@table-forms
+   (unless (member "ignore" ,params)
+ (if (or (member "scalar" ,params)
+	 (member "verbatim" ,params)
+	 (member "html" ,params)
+	 (member "code" ,params)
+	 (member "pp" ,params)
+	 (member "file" ,params)
+	 (and (or (member "output" ,params)
+			  (member "raw",params)
+			  (member "org",params)
+			  (member "drawer" ,params))
+		  (not (member "table" ,params
+	 ,scalar-form
+	   ,@table-forms)
 
 (defmacro org-babel-temp-directory ()
   "Return temporary directory suitable for `default-directory'."
-- 
2.35.1



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

Re: test-org-table/sort-lines: Failing test on macOS

[Ihor Radchenko]

Max Nikulin  writes:

>> 2. `org-sort-list'
>> 5. `org-sort-entries'
> `downcase' is used, not proper case folding, so a potential issue

`downcase' is used to determine user input about sorting type.
Not for sorting itself.

>> 4. `org-set-tags' (tag order), when `org-tags-sort-function' is set to
>> "Alphabetical" or "Reverse alphabetical".
>
> IGNORE-CASE argument is not used, perhaps `downcase' is hidden in the code.

I feel like we are slightly miscommunicating here.
I mostly tried to list the uses of libc-sensitive sorting. Not
specifically cases when we try to ignore the case.

The problem is not limited to case-sensitive comparisons. Some systems
may fail to implement specific locales and thus sorting may downgrade to
simple string-lessp.

No `downcase' is hidden anywhere there.

>> 6. Agenda sorting, when alphabetical sorting is involved
>
> `string-lessp' and `downcase' so even more severe locale-related issues 
> might be expected.

Could you please elaborate?

>> 7. `org-map-entries'
>
> Unsure which predicate is used.

It is a similar scenario with agenda. `org-map-entries' uses
`org-make-tags-matcher', which calls `org-op-to-function' when user
wants to select property values via />= criterion.
`org-op-to-function' calls `org-string<' or similar that, in turn, uses
`string-collate-lessp' with nil IGNORE-CASE argument.

>> I am not 100% sure where we should add the information to
>> docstring/manual and where we should not.
>
> If footnotes in the manual had fixed labels then I would suggest 
> reference the same footnote in the manual and in the docstrings. 
> Perhaps, a new subsection should be added to info "(org) Miscellaneous" 
> and "see info node ..." should be added to all involved docstrings.

Sounds reasonable.

>>> Concerning the test, I would split the current testcase into 2 parts
>>> depending on WITH-CASE argument, check if caseless collation is
>>> available and skip the related test otherwise.
>> 
>> How can we check the availability?
>
> (string-collate-lessp "a" "B" "C" t)

Thanks!

>> Indeed. Also, see https://nullprogram.com/blog/2014/06/13/. However,
>> what we are concerned about here is consistency. Not the pitfalls per
>> se.
>
> Achieving consistency across Org code requires additional efforts.

Well. Just using `string-lessp' would make things very consistent.
Easily and with no efforts.

The question though is what is the right thing to do for users while
also keeping consistency.

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

Re: [MAINTENANCE] Org orphanage?

[Alexis]

Ihor Radchenko  writes:


P.S. Does sourcehut have a notion of organizations?


Not at the moment, but Drew recently blogged that the plan is to 
commence work on this soon:


We also plan on tackling another long-awaited feature soon: user 
groups, or organizations. This and the other features described 
have been blocked on the completion of our GraphQL work, and 
with this work out of the way, it’s time to prepare for a flurry 
of new feature development to round out the alpha and finally 
bring the SourceHut beta into life.


-- https://sourcehut.org/blog/2022-11-15-four-years/


Alexis.

Re: [MAINTENANCE] Org orphanage?

[Tim Cross]

Ihor Radchenko  writes:

> Dear all,
>
> This email is inspired by recent request by org-vcard maintainer to
> transfer maintenance to someone else:
> https://github.com/flexibeast/org-vcard
>
> As a part of Org project (https://sr.ht/~bzg/org/), we currently have
> https://git.sr.ht/~bzg/org-contrib/:
>
>org-contrib: Contributed packages to Org in search for new maintainers.
>
> There, we do a very minimal maintenance and encourage people to take
> over the containing packages.
>
> Should we extend the org-contrib's current idea to other Org-related
> packages that are seeking a maintainer? Similar to
> https://github.com/emacsorphanage
>
> We may temporarily use Org mailing list as a place to report bugs.
>
> - This will give a better chance for interested people to contribute,
>   and hopefully take over the work on abandoned packages.
>
> - We can also guarantee some (very) minimal maintenance.
>
> - And it will promote Org mailing list as a place to discuss Org-related
>   staff.
>
> WDYT?

I think it is an excellent idea. A rename to something like
org-orphanage would also be good as it makes the status of these
packages much clearer and may encourage adoption of those packages
people find useful.

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

I am happy with whatever you decide.  :-)

On 11/20/22 20:34, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Please see attached which has the following code which reproduces the issue:

#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
      head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src

Thanks!

I was able to reproduce. However, this particular error appears to be
intentional.

`org-table-convert-region-max-lines' has been introduced explicitly for
such scenarios because table conversion may take significant time when
the output is large.

I think we can do 2 things to address the problem:

1. Tweak the error wording. Probably to something like
Babel result processing: Region is longer than 
`org-table-convert-region-max-lines' (%s) lines; not converting

2. Maybe introduce something like :results ignore to discard the results
completely.

Re: test-org-table/sort-lines: Failing test on macOS

[Max Nikulin]

On 21/11/2022 10:15, Ihor Radchenko wrote:

Max Nikulin writes:


However, I am not sure if ignoring locale is something we really want.
WDYT?


I think we should keep `string-collate-lessp' in the
`org-table-sort-lines' implementation. Users expect sorting accordingly
to their locales. However it is better to add a warning to
`org-table-sort-lines' docstring and to the manual that caseless sort
depends on its implementation in libc, so currently it does not work in
clang/llvm and so e.g. on MacOS.


Sounds reasonable.

Note that not only `org-table-sort-lines' is using
`string-collate-lessp'. The full list of functions potentially affected
by libc sorting is:

1. Bibliography order in `org-cite-basic-export-bibliography'
(via org-cite-basic--sort-keys -> org-cite-basic--field-less-p)

> 3. `org-table-sort-lines'
Confirmed.


2. `org-sort-list'
5. `org-sort-entries'

`downcase' is used, not proper case folding, so a potential issue


4. `org-set-tags' (tag order), when `org-tags-sort-function' is set to
"Alphabetical" or "Reverse alphabetical".


IGNORE-CASE argument is not used, perhaps `downcase' is hidden in the code.


6. Agenda sorting, when alphabetical sorting is involved


`string-lessp' and `downcase' so even more severe locale-related issues 
might be expected.



7. `org-map-entries'


Unsure which predicate is used.


I am not 100% sure where we should add the information to
docstring/manual and where we should not.


If footnotes in the manual had fixed labels then I would suggest 
reference the same footnote in the manual and in the docstrings. 
Perhaps, a new subsection should be added to info "(org) Miscellaneous" 
and "see info node ..." should be added to all involved docstrings.



Concerning the test, I would split the current testcase into 2 parts
depending on WITH-CASE argument, check if caseless collation is
available and skip the related test otherwise.


How can we check the availability?


(string-collate-lessp "a" "B" "C" t)


Indeed. Also, see https://nullprogram.com/blog/2014/06/13/. However,
what we are concerned about here is consistency. Not the pitfalls per
se.


Achieving consistency across Org code requires additional efforts.

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Samuel W. Flint]

> Ihor Radchenko writes:

IR> Ihor Radchenko  writes:
>>> I've sent in the assignment, but I'm waiting on the FSF's response & a
>>> waiver/documentation from my employer.
>> 
>> Good to hear. Note that FSF should reply within 5 working days.

IR> May I know if you got any reply from FSF?

I'm still waiting for final confirmation.  Having some issues getting
confirmation from the University.

Sam


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


-- 
Samuel W. Flint
4096R/FA13D704
  (F50D 862B 4F65 5943 A8C2  EF0E 86C9 3E7A FA13 D704)
λs.(s s) λs.(s s)
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: [PATCH] LSP support in org-src buffers

[João Pedro]

Hey there, Karthik!

I've had a similar idea, though not tied to LSP or anything. I created a
=org-contextual-src-mode= [1] ir order to have completion working on
Ledger and LaTeX source buffers. It also handles tangling! I have made a
Gist explaining, in a literate style, my process of building such a
mode.

I think the contextual src block could be split from the LSP
functionality, since it could be used in other contexts other than
dealing with language servers. My iteration is not tied to anything in
particular and simply creates a source buffer with the whole context for
that tangled file.

Hope this can help you in some way!

[1] https://gist.github.com/bigodel/15599f3c1da23d1008b7d7d4ff8bff77

Cheers,

-- 
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Bastien  writes:

> I think it is a very good idea and a natural evolution of org-contrib,
> thanks for suggesting this.
>
> If we move in this direction, "org-contrib" is probably not a good
> name anymore: perhaps "org-stub"? "org-orphanage"? Other ideas?

I am not sure if it is a good idea to keep everything in a single
repository. Maybe just create org-orphanage project, a sub-project of our
main ~bzg/org project. That org-orphanage will link to the repos we are
taking care of.

Maybe we can even gather links to all the active Org-related packages in
a similar fashion (within a dedicated sub-project).

P.S. Does sourcehut have a notion of organizations?

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

Re: [PATCH] Remove 'org-speed-commands-user' warning

[Ihor Radchenko]

Stefan Kangas  writes:

> Just a small cleanup in preparation of 9.6, see attached.

Thanks!
Applied.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f78dfea63

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

[PATCH] Remove 'org-speed-commands-user' warning

[Stefan Kangas]

Just a small cleanup in preparation of 9.6, see attached.
From bb02572eb41f61023dc421f80709fa602a9a7822 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Mon, 21 Nov 2022 12:01:29 +0100
Subject: [PATCH] Remove 'org-speed-commands-user' warning

* lisp/org-keys.el (org-speed-command-help): Remove
'org-speed-commands-user' warning.
---
 lisp/org-keys.el | 4 
 1 file changed, 4 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 79e34cbd1..95f64a3f9 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -808,10 +808,6 @@ command."
   (interactive)
   (unless org-use-speed-commands
 (user-error "Speed commands are not activated, customize `org-use-speed-commands'"))
-  ;; FIXME: remove this warning for 9.6
-  (when (boundp 'org-speed-commands-user)
-(message "`org-speed-command-user' is obsolete, please use `org-speed-commands'")
-(sit-for 3))
   (with-output-to-temp-buffer "*Help*"
 (princ "Speed commands\n==\n")
 (mapc #'org-print-speed-command
-- 
2.35.1

Re: [MAINTENANCE] Org orphanage?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> WDYT?

I think it is a very good idea and a natural evolution of org-contrib,
thanks for suggesting this.

If we move in this direction, "org-contrib" is probably not a good
name anymore: perhaps "org-stub"? "org-orphanage"? Other ideas?

We can announce this along with the Org 9.6 release.

Thanks,

-- 
 Bastien

Re: [PATCH v2 1/2] lisp/org-clock.el: Make switching states on clock-in/-out easier

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I've sent in the assignment, but I'm waiting on the FSF's response & a
>> waiver/documentation from my employer.
>
> Good to hear. Note that FSF should reply within 5 working days.

May I know if you got any reply from FSF?

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

Re: 2 'echo' bash instructions produce a table

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Confirmed, but it does not look like Org's fault.
>
> Reported to Emacs devs.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59293

Upon discussion, I have settled with a workaround.
This is a known Emacs info.el limitation.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=79c64d8c3

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

Re: 2 'echo' bash instructions produce a table

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Confirmed, but it does not look like Org's fault.
>
> Reported to Emacs devs.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59293

Upon discussion, I have settled with a workaround.
This is a known Emacs info.el limitation.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=79c64d8c3

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

[MAINTENANCE] Org orphanage?

[Ihor Radchenko]

Dear all,

This email is inspired by recent request by org-vcard maintainer to
transfer maintenance to someone else:
https://github.com/flexibeast/org-vcard

As a part of Org project (https://sr.ht/~bzg/org/), we currently have
https://git.sr.ht/~bzg/org-contrib/:

   org-contrib: Contributed packages to Org in search for new maintainers.

There, we do a very minimal maintenance and encourage people to take
over the containing packages.

Should we extend the org-contrib's current idea to other Org-related
packages that are seeking a maintainer? Similar to
https://github.com/emacsorphanage

We may temporarily use Org mailing list as a place to report bugs.

- This will give a better chance for interested people to contribute,
  and hopefully take over the work on abandoned packages.

- We can also guarantee some (very) minimal maintenance.

- And it will promote Org mailing list as a place to discuss Org-related
  staff.

WDYT?

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