Re: "Orgdown", the new name for the syntax of Org-mode

2021-11-28 Thread Joost Kremers


On Sun, Nov 28 2021, Tom Gillespie wrote:
> PS Another brainstormed name: Orgsyn?

Why not just use the term "Org markup"?  It's descriptive and should be
understandable to people familiar with the concept of markup languages.

-- 
Joost Kremers
Life has its moments



Re: [org-cite] CSL processor, APA Style, and no-date citations

2021-11-17 Thread Joost Kremers


On Wed, Nov 17 2021, Bruce D'Arcus wrote:
> I don't believe so, unless there's some good latex -> html solution
> I'm not aware of.

There's (at least) tex4ht and lwarp, but to what extent they support biblatex, I
don't know.

-- 
Joost Kremers
Life has its moments



Re: Evaluate or execute?

2021-10-24 Thread Joost Kremers


On Sun, Oct 24 2021, Thomas S. Dye wrote:
> The org manual and various documents on Worg appear to use the subject terms 
> as
> synonyms for running a bit of source code and gathering its result.  Is there 
> a
> useful distinction that this non-software engineer is missing?  Or, are the
> terms simply synonymous?

To me, the term "evaluate" suggests that the piece of code returns a value that
one is interested in, while "execute" suggest that the code has some side effect
and doesn't return a value (or one that is ignored). Though I doubt this is a
very firm distinction that is strictly adhered to. For practical purposes, you
can probably consider them synonymous.

-- 
Joost Kremers
Life has its moments



[OT] Ebib file field [was: New user experience ct'd: exporting citations into LaTeX (9.5)]

2021-10-13 Thread Joost Kremers


On Wed, Oct 13 2021, Leszek Wroński wrote:
> thank you very much for your responses to my previous query. (I will
> study the ebib package more closely; as of now it does not seem to
> work with the file fields in my Mendeley-created .bib file.

This can probably be remedied with a little Elisp. There's a user option
`ebib-file-name-mod-function`, which is called to convert the contents of the
`file` field into a file name that can be passed to a pdf viewer (and vice
versa).

An example is in this Github issue:

https://github.com/joostkremers/ebib/issues/126

If your Elisp fu isn't too strong, I should be able to help.


-- 
Joost Kremers
Life has its moments



Re: Useful package? Compat.el

2021-10-11 Thread Joost Kremers


On Mon, Oct 11 2021, Timothy wrote:
> I think the way to do this would be as a “soft” dependency, i.e. not needed 
> for
> anyone running a recent version of Emacs, but needed if you want to use Org 
> with
> an old version of Emacs. Not sure how this would best be done, but if this 
> were
> to be useful, this is how I’d imagine it working.

IIUC you can simply specify a dependency on `compat` and the package itself will
make sure only the necessary compatibility functions are loaded given the Emacs
version it's running in. So if you're running Emacs 28, nothing is loaded; if
you're running Emacs 27, `compat-28.1` is loaded to ensure packages written for
Emacs 28 can still be used; if you're running Emacs 26, both `compat-27.1` and
`compat-28.1` are loaded, etc.

-- 
Joost Kremers
Life has its moments



Re: Request to Unsubscribe

2021-10-01 Thread Joost Kremers


On Fri, Oct 01 2021, Jain, Rishabh wrote:
> Hi:
>
> Hope you are doing well. I'd appreciate if you can help unsubscribe me from
> the orgmode mailing list.
>
> Please let me know if you have any questions or concerns.
>
> Kind Regards,
> Rishabh

It's not immediately obvious, but the mailing list page tells you how to 
unsubscribe:

https://lists.gnu.org/mailman/listinfo/emacs-orgmode

Just scroll down to the bottom.

-- 
Joost Kremers
Life has its moments



Re: Org-cite follow function for ebib

2021-08-09 Thread Joost Kremers
Hi Thomas & others,

On Sat, Aug 07 2021, Thomas S. Dye wrote:
> Aloha Joost,
>
> Following some pointers from Eric and Bruce I have this in my
> configuration and it seems to work fine, though I haven't had a chance
> to use it very much.

Thanks for figuring that out. :-) Once I get to implementing support, I'll use
it as a starting point. There should also be a way to open the correct file
automatically, without the user having to select it.



-- 
Joost Kremers
Life has its moments



Re: Org-cite follow function for ebib

2021-08-07 Thread Joost Kremers


On Fri, Aug 06 2021, Thomas S. Dye wrote:
> Yes, I have set the basic follow processor and org-open-at-point takes
> me to the .bib file at the entry for the key at point.

Unfortunately, I haven't had the time yet to update Ebib for the new
functionality. Ebib needs to implement a follow processor so that
`org-open-at-point` takes you to the entry in Ebib.

> Surprisingly (to me), M-x ebib sometimes displays the entry for the key
> at point, too.

That's because when you start Ebib with `M-x ebib` (or a key bound to that
function, of course), it checks to see if point is at something that looks like
a key and tries to find a corresponding entry in the current database. That
functionality is not customisable and not very well implemented, so it doesn't
always work. (Also, if point is at the `cite` prefix, it doesn't work.)

-- 
Joost Kremers
Life has its moments



Re: [wip-cite-new] Merging tomorrow?

2021-07-08 Thread Joost Kremers


On Thu, Jul 08 2021, Bruce D'Arcus wrote:
> On Wed, Jul 7, 2021 at 11:48 PM Timothy  wrote:
>
>> wip-cite-new deals with citing from bibliographies, but I don't think it
>> deals with within-document referencing --- should it?
>
> It doesn't now.
>
> I guess to break down the second question further:
>
> 1. Should it?

One thing to keep in mind here: these are two different sets of functionality
and a tool designed to handle one isn't necessarily right for handling the
other.

Org-cite provides four capabilities: insert, follow, activate and export. And
while they may be very similar conceptually for a user, a provider would need to
handle each of these very differently for citations and in-document references.

And that's the point: while it makes sense for Ebib to provide insert and follow
capabilities for citations, there is really no point in Ebib providing those for
in-document references as well. It doesn't have the infrastructure for it, nor
is Ebib the first (or even second or third) option that comes to mind when you
think about inserting and following in-document references.

I do think it makes sense if such a hypothetical org-new-ref has a very similar
conceptual design to org-cite and a very similar user interface (e.g., the same
keybindings), and perhaps a part of the code can be shared, it should be
possible to register different provides for them.

-- 
Joost Kremers
Life has its moments



Re: [org-cite] citekey restrictions?

2021-05-16 Thread Joost Kremers
 
On Sun, May 16 2021, Nicolas Goaziou wrote:
> However, allowing anything means some keys will not be compatible with
> some bibliography formats. For example, I doubt BibTeX would appreciate
> a percent character in a key.

Careful, trying to find out the details of BibTeX's file format is a quest that
I think no-one has ever returned from. :D I have a comment in =parsebib.el=
saying that BibTeX allows $ ^ and & in entry keys, despite the fact that those
characters are special in TeX...

The regexp =parsebib.el= uses for entry keys is this:

"[^\"@\\#%',={} \t\n\f]+"

Mind you, I have no idea if BibTeX really rejects all these characters (well,
I'm pretty sure about the white space... :D ), but even if they are acceptable,
they probably don't occur much in the wild. At least I'm not aware of any user
complaints since the time I added support for $^&, which was four years ago,

> So... let's get liberal and say a key must match:
>
>   (rx "@" (one-or-more (any word "-.:?!`'/*@+|()<>&_^$#%&~")))
>
> Nothing bad could happen, right?

On a scale of 1 to 10, 1 being getting an error message and having to go online
to find out what it means, and 10 being the total and utter destruction of our
solar system, I doubt it'll exceed 1.

-- 
Joost Kremers
Life has its moments



Re: CSL-JSON support for =parsebib=

2021-05-08 Thread Joost Kremers


On Sat, May 08 2021, András Simonyi wrote:
> this is just to +1 this on my part as well. Although unadvertised,
> citeproc-org basically already supports CSL-JSON bibliographies, and
> it would be fantastic if other components of the Emacs
> citation/bibliography infrastructure also did. BTW, would CSL-JSON
> support in =parsebib= mean that there is hope for having CSL-support
> in Ebib too?

Yes, that is the plan. No promises on an ETA, but it's high on my to-do list.

-- 
Joost Kremers
Life has its moments



Re: CSL-JSON support for =parsebib=

2021-05-07 Thread Joost Kremers


On Fri, May 07 2021, Titus von der Malsburg wrote:
>> Apparently, =json-parse-{buffer|string}= then gives you a symbol with a space
>> in it...
>
> I now see that symbol names “can contain any characters whatever” [1]. But 
> many
> characters need to be escaped (like spaces) which isn’t pretty.

Agreed. But if you pass such a symbol to =symbol-name= or to =(format "%s")=,
the escape character is removed, so when it comes to displaying those symbols to
users, it shouldn't matter much.

Note, though, that the keys in CSL-JSON don't seem to contain any spaces or
other weird characters. There are just lower case a-z and dash, that's all.

>> This works for the Elisp library =json.el=, but Emacs 27 can be compiled with
>> native JSON support, which, however, doesn't provide this option,
>> unfortunately.
>
> I see. In this case it might make sense to propose string keys as a feature 
> for
> json.c. The key is a string anyway at some point during parsing, so avoiding 
> the
> conversion to symbol may actually be the best way to speed things up.

True. I'll ask on emacs-devel. Personally, I'd prefer strings, too, but I'm a
bit hesitant about doing the conversion myself, esp. given that in Ebib, all the
keys would need to be converted back before I can save a file.

>> That would be easy to support, but IMHO is better handled in
>> bibtex-completion:
>> just parse the buffer and then call =gethash= on the resulting hash table. Or
>> what use-case do you have in mind?
>
> One use case: bibtex-completion drops fields that aren’t needed early on to 
> save
> memory and CPU cycles. (Some people work with truly enormous bibliographies,
> like crypto.bib with ~60K entries.) But this means that we sometimes have to
> read an individual entry again if we need more fields that were dropped 
> earlier.
> In this case I’d like to be able to read just one entry without having to
> reparse the complete bibliography.

Makes sense. For .bib sources, this should be fairly easy to do. For .json, I
can't really say how easy it would be. It's not difficult to find the entry key
in the buffer, but from there you'd have to be able to find the start of the
entry in order to parse it. Currently, I don't know how to do that.

>>> - Functions for resolving strings and cross-references.
[...]
>> parsebib has a lower-level API and a higher-level API, and the latter does
>> essentially what you suggest here. I thought bibtex-completion was already
>> using it...
>
> Nope. I think the high-level API didn’t exist when I wrote my code in 2014.

No, it didn't. I seem to remember, though, that you gave me the idea for the
higher-level API, which is probably why I assumed you were using it.

So that part of =parsebib= hasn't been tested much... (Ebib doesn't use it,
either). If you do decide to start using it, please test it and report any
issues you find. And let me know if I can help with testing.


-- 
Joost Kremers
Life has its moments



Re: CSL-JSON support for =parsebib=

2021-05-07 Thread Joost Kremers
Hi Titus,

On Fri, May 07 2021, Titus von der Malsburg wrote:
> I’m the maintainer of bibtex-completion, helm-bibtex, and ivy-bibtex. My name 
> is
> actually Titus, not Theo ;)

:$ (I do apologise!)

> Regarding the symbols vs. string issue: I don’t have a strong opinion, but
> personally tend to favor a conservative solution that avoids braking changes.
> First, it’s difficult to predict how switching to symbols is going to affect
> other software including custom code written by users. Second, JSON key names
> can contain spaces and other weird stuff.

Apparently, =json-parse-{buffer|string}= then gives you a symbol with a space 
in it...

> So strings are perhaps a more natural
> choice anyway. (It appears that you can actually configure the JSON parser to
> use strings instead of symbols. See variable `json-key-type`.)

This works for the Elisp library =json.el=, but Emacs 27 can be compiled with
native JSON support, which, however, doesn't provide this option, unfortunately.

> Finally,
> it’s not necessarily clear that avoiding the conversion to strings saves
> sufficiently many CPU cycles to justify the effort.

I can simply try it out. Shouldn't be difficult to code up.

> Regarding support for CSL-JSON: bibtex-completion is currently very
> BibTeX-oriented and uses fairly low-level parsing functions from parsebib. We
> could add similar support for CSL-JSON

I'm afraid that won't be possible, because the CLS-JSON support in parsebib
isn't low-level. ;-) There's basically just a single function that gives you all
the entries in the buffer and that's it.

> Some rough ideas for such an API (just for illustration):
> - A function that returns all entries in a .bib or CSL-JSON file.

Those already exist... ;-) For JSON, that's basically the only option, because
the actual parsing isn't handled by parsebib. For BibTeX, such a function has
existed for some time now.

> - A function that returns an entry with a specific key (or multiple entries).

That would be easy to support, but IMHO is better handled in bibtex-completion:
just parse the buffer and then call =gethash= on the resulting hash table. Or
what use-case do you have in mind?

> - Functions for resolving strings and cross-references.

This, too, is something that parsebib already does.

parsebib has a lower-level API and a higher-level API, and the latter does
essentially what you suggest here. I thought bibtex-completion was already 
using it...


-- 
Joost Kremers
Life has its moments



CSL-JSON support for =parsebib=

2021-05-07 Thread Joost Kremers
Hi,

[Cc-ing Theo von der Malsburg]

Now that Org is getting support for Citeproc, it could be useful to add support
for the CSL-JSON format for bibliographic data to Emacs. Therefore, after a
friendly request from Denis Maier, I have added support for this format to the
=parsebib= library.

Since =parsebib= is used by =bibtex-completions=, which in turn is used by
=bibtex-actions=, =helm-bibtex=, =ivy-bibtex=, =org-ref= and =org-roam-bibtex=,
this is a first step in making bibliographic data in =.json= format directly
available to Org users, without the need of any BibTeX conversion.

[Boy, look at me doing the marketing speak! :D ]

Anyway, this really is the first step. =bibtex-completion= will need to be
modified in order to make use of the new functionality, and the same may be true
of the packages based on it.

At this point, the new code isn't merged into =master= yet. It is available in
the =wip/csl= branch of =parsebib='s Github repo:

https://github.com/joostkremers/parsebib/tree/wip/csl

The README has most of the details. I appreciate any and all comments,
suggestions and tips.

For those maintaining packages based on =parsebib=, I have at least one
question: currently, =parsebib= returns a BibTeX entry in the form of an alist
of =( . )= pairs, where both == and == are strings.
A CSL-JSON entry is returned as an alist, but the == names are symbols,
not strings.

It would be extremely impractical to return the JSON data with strings as field
names, because the JSON parsing libraries in Emacs return symbols, so converting
them would take time. Plus, those libraries also expect symbols when serialising
Elisp data to JSON. (Which I intend to make use of in Ebib later on.)

It would be easier to modify the BibTeX output to return field names as symbols.
I originally chose strings, because that's what =bibtex.el= uses, making it a
little easier to integrate with it.

So the question: would it be helpful to make this change to the BibTeX data, so
that the data from both sources uses the same format? Or would it be better to
keep it as it is, even if that means that BibTeX data and JSON data isn't
compatible?

TIA

Joost


-- 
Joost Kremers
Life has its moments



Re: Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Denis Maier wrote:
> Well, IIRC, in author-year styles \autocite is equivalent to \parencite. I
> think, what the manual talks about is not that \autocite wouldn't be 
> appropriate
> for author-year styles, but rather that relying /solely/ on \autocite doesn't
> give authors the flexibility they might want in these styles, 

Yes, I did a quick test and you're right.

> So, I think \autocite is the better choice.

Yes.

-- 
Joost Kremers
Life has its moments



Re: Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers
Hi Nicolas,

On Tue, May 04 2021, Nicolas Goaziou wrote:
> If you think my assumption is incorrect, please let me know what kind of
> hook would be required.

No, I don't think there's anything Org should provide. I just wanted to be sure
I hadn't missed anything.

>> - =:active= just means "font-lock", right?
>
> Yes, with the emphasis that more than faces could be provided (e.g.,
> help-echo, specific keymap, …).

Ah, that's good to know. I hadn't realised that.

>> - What kind of data structure do the =:follow= and =:activate= functions 
>> take?
>>   Should I just look at =oc-basic.el= or is this written down
>>   somewhere?
>
> Processors must be registered using `org-cite-register-processor'
> function from "oc.el". See its docstring for details. All arguments are
> detailed.

The docstring talks about a "citation object", and the "citation or citation
reference object at point". Do I assume correctly that these are structures as
returned by =org-element-parse-buffer=?

> At some point, we will need to write some documentation in the manual,
> too...

For the moment, I can follow the lead in =oc-basic.el= and do what it does.

> "oc.el" provides a number of hopefully useful tools. Among them,
> `org-cite-list-bibliography-files' function returns what you're asking
> for. Global variable and keywords are cumulative.

Great, thanks!

> HTH!

Yes, this was certainly very helpful. Thank you for your answer and thank you
for all the hard work you've put in.

The same goes for everyone else who put time and effort into making org-cite
happen, of course. :-)

-- 
Joost Kremers
Life has its moments



Re: Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Bruce D'Arcus wrote:
> On Tue, May 4, 2021 at 10:47 AM Joost Kremers  
> wrote:
>
>> I can add some comments regarding biblatex:
>>
>> - default: \parencite[1]
>
> WDYT of \autocite for default?
>
> It's conceptually the same as the CSL default.

If that is the case then it's probably the better choice. The biblatex manual
states that \autocite requires that the citation style defines a command for it
and that it is not appropriate for author-year style citations. I assume that's
something for the user to be aware of when using such citations?

-- 
Joost Kremers
Life has its moments



Re: Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Bruce D'Arcus wrote:
> One other little thing:
>
> On Tue, May 4, 2021 at 10:47 AM Joost Kremers  
> wrote:
>
>> - locators: \notecite[3]
>
> Are you sure about this?

Well, no, I hadn't tried it... I did mention there were variants, though. ;-)

> Here's the use case:
>
> https://github.com/jgm/pandoc/issues/7205

In order to get:

```
According to Jones (1998) , “students often had difficulty using APA
style, especially when it was their first time” (p. 199).
```

i.e., with parentheses around the locator, you need to use \pnotecite:

```
According to \textcite[]{Jones1998} , ``students often had difficulty using APA
style, especially when it was their first time'' \pnotecite[][199]{Jones1998}.
```

\notecite gives the locator without parentheses.

-- 
Joost Kremers
Life has its moments



Re: Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Bruce D'Arcus wrote:
> On Tue, May 4, 2021 at 9:27 AM Joost Kremers  wrote:
>
>> - A user should be able to insert citations into an Org document. IIUC 
>> nothing
>>   in org-cite provides any functionality for this, right? Is there a default
>>   list of styles a user would expect to be supported, or does this depend
>> solely
>>   on the bibliography style one uses?
>
> I'll just comment on this Joost.

Thanks. :-)

> Correct on your first question.

ACK

> As for your second, that's what the activity today is about. TBD, but
> it seems there's some good ideas on that.
>
> I tried to put this together into this wiki page, because doing it on
> an email list is hard.
>
> https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

I can add some comments regarding biblatex:

- default: \parencite[1]
- text: \textcite
- author: \citeauthor[2] 
- title: \citetitle[2]
- year: \citeyear[2]
- locators: \notecite[3]
- nocite: \nocite

Biblatex of course has a wealth of citation commands, most with variants of
different kinds. Not sure if that's relevant right now.

HTH

Joost



Footnotes:
[1] Note that biblatex also has \cite, which produces a citation without
 parentheses. But the natbib column has \citep here, so \parencite seems
 appropriate.

[2]  The biblatex manual states that this does not do "citation tracking",
 though what this implies is not clear to me.

[3]  There are variants \pnotecite and \fnotecite for parenthetical and
 footnote citations, respectively.

-- 
Joost Kremers
Life has its moments



Question about citation processors [wip-cite branch]

2021-05-04 Thread Joost Kremers
Hi list,

As the maintainer of Ebib, I have of course been following the threads on
citation support for Org with some interest. I have not been able to follow
every detail, however, in part probably due to my limited experience with CSL
and citeproc. (I use biblatex myself.)

Now I find myself with some specific questions that I cannot find an answer to.
(Possibly because I'm just daft enough to overlook them in the e-mails Nicolas
sent, but in that case feel free to point this out.)

So, on the assumption that there are Org users out there that may want to use
Ebib to manage their citations, what would Ebib need to do in order to be a good
citizen?

- A user should be able to insert citations into an Org document. IIUC nothing
  in org-cite provides any functionality for this, right? Is there a default
  list of styles a user would expect to be supported, or does this depend solely
  on the bibliography style one uses?

- =:active= just means "font-lock", right?

- Since I don't plan on writing an exporter, I assume that it is possible to
  mix and match processors? Say, have one for the =:follow= property, another
  for =:activate= and a third one for =:export-*=?

- What kind of data structure do the =:follow= and =:activate= functions take?
  Should I just look at =oc-basic.el= or is this written down somewhere?

- Is there a function or buffer-local variable that gives me a list of all the
  bibliography files of a buffer? Related to that: if a user has set
  =org-cite-global-bibliography= and also provides a =#+bibliography= keyword,
  are both sources used, or only the keyword?

Thanks for any and all comments!

-- 
Joost Kremers
Life has its moments



Re: Notes about citations in Org (part 3)

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Eric S Fraga wrote:
> Question for the longer term: for LaTeX export, I will be wanting to
> have the [cite:] constructs export to BiBTeX code.  Will this be
> possible in due course?  For other targets (ODT, HTML), what has been
> done in this branch is fantastic but, for LaTeX, publishers will expect
> BiBTeX.

Pedantic nit-pick: they *should* be expecting and using biblatex. (But perhaps
that is what you meant already. :-) )

-- 
Joost Kremers
Life has its moments



Input methods [was: Re: About multilingual documents]

2021-05-04 Thread Joost Kremers


On Tue, May 04 2021, Eric S Fraga wrote:
> So, on this note, without hopefully hijacking the thread, maybe somebody
> can tell me: what is the "default" input method, i.e. the one I get when
> I start Emacs and haven't changed input methods at all?  I see no way to
> get back to it once I have switched to a different one.

It's not really an input method, more like the lack of one. You're probably
using =set-input-method= to change input methods? Check out
=toggle-input-method=. :-)

-- 
Joost Kremers
Life has its moments



Re: About multilingual documents

2021-05-03 Thread Joost Kremers


[Not directly related to the OP, but might be useful to know.]

On Mon, May 03 2021, Aleksandar Dimitrov wrote:
> this sounds very interesting to me, as I, too, mostly write in Org
> and, sometimes write documents in multiple languages, usually with
> different varieties of either Latin or Cyrillic.
[...]
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.

flyspell is basically just ispell, and ispell can be configured with different
backends. One possible backend is hunspell, which allows you to set multiple
dictionaries. So if you regularly use different languages in a buffer, you
should give hunspell a try.

[...]
> The drawback, and the clear disadvantage compared to your method is that
> this works great only when the languages are separated by paragraph
> breaks.

If that is the case, you could also check out the =guess-language= package:
<https://github.com/tmalsburg/guess-language.el>. It tries to detect the
language of the current paragraph and sets the ispell (and hence flyspell)
dictionary accordingly. I use it because I write in three different languages,
but usually don't mix them in one buffer.



-- 
Joost Kremers
Life has its moments



Re: (Not so) Short note about citations in Org

2021-04-26 Thread Joost Kremers


On Mon, Apr 26 2021, Denis Maier wrote:
> No, I was not talking about having multiple input files, but about having
> multiple bibliographies in the output doc.
> Perhaps each filtered in some way:
>
> #+print_bibliography: [style] [filter1]
> #+print_bibliography: [style] [filter2]
>
> Obviously, filter1 and filter2 must be defined somewhere. The use case would 
> be
> something along these lines:
> - One bibliography with all the works by author X, a second bibliography with
>  everything else.
> - One bibliography with books, the other with webpages

Another use case would be a book in which each chapter has its own bibliography.

A quick synopsis of the biblatex way:

https://texblog.org/2012/10/22/multiple-bibliographies-with-biblatex/


-- 
Joost Kremers
Life has its moments



Re: org-cite: make 'suppress-author' a citation 'style'

2021-04-26 Thread Joost Kremers


On Mon, Apr 26 2021, Denis Maier wrote:
> [...] Interestingly, I 
> couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
> ... argues". You'd probably have to resort to lower level commands such 
> as \citeauthor in combination with other commands.
> \citeauthor{doe} \parencites*[34]{doe}{smith}

Actually, that won't print the author name of =smith=. AFAIK If you want to
suppress the author in the first citation but not in the second, you need to be
even more low-level:

\citeauthor{Chomsky1995} (\cite*[34]{Chomsky1995}, \cite{Kayne1994})

At least that's the only way I've been able to find.

IOW it seems that in biblatex, suppress-author (obtained by the asterisk
following the command) is a property of the citation command, even if it
includes multiple citations. OTOH there are real cases (I have written
references such as the example here myself) where you want it to be a property
of the individual citation.

The thing about biblatex is that it offers low-level commands that allow you to
create unusual citations (my default LaTeX header contains three definitions of
citation commands that biblatex doesn't provide but which I use quite a lot). So
I would argue that it's better to keep the syntax =-@key=, just to keep the
system flexible in case the need arises.

-- 
Joost Kremers
Life has its moments



Re: Using backticks for the inline code delimeter?

2021-04-04 Thread Joost Kremers


On Sun, Apr 04 2021, Nicolas Goaziou wrote:
> Joost Kremers  writes:
>
>> On Sat, Apr 03 2021, Tom Gillespie wrote:
>>> Is there any reason why folks couldn't just customize
>>> org-emphasis-alist using a file local variable? 
>
> [...]
>
>> If all exporters worked off an internal representation such as what is
>> returned by `org-element-parse-buffer`, it should be easier to modify the
>> front-end syntax.
>
> I think they do.

So if I were so inclined, I could write a parser for Markdown that produces this
internal format and get all the export targets that Org has? (Not that I'm so
inclined... Just wondering. ;-) )

> Anyway, one of the goals of Org is to provide a universal document
> format. It is not there yet, but allowing local modifications of the
> syntax certainly goes against that goal.

I tend to agree that allowing local modifications of Org's syntax is pretty much
pointless, but then why is `org-emphasis-alist` a user option? I originally
thought its purpose was to customise Org's syntax, until I found that the
exporters didn't play ball. ;-)


-- 
Joost Kremers
Life has its moments



Re: Using backticks for the inline code delimeter?

2021-04-04 Thread Joost Kremers


On Sat, Apr 03 2021, Tom Gillespie wrote:
> Is there any reason why folks couldn't just customize
> org-emphasis-alist using a file local variable? Just add ("`" org-code
> verbatim) and see what happens. Knowing a bit about the codebase this
> will probably lead to trouble during export because the backends are
> likely unaware,

Yes, I tried this at one time because /.../ is used in linguistics to denote
phonological representations. So I removed the entry for `/` in
`org-emphasis-alist` and replaced it with something else. It worked up until the
point where you start exporting.

If all exporters worked off an internal representation such as what is
returned by `org-element-parse-buffer`, it should be easier to modify the
front-end syntax.



-- 
Joost Kremers
Life has its moments



Re: Using backticks for the inline code delimeter?

2021-04-01 Thread Joost Kremers


On Fri, Apr 02 2021, Tim Cross wrote:
> Getting backticks to font-lock correctly is relatively easy. Getting the
> exporters to understand the new syntax is more of a challenge

Don't the exporters work off of some intermediate representation, like Pandoc
does? I kinda thought that was what `org-element.el` was all about... 

And of course I meant to type ~org-element.el~ there... :D

-- 
Joost Kremers
Life has its moments



Re: About exporting

2021-03-30 Thread Joost Kremers


On Tue, Mar 30 2021, Eric S Fraga wrote:
> On Tuesday, 30 Mar 2021 at 10:13, Detlef Steuer wrote:
>> Btw. I had do deliver rtf recently. Is there any documented way to generate
>> rtf from org? 
>
> Two routes that I know of:
> 1. org -> LaTeX -> rtf using latex2rtf
> 2. org -> odt -> rtf by saving as that format in LibreOffice.
> Pandoc may have similar, of course.

Yes, Pandoc can write rtf files. Since it can also read Org files, you may be
able to use it to go from Org to rtf directly.

-- 
Joost Kremers
Life has its moments



Re: How to jump from one spelling mistake to the next?

2021-03-20 Thread Joost Kremers


On Sat, Mar 20 2021, Dr. Arne Babenhauserheide wrote:
> Kyle Meyer  writes:
>
>> Sharon Kimble writes:
>>
>>> When I'm writing in org-mode I very often make spelling mistakes which I
>>> can go back to later to correct. So how can I jump from one mistake to
>>> the next please?
>>
>> If you have Flyspell mode enabled in the buffer,
>> flyspell-goto-next-error (bound to `C-,' by default) will jump to the
>> next marked word, cycling around once you've reached the last marked
>> word in the buffer.

Also, if you have flyspell-mode enabled, `C-;` is bound to
`flyspell-auto-correct-previous-word`. It'll correct the last misspelled word
preceding point (though there may be correctly spelled words between point and
the misspelled word). Type `C-;` multiple times to cycle through different
correction suggestions. Because you don't need to move back to the misspelled
word to correct it, you can correct words while you type without interrupting
the flow too much.

YMMV, of course.

-- 
Joost Kremers
Life has its moments



Re: org-capture: question about function to create template

2021-03-16 Thread Joost Kremers
Hi Ihor & No Wayman,

Thanks for your replies.

On Tue, Mar 16 2021, Ihor Radchenko wrote:
> Joost Kremers  writes:
>
>> ... I was wondering if there's any
>> way for this function to access the state of the ongoing capture process.
>> Specifically, it would be useful for me if the function can find out the key 
>> of
>> the template that the user selected.
>
> See org-capture-plist.

Yes, I thought that might be it, but I wasn't sure.

On Mon, Mar 15 2021, No Wayman wrote:
>> From: Joost Kremers 
>> Specifically, it would be useful for me if the function can find out the key
>> of the template that the user selected.
>
> This is stored on the above plist as :key.
>
> There are some corner cases to consider if you have overlapping 
> capture processes.
> You'll want to look into `org-capture-get' and 
> `org-capture-current-plist' as well.

Thanks for the pointers. I'll dive in a little and see what's best for my use
case.



-- 
Joost Kremers
Life has its moments



org-capture: question about function to create template

2021-03-15 Thread Joost Kremers
Hi list,

I've been looking at the =org-capture= mechanism a bit more closely recently and
noticed that in =org-capture-templates=, the template can also be a function.
This looks like a potentially useful feature, but I was wondering if there's any
way for this function to access the state of the ongoing capture process.
Specifically, it would be useful for me if the function can find out the key of
the template that the user selected.

Of course I could have a different function for each template that I want to
create dynamically, or use a lambda that calls my function with an appropriate
argument, but that wouldn't be as useful to me.

TIA

Joost


-- 
Joost Kremers
Life has its moments



Font lock in inner blocks [was: Re: Differentiate source blocks in export?]

2020-11-25 Thread Joost Kremers


On Wed, Nov 25 2020, Eric S Fraga wrote:
> On Wednesday, 25 Nov 2020 at 09:37, Joost Kremers wrote:
>> I like this solution for the "Org-ness" of the syntax, and yes, =C-c
>> '= works, but font lock is gone...
>
> Yes, font lock is gone unfortunately but I am not sure why that
> is.  Something for somebody who understands the syntax highlighting code
> to investigate?

I guess font lock is based on the outer block, which in this case doesn't
correspond to any major mode, so there is no font lock. Or at least no
major-mode-based font lock. Org markup such as for =code= *is* font locked.

One could argue that this isn't entirely consistent with the fact that
=org-edit-special= *does* recognise the inner code block. It certainly would be
nice if font lock did, as well.

-- 
Joost Kremers
Life has its moments



Re: ob-python: import local package into a session

2020-11-25 Thread Joost Kremers


On Tue, Nov 24 2020, Jack Kamm wrote:
> If you install the package using either "python setup.py develop", or
> "pip install -e", then Python will install your code via symlinks
> instead of copying, so then you don't have to worry about reinstalling
> every time you make an edit.

Hey, that's good to know, thanks.

> To switch between venv's in emacs, I use pyvenv:
> https://github.com/jorgenschaefer/pyvenv

Yes, that's what I use, as well.

-- 
Joost Kremers
Life has its moments



Re: Differentiate source blocks in export?

2020-11-25 Thread Joost Kremers


On Wed, Nov 25 2020, Eric S Fraga wrote:
> On Tuesday, 24 Nov 2020 at 23:02, Joost Kremers wrote:
>> That, unfortunately, seems to make it impossible to edit the source block as
>> Octave (or in my case Python) code. Pressing =C-c '= in this source block 
>> gives
>> me an Org buffer.
>
> Take away the begin...end org block itself which I only put to protect
> the org code for the email.  You should then be able to edit the src
> block with no problem.

Oh, sorry, I didn't realise that... 

>   #+begin_myclass
>   #+begin_src octave
>   y = 3 * x + 5
>   #+end_src
>   #+end_myclass
>
> If I have point within the octave src block, C-c ' works fine for me.

I like this solution for the "Org-ness" of the syntax, and yes, =C-c '= works,
but font lock is gone...

-- 
Joost Kremers
Life has its moments



Re: Differentiate source blocks in export?

2020-11-24 Thread Joost Kremers


On Tue, Nov 24 2020, Eric S Fraga wrote:
> On Tuesday, 24 Nov 2020 at 17:22, Diego Zamboni wrote:
>> And even (a bit) shorter:
>>
>> #+html:
>
> Or, if you want a more org-like feel to your special constructs, and
> something that would in principle work to other export engines:
>
> #+begin_src org
>   ,#+begin_myclass
>   ,#+begin_src octave
>   y = 3 * x + 5
>   ,#+end_src
>   ,#+end_myclass
> #+end_src
>
> using special blocks which translate to divs on HTML export.

That, unfortunately, seems to make it impossible to edit the source block as
Octave (or in my case Python) code. Pressing =C-c '= in this source block gives
me an Org buffer.

-- 
Joost Kremers
Life has its moments



Re: Differentiate source blocks in export?

2020-11-24 Thread Joost Kremers


On Tue, Nov 24 2020, Diego Zamboni wrote:
> And even (a bit) shorter:
>
> #+html:
> #+BEGIN_SRC python
> print(5)
> #+END_SRC
> #+html:

Thanks everyone for your suggestions. I tried this one and it works great.
=myclass= of course ends up containing the =src= class, but as I just found out,
that's not a problem.

-- 
Joost Kremers
Life has its moments



Re: ob-python: import local package into a session

2020-11-24 Thread Joost Kremers


On Tue, Nov 24 2020, Maxim Nikulin wrote:
> 2. It seems that *recommended* and more flexible way is per-project 
> (per-version) virtual environments: venv in python3, similar thing were 
> called virtualenv in python2: 
> https://docs.python.org/3/tutorial/venv.html Maybe there is a convenient 
> way to choose and switch venv's directly from emacs. In simple cases 
> venv could be activated before starting emacs.

Yes, I'm using virtual environments. Took me a while to get that figured out,
though. Python-the-language is nice enough, but Python-the-ecosystem is quite a
different thing... (Who said there should only be one way to do something?)

I haven't really considered the option to install the utility functions as a
package in the virtual environment, because I expect to change and develop those
functions together with the rest of the project. If it were a separate package,
I'd need to reinstall it every time I make changes to it, which will probably
happen often.

-- 
Joost Kremers
Life has its moments



Differentiate source blocks in export?

2020-11-24 Thread Joost Kremers
Hi all,

I was wondering if there's a way to distinguish between different kind of source
code blocks when exporting to HTML.

Specifically, I would like a way to mark certain code blocks in my Org file so
that those code blocks get a specific class in the HTML export. I can then style
them with some CSS to make them stand out visually. I know I can use special
blocks to get divs with a custom class, but I don't want to lose all the
benefits of code blocks...

I tried Google and the Org manual but I haven't been able to find anything on
this.

TIA

-- 
Joost Kremers
Life has its moments



Re: ob-python: import local package into a session

2020-11-23 Thread Joost Kremers
Hi Jack,

On Mon, Nov 23 2020, Jack Kamm wrote:
> This shouldn't be ob-python or even Emacs specific. You can test whether
> things work by typing "python" in the terminal and attempting to import
> your module.

It all seems to depend on the exact directories, though, and other than
modifying =sys.path= there doesn't seem to be a way to make Org, Python and me
happy at the same time. :-)

I wanted to create a few small, related projects that would share the utility
functions, so I thought I'd put them all in separate subpackages of a single
package. That works with `M-x run-python` and with an LSP server, but when I
then put an Org file in its own subdirectory inside the package, I couldn't
import the utils subpackage.

I guess putting a =:dir= header arg might resolve that, but the Org manual says
that =:dir= should not be used with =:exports both=, which I was also using.

Anyway, thanks to you and to John. I think I have a better idea now how it all
works and what my options are.

> By the way, are you using IPython or vanilla Python? I recently
> encountered an issue trying to import modules through a symlink in
> IPython, whereas it worked perfectly fine in a vanilla Python session.

I'm using IPython in `M-x run-python`, but vanilla Python for Org. There are no
symlinks involved, so I guess it shouldn't matter.

-- 
Joost Kremers
Life has its moments



ob-python: import local package into a session

2020-11-23 Thread Joost Kremers
Hi all,

If I have an Org file with Python source blocks, I can run them in a session
with the `:session` header arg. That way, I can include packages installed in
`site-packages` and have them available in all code blocks. But is there a way
to import my own packages into a session? In particular, packages I haven't
installed system-wide?

What I'm trying to do is to import a Python file with a bunch of utility
functions into the ob-python session. I thought this might be possible if I'd
structure my code as a regular Python package, because that works if I want to
import my utility functions into another Python file. But it doesn't seem to
work for the ob-python session.

Is there a way to achieve this? I don't *have* to structure my utility functions
as a Python package, so if there's another way of doing this, I'd be interested
as well.

TIA

Joost


-- 
Joost Kremers
Life has its moments



Re: Use-case: simple nodes and todo-list

2020-10-09 Thread Joost Kremers

Hi,
On Fri, Oct 09 2020, c.bu...@posteo.jp wrote:

1. Simple notes with keywords and endless time to life
I have notes (most of them as post-its on the wall and monitor 
in my 
office) with information's I am not able or willing to remember. 
But I 
need this information's every few days. e.g. numbers for 
bank-account, 
projects, persons
I find this information's by place (post-it glued to a specific 
place in 
my office). When they are digitized I would use keywords or 
in-text 
search. e.g. searching for the project name "my project" to find 
its 
number.


Yes, Org can definitely do this, though in this particular case, 
I'm not sure Org really has any advantage over using just plain 
text files or say markdown files. (The advantage of Org would be 
in the integration that would be possible with other parts of your 
setup.)


I personally have something similar: a bunch of files in which I 
keep notes of things I may need in the future. I keep them in Org 
format and I search them with Deft: 
<https://jblevins.org/projects/deft/>. (Though I do not follow the 
advice on that page of using Melpa Stable. I just use the Melpa 
version.) Of course, searching them can also be done with grep (or 
one of its alternatives, ripgrep, ag, etc.) and an Emacs frontend 
(ivy, helm, what have you).



2.ToDo List without time information's


Yes, you can create todo-lists without time information. You can 
attach a deadline to a task, but you don't have to. You can also 
create multiple TODO-states (e.g., TODO, INPROGRESS, SUSPENDED, 
DONE, etc.) and set different priorities.


--
Joost Kremers
Life has its moments



Re: Anyone doing any fancy customizations of source blocks?

2020-06-19 Thread Joost Kremers



On Fri, Jun 19 2020, Norman Tovey-Walsh wrote:
What’s the trick to get the background color to extend across 
the entire line?


In Emacs 27, add an `:extend t` property to the face. In Emacs 26 
and earlier, IIRC, you need to make sure that the newline at the 
end of the line is also fontified. (That may actually be necessary 
in Emacs 27 as well, in addition to the `:extend` property...)


--
Joost Kremers
Life has its moments



Re: Replace Org's C-TAB with C-M-TAB - objection?

2020-05-24 Thread Joost Kremers



On Sun, May 24 2020, stardiviner wrote:

Bastien  writes:
C-TAB in Org is bound to `org-force-cycle-archived' to allow to 
cycle

through archived subtrees.

In the Emacs tab-bar mode, it is now bound to `tab-next', which 
needs

to work globally.

So Org's binding and tab-bar's one are in conflict, as reported 
here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325

I suggest binding `org-force-cycle-archived' to C-M-TAB: any 
objection?


Thanks,


I object this change. Emacs tab-bar is not enabled by default. 
When conflict,
user can customize keybinding. I don't think it's very necessary 
to change.


I would support the change, since both Org mode and tab-bar-mode 
are part of core Emacs and I doubt it'll be clear to new users 
coming to Emacs why these conflicting key bindings exist. Instead, 
they'll be annoyed that they cannot C-TAB out of the Org buffer 
and their impression of Emacs (not just Org mode or tab-bar-mode) 
will suffer. Ever more so because it's probably not immediately 
obvious to new users how C-TAB is different from just TAB: they 
both open the subtree at point.


I've been using C-TAB for a long time to switch buffers (albeit 
not with tab-bar-mode), and it's always annoying when some mode 
usurps (from my perspective) this keybinding. Now, I'm familiar 
with Emacs and the relative independence and freedom that 
individual packages have, plus C-TAB is a personal keybinding, so 
I know this sort of thing may happen and I know how to resolve it. 
For a new user, that won't be so obvious. For them, this will 
simply look like a badly designed UI.


So I think the general argument for habit-breaking UI changes 
applies: it creates a more consistent UI, which means it's easier 
on new users and more in line with what they expect. For existing 
users that want the old behaviour back, it's a simple 
configuration in their init.el.


--
Joost Kremers
Life has its moments



Re: wip-cite status question and feedback

2020-04-18 Thread Joost Kremers



On Sat, Apr 18 2020, Bruce D'Arcus wrote:
The question, then: Is that what you're saying; we don't need 
suppress-author?


I think I actually agree, though will add a topic that came up 
in the
CSL implementation discussion for the author-in-text styles in 
the

past few days.

Here's a common way a citation might be integrated in a 
narrative text:


Doe, by contrast, found negative results (2017).


There are other constructions in with suppress-author is useful. 
For example, possessives:


Doe's (2017) results... 

or 


Doe's (2017) ground braking paper...

Such use is not uncommon in my field.

Also, consider languages that require a case ending on the author 
name. And who knows what quirks other languages may have?


So we have the author name in-text, than some text, then the 
year-only citation.


The traditional way to do that in pandoc is to use the 
suppress-author

command at the end.

Doe, by contrast, found negative results [-@doe17].

So the piece of information I refer to above is that one of the 
CSL

implementers (Frank Bennett) figured out  how to make the above
example an author-in-text variant, so that you don't need
suppress-author, and the entire sentence is the citation.

He did this by adding an optional "infix" variable to the 
citation.


I doubt that would work in every case. Consider e.g.,
;
In her original (2017) study, Doe argues that... 


[...]
This is arguably an edge case, but it does relate to the 
question of
whether we need two (standard and author-in-text) or three 
commands

(adding the suppress-author).


I would definitely say that a way to suppress the author is 
necessary. In fact, I would argue that there should also be a way 
to cite just the author name, if only to make sure it's not 
misspelled or written inconsistently. (I'm a regular user of 
\citeauthor in BibLaTeX... ;-) But I admit that's less of a 
necessity.



--
Joost Kremers
Life has its moments



Fwd: Re: how to renumber footnotes?

2020-04-18 Thread Joost Kremers

Accidentally sent this message off-list. Trying again:

On Fri, Apr 17 2020, Sharon Kimble wrote:
org-footnote can't tell that footnote 1 ([fn:1]) at the 
beginning is in
the right place when confronted with footnote 1 ([fn:1]) 
half-way

through!


No, obviously, so you'll have to renumber the footnotes in the 
second file

before you merge the two files.


Which is why I'm looking for some other solution, and I believe
that it might be able to be achieved programmatically. 
Unfortunately my
lisp skills are almost nil, hence my request for someone to 
help.


I use the following function for renumbering stuff such as 
footnotes:


#+begin_src emacs-lisp
(defun jk-renumber-counters (start regexp)
"Renumber counters.
Renumbering starts at START.  REGEXP describes the counters to be
renumbered.  The actual number must be enclosed in a group."
(save-excursion
  (goto-char (point-min))
  ;; because we incf the counter before using it, we need to 
  adjust:

  (let ((counter (1- start))
(counters (make-hash-table :test 'equal))
fn)
(while (re-search-forward regexp nil t)
  (setq fn (match-string 1))
  (replace-match (or (gethash fn counters)
 (puthash fn (format "%s" (cl-incf
 counter)) counters))
 nil nil nil 1)
#+end_src

In your case, you should be able to call this function with:

  M-: (jk-renumber-footnotes 355 "\\[fn:\\([0-9]+\\)\\]") RET

Change «355» to the number you want to start the footnotes in the 
second file

with.

If you already merged the two files and don't want to separate 
them again, you
could take out the line `(goto-char (point-min))`, put point at 
the position
where you want to start renumbering footnotes and then call the 
function. But
I'd play it safe and renumber the footnotes before merging the 
files.


HTH


--
Joost Kremers
Life has its moments



Re: wip-cite status question and feedback

2020-04-15 Thread Joost Kremers



On Wed, Apr 15 2020, Richard Lawrence wrote:
62 combinations might sound like a lot, but if you want your 
cite
commands to be mnemonic, you'll run out of options much more 
quickly.

[...]

So, I think the relevant question
is: how many different basic citation types are needed *within a 
single
document*, keeping in mind that these basic types will be 
formatted in

different ways, depending on the choice of stylesheet?

My experience is that it's typically just two (e.g. 
parenthetical and
author-in-text), and my memory of the earlier conversation was 
that most
people agreed. This is also borne out in the Pandoc syntax. As 
long as
we have two basic types of citations, the finer points of 
formatting

them can be achieved via other syntax, including the choice of
stylesheet.


Good points. I guess what this boils down to is whether Org wants 
to be like LaTeX, where simple things are doable and complicated 
things possible, or Pandoc, where simple things are simple indeed 
and complicated things essentially impossible.


To clarify: in LaTeX (biblatex) you can mix footnote and in-text 
citations in a single document, Pandoc doesn't allow that. 
Pandoc's functionality is sufficient for a great majority of 
cases, but if you want or need to go beyond it, things get very 
difficult.


My suggestion would still be not to hard-code a limit on possible 
citation commands. Org itself should probably just provide the 
basics, but users and add-on packages should be allowed to define 
more specific commands with readable names and there should be a 
well-defined interface for doing so (just like users and packages 
can add new link types, for example).


Just my €0.02, of course.

--
Joost Kremers
Life has its moments



Re: wip-cite status question and feedback

2020-04-13 Thread Joost Kremers



On Mon, Apr 13 2020, Nicolas Goaziou wrote:

denis.maier.li...@mailbox.org writes:

What about allowing something more verbose? Perhaps
"cite-intext:" or "cite:intext:"?

[...]
The simple syntax is great for most cases, but if you want to 
support
some of those not so common biblatex commands, this might be 
better.


Alphanumeric suffix provides 62 combinations, which should 
hopefully be

enough for any citation back-end out there (I'm looking at you
biblatex). It's not terribly readable, tho, as you point out.


62 combinations might sound like a lot, but if you want your cite 
commands to be mnemonic, you'll run out of options much more 
quickly.


This is a conciseness versus readability problem, not a 
technical one,
as long as we do not allow too much, from a parser point of 
view.


I have no strong opinion on the topic. It would be more valuable 
to hear

from actual citations users. What would they prefer?


Not sure if my opinion counts, given that I mainly use LaTeX + 
biblatex to write my texts, but I would definitely allow more than 
one character. The more common commands (=citep=, =citet=) can 
still use a single character (and thus remain concise), but for 
less common commands, the ability to have more descriptive names 
is to be preferred. Imagine looking at a document you wrote a few 
years back and having to figure out what =citeQ= or =cite7= was 
meant for again, or finding that =citeF= was changed from 
=\fullcite= to =\footfullcite= because at some point the 
developers figured the latter would be used more often.


I don't think it's necessary to use a dash (or any other 
character) in longer cite commands, though. =citeintext= isn't 
that much more difficult to read than =cite-intext=. (Biblatex 
does just fine without dashes, and there's always camelCase if 
you're so inclined.)



1. For the bibliography:

#+bibliography: something.bib
(Could this be a list containing multiple files?)


Multiple keywords may be more appropriate, particularly if you 
need to

spell out absolute file names.

Org can provide a function listing all of them anyway.


Yes, and please make it a public (one-dash) function. :-)


2. Placing the bibliography with:

#+bibliography: here
(Ideally, it would be possible to have this multiple times, 
perhaps
with some filters, like printing only the works of a certain 
author,
or with certain keywords, or so. But that's, of course 
something for

later...)


It is smart, but I'm not sure I like using the same keyword for 
two

different things. OTOH, I don't have a better idea.


As someone already suggested, using something like 
=#+printbibliography:= would work. And if that is too 
biblatex-like, you could instead opt for e.g. 
=#+list-of-references:=. (Output formats such as HTML or epub 
don't involve any printing anyway, so... ;-)



--
Joost Kremers
Life has its moments



Re: wip-cite status question and feedback

2020-04-08 Thread Joost Kremers



On Wed, Apr 08 2020, Bruce D'Arcus wrote:
On Tue, Apr 7, 2020 at 5:13 PM Joost Kremers 
 wrote:
What would help, BTW, is if there's an easy way to find out 
what

the bibliography file or files are that are associated with the
current Org buffer.


I guess the simplest and most flexible option would be to 
specify the

bib file in the header?

So if present use that; otherwise use the global bib file(s) 
specified

in the init?


That sounds like a good approach, yes. I don't know if Org would 
want to support having different bib files for different headers 
(i.e., be able to specify bib files in a :PROPERTIES: block). I 
believe that would be a bad idea, but who knows?


For my purpose, the best thing would be to have a function that 
returns a list of bibliography files for the current buffer (or 
header, if you want to go that way). That way, I wouldn't have to 
come up with my own (bug-prone) way of figuring out what bib files 
a user expects a particular Org file to use. Since (presumably) 
such a function is going to be needed anyway for exporting, it 
would be a simple matter of making that function public (i.e., 
name it with one dash, not two).


Thanks,

--
Joost Kremers
Life has its moments



Re: wip-cite status question and feedback

2020-04-07 Thread Joost Kremers



On Tue, Apr 07 2020, Bruce D'Arcus wrote:
While I of course can't speak for John, I would hope and expect 
org

ref to support the new syntax.

I would hope and expect the same of other packages (like ebib) 
that

use their own custom syntax.


Ebib maintainer here. I would certainly include support in Ebib 
for any citation syntax that Org would adopt. 

What would help, BTW, is if there's an easy way to find out what 
the bibliography file or files are that are associated with the 
current Org buffer.


--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-04-01 Thread Joost Kremers

Hi Thomas,

Thanks for that link. I really need to go over that document 
carefully. :-)


Best,

Joost



On Tue, Mar 31 2020, Thomas S. Dye wrote:

Aloha Joost,

This link reflects my understanding of how properties 
accumulate, rather than
overwrite: 
https://org-babel.readthedocs.io/en/latest/header-args/


hth,
Tom



--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-31 Thread Joost Kremers



On Tue, Mar 31 2020, Berry, Charles via General discussions about 
Org-mode. wrote:
`org-babel-view-src-block-info' (C-c C-v C-i with point in the 
src block below) reports


I didn't know about that command, it's proven to be very helpful.

Thanks!

Joost


--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-31 Thread Joost Kremers



On Tue, Mar 31 2020, Ken Mankoff wrote:

Yes I'm sure. From the link Thomas sent,

Any property specification, unless it is postfixed with a `+`, 
will *reset*

the value of that property to its current value.


Yes, I realise now I was mistaken. For some reason, I though that 
`:results function` meant something, which it doesn't.


C-c C-v  (for me, Charles uses C-c C-v C-i) withitn a code 
block shows
you the header args that are set for that block. Useful for 
debugging.


Yes, that turned out to be very useful. Thanks.

Joost


--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-30 Thread Joost Kremers



On Mon, Mar 30 2020, Ken Mankoff wrote:
Header args overwrite. Change python to python+ to append header 
args.


Are you sure? That's not documented anywhere I can find and it 
seems to be belied by the fact that if I put the headers in the 
order:


```
:PROPERTIES:
:header-args:python: :tangle out1.py
:header-args:python: :session py1 :results function
:END:
```

everything works as I would expect (the code blocks are tangled to 
a file `out1.py` *and* they are evaluated in a python session 
`py1`), meaning that *all* header args are picked up.


If I reverse the order and add a `+` sign, like so:

```
:PROPERTIES:
:header-args:python+: :session py1 :results function
:header-args:python+: :tangle out1.py
:END:
```

the code does indeed get tangled, but the `:results` header arg 
isn't picked up, because the code block doesn't produce any 
output.


For reference, this is my test file:

```
* Header 1
:PROPERTIES:
:header-args:python+: :session py1 :results function
:header-args:python+: :tangle out1.py
:END:

#+begin_src python
a=1
b=2
c=a+b
return c
#+end_src

#+RESULTS:
```


--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-29 Thread Joost Kremers



On Mon, Mar 30 2020, Joost Kremers wrote:

Looks like a bug, right?


And while I'm at it, this doesn't work as expected either:

```
#+PROPERTY: header-args :dir /home/joost/tmp/dlpy/

* Header 1
:PROPERTIES:
:header-args:python: :tangle out1.py
:header-args:python: :session py1 :results function
:END:

#+begin_src python
a=1
b=2
c=a+b
return c
#+end_src
```

I would expect that the file `out1.py` is created in the directory 
`/home/joost/tmp/dlpy`, but it's created in the same directory as 
the Org file.


Are my expectations wrong or is this really a bug?


--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-29 Thread Joost Kremers



On Sun, Mar 29 2020, Berry, Charles via General discussions about 
Org-mode. wrote:

What we really need is an ECM rather than snippets of code.


Yes, my apologies. It seems that having more than one `header-arg` 
line doesn't work properly. The following works:


```
* Header 1
:PROPERTIES:
:header-args:python: :tangle out1.py
:header-args:python: :session py1 :results function
:END:
#+begin_src python
a=1
b=2
c=a+b
return c
#+end_src

#+RESULTS:
: 3
```

But if I swap the two `header-args` lines, tangling stops working 
and at the same time evaluating the code block doesn't give any 
output at all:


```
* Header 1
:PROPERTIES:
:header-args:python: :session py1 :results function
:header-args:python: :tangle out1.py
:END:
#+begin_src python
a=1
b=2
c=a+b
return c
#+end_src

#+RESULTS:
```

With a `#+PROPERTY` line, I can't make it work at all:

```
#+PROPERTY: header-args:python :tangle out.py
#+PROPERTY: header-args:python :results function

* Header 1
#+begin_src python
a=1
b=2
c=a+b
return c
#+end_src

#+RESULTS:
: 3
```

Evaluating the code block works, but tangling doesn't. Reversing 
the order of the `#+PROPERTY` lines has no effect in this case.


Looks like a bug, right?

--
Joost Kremers
Life has its moments



Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-29 Thread Joost Kremers



On Sun, Mar 29 2020, Berry, Charles via General discussions about 
Org-mode. wrote:
On Mar 28, 2020, at 3:00 PM, Joost Kremers 
 wrote:

Is this expected behaviour? Am I doing something wrong?


IIUC what you did, then yes and yes.

This is the accepted idiom:

#+PROPERTY: header-args :tangle yes


I have tried:

#+begin_example
 #+PROPERTY: header-args:python :tangle yes :dir 
 /home/joost/tmp/dlpy

#+end_example

which AFAICT is the syntax shown in the info node you mentioned. I 
have also tried a file name instead of =yes=, both with and 
without quotes, but it doesn't work.


What I really want is to have a property block with the =:tangle= 
arg under each top-level header, like so:


#+begin_example
 :PROPERTIES:
 :header-args:python: :tangle out1.py
 :END:
#+begin_example

because I want the code below each top-level header to be tangled 
to a separate file. Again, AFAICT this is the syntax described in 
the info manual.


Hmm, experimenting a bit more I find that if I leave out the 
=python= part, it works:


#+begin_example
 :PROPERTIES:
 :header-args: :tangle out1.py
 :END:
#+begin_example

But the info manual gives this example:

#+begin_example
 :PROPERTIES:
 :header-args:clojure::session *clojure-1*
 :END:
#+begin_example

The same is true for the #+PROPERTY block at the top of the file: 
leave out the =python=, it works. Isn't it possible to restrict 
tangling to source blocks of a particular language? (Or, more 
specifically what I want: to specify different tangling targets 
for different language? I wanted to have both python and bash code 
blocks under one header and have them tangled to different 
files...)


Joost


--
Joost Kremers
Life has its moments



:tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-28 Thread Joost Kremers

Hi list,

I'm having trouble tangling an Org file. Basically, if I put a 
=:tangle= header argument in a =#+PROPERTY= line at the top of the 
file or in a =:PROPERTIES:= block under a header, it is not picked 
up and the code blocks to which (I think) it should apply are not 
tangled. Only when I put a =:tangle= argument at the top of the 
source block itself is the source block tangled.


Is this expected behaviour? Am I doing something wrong?

Emacs 26.3, Org 9.3.6.

TIA

Joost


--
Joost Kremers
Life has its moments



Re: Binding literal tab to C-Tab

2020-03-06 Thread Joost Kremers



On Fri, Mar 06 2020, Josh wrote:

Hi all,

I have a need to insert literal tab characters into my org-mode 
files
frequently. I would like to bind a key to insert literal tabs 
(ASCII 9). I
thought Control-TAB would be a good option. So I inserted the 
following lines
into my .emacs file. It works when in normal emacs, but not in 
org-mode. Is
there a way to get this to work in org-mode? If this is a bad 
key combination

for org-mode, I'm ok switching to another key combo.


Well, C-TAB is already bound in Org (to 
`org-force-cycle-archived`), but if you have no use for that 
command, you can of course rebind it. Since `global-set-key` 
creates global bindings, which are shadowed by local bindings, 
your binding has no effect in Org buffers. You need to bind C-TAB 
in `org-mode-map`:


   (define-key org-mode-map (kbd "C-") #'my-insert-tab-char)

HTH

--
Joost Kremers
Life has its moments



Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Joost Kremers



On Wed, Feb 19 2020, Matthew Lundin wrote:

- org-hide-emphasis-markers => t
- org-hide-macro-markers => t

[...]
I have a few concerns about this. I believe that markup syntax, 
as a
rule, should be visible. Most markdown editors do not hide 
markup by
default. I realize that there are some exceptions in Org (e.g., 
links).
But editing around the invisible boundaries of links can be in 
Org can
be fussy (sometimes I have to do M-x visible-mode when editing 
near the

edges of links). So I'd recommend not changing the default here,
especially for emphasis markers.


I was going to say the same thing. I set 
`org-hide-emphasis-markers` to t when I started out using Org, but 
at some point changed it to `nil` because editing at the 
beginning/end of words in emphasis markers was just too 
unpredictable. Same with links, BTW.


What I'm wondering, though, is why Org doesn't make hidden markup 
visible when the cursor moves into it. `prettify-symbols-mode` can 
do this, and AUCTeX does it by default (IINM) in folded macros and 
preview snippets, so it's definitely doable.


So my suggestion would be to keep it off unless/until such 
make-visible-at-point functionality is implemented.


--
Joost Kremers
Life has its moments



Re: Fixed vs variable pitch font [legibility 4/6]

2020-02-11 Thread Joost Kremers



On Tue, Feb 11 2020, Bastien wrote:

Hi Texas,

Texas Cyberthal  writes:

Why does there need to be an Org version of mixed-pitch-mode? 
It

already works for Org.


Yes, indeed.


Besides, there's also `org-variable-pitch`, available on Melpa.

--
Joost Kremers
Life has its moments



Re: ob-scheme haunted source code block?

2020-01-23 Thread Joost Kremers



On Tue, Jan 21 2020, Neil Jerram wrote:
OK, up to this point I am thinking: this is all quite curious, 
but
presumably not really a big problem, as you surely don't need to 
use this

rather strange workflow...


Mind you, that's not my normal workflow. I normally just do =C-'= 
to edit a source block, =C-'= to finish the edit and return to the 
Org file, and then =C-c C-c= to evaluate the source block. The 
rest was just to try and find out where the problem lies.


The weirdest thing about this is that the problem is 
persistent. I
restarted Emacs and in my desperation even rebooted the 
computer,

but to no avail.


But this is indeed weird.  Are you saying that you can reboot 
your
computer, restart Emacs, open the relevant Org file, evaluate 
the source

block (without any C-c ') and you still see the problem?


Yes, that was what was happening. I suspected there might be some 
history being kept somewhere, that's why I grepped through my 
=~/.emacs.d/= directory.


If so, I wonder if it's a real but intermittent problem in your 
code that
was somehow made more likely by the original workflow, and now 
you're just

being unlucky?


The code was fairly straightforward (and not even mine... It came 
directly from SICP), so I doubt that had much to do with it.


Anyway, I'm gonna have to put this down as a Heisenbug. The 
problem disappeared after a while and I can't reproduce it: Going 
through the steps that I thought triggered the bug doesn't 
recreate it. Weird.


Thanks for reading and apologies for wasting everyone's time...

Joost



ob-scheme haunted source code block?

2020-01-17 Thread Joost Kremers

Hi list,

I've been learning some Scheme recently and decided to use Org 
mode and babel so I could document my progress, keep notes, etc. 
together with the code I write. I also installed the geiser 
package to work with Scheme source files directly. 

This all worked perfectly, until I made the (apparent) mistake of 
typing =C-c C-c= on an expression while editing a source code 
block. That is, I had pressed =C-c '= in an Org buffer on a source 
block and in the editing buffer that popped up, I hit =C-c C-c= 
(bound to =geiser-eval-definition=) on a particular function (well 
procedure...) definition.


From that moment on, that particular procedure definition seems 
haunted. Whenever I evaluate a source block containing it from 
within an Org file, the associated REPL is doomed. It takes about 
30 seconds for the evaluation to complete, during which time Emacs 
seems to hang (no CPU activity, just waiting). Any further 
interaction with the REPL from that point on, either from other 
source blocks in the same file (all source blocks in it use the 
same session) or in the REPL buffer directly, causes the same 
hang.


I can `C-g` out of the hang, but this doesn't solve much because 
any further interaction causes the same hang. 

Putting the relevant procedure definition in a Scheme source file 
and evaluating that (within Emacs, through geiser) is 
unproblematic, so the code itself is not to blame.


The weirdest thing about this is that the problem is persistent. I 
restarted Emacs and in my desperation even rebooted the computer, 
but to no avail.


Does anyone have any idea what might be going on? I rgrepped 
through my =.emacs.d= directory to see if the relevant procedure 
name turns up anywhere but found nothing. I'm not really sure 
where to look beyond that.


Versions:

IELM> emacs-version
"26.3"
IELM> org-version
"9.3.1"

TIA

Joost

--
Joost Kremers
Life has its moments



Re: very strange LaTeX error

2019-12-20 Thread Joost Kremers
On Fri, Dec 20, 2019, at 12:56 PM, Fraga, Eric wrote:
> #+begin_src latex
>   \documentclass{scrartcl}
>   \begin{document}
>   % packages deleted, none of which is used anyway in the following
>   \tableofcontents
> 
>   \section{some results}
>   \label{sec:org4f5891c}
>   \begin{table}[hbtp]
>   \label{atable}
>   \centering
>   \begin{tabular}{lrrr}
>   \hline
>   x & z1 & z2 & g\\
>   \hline
>   [0.0005, 0.05, 0.5] & 9.0 & 0.05 & 0.0\\
>   [0.000787451, 0.0575948, 0.5] & 11.0 & 0.05759476698672508 & 0.0\\
>   \hline
>   \end{tabular}
>   \end{table}
>   \end{document}
> #+end_src
> 
> I get errors like this when compiling with pdflatex:
> 
> #+begin_example
>   ! Illegal unit of measure (pt inserted).
>
>  ,
>   l.18 [0.000787451, 0.0575948, 0.5]
>  & 11.0 & 0.05759476698672508 & 0.0\\
>   ! Missing = inserted for \ifdim.
>
> #+end_example
> 
> What am I doing wrong? 

You have `[...]` in the first cell of a table row that is not the first row. 
Few people seem to realise that the double backslash `\\` in LaTeX is a macro 
that can actually take an optional argument, a measure specifying the height of 
the newline. So when a table row ends in `\\` (which is the normal case) and 
the next row starts with an opening bracket, LaTeX assumes it is looking at an 
optional argument and expects a measure, i.e., a number followed by one of the 
supported units.

The solution I usually opt for is to enclose the brackets in an additional set 
of braces: `{[...]}`. Whether Org export can and should automate that, I can't 
say.

HTH

-- 
  Joost Kremers
  Life has its moments



[O] Get the text of a node

2019-10-23 Thread Joost Kremers

Hi all,

I was wondering if there's a way to programmatically get the text 
of a node in an Org buffer. Basically, I have a buffer that looks 
something like this:


#+BEGIN_SRC org
* Top header
** Subheader
  :PROPERTIES:
  :Custom_ID: some_id
  :END:

  Text starts here, possibly with additional subheaders
#+END_SRC

What I would like to extract is the text below "Subheader", but 
without the :PROPERTIES: block.


I've looked at the org-element library, but I haven't been able to 
figure out how to use it to extract just the plain text.


I use the :Custom_ID: property to find the relevant subheading and 
I know I can use (org-back-to-heading) to get point to the 
Subheader containing the relevant :PROPERTIES: block. Obviously, I 
could then narrow the buffer to the subheader, use a text search 
to move point past the line containing :END: and then extract the 
text from there until (point-max).


I'm just wondering if this may break in unexpected circumstances 
and whether there's a better way.


TIA

Joost



--
Joost Kremers
Life has its moments



Re: [O] lisp: scoping vars in repetitive defuns

2019-09-18 Thread Joost Kremers



On Wed, Sep 18 2019, Matt Price wrote:

Is thre away to do that kind of destructuring bind -- which
binds *everything* in the plist, without knowing the symbol 
names in

advance? that would be really great.


let-alist perhaps?


--
Joost Kremers
Life has its moments



Re: [O] Pandoc and Org-mode: list indention

2019-08-20 Thread Joost Kremers



On Mon, Aug 19 2019, Devin Prater wrote:
I’ve taken it upon myself to clean all this up, and Org-mode 
does it all. The only problem is, when I convert from HTML to 
Org-mode using Pandoc, just doing:

Pandoc -I lesson1.html -o lesson1.org <http://lesson1.org/>
The lists are not made into indented ones, just a paragraph, 
which I manually have to indent,


If you're using Pandoc to convert html to org, then you should 
probably ask on the Pandoc mailing list:


https://pandoc.org/help.html

HTH

--
Joost Kremers
Life has its moments



Re: [O] ivy-bibtex and orgmode inserts ebib: link

2019-03-22 Thread Joost Kremers



On Fri, Mar 22 2019, Eric S Fraga wrote:

I am going down a rabbit hole here...

Short question: how can I add a new link type to org?  It used 
to be

that we would use ~org-add-link-type~ but this is
deprecated.  Fine.  The documentation points to
~org-link-set-parameters~ instead but this can only set the 
parameters
for known links.  Known links seem to be defined by a complex 
regex in

~org-link-types-re~.

What is the replacement for ~org-add-link-type~ in the latest 
version of

org, if any?  Or do I have to both add to the regex and set link
parameters separately?


I'm pretty sure the regex is created automatically. I only needed 
to do this:


   (org-link-set-parameters "ebib" :follow #'org-ebib-open :store 
   #'org-ebib-store-link)


And then define the functions `org-ebib-open` and 
`org-ebib-store-link`. (Cf. 
<https://github.com/joostkremers/ebib/blob/master/org-ebib.el>).


And yes, I apologize for the irony. ;-)


--
Joost Kremers
Life has its moments



Re: [O] New bug in org-agenda?

2019-03-04 Thread Joost Kremers



On Mon, Mar 04 2019, Roland Everaert wrote:
I am facing the same issue with that version on emacs 25.2.2 
(Ubuntu

18.04.2 LTS).


When will it be available throu the Org Mode ELPA repo?


I got the update this morning (finally...)

--
Joost Kremers
Life has its moments



Re: [O] Placement of \makeatletter with \beamer@frametextheight

2018-11-29 Thread Joost Kremers



On Thu, Nov 29 2018, Gustavo Barros wrote:

Louis,

a hunch, which might work.
It seems that, if you try to set the length in your preamble,
`\beamer@frametextheight` is not yet defined.
So, you might try the hook `\AtBeginDocument` to see if the 
definition comes at

a better timing.

 #+LATEX_HEADER:
\newlength\mytextheight\AtBeginDocument{\makeatletter\setlength\mytextheight{\beamer@frametextheight}\makeatother}

As I said, it's a hunch, for I haven't tested. But I think it 
may be it.


Why not put the entire thing inside \AtBeginDocument?

To the OP: \paperheight does seem to be available in Beamer. 
Couldn't you use that?


--
Joost Kremers
Life has its moments



Re: [O] malformed function

2018-07-11 Thread Joost Kremers



On Wed, Jul 11 2018, Joost Kremers wrote:

On Mon, Jul 09 2018, hymie! wrote:

Greetings.

I know this is technically


Technically and practically. ;-)


Actually, I just now noticed your code is coming from worg, so 
that makes it not completely off-topic, I'd say.


--
Joost Kremers
Life has its moments



Re: [O] malformed function

2018-07-11 Thread Joost Kremers



On Mon, Jul 09 2018, hymie! wrote:

Greetings.

I know this is technically


Technically and practically. ;-)


an emacs problem and not an Orgmode problem,
but maybe you guys will see the error that I can't find.


A better place to ask would probably be the mailing list 
help-gnu-emacs, but:



I have two different machines.  One is a Linux machine running
Orgmode 9.1.13 under Emacs 25.3.1 , and one is a Windows 10 
machine
running Orgmode 9.1.13 under Emacs 24.5.1 .  Both have the same 
.emacs

file as far as I can tell.


Try diff or ediff to make sure.


The Linux machine is getting this error:

Warning (bytecomp): ‘(extract-window (line) (let ((start
(get-text-property 1 (quote time-of-day) line)) (dur 
(get-text-property

1 (quote duration) line))) (cond ((and start dur) (cons start
(org-time-from-minutes (+ dur (org-time-to-minutes start) 
(start

start) (t nil’ is a malformed function


That means that the entire s-expr (extract-window ... nil is 
being interpreted as a function, which is caused by the fact that 
it is the first element of the list ((extract-window ... nil) 
(note extra pair of parens). Since such an s-expr cannot be a 
function, you get an error.


The fact that it is interpreted as a function indicates that the 
byte compiler doesn't know that `flet' is a macro, which in turn 
indicates that you haven't loaded the required library.


Note that the documentation for `flet' says that it has been 
obsolete since Emacs 24.3 and that you should be using `cl-flet' 
instead (or `cl-letf', but that doesn't seem to be what you want). 
So best thing to do is to replace `flet' with `cl-flet' and then 
add `(require 'cl-lib)' somewhere at the top of your init file, 
and you should be good to go.


Why you're only getting this error on one machine isn't entirely 
clear to me. It could be that something changed between Emacs 24 
and 25 that causes this, it could be that you're loading a package 
on the Windows machine that loads cl or cl-lib and that you don't 
use on Emacs.


HTH


--
Joost Kremers
Life has its moments



Re: [O] Org mode in combination with emacs follow-mode is terrible

2018-06-13 Thread Joost Kremers



On Wed, Jun 13 2018, Eric S Fraga wrote:

On Wednesday, 13 Jun 2018 at 09:53, Gerald Wildgruber wrote:
Switching to text-mode, with 5 windows and follow-mode still 
being

active reduces lag significantly.

So there must be an issue specifically with the combination of 
org-mode

and follow-mode!


I don't think there's an issue per se in the sense of bugs.  Org 
does
much more processing of the text than does text mode so if you 
have 60k
worth of text to process each time you type something, it's 
probably not

surprising that there is a lag.


Actually, I would suspect it's more of a problem for follow-mode 
than org-mode, because follow-mode needs to keep the different 
windows in sync. For this, it adds a function to 
`post-command-hook', which means it's run after every key press.


It's not inconceivable that `follow-mode' does something that is 
extra time-consuming in an Org buffer. To find out what that might 
be, you could try the Elisp profiler that comes with Emacs. See 
the section "Profiling" in the Elisp manual for details.


Once you've found out which function(s) consume so much time, it 
might be possible to ask in here or on emacs-devel what exactly is 
causing the problem and whether there's a way around it.


--
Joost Kremers
Life has its moments



Re: [O] refile workflow -- move to same heading in different file?

2017-08-04 Thread Joost Kremers


On Fri, Aug 04 2017, Adam Porter wrote:

"Raymond Zeitler" <zei...@yahoo.com> writes:
Gosh, I was really hoping to be doing export to ODT or PDF by 
now!


If you don't have time to fix it, you could export to HTML and 
convert

it with Pandoc.


Why convert to HTML first? Pandoc can read Org files pretty well.

--
Joost Kremers
Life has its moments



Re: [O] exporting markdown with tables

2017-06-04 Thread Joost Kremers


On Sat, Jun 03 2017, Peter Davis wrote:
(FWIW, I tried using pandoc, but this just removed the table 
syntax altogether, so an entire table would just run together 
into a

paragraph of gibberish.)


You need a somewhat recent version of Pandoc for Org tables to be 
handled correctly (some distros still ship a very outdated 
version; latest is 1.19), and not all features are supported. So 
yeah, it's not necessarily the best option...



--
Joost Kremers
Life has its moments



Re: [O] Exporting PDF (new setup)

2017-05-01 Thread Joost Kremers


On Mon, May 01 2017, Peter Davis wrote:

Nick Dokos <ndo...@gmail.com> writes:



As a first step, switch to buffer *Org PDF LaTeX Output* and 
check for errors.


Thanks, Nick. I found the same error I got running pdflatex in a 
command shell:


! LaTeX Error: File `wrapfig.sty' not found.

I had installed basictex using Homebrew (one of several Mac 
package managers), but I think I'd be better off with TeXLive or

MacTeX. I'm trying that now.


IIUC BasicTeX is a subset of TeXLive. If it comes with the TeXLive 
Manager, it should be possible to add packages on a need-to-have 
basis, rather than installing all of TeXLive. Just do `tlmgr 
install wrapfig` in a shell, or (if installed) use the graphical 
TeXLive Manager.



--
Joost Kremers
Life has its moments



Re: [O] Exporting PDF (new setup)

2017-05-01 Thread Joost Kremers


On Mon, May 01 2017, Peter Davis wrote:
I'm running Org 8.2.10 on a new MacBook with El Capitan as the 
OS. I can't seem to get PDF export working. I get these 
messages:


Processing LaTeX file ./blahblahblah.tex...
/bin/bash: pdflatex: command not found [3 times]
org-latex-compile: PDF file ./blahblahblah.pdf wasn’t produced

I did install basictex, and when I enter pdflatex on the command 
line, it works with no problems. Any clues why org export isn't

finding the executable?


This:

https://github.com/purcell/exec-path-from-shell

perhaps?


--
Joost Kremers
Life has its moments



Re: [O] Tables not converted to markdown format with markdown exporter

2017-02-08 Thread Joost Kremers


On Wed, Feb 08 2017, Sharon Kimble wrote:

Roland Everaert <reveatw...@gmail.com> writes:


Hi,

Since a few weeks we use mattermost at work and I had recently 
to post a table to a team channel. I have created my table with 
org-mode, but when I export it to markdown format, the table is 
converted to html instead of markdown.


Is there any reason to that, except the simple fact that table 
conversion is not implemented yet?


As the markdown format is quite similar to the org-mode format 
regarding tables, I don't really see where could lie the 
difficulty.


Example:
- org format

| column 1 | column 2 | column 3 |
|---++-|
| some text | some more text | event more text |
| blah | 45 | fgf |

- markdown format
| column 1 | column 2 | column 3 |
|---||-|
| some text | some more text | event more text |
| blah | 45 | fgf |

This is obviously a very simple example, but usually, with 
mattermost, one doesn't post very complex messages.


Regards.


AFAIK markdown can't do tables. Any search of google won't show 
any ways

of doing markdown-tables because its not available on markdown.


There are certainly markdown variants that support tables, 
MultiMarkdown, PHP Markdown Extra and Pandoc markdown do, for 
example.


Roland, if Org export won't work, you may want to take a look at 
Pandoc. It accepts Org files as input and can produce Markdown 
files as output, and it supports a number of different types of 
tables. The kinds of tables you're looking for are called pipe 
tables in Pandoc's documentation:


http://pandoc.org/MANUAL.html#tables

HTH

--
Joost Kremers
Life has its moments



Re: [O] Make wide tables more readable

2016-12-01 Thread Joost Kremers


On Thu, Dec 01 2016, John Kitchin wrote:

I use:

;;;###autoload
(defun tq-increase-text-size ()
  "Increase text size."
  (interactive)
  (set-face-attribute 'default nil :height
 (truncate (* 1.1 (face-attribute 'default :height)

;;;###autoload
(defun tq-decrease-text-size ()
  "Decrease text size."
  (interactive)
  (set-face-attribute 'default nil :height
 (truncate (* 0.9 (face-attribute 'default :height)

which I bind to C-- and  C-= to shrink the font size down until 
it fits,

then when I am done increase it.


Why not use `text-scale-adjust`? This function has convenient 
bindings in the form `C-x C-+` to increase text size, `C-x C--` to 
decrease, and `C-x C-0` to reset to default size. Furthermore, 
once you press any of these, you can simply use `+`, `-` and `0` 
for increasing, decreasing and resetting until you've found your 
preferred text size.


--
Joost Kremers
Life has its moments



Re: [O] Track time on day-to-day basis

2016-11-27 Thread Joost Kremers

Hi Oliver,

On Fri, Nov 25 2016, ngre...@gmx.net wrote:

I do reports on a day-to-day basis using clocktables:

#+BEGIN: clocktable :maxlevel 4 :block 2016-11 :scope 
("./Projekt01.org") :link t :step day :stepskip0


#+END:

Hope this helps.


Yes, that's exactly what I was looking for, thanks!

--
Joost Kremers
Life has its moments



Re: [O] How to find out in Elisp which .bib file is used for the current org buffer?

2016-11-25 Thread Joost Kremers

Hi,

[Sorry for the late reply, I've been rather busy...]

On Fri, Nov 18 2016, John Kitchin wrote:
It depends on how you put citations in I guess. If you use 
org-ref, then
there is a bibliography link or a latex_header with 
addbibresource.

Otherwise, it is one of the files defined in
org-ref-default-bibliography.

I am not sure about the ox-bibtex setup.


Ok, so there's no single method that will always work. Thanks for 
the info. It doesn't solve my problem but at least I know where to 
start looking. :-)


--
Joost Kremers
Life has its moments



[O] Track time on day-to-day basis

2016-11-25 Thread Joost Kremers

Hi all,

I've come into the need to track the time I'm working on a 
particular project, which is great with Org, but I also need to 
report the tracked time on a day-to-day basis. This seems somewhat 
less straightforward to do. I realize I can generate a report 
limited to today by specifying `:block today`, but that only gives 
me the time clocked today. What do I do when I want to get a 
day-to-day overview of the time spent on a project? Do I need to 
maintain another table by hand, in which I copy the time 
calculated by `org-clock-report` at the end of each day? Or is 
there a better method?


BTW, just looking at the LOGBOOK drawer doesn't work, because I 
may clock in and out of a project several times a day.


Thanks for any hints and suggestions!

--
Joost Kremers
Life has its moments



[O] How to find out in Elisp which .bib file is used for the current org buffer?

2016-11-18 Thread Joost Kremers

Hi all,

If you're writing a scientific document in Org, you'll normally 
have a .bib file that you use for your references. What I'd like 
to know is: is there a (robust) way to find out if a specific Org 
buffer has a .bib file associated with it?


In a LaTeX file, you can usually find this out by looking for a 
\bibliography command or, if you use biblatex, for 
\addbibresource. I'm wondering what the canonical way is to 
specify this for an Org file.


TIA

Joost



--
Joost Kremers
Life has its moments



Re: [O] Obsolete org contrib package

2016-11-11 Thread Joost Kremers


[removed Grégoire Jadi <daim...@gmail.com> from the discussion.]

On Thu, Nov 10 2016, Nicolas Goaziou wrote:

Joost Kremers <joostkrem...@fastmail.fm> writes:

Like I said, I'd be happy to take over maintainance. Just let 
me know
how to go about making it available to org-contrib. (If there 
is a way

to keep the file in the main Ebib repository, that would be my
preference.)


We don't need to make it available to Org contrib. Let me know 
when your
version of org-ebib.el is available to Org users (e.g., through 
ELPA)

and I'll remove it from contrib/ directory.


In that case, I'll just make it part of the normal Ebib 
installation. No-one will be interested in org-ebib.el if they're 
not also using Ebib, so I believe this makes sense. Those that use 
Ebib but not Org will only have one small file added to their 
installation, which shouldn't be a problem. I won't `require' 
org-ebib.el in ebib.el, that will be up to the user.


Unless there's some reason to make it available as a separate 
package?


Thanks,

Joost


--
Joost Kremers
Life has its moments



Re: [O] Obsolete org contrib package

2016-11-10 Thread Joost Kremers


On Tue, Nov 08 2016, Joost Kremers wrote:

Hi,

On Tue, Nov 08 2016, Nicolas Goaziou wrote:

So you mean there is no equivalent to both

  (ebib-cur-entry-key)


This one was what I was worried about, but on second thought, it 
should be possible to simply use:


(ebib--get-key-at-point)


and

  (ebib-db-get-field-value 'title key ebib-cur-db)


That one's easier: 


   (ebib-db-get-field-value "title" key ebib--cur-db)


"org-ebib.el" is already compatible with Org 9.0.


Ah, good, I didn't realise that.

I'm Cc'ing the author. Ideally this library should be updated 
to 
new

Ebib and moved to some ELPA.

If Grégoire doesn't want to take care of it and no one 
volunteers to

maintain that file, we can remove it.


I was actually planning to add this functionality to Ebib 
itself. 
So if Grégoire isn't interested in it anymore, I could put it in 
the Ebib repo, or create a separate repo for it, either on 
Github 
or somewhere else, wherever you prefer.


I received the following reply from Grégoire (which, although it 
was sent to the mailing list as well, apparently didn't show up 
there):



==

On 11/08/16 13:23, Nicolas Goaziou wrote:
I'm Cc'ing the author. Ideally this library should be updated to 
new

Ebib and moved to some ELPA.

If Grégoire doesn't want to take care of it and no one 
volunteers to

maintain that file, we can remove it.


I don't use this package anymore.
If anyone uses it, s/he take over it, otherwise we can just remove 
it

from org-contrib.

==

Like I said, I'd be happy to take over maintainance. Just let me 
know how to go about making it available to org-contrib. (If there 
is a way to keep the file in the main Ebib repository, that would 
be my preference.)


Best,

Joost




--
Joost Kremers
Life has its moments



Re: [O] Obsolete org contrib package

2016-11-08 Thread Joost Kremers

Hi,

On Tue, Nov 08 2016, Nicolas Goaziou wrote:

So you mean there is no equivalent to both

  (ebib-cur-entry-key)


This one was what I was worried about, but on second thought, it 
should be possible to simply use:


   (ebib--get-key-at-point)


and

  (ebib-db-get-field-value 'title key ebib-cur-db)


That one's easier: 


  (ebib-db-get-field-value "title" key ebib--cur-db)


"org-ebib.el" is already compatible with Org 9.0.


Ah, good, I didn't realise that.

I'm Cc'ing the author. Ideally this library should be updated to 
new

Ebib and moved to some ELPA.

If Grégoire doesn't want to take care of it and no one 
volunteers to

maintain that file, we can remove it.


I was actually planning to add this functionality to Ebib itself. 
So if Grégoire isn't interested in it anymore, I could put it in 
the Ebib repo, or create a separate repo for it, either on Github 
or somewhere else, wherever you prefer.




--
Joost Kremers
Life has its moments



[O] Obsolete org contrib package

2016-11-07 Thread Joost Kremers

Hi all,

I just ran into org-ebib.el, a file that's part of org-contrib. I 
noticed that it uses functions from Ebib that were renamed pretty 
much exactly two years ago. (They're internal functions and thus 
got an extra dash.) This could in principle be fixed by changing 
the relevant function calls in org-ebib.el, but as it happens I'm 
about to push some changes to Ebib that will make it less 
straightorward to fix org-ebib.el.


So perhaps it would be best to simply remove org-ebib.el from 
org-contrib? It doesn't seem to have been used by anyone the past 
two years and all it does is define a function to store an org 
link to an Ebib entry, which, IIUC, is done in a completely 
different way in Org 9.0.


Joost


--
Joost Kremers
Life has its moments



Re: [O] Making DocBook xml books from org mode?

2016-10-02 Thread Joost Kremers

On Sun, Oct 02 2016, Peter Davis wrote:
> Interesting. I just installed Pandoc on my Mac today with Homebrew, but
> it claims to be 1.13.1. I'll try to find an update. Thanks.

Check the "Installing" page on pandoc.org: there's a link to an OS X
package on Pandoc's Github page:

https://github.com/jgm/pandoc/releases/tag/1.17.2

Perhaps you can use that?

-- 
Joost Kremers
Life has its moments



Re: [O] Making DocBook xml books from org mode?

2016-10-02 Thread Joost Kremers

On Sun, Oct 02 2016, Peter Davis wrote:
> When I try to export to docbook via pandoc (C-c C-e p d), I get
>
> Running pandoc with args: (-f org -t docbook5 -o 
> /Users/peterdavis/Dropbox/HMH/my_file.dbk --parse-raw --mathjax --standalone 
> /Users/peterdavis/Dropbox/HMH/my_file.tmp3362h9T.org)
> Error occured.
> pandoc: Unknown writer: docbook5
>
> Any guesses? Is there something additional I need to install in pandoc?

The `docbook5' writer was added to Pandoc fairly recently, in version
1.17.1, released in June of this year. There's also a `docbook' writer,
which has been part of Pandoc much longer and which outputs to (I
assume) DocBook v4. So I suspect you either need to upgrade your Pandoc
or make sure ox-pandoc sets the output format to `docbook'.

--
Joost Kremers
Life has its moments



Re: [O] Making DocBook xml books from org mode?

2016-09-29 Thread Joost Kremers

On Thu, Sep 29 2016, Peter Davis wrote:
> I've started a new position in which I have to create and maintain a
> large set of documents in DocBook xml format. For new books, I'd really
> like to use org mode, since a) I'm already familiar with it, b) I love
> it, and c) I believe it does (or can be made to do) nearly everything I
> need.
>
> However, after Googling around the org-mode/DocBook space, I'm left with
> some questions.
>
> 1. I'm going to be creating books, as opposed to articles. My org-header
> looks like this:
>
> #+STARTUP: showeverything logdone
> #+OPTIONS:   H:5 num:t \n:nil @:t ::t |:t ^:nil -:t f:t *:t <:t
> #+LaTeX_CLASS: koma-article
> #+LaTeX_HEADER: \usepackage{listings}
> #+LATEX_HEADER: \setlength{\parskip}{2ex plus 4pt minus 2pt}
> #+LATEX_HEADER: \setlength{\parindent}{0pt}
> #+LATEX_HEADER: \renewcommand{\baselinestretch}{1.0}
> #+LATEX_HEADER: \setlength{\topsep}{-10pt}
> #+LATEX_HEADER: \setlength{\partopsep}{0pt}
> #+LaTeX_HEADER: \usepackage{xcolor}
> #+LaTeX_HEADER: \lstset{
> #+LaTeX_HEADER: basicstyle=\ttfamily,
> #+LaTeX_HEADER: breaklines=true,
> #+LaTeX_HEADER:
> prebreak=\mbox{\ensuremath{\color{red}\hookleftarrow}},
> #+LaTeX_HEADER:
> postbreak=\raisebox{0ex}[0ex][0ex]{\ensuremath{\color{red}\hookrightarrow\space}},
> #+LaTeX_HEADER: columns=fullflexible,
> #+LaTeX_HEADER: keepspaces=true
> #+LaTeX_HEADER: }
> #+LaTeX_CLASS_OPTIONS:
> [book,letterpaper,times,12pt,listings-bw,microtype]
>
> but the PDFs I'm getting still look like articles. (I copied the
> above from some examples posted on this list a while ago. Thanks!)

Your LaTeX_CLASS is set to `koma-article', so that makes sense.

>  2. Are there any advantages to considering MarkDown or AsciiDoc as
>  opposed to org markup? (Again, my familiarity with org is a strong
>  incentive here, but I'm willing to consider other options.)

There is a (IMHO) excellent markdown-mode available on Melpa, and if you
use Pandoc[1] to convert your documents you have a lot of flexibility.
There's also `pandoc-mode' (of which I'm the author), a minor mode that
makes interacting with pandoc from within Emacs easier.

>  3. The direct route from org to DocBook xml seems to be missing. From
>  what I gather, I can get there somehow via texi (but I don't even have
>  that in org currently), or perhaps export to HTML and then convert that
>  to db xml. Am I missing something? Is there some other route I should
>  consider?

Pandoc can convert to Docbook, so that might be an option. Note that
Pandoc also converts *from* Org, (although it cannot handle all of Org's
capabilities), so depending on your needs, that might be a way to go
directly from Org to Docbook.

>  4. [LONGSHOT] Is there any way to /import/ docbook xml into org mode?

Pandoc also converts *from* Docbook, and can convert *to* Org, so again,
that might be of help.

Of course, whether Pandoc can be useful to you really depends on your
needs. Pandoc's internal document representation is based on Markdown,
and by its very nature Markdown is more limited in it capabilities than
Org. In essence, anything that cannot be handled by (Pandoc's version
of) Markdown, cannot be handled by Pandoc in other formats.

HTH

--
Joost Kremers
Life has its moments



Re: [O] Programmatically handling org files

2016-09-12 Thread Joost Kremers

On Mon, Sep 12 2016, John Kitchin wrote:
>> I was wondering if there is some sort of (semi)official API for handling
>> org files programmatically. That's to say, is there a documented way for
>> non-org Emacs packages to manipulate (the contents of) org files?
>
> None that I know of. A non-elisp lib would have to be able to parse the
> org-files.

As you've already realised, I was asking about Elisp code that's not
part of or intended to extend orgmode.

>> Also, I was wondering if there's a way to hook into org-store-link. For
>> a particular major mode, I would like to be able to define what kind of
>> link is created when the user calls `org-store-link`. I looked at the
>> source of `org-store-link` and it looks like the answer is no, but I
>> thought I'd ask anyway. I could of course create the link myself and add
>> it to `org-stored-links` but that feels rather hackish and I suspect
>> will blow up in my face at some point in the future.
>
> You want to add a function to org-store-link-functions. The function
> should check if it is responsible for creating this link (for example by
> looking at the major mode). If not, it must exit and return nil. If yes,
> it should return a non-nil value after a calling `org-store-link-props'
> with a list of properties and values.

Great, thanks! I looked at the source of `org-store-link', but this
wasn't obvious to me. :-/


-- 
Joost Kremers
Life has its moments



Re: [O] Programmatically handling org files

2016-09-12 Thread Joost Kremers

On Mon, Sep 12 2016, John Kitchin wrote:
> indeed! Maybe I misunderstood the OP.
>
> You can find more on the API here:
>
> http://orgmode.org/worg/dev/org-element-api.html
>
> There are also a bunch of functions to do other things, e.g.
>
> (org-todo) (org-cut-subtree) (org-entry-put) and many others
>
> that let you change properties of headings, cut them, etc...
>
> These are documented in the org code. The best way to learn how to use them
> is to reverse engineer how you would make the change you want manually,
> e.g. which keys do you press, then use C-h k on those keys to see what
> commands get run.

Yes, I've been doing that and I've arrived at something that works, just
wasn't sure it was the Right Way™. :-)

-- 
Joost Kremers
Life has its moments



Re: [O] Programmatically handling org files

2016-09-12 Thread Joost Kremers

On Mon, Sep 12 2016, Thorsten Jolitz wrote:
> by "non-org Emacs packages" you mean Emacs packages written in Elisp,
> but not part of Org-mode? 

Yes, exactly. My wording wasn't entirely clear, I admit.

> The org-mode parser converts an Org document into a nested list and
> provides many convenience functions to work on this parse tree. So
> org-element.el (and maybe ox.el too) is the core library for converting
> an Org text document into an Elisp data structure and working with that,

So IIUC org-element.el is mainly for getting the contents of an org
buffer in such a way that a program can work with it, but not really for
modifying the contents of the buffer itself in such a way that it's
still a valid org document, right?

> If you feel you don't need the whole parse tree, but rather want to act
> locally on the Org element at point,

Yes. :-)

> you might want to look at 
> org-dp.el

Cool, I will do that!

> with just two core functions (create and rewire an Org
> element) and a mapping functions (plus quite a few utilities in
> org-dp.el and org-dp-lib.el):

[snip example]

> Using this system, creating or rewiring an Org Element from Elisp
> requires only to define the values of the interpreted parameters, all
> the low level stuff (actually creating and inserting the new/modified
> element in text form) is left to the interpreters (from org-element.el).
>
> You just declare what you want and don't worry anymore how it is done
> (=> dp stands for declarative programming, in this context at least ;-)

That sounds pretty cool, thanks!

-- 
Joost Kremers
Life has its moments



[O] Programmatically handling org files

2016-09-12 Thread Joost Kremers
Hi all,

I was wondering if there is some sort of (semi)official API for handling
org files programmatically. That's to say, is there a documented way for
non-org Emacs packages to manipulate (the contents of) org files?

Specifically, I'm wondering about creating and deleting entries (by
entries I mean headers with their contents), changing TODO state, moving
entries, that sort of thing.

Also, I was wondering if there's a way to hook into org-store-link. For
a particular major mode, I would like to be able to define what kind of
link is created when the user calls `org-store-link`. I looked at the
source of `org-store-link` and it looks like the answer is no, but I
thought I'd ask anyway. I could of course create the link myself and add
it to `org-stored-links` but that feels rather hackish and I suspect
will blow up in my face at some point in the future.

TIA


--
Joost Kremers
Life has its moments



Re: [O] Tables in Plain Lists

2012-05-17 Thread Joost Kremers
On Thu, May 17, 2012 at 12:24:22PM +0200, Gregor Zattler wrote:
 Really great.  This works for me with Emacs 23.4.1 and it's org
 version 6.33x, while not with the same Emacs and org-version
 7.8.10 (release_7.8.10-529-gc4cad9).  I copied the version info
 from the info file since org-version shows no
 version any more.

it works for me with:

Elisp emacs-version
24.1.50.1
Elisp org-version
7.8.09


-- 
Dr. Joost Kremers
Georg-August-Universität
Seminar für Deutsche Philologie
Käte-Hamburger-Weg 3
D-37073 Göttingen



Re: [O] Tables in Plain Lists

2012-05-16 Thread Joost Kremers
On Wed, May 16, 2012 at 12:14:45PM -0400, Bernt Hansen wrote:
 SW sabrewo...@gmail.com writes:
 
  I was making notes today as follows:
 
  ==
 
  * List of important items [0%]
  - [ ] Item 1
- This is an important item.
- Remember to do the hokey-pokey.
 
  |---|---|
  | A | B |
  | C | D |
 
  - [ ] Item 2
- This is not as important.
 
  ==
 
  Of course, the plain list terminates when the table starts, so TAB on 
  Item 1
  only collapses it to where the table starts. Also, the table can't be 
  indented
  as part of the list. In the end, I moved the table elsewhere, but for future
  reference, is there a preferred way to do this?
 
 TAB won't indent it but you can use the rectable C-x r o to shift it
 right so it is part of the list.

actually, IME, if you select the table and then hit tab, it does indent.

-- 
Dr. Joost Kremers
Georg-August-Universität
Seminar für Deutsche Philologie
Käte-Hamburger-Weg 3
D-37073 Göttingen



Re: [O] Tables in Plain Lists

2012-05-16 Thread Joost Kremers
On Wed, May 16, 2012 at 07:13:36PM +, SW wrote:
 Emacs 23.2.1 with org 7.8.06. Tested with transient-mark-mode enabled and
 disabled. I selected the table and hit TAB. Point moved by one tab (if I
 selected from the top to the bottom of the table) or moved into the table (if 
 I
 selected the other way round) and, in the one instance, the highlight on the
 region disappeared. But the table remained obstinately unindented.

the trick is to move point to the line *below* the table. TAB will then do
whatever it does on that line and if it happens to be an empty line or a
line with ordinary text, it indents, taking the entire region (including
the table) with it.

in essence, TAB will do whatever TAB does, regardless of whether the region
is active. so if point is still within the table, TAB moves to the next
cell, possibly creating a new one. if the line after the table contains a
headline and you move point to it, it (un)folds the headline. so you need
to make sure TAB is on a line that it indents.

-- 
Dr. Joost Kremers
Georg-August-Universität
Seminar für Deutsche Philologie
Käte-Hamburger-Weg 3
D-37073 Göttingen



Re: [O] Org-drill doesn't work...

2012-01-06 Thread Joost Kremers
On Fri, Jan 06, 2012 at 09:27:53PM +0100, Milan Zamazal wrote:
 It may happen if there is some problem with the contents of the entries
 (unrecognized items are silently skipped).  I was hit by a similar
 problem but once I realized what's wrong, org-drill started to work
 perfectly for me.

thanks for you reply. it prompted me to look a bit closer at the ignored items
and i've now figured out what was wrong with them... it turns out that it is
absolutely necessary that there is some text after the header of a drill item,
before the first subheader. most of my items lacked this, however. my items
looked like this:

#+BEGIN_EXAMPLE

** Verb:drill:

   :PROPERTIES:
   :DRILL_CARD_TYPE: twosided
   :END:

*** Deutsch

some German verb

*** Russisch

Russian translation

#+END_EXAMPLE

however, they need to look like this:

#+BEGIN_EXAMPLE

** Verb:drill:

   :PROPERTIES:
   :DRILL_CARD_TYPE: twosided
   :END:

   some text here   = absolutely essential!

*** Deutsch

some German verb

*** Russisch

Russian translation

#+END_EXAMPLE

what is inconsistent about the way org-drill handles these is that even though
it doesn't use these faulty entries for drilling, it *does* provide them with a
unique :ID: property. so initially it doesn't look like there's anything wrong
with them...

i also didn't find an explicit mention of this in the docs, so perhaps i should
send an email to paul sexton...

but yes, now that i've figured out what i was doing wrong, org-drill works 
great!

-- 
Joost Kremers
Life has its moments



Re: [O] Org-drill doesn't work...

2012-01-05 Thread Joost Kremers
On Wed, Dec 28, 2011 at 10:21:30PM +0100, Milan Zamazal wrote:
 This is all right.  You've just learned all the items and there is
 nothing to learn/repeat now.  Nor tomorrow, there is minimum amount of 4
 days by default before you are prompted for the same item again

ah, i see. silly me, i should have read that in the docs...

 (I
 believe you can customize the interval with
 org-drill-sm5-initial-interval).  In the meantime you can add and train
 new entries. :-)

but org-drill isn't picking up the new entries. i've added a bunch of new
entries to the file and they've all been given an :ID: property, but they are
not being drilled. i'm sure i'm doing something wrong here, but i can't figure
out what...

-- 
Joost Kremers
Life has its moments



[O] Org-drill doesn't work...

2011-12-14 Thread Joost Kremers
hi all,

i'm trying to set up org-drill for learning some russian vocabulary, but i'm not
very successful... i've created an org file that meets the requirements of a
proper org-drill file. i have a bunch of entries that look like this:

#+BEGIN_EXAMPLE

** Nomen  :drill:

   :PROPERTIES:
   :DRILL_CARD_TYPE: twosided
   :ID:   9927d8c4-1692-4784-9afc-9e4a770a62c8
   :END:

*** Deutsch

Herbst

*** Russisch

о́сень (f)

*** Beispiele

im *Herbst*
о́сенью

nächsten *Herbst*
сле́дующей *о́сенью*

letzten *Herbst*
про́шлой о́сенью

#+END_EXAMPLE

of course, the ID was added by org-drill, not by me. after creating the file,
the first run of org-drill seemed to be fine. i was prompted for a couple of
items, maybe five or so, and after i had finished, emacs told me the results.

however, trying to run org-drill the next day, i got the following message:

#+BEGIN_EXAMPLE

0 items reviewed. Session duration 0:00:00.
Recall of reviewed items:
 Excellent (5):   0%   |   Near miss (2):0%
 Good (4):0%   |   Failure (1):  0%
 Hard (3):0%   |   Abject failure (0):   0%

You successfully recalled 0% of reviewed items (quality  2)
0/1 items still await review (0 failed, 0 overdue, 0 new, 0 young, 0 old).
Tomorrow, 0 more items will become due for review.
Session finished. Press a key to continue...

#+END_EXAMPLE

i wasn't prompted for any new items and the message tomorrow, 0 more items will
become due for review worries me.

also, running org-drill-again gives me the same message.

i'm sure i'm doing something wrong, but i can't figure out what... would
appriciate any help pointing me in the right direction.

Org-mode version 7.8.02 (and org-drill included with it), GNU Emacs 23.3.1.

TIA

Joost


btw, i noticed that some of the customize items in org-drill.el are incorrectly
defined. for example, the :type declaration in
org-drill-spaced-repetition-algorithm is:

  :type '(choice (const 'sm2) (const 'sm5) (const 'simple8))

but the symbols shouldn't be quoted:

  :type '(choice (const sm2) (const sm5) (const simple8))

there are one or two more cases like this. they're labelled in the customize
buffer as MISMATCH.

-- 
Dr. Joost Kremers
Georg-August-Universität
Seminar für Deutsche Philologie
Käte-Hamburger-Weg 3
D-37073 Göttingen



  1   2   >