Re: Dynamic block tables: adding prefix of "id:" to %ID

[Kristian Grönberg]

Hi Karl,

> > Would it work for you to use the "<>"?
> > 

> > *** <> barheading
> > :PROPERTIES:
> > :ID: [[bar][barheading]]
> > :END:
> > /Kris
> 

> I'm afraid not because the dynamic block would duplicate the
> target definition and not generating a link.

OK, I see.
If you do find a solution in the future, I would be interested in getting to 
know it as well. Feel free to keep me posted.
Thank you.

signature.asc
Description: OpenPGP digital signature

Re: Dynamic block tables: adding prefix of "id:" to %ID

[Karl Voit]

Hi,

* Kristian Grönberg  wrote:
>
> I didn't read your question properly.
> Would it work for you to use the "<>"?
>
> *** <> barheading
>:PROPERTIES:
>:ID: [[bar][barheading]]
>:END:
>
> /Kris

I'm afraid not because the dynamic block would duplicate the
target definition and not generating a link. 

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Helo for defun/macro arguments list in minibuffer when in org-babel src blocks?

[Tim Cross]

Hi,

when you are editing source blocks are you using org-edit-special, 
normally
bound to C-c ') or are you just editing the source blocks directly 
within the

org buffer?

The functionality you are referring to sounds like eldoc minor 
mode.


If you open a dedicated buffer to edit a file in the same language 
as your
source blocks, do you see the behaviour you want. For example, 
open a file
called test.el and edit some Emacs lisp. If you don't see the 
behaviour your
after, you need to configure emacs-lisp-mode to load eldoc mode. 
Try typing M-x
eldoc-mode  and see if you then get the behaviour your after. 
If you do,

then read up on eldoc-mode and how to enable it.

The environment you get with a dedicated buffer and that you get 
with
org-edit-special should be roughly the same. So the trick is to 
get things
working how you like them using a dedicated *.el buffer and then 
use
org-edit-special whenever you need to edit source blocks. There is 
also another
good reason to use org-edit-special - there are some situations 
where org needs
to add some special escaping characters in source blocks to enable 
things to be
parsed correctly. Using org-edit-special ensures this occurs when 
necessary.

Editing the source blocks directly does not.

Arthur Miller  writes:

I have been doing quite some programming with elisp in org mode, 
and one
thing I am missing is this help that Emacs shows in minibuffer 
for
functions and macros. You can see the example in the attached 
image. I
am not sure what I have to enable (or disable? :)) to get it to 
work in

babel src blocks? Or is it even possible?

Some few days ago I stumbled on a blog post by J. Kitchin about 
enabling

orignal mode maps in src block:



That was another thing I was missing, and that one work really 
well.

Thank yuu John!

Can that hack be used to enable this help to pup up in 
minibuffer as
well. I am not familiar what causes that lookup, but I see it 
happends
even when Emacs is started with -Q option, so it is something 
built-in

and enabled by default, probably in elisp-mode itself.

Last thing I miss is company doing it's thing. I can complete by
pressing TAB, but I would still like it to happen automatically. 
Is it

just me being noob and not enabling something, or is it bit more
coplicated than so?

Sorry for the long writing, but basically what I ask is, can we 
get more

of usualy elisp stuff hanpening in babel src blocks?




Regards,

Tim

--
*Tim Cross*

/For gor sake stop laughing, this is serious!/

Helo for defun/macro arguments list in minibuffer when in org-babel src blocks?

[Arthur Miller]

I have been doing quite some programming with elisp in org mode, and one
thing I am missing is this help that Emacs shows in minibuffer for
functions and macros. You can see the example in the attached image. I
am not sure what I have to enable (or disable? :)) to get it to work in
babel src blocks? Or is it even possible?

Some few days ago I stumbled on a blog post by J. Kitchin about enabling
orignal mode maps in src block:

https://kitchingroup.cheme.cmu.edu/blog/2017/06/10/Adding-keymaps-to-src-blocks-via-org-font-lock-hook/

That was another thing I was missing, and that one work really well.
Thank yuu John! 

Can that hack be used to enable this help to pup up in minibuffer as
well. I am not familiar what causes that lookup, but I see it happends
even when Emacs is started with -Q option, so it is something built-in
and enabled by default, probably in elisp-mode itself.

Last thing I miss is company doing it's thing. I can complete by
pressing TAB, but I would still like it to happen automatically. Is it
just me being noob and not enabling something, or is it bit more
coplicated than so?

Sorry for the long writing, but basically what I ask is, can we get more
of usualy elisp stuff hanpening in babel src blocks? 

Best regards and thanks for help

Re: [PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066

[Timothy]

Marking as applied for updates.orgmode.org.

Nicolas Goaziou  writes:

> Thanks. I applied a slightly different fix.

--
Timothy

Re: [PATCH] ob-core: tangle check library of babel after current buffer

[Timothy]

Hi Tom,

Sorry that it's taken so long for someone to get to this. I've just
applied your patch to my local Org instance, and then tested the
described behaviour before and afterwards. I can confirm that the issue
reported exists, and that your patch fixes this.

In light of this and the two other positive reviews here, I feel it's
pretty safe, and so have applied this patch as f052acee5 :)

--
Timothy

Tom Gillespie  writes:

> Pinging on this to see if anyone can test it so that it can be merged.
> Tom
>
> On Wed, Jun 16, 2021 at 4:29 PM Tom Gillespie  wrote:
>>
>> Hi,
>>This is a patch that fixes tangling behavior when a block has been
>> ingested into the library of babel and then modified. Best!
>> Tom


--
Timothy

Re: Headings and Headlines

[Timothy]

André A. Gomes  writes:

> If the community finds this valuable, I could prepare a patch.

I think at this point the community view is pretty clearly in favour of
consolidating "headlines" to "headings".

I think at this stage a patch would be warranted. Should you still be
happy to make one that would be great, otherwise I might try whipping
one up.

--
Timothy

Re: Headings and Headlines

[Charles Millar]

On 7/23/21 10:06 PM, Tim Cross wrote:


André A. Gomes  writes:


Hi,

The project's documentation refers to headings and headlines as
synonyms.  Relying on a single definition would be beneficial.  If I had
to choose between the two, I'd go with heading.

If the community finds this valuable, I could prepare a patch.



I think heading is better than headline - to me headline is a line at
the top of the buffer (like a newpaper headline). Note that in addition
to changes in the manual, it will probably be necessary to make changes
to variable and function names in the code. This may require marking
some old names as obsolete and creating aliases to allow a transition to
the new names and avoid breakage etc.



Since org requires outline.el, org.el line 4793, why not follow and 
mirror outline.el conventions?


It appears that outline.el uses
`
"header" for some early set-up(?) functions and

"heading" for what appears to provide the outline itself.

Furthermore, "headline" shows up only in comments, and only four or five 
times, at that.


After all, org is an, "Outline-based notes management and organize."


Best,

Charlie Millar

Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual

[Tim Landscheidt]

Timothy  wrote:

> […]

>> The original footnote seems to have been added with commit
>> e30aed8f0c62e74633f7a0398340f9bd7bdfa3cc (but personally I
>> don't find that text very helpful).

> Do you think it would be more appropriate to update or remove the
> footnote?

AFAIUI, if LANGUAGE is set, for LaTeX export,
org-latex-package-alist *must* also be set/amended, so the
documentation of this relationship cannot be removed.

But some other minor nitpicks with that setting (from a non-
native speaker):

| - =LANGUAGE= ::

|   #+cindex: @samp{LANGUAGE}, keyword
|   #+vindex: org-export-default-language
|   Language to use for translating certain strings
|   (~org-export-default-language~).  With =#+LANGUAGE: fr=, for
|   example, Org translates =Table of contents= to the French =Table des
|   matières=[fn:122].

1. "Certain strings" is true, but which ones are they?
   Without the second sentence, I couldn't imagine what
   strings the documentation is talking about.  And does
   org-mode change user-supplied occurences of "Table of
   contents" to "Table des matières" as well?

2. Neither org-mode nor anything else is /translating/
   (how?) those strings.  Instead, one chooses the language
   for the name of the "Table of contents" section and
   others.

| - =LANGUAGE= ::
|   #+cindex: @samp{LANGUAGE}, keyword
|   #+vindex: org-latex-package-alist
|   In order to be effective, the =babel= or =polyglossia=
|   packages---according to the LaTeX compiler used---must be loaded
|   with the appropriate language as argument.  This can be accomplished
|   by modifying the =org-latex-package-alist= variable, e.g., with the
|   following snippet:
|
|   #+begin_src emacs-lisp
|   (add-to-list org-latex-package-alist
|'("AUTO" "babel" t ("pdflatex")))
|   (add-to-list org-latex-package-alist
|'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
|   #+end_src

3. General question: Why can't the requirement be automatic?
   E. g., if LANGUAGE != "en", use babel or polyglossia?

4. In org-latex-packages-alist (or
   org-latex-default-packages-alist), "AUTO" is not docu-
   mented, neither is OPTIONS in general.

5. My (rudimentary) understanding of LaTeX and babel &
   Co. is that one needs to use it with something like
   "\usepackage[english,german]{babel}".  The first sentence
   ("be loaded with the appropriate language as argument")
   seems to confirm that.  The second sentence says that
   "this" can be accomplished by the following snippet.
   However, there does not seem to be any argument that con-
   veys a language.  Does that happen automatically?  I. e.,
   does the snippet actually accomplish what it claims to?
   (I haven't tested this.)

Tim

Re: what would cause failure in template for org capture?

[Eric S Fraga]

On Saturday, 24 Jul 2021 at 10:37, Tim Cross wrote:
> My advice would be not to use native compilation. 

Probably good advice but, for me, native compilation has (generally)
been working very well and has had significant performance
improvement.  I use Emacs as my window manager (EXWM) and every little
bit of speed helps.

Yes, there are some issues and org-capture may be one of them.  As you
say in another followup, this is probably an Emacs bug and not for org.

thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Headings and Headlines

[Matt Price]

I don't really have a strong preference for either but I would love to
remove the cognitive load of wondering whether the name is heading or
header!

On Sat., Jul. 24, 2021, 12:04 a.m. Tom Gillespie,  wrote:

> I enthusiastically support changing the documentation to use heading.
> I use heading in my formal grammar because I have found there are more
> ways that it can be modified and remain grammatically correct when
> used in english sentences. The internal implementation in elisp still
> refers to headlines, but changing the docs would be a good first step.
> Best!
> Tom
>
>