Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)

[Ihor Radchenko]

Dear Dmitrii,

I strongly support the proposal.

Another use case for me is to speed up agenda creation.
I usually do not like to split my org files into too many. However, it
results in very large and slow org buffers later. If I can store some
parts of the org files externally and only show them if some condition
is met (say, for certain todo state of the parent entry), it would speed
up my agenda and the buffer navigation quite significantly.

Example:
#+begin_src org
* Projects
** 2019
*** TODO Project 1 :ORG:
# the project contents is stored in an external file
:PROPERTIES:
:ORG-FILE: project1.org
:END:
# beginning of a lense, which is linked to project1.org
 Heading 1
 Heading 2
And many headings below
# ...
# end of the lense
*** HOLD Project 2 :ORG:
:PROPERTIES:
:ORG-FILE: project2.org
:END:
# beginning of another lense
# nothing is included here because the project state is =HOLD=
# end of the lense
#+end_src

Let me put some historical context to this proposal.
There was a discussion of similar feature in emacs-dev last year.
The idea was to implement nested buffers:
https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html 

There are also several projects, which implement part of the
functionality you described:
- mmm-mode: https://github.com/purcell/mmm-mode
- polymode: https://github.com/polymode/polymode

Best,
Ihor

Dmitrii Korobeinikov  writes:

> I have written a proposal for buffer lenses which could prove useful in
> Org-mode, especially for interacting with code.
> If you are interested, please, see this link:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419

-- 
Ihor Radchenko,


signature.asc
Description: PGP signature

Re: [O] Porting Apple Calendars to org-mode

[Ken Mankoff]

On 2019-04-24 at 21:56 +0200, Mohamed Wael Khobalatte 
 wrote...
> The file(s) you linked to usually assume a generated list of ics files
> no?

I didn't link to any files. There are *many* ical2org packages, many different 
ones. The one I currently use does expect an ICS file. If you use iCloud you 
have access to these. If your calendar is 100% local, then try this ical2org 
code: https://github.com/mankoff/ical2org  I used to maintain that fork, and 
used it many years ago with an only-local iCal setup that did not have ICS 
files, just some weird Apple folder structure in ~/Library/.

Sorry I can't help more. The code is old and I'm going offline for the next 5 
weeks. But if you look at these two different ical2org, the ruby 
implementation, the Perl implementation, etc. one of them might do what you 
want.

  -k.

Re: [O] Porting Apple Calendars to org-mode

[Mohamed Wael Khobalatte]

Thanks Ken, I'll check them out. If none works then I might try to code up
something.

On Wed, Apr 24, 2019 at 10:31 PM Ken Mankoff  wrote:

>
> On 2019-04-24 at 21:56 +0200, Mohamed Wael Khobalatte <
> wael.khobala...@gmail.com> wrote...
> > The file(s) you linked to usually assume a generated list of ics files
> > no?
>
> I didn't link to any files. There are *many* ical2org packages, many
> different ones. The one I currently use does expect an ICS file. If you use
> iCloud you have access to these. If your calendar is 100% local, then try
> this ical2org code: https://github.com/mankoff/ical2org  I used to
> maintain that fork, and used it many years ago with an only-local iCal
> setup that did not have ICS files, just some weird Apple folder structure
> in ~/Library/.
>
> Sorry I can't help more. The code is old and I'm going offline for the
> next 5 weeks. But if you look at these two different ical2org, the ruby
> implementation, the Perl implementation, etc. one of them might do what you
> want.
>
>   -k.
>
>

-- 
Wael Khobalatte

[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)

[Noam Postavsky]

Dmitrii Korobeinikov  writes:

> * Implementation
>
>   I am not familiar with Emacs internals to say what's feasible of the
> proposed structure.

Have you looked at Phil Lord's lentic package?  I think it implements a
lot of what you're talking about.

https://github.com/phillord/lentic

Re: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.

[Alan L Tyree]

On 25/4/19 5:05 am, Karl Fogel wrote:

Hi.  This is a feature proposal -- if the consensus is that it would be 
welcomed, I'm happy to code it.  I just didn't want to take the time to write 
it if there's no chance for it to be accepted upstream (since I don't want to 
be maintaining my own personal branch of Org Mode).

It would be useful if `org-narrow-to-subtree' could optionally narrow to the 
next subtree(s) up, rather than only to the subtree point is currently in.  For 
example, assume this text:

* This is the first level
Some text here.
** This is the second level
Some other text here.
*** This is the third level
By now we all know this song.
It is such a pretty song.
 This is the fourth level
But do we have to sing it all day long?
This car trip is getting incong
* This is the fifth level
ruously unrhymed.

Further assume that point is on the "c" of "car trip".

In the current Org Mode, if you type `C-x n s', it will narrow to the 
fourth-level subtree (with the fifth level included in the narrowed buffer, of 
course).

Since `org-narrow-to-subtree' takes no arguments at all right now, it's 
conveniently ripe for improvement :-).

My proposal is for each raw prefix arg (each `C-u' prefix) to expand the 
narrowing level outward/upward by one.  So in the above situation:

   - `C-u C-x n s' would narrow to the third-level subtree

   - `C-u C-u C-x n s' would narrow to the second-level subtree

And so on.

If you offer too many `C-u's, such that the narrowing would be wider than the 
current surrounding first-level subtree, then there are two possible ways we 
could handle it:

1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.

2) Throw an error.

I prefer (1), because it would be the more useful behavior, even though (2) 
would be easier to implement (since `org-back-to-heading' already throws the 
error).  However, I'd welcome others' feedback on that question, or on any 
other aspect of this proposal.

Best regards,
-Karl

Further to my previous message: there is already provision for a 
numerical prefix in org-tree-to-indirect-buffer.  I suppose that it and 
org-narrow-to-subtree should behave the same.


org-narrow-to-subtree is what the old pc outliners called "hoisting". I 
first saw it in Thinktank and it was a blessing when writing book length 
documents.



Cheers,

Alan


--
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.

[Alan L Tyree]

On 25/4/19 5:05 am, Karl Fogel wrote:

Hi.  This is a feature proposal -- if the consensus is that it would be 
welcomed, I'm happy to code it.  I just didn't want to take the time to write 
it if there's no chance for it to be accepted upstream (since I don't want to 
be maintaining my own personal branch of Org Mode).

It would be useful if `org-narrow-to-subtree' could optionally narrow to the 
next subtree(s) up, rather than only to the subtree point is currently in.  For 
example, assume this text:

* This is the first level
Some text here.
** This is the second level
Some other text here.
*** This is the third level
By now we all know this song.
It is such a pretty song.
 This is the fourth level
But do we have to sing it all day long?
This car trip is getting incong
* This is the fifth level
ruously unrhymed.

Further assume that point is on the "c" of "car trip".

In the current Org Mode, if you type `C-x n s', it will narrow to the 
fourth-level subtree (with the fifth level included in the narrowed buffer, of 
course).

Since `org-narrow-to-subtree' takes no arguments at all right now, it's 
conveniently ripe for improvement :-).

My proposal is for each raw prefix arg (each `C-u' prefix) to expand the 
narrowing level outward/upward by one.  So in the above situation:

   - `C-u C-x n s' would narrow to the third-level subtree

   - `C-u C-u C-x n s' would narrow to the second-level subtree

And so on.

If you offer too many `C-u's, such that the narrowing would be wider than the 
current surrounding first-level subtree, then there are two possible ways we 
could handle it:

1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.

2) Throw an error.

I prefer (1), because it would be the more useful behavior, even though (2) 
would be easier to implement (since `org-back-to-heading' already throws the 
error).  However, I'd welcome others' feedback on that question, or on any 
other aspect of this proposal.

Best regards,
-Karl


Hi Karl,

I would definitely use this feature. I'm not in a position to help with 
coding, but would be happy to help test. I presume that it would also 
apply to C-c C-x b: org-tree-to-indirect-buffer.


Regards,

Alan


--
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: [O] Porting Apple Calendars to org-mode

[Mohamed Wael Khobalatte]

See for instance
https://www.reddit.com/r/orgmode/comments/7vidfd/has_anyone_gotten_orgmacical_to_work/,
which describes the same problem (although I *do* see some events, namely
holidays, so I am closer to a solution).

On Wed, Apr 24, 2019 at 3:56 PM Mohamed Wael Khobalatte <
wael.khobala...@gmail.com> wrote:

> Hi Ken,
>
> Thanks for your response. The file(s) you linked to usually assume a
> generated list of ics files no? My problem right now is that I do not want
> to generate those manually from my Mac (could be done of course, but this
> search is for something that does that).
>
> The one that comes close is org-mac-iCal, but again my problem with that
> one is that it does not work for all the calendars, even personal one that
> is not networked. Surprisingly, it works with the holidays calendar (sorry
> I said birthdays before, but it's the holidays one that comes by default).
> I do not know what's special about that one, but my guess is that perhaps
> the formats or locations have changed for the others, although that would
> be..surprising.
>
> On Wed, Apr 24, 2019 at 3:42 PM Ken Mankoff  wrote:
>
>> Hi Mohamed,
>>
>> On 2019-04-24 at 21:32 +0200, Mohamed Wael Khobalatte
>>  wrote...
>> org-mode),
>> > Does anyone know how I can get my Apple calendar to show up in
>> > org-mode as readonly (preferably)? I had no luck with org-mac-iCal.
>>
>> There are several tools named ical2org - different languages,
>> implementations, and/or forks. I used to use one of them when I was on OS X
>> and it worked well for me.
>>
>> I'm not on OS X anymore but use something called "ical2orgpy" that
>> downloads ICS files from Google and Outlook (and could from iCloud I
>> think?) and converts them to read-only Org buffers. The top line is
>>
>> -*- eval: (eval (progn (auto-revert-mode 1) (read-only-mode 1))); -*-
>>
>> So they are read-only and Emacs updates them when the buffer gets changed
>> on disk w/o any questions.
>>
>>   -k.
>>
>>
>
> --
> Wael Khobalatte
>
>

-- 
Wael Khobalatte

Re: [O] Porting Apple Calendars to org-mode

[Mohamed Wael Khobalatte]

Hi Ken,

Thanks for your response. The file(s) you linked to usually assume a
generated list of ics files no? My problem right now is that I do not want
to generate those manually from my Mac (could be done of course, but this
search is for something that does that).

The one that comes close is org-mac-iCal, but again my problem with that
one is that it does not work for all the calendars, even personal one that
is not networked. Surprisingly, it works with the holidays calendar (sorry
I said birthdays before, but it's the holidays one that comes by default).
I do not know what's special about that one, but my guess is that perhaps
the formats or locations have changed for the others, although that would
be..surprising.

On Wed, Apr 24, 2019 at 3:42 PM Ken Mankoff  wrote:

> Hi Mohamed,
>
> On 2019-04-24 at 21:32 +0200, Mohamed Wael Khobalatte
>  wrote...
> org-mode),
> > Does anyone know how I can get my Apple calendar to show up in
> > org-mode as readonly (preferably)? I had no luck with org-mac-iCal.
>
> There are several tools named ical2org - different languages,
> implementations, and/or forks. I used to use one of them when I was on OS X
> and it worked well for me.
>
> I'm not on OS X anymore but use something called "ical2orgpy" that
> downloads ICS files from Google and Outlook (and could from iCloud I
> think?) and converts them to read-only Org buffers. The top line is
>
> -*- eval: (eval (progn (auto-revert-mode 1) (read-only-mode 1))); -*-
>
> So they are read-only and Emacs updates them when the buffer gets changed
> on disk w/o any questions.
>
>   -k.
>
>

-- 
Wael Khobalatte

Re: [O] Porting Apple Calendars to org-mode

[Ken Mankoff]

Hi Mohamed,

On 2019-04-24 at 21:32 +0200, Mohamed Wael Khobalatte
 wrote...
org-mode),
> Does anyone know how I can get my Apple calendar to show up in
> org-mode as readonly (preferably)? I had no luck with org-mac-iCal.

There are several tools named ical2org - different languages, implementations, 
and/or forks. I used to use one of them when I was on OS X and it worked well 
for me.

I'm not on OS X anymore but use something called "ical2orgpy" that downloads 
ICS files from Google and Outlook (and could from iCloud I think?) and converts 
them to read-only Org buffers. The top line is

-*- eval: (eval (progn (auto-revert-mode 1) (read-only-mode 1))); -*-

So they are read-only and Emacs updates them when the buffer gets changed on 
disk w/o any questions.

  -k.

[O] Porting Apple Calendars to org-mode

[Mohamed Wael Khobalatte]

Hi guys, I posted a question to the Emacs StackExchange (
https://emacs.stackexchange.com/questions/50137/show-apple-calendar-events-in-org-mode),
but I believe it's better asked here. Does anyone know how I can get my
Apple calendar to show up in org-mode as readonly (preferably)?

I had no luck with org-mac-iCal. Only one calendar (the Birthdays calendar)
shows up, eventhough all other calendars are *checked*, as the
documentation from that package requires. It is also rather old, so not
sure if it works anymore?

[O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)

[Dmitrii Korobeinikov]

I have written a proposal for buffer lenses which could prove useful in
Org-mode, especially for interacting with code.
If you are interested, please, see this link:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419

Re: [O] [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

Sorry for not answering these two days.

You are right, that's an option.
But I just don't think that's the best possible one - for usability.

Introducing this would imply architectural decisions, so it might not be
immediately clear if it's right or not.
Especially that the improvement might not seem that big.
So, I understand that.

I have proposed buffer lenses today and they seem like something that can
solve the issue from the user side. Hopefully they will get some traction.

пн, 22 апр. 2019 г. в 23:31, Berry, Charles :

>
>
> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov 
> wrote:
> >
> > Thank you!
> > That's a handy technique and it does help.
> > As I understand, there's no way to extend that to multiple lines?
>
> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>
> Of course, you can always follow a src block that provides a function with
> another src block that imports the code via noweb and then tests the
> function with as many lines of code as you need.
>
> Chuck
>
>
>
>

[O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.

[Karl Fogel]

Hi.  This is a feature proposal -- if the consensus is that it would be 
welcomed, I'm happy to code it.  I just didn't want to take the time to write 
it if there's no chance for it to be accepted upstream (since I don't want to 
be maintaining my own personal branch of Org Mode).

It would be useful if `org-narrow-to-subtree' could optionally narrow to the 
next subtree(s) up, rather than only to the subtree point is currently in.  For 
example, assume this text:

   * This is the first level
   Some text here.
   ** This is the second level
   Some other text here.
   *** This is the third level
   By now we all know this song.
   It is such a pretty song.
    This is the fourth level
   But do we have to sing it all day long?
   This car trip is getting incong
   * This is the fifth level
   ruously unrhymed.

Further assume that point is on the "c" of "car trip".  

In the current Org Mode, if you type `C-x n s', it will narrow to the 
fourth-level subtree (with the fifth level included in the narrowed buffer, of 
course).

Since `org-narrow-to-subtree' takes no arguments at all right now, it's 
conveniently ripe for improvement :-).

My proposal is for each raw prefix arg (each `C-u' prefix) to expand the 
narrowing level outward/upward by one.  So in the above situation:

  - `C-u C-x n s' would narrow to the third-level subtree

  - `C-u C-u C-x n s' would narrow to the second-level subtree

And so on.

If you offer too many `C-u's, such that the narrowing would be wider than the 
current surrounding first-level subtree, then there are two possible ways we 
could handle it:

1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.

2) Throw an error.

I prefer (1), because it would be the more useful behavior, even though (2) 
would be easier to implement (since `org-back-to-heading' already throws the 
error).  However, I'd welcome others' feedback on that question, or on any 
other aspect of this proposal.

Best regards,
-Karl

Re: [O] source-block 'uncomment-region' comments out a second time

[Daniel Herzig]

M-; is definitely what I've been searching for!

Thanks for the advice,
Daniel


"Berry, Charles"  writes:

> My bad. See inline.
>
>> On Apr 24, 2019, at 8:45 AM, Daniel Herzig  wrote:
>> 
>> Hi!
>> 
>> "Berry, Charles"  writes:
>> 
 On Apr 22, 2019, at 3:49 AM, Daniel Herzig  
 wrote:
 
 I found a minor problem when editing source code blocks. I am on
 Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian.
>>> 
>>> With more modern versions (9.2.3, for example), the behavior you describe 
>>> does not occur.
>>> 
>
>
> I should have said M-; behaves as you would expect.
>
> But it runs `org-comment-dwim' when in an org-mode buffer.
>
> Outside of org-mode it runs `comment-dwim' which calls on 
> `(un)comment-region'.
>
>
>>> viz., (un)commenting is language aware in the org buffer (as well as in the 
>>> edit buffer).
>>> 
>>> HTH,
>>> 
>>> Chuck
>> 
>> Thanks for your hint. 
>> 
>> I just upgraded to 9.2.3 through org/elpa -- but the situation seems to have
>> gotten even worse in my case.  Not only (un)comment-region in a
>> source-code block of the main .org-file (not inside the edit-buffer) still 
>> do the
>> same thing (commenting *OUT*) -- now the commands even comment out the
>> first part of the next line after the marked region, resulting in
>> tearing this line apart.
>> 
>
> Right. I confirm this.
>
> So the advice is to use `org-comment-dwim' (which silently does `comment-dim' 
> in an edit buffer).
>
> HTH,
>
> Chuck

Re: [O] source-block 'uncomment-region' comments out a second time

[Berry, Charles]

My bad. See inline.

> On Apr 24, 2019, at 8:45 AM, Daniel Herzig  wrote:
> 
> Hi!
> 
> "Berry, Charles"  writes:
> 
>>> On Apr 22, 2019, at 3:49 AM, Daniel Herzig  wrote:
>>> 
>>> I found a minor problem when editing source code blocks. I am on
>>> Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian.
>> 
>> With more modern versions (9.2.3, for example), the behavior you describe 
>> does not occur.
>> 


I should have said M-; behaves as you would expect.

But it runs `org-comment-dwim' when in an org-mode buffer.

Outside of org-mode it runs `comment-dwim' which calls on `(un)comment-region'.


>> viz., (un)commenting is language aware in the org buffer (as well as in the 
>> edit buffer).
>> 
>> HTH,
>> 
>> Chuck
> 
> Thanks for your hint. 
> 
> I just upgraded to 9.2.3 through org/elpa -- but the situation seems to have
> gotten even worse in my case.  Not only (un)comment-region in a
> source-code block of the main .org-file (not inside the edit-buffer) still do 
> the
> same thing (commenting *OUT*) -- now the commands even comment out the
> first part of the next line after the marked region, resulting in
> tearing this line apart.
> 

Right. I confirm this.

So the advice is to use `org-comment-dwim' (which silently does `comment-dim' 
in an edit buffer).

HTH,

Chuck

Re: [O] source-block 'uncomment-region' comments out a second time

[Daniel Herzig]

Hi!

"Berry, Charles"  writes:

>> On Apr 22, 2019, at 3:49 AM, Daniel Herzig  wrote:
>> 
>> I found a minor problem when editing source code blocks. I am on
>> Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian.
>
> With more modern versions (9.2.3, for example), the behavior you describe 
> does not occur.
>
> viz., (un)commenting is language aware in the org buffer (as well as in the 
> edit buffer).
>
> HTH,
>
> Chuck

Thanks for your hint. 

I just upgraded to 9.2.3 through org/elpa -- but the situation seems to have
gotten even worse in my case.  Not only (un)comment-region in a
source-code block of the main .org-file (not inside the edit-buffer) still do 
the
same thing (commenting *OUT*) -- now the commands even comment out the
first part of the next line after the marked region, resulting in
tearing this line apart.

Anyway, I'll stick with the new version, as code-highlighting is way
better than in 8.2.10 (and keep un/commenting a thing for the
edit-buffer solely).

Cheers,
Daniel

Re: [O] table --> org-drill

[Damon Permezel]

Just noticed a bug as I was reading my post.  Just if argument-prefix is 
applied, it will keep trying a line with no tabs (or less than 2) and not 
advance the line.  I’m sure there are more….

> On 2019-Apr-24, at 23:54, Damon Permezel  wrote:
> 
> Hi.
> I am trying to learn Japanese and I am creating word lists as:
> 
> Kanji/Katakana  Katakana  meaning
> 
> 理由りゆう reason
> 地理ちり  geography
> 無理な   むりな impossible
> 特にとくに especially
> 安いやすい cheap
> 
> I just now scraped together the following to turn it into org-drill format.
> I have not written any elisp for probably at least 40 years so, as they say, 
> よろしくお願いします。
> You should be able to munge it for your purposes.
> 
> (defun txt-to-TSV ()
>   "turn a tab-separated text line into TSV"
>   (interactive)
>   (save-mark-and-excursion
> (save-restriction
>   (let ((beg (progn (beginning-of-line) (point)))
>   (end (progn (forward-line)
>   (if (looking-at "\n")
>   (- (point) 1)
> (point
>   (tabs nil)
>   (tsv (vector))
>   (prev nil))
> 
>   (narrow-to-region beg end)
>   (goto-char beg)
>   (setq tabs (vector beg))
>   (setq prev beg)
>   (while (< (point) end)
> (if (looking-at "\t")
> (progn
>   (setq tabs (vconcat tabs (vector (point
>   (setq tsv  (vconcat tsv (vector (buffer-substring prev 
> (point)
>   (setq prev (+ 1 (point)
> (forward-word))
>   (setq tabs (vconcat tabs (vector end)))
>   (setq tsv  (vconcat tsv (vector (buffer-substring prev (point)
>   ))
> ))
> 
> (defun txt-to-drill (arg)
>   "convert TSV to drill"
>   (interactive "p")
> 
>   (while (> arg 0)
> (setq arg (- arg 1))
> (let ((tsv (txt-to-TSV))
> (query (concat
> "*** Query:drill:\n"
> ":PROPERTIES:\n"
> ":END:\n"))
> (answer (concat
>  " Answer\n")))
>   (if (> (length tsv) 2)
> (progn
>   (beginning-of-line)
>   (insert "\n" query (aref tsv 0))
>   (insert "\n" answer (aref tsv 1))
>   (let ((i 2))
> (while (< i (length tsv))
>   (insert "\n" (aref tsv i))
>   (setq i (+ 1 i
>   (insert "\n")
>   (insert "# ")
>   (beginning-of-line)
>   (forward-line)))
>   )))
> 
> 
> 
>> On 2019-Apr-22, at 23:18, Matt Price > > wrote:
>> 
>> Hello everyone,
>> 
>> I'm taking an informal but intensive Nepali language class. There's no 
>> textbook, and vocabulary comes rapidly from the teacher during lcass.  I end 
>> up with notes that look like this:
>> 
>>  yo & tyo-based constructions
>> 
>> *yo*
>> | yatti  | this much  |
>> | katti  | how much   |
>> | yaha   | this place |
>> | kaahaa | where  |
>> | yasto  ||
>> | kasto  | how|
>> | yasari ||
>> | kasari ||
>> 
>> *tyo* and *u*
>> 
>> similar, but over there.  nearly synonymous is "u", which in principle is 
>> reserved for persons, but is used for both. "u" can also be in between yo 
>> and two, between this and that.
>> 
>> - u kosto manche ho? ::  what kind of person is he?
>> - u kosto manche ho? :: u asal manche ho
>> 
>> -
>> So there are two types of notes here --
>> - vocabulary in a 2-column table (sometimes there is a third or fourth 
>> table, with devenagri and a note of some kind, ubt thosse have been rare)
>> - example sentences in definition lists -- sometimes they are nepali --> 
>> english, and osmetimes question --> answer
>> 
>> I would like ot convert both these types of construction to flashcards using 
>> org-drill, but doing so by hand would be prohibitively time-consuming.  Has 
>> anyone already written some code to doe these kinds of ocnversions? My head 
>> is so scrambled fro mthis ocurse that it's hard for me to think in lisp...
>> 
>> THank you!
>> 
>> Matt
>> I would like to convert
> 



signature.asc
Description: Message signed with OpenPGP

Re: [O] table --> org-drill

[Damon Permezel]

Hi.
I am trying to learn Japanese and I am creating word lists as:

Kanji/Katakana  Katakana  meaning

理由  りゆう reason
地理  ちり  geography
無理な むりな impossible
特に  とくに especially
安い  やすい cheap

I just now scraped together the following to turn it into org-drill format.
I have not written any elisp for probably at least 40 years so, as they say, 
よろしくお願いします。
You should be able to munge it for your purposes.

(defun txt-to-TSV ()
  "turn a tab-separated text line into TSV"
  (interactive)
  (save-mark-and-excursion
(save-restriction
  (let ((beg (progn (beginning-of-line) (point)))
(end (progn (forward-line)
(if (looking-at "\n")
(- (point) 1)
  (point
(tabs nil)
(tsv (vector))
(prev nil))

(narrow-to-region beg end)
(goto-char beg)
(setq tabs (vector beg))
(setq prev beg)
(while (< (point) end)
  (if (looking-at "\t")
  (progn
(setq tabs (vconcat tabs (vector (point
(setq tsv  (vconcat tsv (vector (buffer-substring prev 
(point)
(setq prev (+ 1 (point)
  (forward-word))
(setq tabs (vconcat tabs (vector end)))
(setq tsv  (vconcat tsv (vector (buffer-substring prev (point)
))
))

(defun txt-to-drill (arg)
  "convert TSV to drill"
  (interactive "p")

  (while (> arg 0)
(setq arg (- arg 1))
(let ((tsv (txt-to-TSV))
  (query (concat
  "*** Query:drill:\n"
  ":PROPERTIES:\n"
  ":END:\n"))
  (answer (concat
   " Answer\n")))
  (if (> (length tsv) 2)
  (progn
(beginning-of-line)
(insert "\n" query (aref tsv 0))
(insert "\n" answer (aref tsv 1))
(let ((i 2))
  (while (< i (length tsv))
(insert "\n" (aref tsv i))
(setq i (+ 1 i
(insert "\n")
(insert "# ")
(beginning-of-line)
(forward-line)))
  )))



> On 2019-Apr-22, at 23:18, Matt Price  wrote:
> 
> Hello everyone,
> 
> I'm taking an informal but intensive Nepali language class. There's no 
> textbook, and vocabulary comes rapidly from the teacher during lcass.  I end 
> up with notes that look like this:
> 
>  yo & tyo-based constructions
> 
> *yo*
> | yatti  | this much  |
> | katti  | how much   |
> | yaha   | this place |
> | kaahaa | where  |
> | yasto  ||
> | kasto  | how|
> | yasari ||
> | kasari ||
> 
> *tyo* and *u*
> 
> similar, but over there.  nearly synonymous is "u", which in principle is 
> reserved for persons, but is used for both. "u" can also be in between yo and 
> two, between this and that.
> 
> - u kosto manche ho? ::  what kind of person is he?
> - u kosto manche ho? :: u asal manche ho
> 
> -
> So there are two types of notes here --
> - vocabulary in a 2-column table (sometimes there is a third or fourth table, 
> with devenagri and a note of some kind, ubt thosse have been rare)
> - example sentences in definition lists -- sometimes they are nepali --> 
> english, and osmetimes question --> answer
> 
> I would like ot convert both these types of construction to flashcards using 
> org-drill, but doing so by hand would be prohibitively time-consuming.  Has 
> anyone already written some code to doe these kinds of ocnversions? My head 
> is so scrambled fro mthis ocurse that it's hard for me to think in lisp...
> 
> THank you!
> 
> Matt
> I would like to convert



signature.asc
Description: Message signed with OpenPGP

[O] [PATCH] org-manual: Fix typo

[Sebastian Miele]

* doc/org-manual.org (Footnotes): Fix typo.
---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index cf58f75b4..3c16edc4a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21473,7 +21473,7 @@ through ~word-wrap~.
 
 [fn:149] Also see the variable ~org-adapt-indentation~.
 
-[fn:150] Because =LEVEL=2= has 3 stars, =LEVEL=3= has 4 stars, and so
+[fn:150] Because =LEVEL=2= has 3 stars, =LEVEL=3= has 5 stars, and so
 on.
 
 [fn:151] For a server to host files, consider using a WebDAV server,
-- 
2.21.0