Re: Feedback on Org syntax document

2022-11-26 Thread Bastien
Ihor Radchenko  writes:

> Will it be enough?

As long as we can point to a thread that contains all the information
and pointers that allows to quickly read Tim's comments, yes, fine.

-- 
 Bastien



[HELP] Looking for volunteers to maintain babel support for python-mode.el (MELPA)

2022-11-26 Thread Ihor Radchenko
Dear All,

We are going to drop support of python-mode.el in favour of built-in
python.el due to lack of resources and apparent lack of interest.

See https://orgmode.org/list/87r0yk7bx8.fsf@localhost

If anyone is interested to continue supporting python-mode integration,
please let us know. We can then extract python-mode parts from
ob-python.el and hand them over for future maintenance as a separate
package.

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



Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

2022-11-26 Thread Ihor Radchenko
Bastien  writes:

> Jack Kamm  writes:
>
>> If python-mode support is removed, I'd be willing to help create a new
>> ob-python-mode package
>
> Indeed.  A suggestion: can you or Ihor send a help request to the
> list, explaining the issue at hand and asking if someone wants to
> create and maintain ob-python-mode.el?  
>
> This way we can refer to this email on the list when announcing that
> ob-python.el do not support python-mode.el anymore.

Done: https://orgmode.org/list/87lenyjaxx.fsf@localhost

I also added NEWS entry
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6db75d560

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



Re: Feedback on Org syntax document

2022-11-26 Thread Timothy
Hi Ihor,

> I have addressed the most important comments that should be resolved
> before the coming Org release.
>
> See the attached patches.
>
> I will merge them if there are no objections.

Thanks for getting to this, I really appreciate you picking up the slack with
this 😀.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .


Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

2022-11-26 Thread Bastien
Ihor Radchenko  writes:

> Done: https://orgmode.org/list/87lenyjaxx.fsf@localhost
>
> I also added NEWS entry
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6db75d560

Thanks!

-- 
 Bastien



Re: org-mode code fence for markdown

2022-11-26 Thread Norwid Behrnd
Ihor Radchenko  wrote:

> 
> It should, if you have markdown-mode installed.
> 
> Try
> 
> #+begin_src markdown :tangle yes
> ,* Item 1
> ,* Item 2
>   - Item 2a
> + Item 2a1
>   - Item 2b
> ,* Item 3
> #+end_src

Affirmative, after installing elpa-markdown-mode (example in Linux Debian's
synaptic), the box opens as anticipated.  The text's markup indications for
e.g., text in bold, italic equally work as does joining snippets via tangle
(C-c C-v t).

> Note that you need to escape the stars as they would be recognized as
> Org headings otherwise.

Similar to org-mode (self)reporting about org-mode, i.e.

```org
  #+begin_src org
,* level one
,** level two
,** level two
  #+end_src
```

the escaping comma equally is added on the fly when closing the box (C-c ') for
a box about markdown, too.  The handy promotion/demotion of headers, or entries
of a list (M-left, M-right) which equally is available in an open box about
orgmode however is absent for an open box about markdown (M-up/M-down is
absent for both); however, this is not perceived as a constraint.

Thank you, the issue is resolved.

Norwid



Re: LIterate programming with calc (help)

2022-11-26 Thread Ypo
Just in case you find this package interesting. Except some problems 
with units conversion, it's nice:


https://github.com/sulami/literate-calc-mode.el


This is a literate calc file.

Lines without "=" are ignored.

All results starting with "=>" are an overlay generated by
literate-calc-mode. That means they are displayed in Emacs, but not
actually in the buffer/file contents.

We can calculate a value like so:

= 2 + 2 => 4

If there is any string on the left hand side, it becomes a bound
variable.

Pi = 3.14159 => Pi: 3.14159

We can use this variable below the definiton.

Tau = Pi * 2 => Tau: 6.28318

Results are calculated using Emacs' own calc, so you can use formulas
as well.

= round(Pi, 2) => 3.14

Later bindings shadow earlier ones:

Pi = 3 => Pi: 3

= Pi => 3

Variable names can have spaces as well:

Monthly Expenses = 500 => Monthly Expenses: 500

Monthly Income = 1000 => Monthly Income: 1000

Annual Savings = 12 * (Monthly Income - Monthly Expenses) => Annual Savings: 
6000

All values are recalculated on every update in a spreadsheet-like
fashion.

Calc also has a lot of advanced features, like arrays:

Numbers = [1 2 3] => Numbers: [1, 2, 3]

= 3 Numbers => [3, 6, 9]




"Fraga, Eric"  writes:

>/> I guess that the main problem is that calc is tightly integrated with/
>/> interactive commands. Maybe ob-calc could be extended to somehow/
>/> indicate the commands to be executed in addition to inputting stack/
>/> entries./
>/>/
>/> Not sure if there is much interest in such feature though./
>
>/Thinking out loud, what would be better, but I have no idea how feasible/
>/it would be, would be to have ob-calc make use of the embedded calc/
>/functionality and syntax, so that you could write something like this:/
>
>/#+begin_src calc/
>/a := 300 m/
>/b := 2 a =>/
>/#+end_src/
>
>/which would output the result of any line with => on it./

I am CCing Tom Gillespie, the maintainer of ob-calc. Maybe he has
something to say.


[BUG] global-whitespace-mode + org-capture: Second capture fails w/ "Marker does not point anywhere" [9.5.5 (release_9.5.5 @ /usr/share/emacs/29.0.50/lisp/org/)]

2022-11-26 Thread Arsen Arsenović
Evening,

If attempting to capture something while global-whitespace-mode is
enabled, a second capture will fail with "Marker does not point
anywhere".  The first capture attempt presumably succeeds since
whitespace-mode didn't touch the buffer yet at time of searching.
Reproduction steps:

(in an org-mode.git clone)

1. emacs -Q --execute '(global-whitespace-mode)' -L lisp/
2. M-x org-capture RET t C-c C-c
2. M-x org-capture RET t

I'm uncertain if this is relevant, but I just spotted that *Warnings*
also gets:

  Warning (org): Capture requirement: switching buffer #
  to Org mode

Backtrace:

Debugger entered--Lisp error: (error "Capture template ‘t’: Marker does not 
point anywhe...")
  error("Capture template `%s': %s" "t" "Marker does not point anywhere")
  (condition-case error (org-capture-place-template (eq (car (org-capture-get 
:target)) 'function)) ((error quit) (if (and (buffer-base-buffer 
(current-buffer)) (string-prefix-p "CAPTURE-" (buffer-name))) (progn 
(kill-buffer (current-buffer (set-window-configuration (org-capture-get 
:return-to-wconf)) (error "Capture template `%s': %s" (org-capture-get :key) 
(error-message-string error
  (cond ((equal entry "C") (customize-variable 'org-capture-templates)) ((equal 
entry "q") (user-error "Abort")) (t (org-capture-set-plist entry) 
(org-capture-get-template) (org-capture-put :original-buffer orig-buf 
:original-file (or (buffer-file-name orig-buf) (and (featurep 'dired) (car 
(rassq orig-buf dired-buffers :original-file-nondirectory (and 
(buffer-file-name orig-buf) (file-name-nondirectory (buffer-file-name 
orig-buf))) :annotation annotation :initial initial :return-to-wconf 
(current-window-configuration) :default-time (or org-overriding-default-time 
(org-current-time))) (org-capture-set-target-location (and (equal goto 0) 
'here)) (condition-case error (org-capture-put :template 
(org-capture-fill-template)) ((error quit) (if (get-buffer "*Capture*") 
(kill-buffer "*Capture*")) (error "Capture abort: %s" (error-message-string 
error (setq org-capture-clock-keep (org-capture-get :clock-keep)) 
(condition-case error (org-capture-place-template (eq (car (org-capture-get 
:target)) 'function)) ((error quit) (if (and (buffer-base-buffer 
(current-buffer)) (string-prefix-p "CAPTURE-" (buffer-name))) (progn 
(kill-buffer (current-buffer (set-window-configuration (org-capture-get 
:return-to-wconf)) (error "Capture template `%s': %s" (org-capture-get :key) 
(error-message-string error (if (and (derived-mode-p 'org-mode) 
(org-capture-get :clock-in)) (progn (condition-case nil (progn (if 
(org-clock-is-active) (progn ...)) (org-clock-in) (set (make-local-variable 
...) (copy-marker org-clock-marker))) (error "Could not start the clock in this 
capture buffer" (if (org-capture-get :immediate-finish) (progn 
(org-capture-finalize)
  (let* ((orig-buf (current-buffer)) (annotation (if (and (boundp 
'org-capture-link-is-already-stored) org-capture-link-is-already-stored) 
(plist-get org-store-link-plist :annotation) (condition-case nil (progn 
(org-store-link nil)) (error nil (entry (or org-capture-entry 
(org-capture-select-template keys))) initial) (setq initial (or 
org-capture-initial (and (org-region-active-p) (buffer-substring (point) 
(mark) (if (stringp initial) (progn (remove-text-properties 0 (length 
initial) '(read-only t) initial))) (if (stringp annotation) (progn 
(remove-text-properties 0 (length annotation) '(read-only t) annotation))) 
(cond ((equal entry "C") (customize-variable 'org-capture-templates)) ((equal 
entry "q") (user-error "Abort")) (t (org-capture-set-plist entry) 
(org-capture-get-template) (org-capture-put :original-buffer orig-buf 
:original-file (or (buffer-file-name orig-buf) (and (featurep 'dired) (car 
(rassq orig-buf dired-buffers :original-file-nondirectory (and 
(buffer-file-name orig-buf) (file-name-nondirectory (buffer-file-name 
orig-buf))) :annotation annotation :initial initial :return-to-wconf 
(current-window-configuration) :default-time (or org-overriding-default-time 
(org-current-time))) (org-capture-set-target-location (and (equal goto 0) 
'here)) (condition-case error (org-capture-put :template 
(org-capture-fill-template)) ((error quit) (if (get-buffer "*Capture*") 
(kill-buffer "*Capture*")) (error "Capture abort: %s" (error-message-string 
error (setq org-capture-clock-keep (org-capture-get :clock-keep)) 
(condition-case error (org-capture-place-template (eq (car (org-capture-get 
:target)) 'function)) ((error quit) (if (and (buffer-base-buffer ...) 
(string-prefix-p "CAPTURE-" ...)) (progn (kill-buffer ...))) 
(set-window-configuration (org-capture-get :return-to-wconf)) (error "Capture 
template `%s': %s" (org-capture-get :key) (error-message-string error (if 
(and (derived-mode-p 'org-mode) (org-capture-get :clock-in)) (progn 
(condition-case nil (progn (if ... ...) (org-clock-in) (set ... ...)) (error 
"Could not start the clock in this capture 

Switching over from package org-radiobutton to native support

2022-11-26 Thread Terje Larsen
So I found out that there is now native support for radio-button style
selects and I have tested it and it seems to work well.

However I am missing a function similar to `org-radiobutton-value`:
https://github.com/Fuco1/org-radiobutton/blob/master/org-radiobutton.el#L111-L121

That will return the value of the currently selected checkbox by the
attached name.

So for example:

#+ATTR_ORG: :radio t
#+NAME: named_radio_value
- [ ] Value A
- [X] Value B
- [ ] Value C

Would return `Value B` for `named_radio_value`. This is useful when
creating interfaces in Org Mode and acting on those.

I know it is possible via a mouthful of lisp. But it would be nice if it
was natively supported. It would also be nice if this also worked for
normal lists, e.g. having the possibility to easily extract all selected
values.

What do you think? Is something like this already implemented, but I missed
it?

Best regards,
Terje Larsen


[HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-11-26 Thread Ihor Radchenko
Hi,

We have the following translations for clock table column names:

;; FIXME: translate es and nl last string "Clock summary at"
(defcustom org-clock-clocktable-language-setup
  '(("en" "File" "L"  "Timestamp"  "Headline" "Time"  "ALL"   "Total time"  
 "File time" "Clock summary at")
("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO" "Tiempo total" 
"Tiempo archivo" "Clock summary at")
("fr" "Fichier"  "N"  "Horodatage" "En-tête"  "Durée" "TOUT"  "Durée 
totale" "Durée fichier" "Horodatage sommaire à")
("nl" "Bestand"  "N"  "Tijdstip"   "Hoofding" "Duur"  "ALLES" "Totale duur" 
 "Bestandstijd" "Clock summary at")
("de" "Datei""E"  "Zeitstempel" "Kopfzeile" "Dauer" "GESAMT" 
"Gesamtdauer"  "Dateizeit" "Erstellt am"))
  "Terms used in clocktable, translated to different languages."
  ...)

As FIXME states, we at least need to translate "Clock summary at" to
Spanish and Dutch.

Contributions for other languages are also welcome.

P.S. I am taking this opportunity with an easy help request to see how
many people would be interested to contribute non-code.

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



Re: [BUG] global-whitespace-mode + org-capture: Second capture fails w/ "Marker does not point anywhere" [9.5.5 (release_9.5.5 @ /usr/share/emacs/29.0.50/lisp/org/)]

2022-11-26 Thread Ihor Radchenko
Arsen Arsenović  writes:

> If attempting to capture something while global-whitespace-mode is
> enabled, a second capture will fail with "Marker does not point
> anywhere".  The first capture attempt presumably succeeds since
> whitespace-mode didn't touch the buffer yet at time of searching.
> Reproduction steps:
>
> (in an org-mode.git clone)
>
> 1. emacs -Q --execute '(global-whitespace-mode)' -L lisp/
> 2. M-x org-capture RET t C-c C-c
> 2. M-x org-capture RET t
>
> I'm uncertain if this is relevant, but I just spotted that *Warnings*
> also gets:
>
>   Warning (org): Capture requirement: switching buffer #
>   to Org mode
>
> Backtrace:
>
> Debugger entered--Lisp error: (error "Capture template ‘t’: Marker does not 
> point anywhe...")

I can reproduce on Emacs 29, but not on Emacs 28.
Does not look like Org's fault.
I replied in your Emacs bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59618

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



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

2022-11-26 Thread Ihor Radchenko
Ihor Radchenko  writes:

> See the updated patch.

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

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



Re: [RFC] Re: Headings and Headlines

2022-11-26 Thread Ihor Radchenko
Ihor Radchenko  writes:

> Bastien  writes:
>
>>> 2. We introduce a new constant: org-element-heading-type, defaulting to
>>>'headline
>>> 3. We use the new constant instead of 'headline element type symbol
>>> 4. We announce loudly that 'headline will be deprecated in favour of the
>>>new constant
>>> 5. Few years later, we change the org-element-heading-type value to
>>>'heading
>>
>> I think this is okay too, though `org-element-heading-type' might not
>> be explicit enough: what about `org-element-heading-type-symbol'?
>
> Agree. I was leaning towards having "symbol" in the name as well after
> sleeping with the idea.

I looked into this further and I do not think that it is a good idea to
make this change in the coming release. Renaming some things is very too
easy to get wrong and cause failures.

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