[APPLIED] Re: [PATCH] I updated patch by deleteing duplicate tags

[Christopher Miles]

Kyle Meyer  writes:

> Christopher Miles writes:
>
>> Subject: [PATCH] org.el: Complete tags from both global and buffer local
>
> Thanks.  Applied (86ad8d279)...
>
>> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
>> index 5e5f1954d..0c9bb99d3 100644
>> --- a/etc/ORG-NEWS
>> +++ b/etc/ORG-NEWS
>> @@ -149,6 +149,13 @@ Example:
>>  A new =u= mode flag for Calc formulas in Org tables has been added to
>>  enable Calc units simplification mode.
>>  
>> +*** =org-set-tags-command= select tags from 
>> ~org-global-tags-completion-table~
>> +
>> +Let ~org-set-tags-command~ TAB fast tag completion interface complete
>> +tags including from both buffer local and user defined persistent
>> +global list (~org-tag-alist~ and ~org-tag-persistent-alist~). Now
>> +option ~org-complete-tags-always-offer-all-agenda-tags~ is horored.
>
> ... adding another space before "Now"

Is there any good solution to auto suitable sentence end of one space or two
space configuration?

> and s/horored/honored/.

Sorry about the typo, being busy, so a little bit of rush.

-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [PATCH] I updated patch by deleteing duplicate tags

[Kyle Meyer]

Christopher Miles writes:

> Subject: [PATCH] org.el: Complete tags from both global and buffer local

Thanks.  Applied (86ad8d279)...

> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
> index 5e5f1954d..0c9bb99d3 100644
> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -149,6 +149,13 @@ Example:
>  A new =u= mode flag for Calc formulas in Org tables has been added to
>  enable Calc units simplification mode.
>  
> +*** =org-set-tags-command= select tags from 
> ~org-global-tags-completion-table~
> +
> +Let ~org-set-tags-command~ TAB fast tag completion interface complete
> +tags including from both buffer local and user defined persistent
> +global list (~org-tag-alist~ and ~org-tag-persistent-alist~). Now
> +option ~org-complete-tags-always-offer-all-agenda-tags~ is horored.

... adding another space before "Now" and s/horored/honored/.

Re: [PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs

[Kyle Meyer]

Kyle Meyer writes:

> Sure, I'll wait another day or two for any comments on this patch as a
> whole before applying.

Applied (1806abdc3).

Re: [PATCH] testing/lisp/test-org-archive.el: Fix test

[Kyle Meyer]

Christian Garbs via "General discussions about Org-mode." writes:

> Hello,
>
> I've run across a test error on the current HEAD.
> When I run "make test" on my system, then test-org-archive/datetree
> fails.
>
> The test fails because the expected output should contain "Sunday",
> but with a German locale the generated text is "Sonntag" instead
> (which is the German translation of "Sunday").

Ah, that was dumb on my part.

> Subject: [PATCH] testing/lisp/test-org-archive.el: Fix test
>
> * testing/lisp/test-org-archive.el
> (test-org-archive/datetree): Fix test for locales that don't use
> English weekday names.
> ---
>  testing/lisp/test-org-archive.el | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/testing/lisp/test-org-archive.el 
> b/testing/lisp/test-org-archive.el
> index 71ab427d2..d24a54794 100644
> --- a/testing/lisp/test-org-archive.el
> +++ b/testing/lisp/test-org-archive.el
> @@ -63,7 +63,7 @@
>  ;; Test in buffer target with no additional subheadings...
>  (should
>   (string-match-p
> -  (regexp-quote "*** 2020-07-05 Sunday\n a")
> +  (regexp-quote (format-time-string "*** 2020-07-05 %A\n a"))

Works for me.  Another option would be to let-bind system-time-locale.

Applied (d02c0218e).  Thank you.

[PATCH] testing/lisp/test-org-archive.el: Fix test

[General discussions about Org-mode.]

Hello,

I've run across a test error on the current HEAD.
When I run "make test" on my system, then test-org-archive/datetree
fails.

The test fails because the expected output should contain "Sunday",
but with a German locale the generated text is "Sonntag" instead
(which is the German translation of "Sunday").

The attached patch fixed the test for me.

Best regards
Christian
-- 
Christian.Garbshttps://www.cgarbs.de

Q:  What's a light-year?
A:  One-third less calories than a regular year.
>From 94055073ce79080be360070b86dcd5f2c074c9d3 Mon Sep 17 00:00:00 2001
From: Christian Garbs 
Date: Wed, 13 Jan 2021 22:57:21 +0100
Subject: [PATCH] testing/lisp/test-org-archive.el: Fix test

* testing/lisp/test-org-archive.el
(test-org-archive/datetree): Fix test for locales that don't use
English weekday names.
---
 testing/lisp/test-org-archive.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/testing/lisp/test-org-archive.el b/testing/lisp/test-org-archive.el
index 71ab427d2..d24a54794 100644
--- a/testing/lisp/test-org-archive.el
+++ b/testing/lisp/test-org-archive.el
@@ -63,7 +63,7 @@
 ;; Test in buffer target with no additional subheadings...
 (should
  (string-match-p
-  (regexp-quote "*** 2020-07-05 Sunday\n a")
+  (regexp-quote (format-time-string "*** 2020-07-05 %A\n a"))
   (org-test-with-temp-text-in-file "* a\n"
 	(let ((org-archive-location "::datetree/"))
 	  (org-archive-subtree)
@@ -71,7 +71,7 @@
 ;; ... and with `org-odd-levels-only' non-nil.
 (should
  (string-match-p
-  (regexp-quote "* 2020-07-05 Sunday\n*** a")
+  (regexp-quote (format-time-string "* 2020-07-05 %A\n*** a"))
   (org-test-with-temp-text-in-file "* a\n"
 	(let ((org-archive-location "::datetree/")
 	  (org-odd-levels-only t))
@@ -80,7 +80,7 @@
 ;; Test in buffer target with an additional subheading...
 (should
  (string-match-p
-  (regexp-quote "*** 2020-07-05 Sunday\n a\n* b")
+  (regexp-quote (format-time-string "*** 2020-07-05 %A\n a\n* b"))
   (org-test-with-temp-text-in-file "* b\n"
 	(let ((org-archive-location "::datetree/* a"))
 	  (org-archive-subtree)
@@ -88,7 +88,7 @@
 ;; ... and with `org-odd-levels-only' non-nil.
 (should
  (string-match-p
-  (regexp-quote "* 2020-07-05 Sunday\n*** a\n* b")
+  (regexp-quote (format-time-string "* 2020-07-05 %A\n*** a\n* b"))
   (org-test-with-temp-text-in-file "* b\n"
 	(let ((org-archive-location "::datetree/* a")
 	  (org-odd-levels-only t))
-- 
2.20.1

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

[and whether it is upon typing vs. movement.]

On 1/13/21, Samuel Wales  wrote:
> [my point aboutg orthogonal solution is that different mechanisms
> would not be needed for mouse and cursor and different stuff to
> display in the echo area.  to complete my incomplete sentence,
> major/minor modes and potentially differing delays.]
>
> On 1/13/21, Samuel Wales  wrote:
>> this is an interesting discussion.  is there any side discussion that
>> takes into account both mouse and cursor?  i have had a devil of a
>> time trying to get:
>>
>> 1] displaying value of link in echo area [the problem you are
>> discussing -- don't let me derail it] with a short nonzero delay
>> 2] doing so *for both cursor and mouse* -- too much futzing here
>> 3] also doing other stuff -- also futzing
>>
>> other stuff includes maybe [or maybe not] showing function signature
>> or docstrings in elisp buffers [possibly with longer delay], and
>> showing the time span in number of days from now to the org timestamp
>> at point or under mouse in any mode.
>>
>> i have code for the last thing.  the problem is figuring out making
>> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
>> keyboard without verbose help-echo like in dired.  also the
>> major/minor modes and
>>
>> i guess i am saying [back to topic] this is a bit complex and i wonder
>> if a more orthogonal solution is called for?  as some might want mouse
>> activation also, and eldoc already shows elisp stuff.
>>
>> and another suggestion: org-link-minor-mode is what i might use to
>> identify when to activate org links and timestamps.
>>
>>
>> On 1/13/21, Juri Linkov  wrote:
 Still, I would like to continue to promote my solution, because it's
 much simpler and is instantaneous upon key-press. It might also be more
 efficient: The help-at-pt solution runs code in all buffers, let's say
 every 0.1 seconds, all the time; my solution only runs in the selected
 mode(s) buffers but after every key-press, which for an 'average'
 touch-typist taking a speed test would be 0.3 seconds.
>>>
>>> I agree.  Overhead of needlessly running the global timer is what
>>> concerns
>>> me too.  But using an idle timer by help-at-pt is not that bad either.
>>> It runs code only after the last key-press in a sequence of many
>>> key-presses.
>>> So with idle timer in help-at-pt and the default delay, code runs less
>>> often
>>> than by using post-command-hook.  Here are a brief comparison of
>>> advantages and disadvantages of these two approaches:
>>>
>>> 1. help-at-pt idle timer
>>>
>>> Pros:
>>> 1.1. runs code once a sequence of key-presses is finished,
>>>  and 1 second has passed after the last key-press,
>>>  where 1 second is the default value of help-at-pt-timer-delay.
>>>  Customizing it to 0.1 removes this advantage because on average
>>>  there is more time between key-presses than 0.1 seconds.
>>>
>>> Cons:
>>> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1
>>> second)
>>>  that helps code to run less often (not after every key-press),
>>>  the effect of the primary goal of this feature to display
>>>  the help-echo string is not instantaneous;
>>> 1.2. the timer runs globally in all modes (this could be mitigated
>>>  by checking major mode in the timer function).
>>>
>>> 2. post-command-hook
>>>
>>> Pros:
>>> 1.1. can be activated locally only in org-mode buffers;
>>> 1.2. display of the help-echo string is instantaneous.
>>>
>>> Cons:
>>> 1.1. runs code after every key-press.
>>>
>>> So your approach has more advantages.  The only problem with your code
>>> is that it displays the garbled mojibake on URLs with Unicode symbols,
>>> that need to be decoded to UTF-8 with:
>>>
>>>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>>>
>>> Also not to step on other more important minibuffer echo-area messages,
>>> help-at-pt-maybe-display has better handling with:
>>>
>>>(or (not (current-message))
>>>(string= (current-message) "Quit"))
>>>
>>>
>>>
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

[my point aboutg orthogonal solution is that different mechanisms
would not be needed for mouse and cursor and different stuff to
display in the echo area.  to complete my incomplete sentence,
major/minor modes and potentially differing delays.]

On 1/13/21, Samuel Wales  wrote:
> this is an interesting discussion.  is there any side discussion that
> takes into account both mouse and cursor?  i have had a devil of a
> time trying to get:
>
> 1] displaying value of link in echo area [the problem you are
> discussing -- don't let me derail it] with a short nonzero delay
> 2] doing so *for both cursor and mouse* -- too much futzing here
> 3] also doing other stuff -- also futzing
>
> other stuff includes maybe [or maybe not] showing function signature
> or docstrings in elisp buffers [possibly with longer delay], and
> showing the time span in number of days from now to the org timestamp
> at point or under mouse in any mode.
>
> i have code for the last thing.  the problem is figuring out making
> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
> keyboard without verbose help-echo like in dired.  also the
> major/minor modes and
>
> i guess i am saying [back to topic] this is a bit complex and i wonder
> if a more orthogonal solution is called for?  as some might want mouse
> activation also, and eldoc already shows elisp stuff.
>
> and another suggestion: org-link-minor-mode is what i might use to
> identify when to activate org links and timestamps.
>
>
> On 1/13/21, Juri Linkov  wrote:
>>> Still, I would like to continue to promote my solution, because it's
>>> much simpler and is instantaneous upon key-press. It might also be more
>>> efficient: The help-at-pt solution runs code in all buffers, let's say
>>> every 0.1 seconds, all the time; my solution only runs in the selected
>>> mode(s) buffers but after every key-press, which for an 'average'
>>> touch-typist taking a speed test would be 0.3 seconds.
>>
>> I agree.  Overhead of needlessly running the global timer is what
>> concerns
>> me too.  But using an idle timer by help-at-pt is not that bad either.
>> It runs code only after the last key-press in a sequence of many
>> key-presses.
>> So with idle timer in help-at-pt and the default delay, code runs less
>> often
>> than by using post-command-hook.  Here are a brief comparison of
>> advantages and disadvantages of these two approaches:
>>
>> 1. help-at-pt idle timer
>>
>> Pros:
>> 1.1. runs code once a sequence of key-presses is finished,
>>  and 1 second has passed after the last key-press,
>>  where 1 second is the default value of help-at-pt-timer-delay.
>>  Customizing it to 0.1 removes this advantage because on average
>>  there is more time between key-presses than 0.1 seconds.
>>
>> Cons:
>> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
>>  that helps code to run less often (not after every key-press),
>>  the effect of the primary goal of this feature to display
>>  the help-echo string is not instantaneous;
>> 1.2. the timer runs globally in all modes (this could be mitigated
>>  by checking major mode in the timer function).
>>
>> 2. post-command-hook
>>
>> Pros:
>> 1.1. can be activated locally only in org-mode buffers;
>> 1.2. display of the help-echo string is instantaneous.
>>
>> Cons:
>> 1.1. runs code after every key-press.
>>
>> So your approach has more advantages.  The only problem with your code
>> is that it displays the garbled mojibake on URLs with Unicode symbols,
>> that need to be decoded to UTF-8 with:
>>
>>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>>
>> Also not to step on other more important minibuffer echo-area messages,
>> help-at-pt-maybe-display has better handling with:
>>
>>(or (not (current-message))
>> (string= (current-message) "Quit"))
>>
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

this is an interesting discussion.  is there any side discussion that
takes into account both mouse and cursor?  i have had a devil of a
time trying to get:

1] displaying value of link in echo area [the problem you are
discussing -- don't let me derail it] with a short nonzero delay
2] doing so *for both cursor and mouse* -- too much futzing here
3] also doing other stuff -- also futzing

other stuff includes maybe [or maybe not] showing function signature
or docstrings in elisp buffers [possibly with longer delay], and
showing the time span in number of days from now to the org timestamp
at point or under mouse in any mode.

i have code for the last thing.  the problem is figuring out making
tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
keyboard without verbose help-echo like in dired.  also the
major/minor modes and

i guess i am saying [back to topic] this is a bit complex and i wonder
if a more orthogonal solution is called for?  as some might want mouse
activation also, and eldoc already shows elisp stuff.

and another suggestion: org-link-minor-mode is what i might use to
identify when to activate org links and timestamps.


On 1/13/21, Juri Linkov  wrote:
>> Still, I would like to continue to promote my solution, because it's
>> much simpler and is instantaneous upon key-press. It might also be more
>> efficient: The help-at-pt solution runs code in all buffers, let's say
>> every 0.1 seconds, all the time; my solution only runs in the selected
>> mode(s) buffers but after every key-press, which for an 'average'
>> touch-typist taking a speed test would be 0.3 seconds.
>
> I agree.  Overhead of needlessly running the global timer is what concerns
> me too.  But using an idle timer by help-at-pt is not that bad either.
> It runs code only after the last key-press in a sequence of many
> key-presses.
> So with idle timer in help-at-pt and the default delay, code runs less
> often
> than by using post-command-hook.  Here are a brief comparison of
> advantages and disadvantages of these two approaches:
>
> 1. help-at-pt idle timer
>
> Pros:
> 1.1. runs code once a sequence of key-presses is finished,
>  and 1 second has passed after the last key-press,
>  where 1 second is the default value of help-at-pt-timer-delay.
>  Customizing it to 0.1 removes this advantage because on average
>  there is more time between key-presses than 0.1 seconds.
>
> Cons:
> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
>  that helps code to run less often (not after every key-press),
>  the effect of the primary goal of this feature to display
>  the help-echo string is not instantaneous;
> 1.2. the timer runs globally in all modes (this could be mitigated
>  by checking major mode in the timer function).
>
> 2. post-command-hook
>
> Pros:
> 1.1. can be activated locally only in org-mode buffers;
> 1.2. display of the help-echo string is instantaneous.
>
> Cons:
> 1.1. runs code after every key-press.
>
> So your approach has more advantages.  The only problem with your code
> is that it displays the garbled mojibake on URLs with Unicode symbols,
> that need to be decoded to UTF-8 with:
>
>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>
> Also not to step on other more important minibuffer echo-area messages,
> help-at-pt-maybe-display has better handling with:
>
>(or (not (current-message))
>  (string= (current-message) "Quit"))
>
>
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

> Still, I would like to continue to promote my solution, because it's
> much simpler and is instantaneous upon key-press. It might also be more
> efficient: The help-at-pt solution runs code in all buffers, let's say
> every 0.1 seconds, all the time; my solution only runs in the selected
> mode(s) buffers but after every key-press, which for an 'average'
> touch-typist taking a speed test would be 0.3 seconds.

I agree.  Overhead of needlessly running the global timer is what concerns
me too.  But using an idle timer by help-at-pt is not that bad either.
It runs code only after the last key-press in a sequence of many key-presses.
So with idle timer in help-at-pt and the default delay, code runs less often
than by using post-command-hook.  Here are a brief comparison of
advantages and disadvantages of these two approaches:

1. help-at-pt idle timer

Pros:
1.1. runs code once a sequence of key-presses is finished,
 and 1 second has passed after the last key-press,
 where 1 second is the default value of help-at-pt-timer-delay.
 Customizing it to 0.1 removes this advantage because on average
 there is more time between key-presses than 0.1 seconds.

Cons:
1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
 that helps code to run less often (not after every key-press),
 the effect of the primary goal of this feature to display
 the help-echo string is not instantaneous;
1.2. the timer runs globally in all modes (this could be mitigated
 by checking major mode in the timer function).

2. post-command-hook

Pros:
1.1. can be activated locally only in org-mode buffers;
1.2. display of the help-echo string is instantaneous.

Cons:
1.1. runs code after every key-press.

So your approach has more advantages.  The only problem with your code
is that it displays the garbled mojibake on URLs with Unicode symbols,
that need to be decoded to UTF-8 with:

  (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))

Also not to step on other more important minibuffer echo-area messages,
help-at-pt-maybe-display has better handling with:

   (or (not (current-message))
   (string= (current-message) "Quit"))

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Tim Visher]

On Tue, Jan 12, 2021 at 10:43 PM Kyle Meyer  wrote:

> Tim Visher writes:
>
> > On Mon, Jan 11, 2021 at 8:19 PM Kyle Meyer  wrote:
>
> >> Thanks for reporting.  Is this addressed by the in-progress series at
> >> ?
> >>
> >
> > IIUC yes. I believe the following section of the diff should address it.
> [...]
> > If I'm reading the code correctly, `org-html-plain-text` is a specialized
> > form of converting org data into a plain text string with no markup. If I
> > have that correct then I believe you're right.
> >
> > Is that your read as well?
>
> Yep.  And as a light test:
>
> #+title: a *b* c
>
> exports
>
>   a *b* c
>
> rather than
>
>   a b c
>

Nice! I don't know enough about `org-export` but FWIW the use case I have
is not to have an explicit `title` property but instead just the default
title of the heading contents. I assume that's all handled transparently by
the `(plist-get …` section.

Do you have any idea the timeline for getting that patch merged?

Re: Exporting from Org to Gift/Aiken or other quiz formats

[Eric S Fraga]

On Wednesday, 13 Jan 2021 at 12:59, Diego Zamboni wrote:
> I also started exploring the Moodle XML format, but I was happy to discover
> Moodle can also import other formats. I think I might stick to GIFT, Aiken
> or some other text-based format, since they seem easier to manipulate
> (albeit of course less powerful).

Yeah, I looked at the text based ones.  For some reason, I ended up with
XML (which I do not particularly like) but I cannot remember why!

> I'll keep you posted if I come up with anything.

Please do!  Thank you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-179-g5b5c42

Re: Exporting from Org to Gift/Aiken or other quiz formats

[Diego Zamboni]

Hi Eric,


> I did not manage to develop an exporter for moodle.  I did write a very
> hackish awk script that takes a sort of org document (i.e. it is an org
> document but has to follow a strict layout) and creates a Moodle XML
> format file.
>
> Lots of introspection of exported Moodle quizzes to figure out some of
> the basics...  What I've got does the job so long as you only want
> multiple choice questions and numeric answer questions (with tolerances)
> and provides question specific feedback.  As I said, very hackish...
>

Thanks! I found there is http://www.qml2xml.pro/, which is a custom markup
language for quizzes, and from which Moodle XML can be exported.
Unfortunately the tool seems to be online-only, no downloadable version I
could find. And also, the QML format is a bit strange.

I also started exploring the Moodle XML format, but I was happy to discover
Moodle can also import other formats. I think I might stick to GIFT, Aiken
or some other text-based format, since they seem easier to manipulate
(albeit of course less powerful).

My ultimate ideal goal would be to be able to export a whole Org document
into the whole contents of a course, including Books/pages (not sure yet if
Moodle can import Markdown or something else), quizzes, etc. But quizzes
would be a good start :)

I'll keep you posted if I come up with anything.

--Diego

Re: Exporting from Org to Gift/Aiken or other quiz formats

[Eric S Fraga]

Hi Diego,

I did not manage to develop an exporter for moodle.  I did write a very
hackish awk script that takes a sort of org document (i.e. it is an org
document but has to follow a strict layout) and creates a Moodle XML
format file.

Lots of introspection of exported Moodle quizzes to figure out some of
the basics...  What I've got does the job so long as you only want
multiple choice questions and numeric answer questions (with tolerances)
and provides question specific feedback.  As I said, very hackish...

I would love to be able to export from org, mind you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-179-g5b5c42

Exporting from Org to Gift/Aiken or other quiz formats

[Diego Zamboni]

Hi everyone,

I've started to develop online teaching materials with Moodle (
https://moodle.com/), and I'm looking for ways to generate my content using
Org as much as possible.

For quizzes, Moodle can import various known question/answer formats,
including GIFT, Aiken, Moodle's own XML format, and a few others:

- Aiken format
- Blackboard
- Embedded answers (Cloze)
- Examview
- GIFT format
- Missing word format
- Moodle XML format
- WebCT format

I was wondering if anyone has any experience or pointers to existing ways
of exporting from Org to some of these formats.

Eric: I found this old thread:
https://lists.gnu.org/archive/html/emacs-orgmode/2015-08/msg01219.html -
did you ever develop or find a way to do the export? Otherwise I might take
a shot at it, using Marcin's code as a starting point.

Thanks in advance!
--Diego

Re: [PATCH] I updated patch by deleteing duplicate tags

[Christopher Miles]

Kyle Meyer  writes:

> Christopher Miles writes:
>
>> Kyle Meyer  writes:
>>
>>> stardiviner writes:
> By this patch, will merge both buffer-local tags and user defined global
> `org-tags-alist`.
>>>
>>> It does a bit more than that.  It uses org-global-tags-completion-table,
>>> which considers tags in all agenda files by default and takes into
>>> account org-tag-alist (as well as org-tag-persistent-alist) via the use
>>> of the org-current-tag-alist variable.
>>
>> That's what I want. Why obviously user pre-defined tags can't be used 
>> globally.
>> Right? It should be.
>
> My point was that it's not just adding these pre-defined lists (#1);
> it's also adding tags from agenda files (#2).  I think we certainly
> don't want to do #2 unconditionally.  On the other hand, #1 is probably
> okay, but as I said in my last email, I could see not wanting that
> either.
>
> Anyway, the patch I proposed (which you've adapted for your latest
> round), avoids #2 by guarding the behavior behind the existing
> org-complete-tags-always-offer-all-agenda-tags option, and I think
> that's a good path forward.
>
>> Subject: [PATCH] org.el: Complete tags from both global and buffer local
>>
>> * lisp/org.el (org-fast-tag-selection): Merge buffer local tags with
>> global alist of tags. And it obey the option
>> org-complete-tags-always-offer-all-agenda-tags.
>
> s/obey/&s/

Applied.

>
>> * doc/org-manual.org: Update the TAB key doc in tags selection UI.
>>
>> * etc/ORG-NEWS: Mention the change in org-set-tags-command.
>> ---
>>  doc/org-manual.org |  6 +++---
>>  etc/ORG-NEWS   |  5 +
>>  lisp/org.el| 24 ++--
>>  3 files changed, 22 insertions(+), 13 deletions(-)
>>
>> diff --git a/doc/org-manual.org b/doc/org-manual.org
>> index b015b502c..01cec4b8d 100644
>> --- a/doc/org-manual.org
>> +++ b/doc/org-manual.org
>> @@ -4860,9 +4860,9 @@ In this interface, you can also use the following 
>> special keys:
>>  
>>#+kindex: TAB
>>Enter a tag in the minibuffer, even if the tag is not in the
>> -  predefined list.  You can complete on all tags present in the
>> -  buffer.  You can also add several tags: just separate them with
>> -  a comma.
>> +  predefined list.  You can complete on all tags present in the buffer
>> +  and globally pre-defined tags from ~org-tag{-persistent}-alist~.
>
> Please spell these two options out: ~org-tag-alist~ and
> ~org-tag-persistent-alist~.

Applied.

>
>> +  You can also add several tags: just separate them with a comma.
>>  
>>  - {{{kbd(SPC)}}} ::
>>  
>> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
>> index 5e5f1954d..5e68d27c0 100644
>> --- a/etc/ORG-NEWS
>> +++ b/etc/ORG-NEWS
>> @@ -149,6 +149,11 @@ Example:
>>  A new =u= mode flag for Calc formulas in Org tables has been added to
>>  enable Calc units simplification mode.
>>  
>> +*** =org-set-tags-command= select tags from 
>> ~org-global-tags-completion-table~
>> +
>> +Let =org-set-tags-command= complete tags from global tags list (both
>> +buffer-local tags and ~org-tag{-persistent}-alist~).
>
> Same note about avoiding shorthand for the option names.

Applied.

>
> Also, please rewrite this to make it clear that this is relevant for TAB
> in the fast completion interface.  It's probably also worth mentioning
> that org-complete-tags-always-offer-all-agenda-tags is now honored.
>
> And, very minor, but any reason for the mix of =...= and ~...~ markup
> here?

Maybe our recognition is different I personally like to markup command as
verbatim, and option as code to display as two different face color. I forget to
drop my habit Now fixed to use "~code~".

>
>> diff --git a/lisp/org.el b/lisp/org.el
>> index 5b0ae389c..ba816dfa6 100644
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -12139,7 +12139,7 @@ (defun org-fast-tag-selection (current inherited 
>> table &optional todo-table)
>>fulltable
>>   (buf (current-buffer))
>>   (expert (eq org-fast-tag-selection-single-key 'expert))
>> - (buffer-tags nil)
>> + (tab-tags nil)
>>   (fwidth (+ maxlen 3 1 3))
>>   (ncol (/ (- (window-width) 4) fwidth))
>>   (i-face 'org-done)
>> @@ -12274,16 +12274,20 @@ (defun org-fast-tag-selection (current inherited 
>> table &optional todo-table)
>>  (setq current nil)
>>  (when exit-after-next (setq exit-after-next 'now)))
>> ((= c ?\t)
>> -(condition-case nil
>
> Unlike the patch I sent, you've dropped the condition-case here, which I
> don't think was intentional.
>

Added back now.

> Thanks.


-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
From 4bb6ca19ceb8dbd8f827e4df2d7cc4ec7c7a931b Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Wed, 2 Dec 2020 17:24:29 +0800
Subject: [PATCH

Re: ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

[Eric S Fraga]

Yes, I use targets for numbered (ordered) lists all the time.  They work
well and export perfectly (at least to LaTeX).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-179-g5b5c42