all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* org-babel-load-file support elisp
@ 2020-02-03 17:30 Troy Hinckley
  2020-02-03 19:23 ` Bastien
  2020-02-12 21:42 ` Bastien
  0 siblings, 2 replies; 11+ messages in thread
From: Troy Hinckley @ 2020-02-03 17:30 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

I tracked down an issue trying to load a literate config file.
org-babel-load-file calls org-babel-tangle-file with lang set to
"emacs-lisp". This means that it won't tangle any blocks with language set
to "elisp", which is equivalent. I can't think of an easy way to fix this
since you would need to target both languages. Maybe at very least we could
add something to the doc string to draw attention to this limitation.

[-- Attachment #2: Type: text/html, Size: 475 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 17:30 org-babel-load-file support elisp Troy Hinckley
@ 2020-02-03 19:23 ` Bastien
  2020-02-03 22:08   ` Troy Hinckley
  2020-02-12 21:42 ` Bastien
  1 sibling, 1 reply; 11+ messages in thread
From: Bastien @ 2020-02-03 19:23 UTC (permalink / raw)
  To: Troy Hinckley; +Cc: emacs-orgmode

Hi Troy,

> I tracked down an issue trying to load a literate config file.
> org-babel-load-file calls org-babel-tangle-file with lang set to
> "emacs-lisp". This means that it won't tangle any blocks with
> language set to "elisp", which is equivalent. I can't think of an
> easy way to fix this since you would need to target both languages.
> Maybe at very least we could add something to the doc string to draw
> attention to this limitation. 

I think supporting "#+begin_src elisp" would be confusing but I agree
we could give a hint somewhere about this.

Can you suggest which docstring should be updated and how?

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 19:23 ` Bastien
@ 2020-02-03 22:08   ` Troy Hinckley
  2020-02-03 22:47     ` Tim Cross
  0 siblings, 1 reply; 11+ messages in thread
From: Troy Hinckley @ 2020-02-03 22:08 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

 > I think supporting "#+begin_src elisp" would be confusing

elisp is already supported in all other babel
functions. org-babel-load-file is the only function that makes a
distinction as far as I can tell. And since that function is outlier it
makes sense to document this limitation in its docstring.

Or even better would be to detect if the user had elisp blocks and throw
and error. Though I am not sure how to do that outside of seeing if
tangling elisp is successful.

-Troy Hinckley

On Feb 3, 2020, 12:23 PM -0700, Bastien <bzg@gnu.org>, wrote:

Hi Troy,

I tracked down an issue trying to load a literate config file.
org-babel-load-file calls org-babel-tangle-file with lang set to
"emacs-lisp". This means that it won't tangle any blocks with
language set to "elisp", which is equivalent. I can't think of an
easy way to fix this since you would need to target both languages.
Maybe at very least we could add something to the doc string to draw
attention to this limitation.


I think supporting "#+begin_src elisp" would be confusing but I agree
we could give a hint somewhere about this.

Can you suggest which docstring should be updated and how?

Thanks,

--
Bastien

[-- Attachment #2: Type: text/html, Size: 2062 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 22:08   ` Troy Hinckley
@ 2020-02-03 22:47     ` Tim Cross
       [not found]       ` <ZclaOPJYs9OChIJ0EmvuYezQf9yKAMMunMPz71gz74t9DKUs83QU20uf80bmCLIA8fvx-dQ_DP_89q6s5ddr1Q==@protonmail.internalid>
                         ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tim Cross @ 2020-02-03 22:47 UTC (permalink / raw)
  To: emacs-orgmode


I came across this inconsistency a while back. I think the problem is
that you should *not* be able to use elisp as a language specifier in
source blocks.

All other language specifiers comply to the pattern of source block
languages being the language major mode name without the '-mode', but
there is no elisp-mode.

The problem now is that removing support for 'elisp' would break too
much. So the question becomes 'Do we want to continue down this road and
if so, does it make sense to support 'elisp' as a synonym for emacs-lisp
in all places where specifying the language is used?'.


Troy Hinckley <troyhinckley@gmail.com> writes:

>  > I think supporting "#+begin_src elisp" would be confusing
>
> elisp is already supported in all other babel
> functions. org-babel-load-file is the only function that makes a
> distinction as far as I can tell. And since that function is outlier it
> makes sense to document this limitation in its docstring.
>
> Or even better would be to detect if the user had elisp blocks and throw
> and error. Though I am not sure how to do that outside of seeing if
> tangling elisp is successful.
>
> -Troy Hinckley
>
> On Feb 3, 2020, 12:23 PM -0700, Bastien <bzg@gnu.org>, wrote:
>
> Hi Troy,
>
> I tracked down an issue trying to load a literate config file.
> org-babel-load-file calls org-babel-tangle-file with lang set to
> "emacs-lisp". This means that it won't tangle any blocks with
> language set to "elisp", which is equivalent. I can't think of an
> easy way to fix this since you would need to target both languages.
> Maybe at very least we could add something to the doc string to draw
> attention to this limitation.
>
>
> I think supporting "#+begin_src elisp" would be confusing but I agree
> we could give a hint somewhere about this.
>
> Can you suggest which docstring should be updated and how?
>
> Thanks,


--
Tim Cross

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 22:47     ` Tim Cross
       [not found]       ` <ZclaOPJYs9OChIJ0EmvuYezQf9yKAMMunMPz71gz74t9DKUs83QU20uf80bmCLIA8fvx-dQ_DP_89q6s5ddr1Q==@protonmail.internalid>
@ 2020-02-04  6:03       ` Jack Kamm
  2020-02-04  6:29         ` Tim Cross
  2020-02-04 17:57         ` Berry, Charles via General discussions about Org-mode.
  2020-02-10  7:25       ` Bastien
  2 siblings, 2 replies; 11+ messages in thread
From: Jack Kamm @ 2020-02-04  6:03 UTC (permalink / raw)
  To: Tim Cross, emacs-orgmode

Tim Cross <theophilusx@gmail.com> writes:

> All other language specifiers comply to the pattern of source block
> languages being the language major mode name without the '-mode', but
> there is no elisp-mode.

Sorry to be pedantic, but I think shell source blocks are another
exception here. They can use various synonyms for the source language,
such as "shell", "sh", or any other name in org-babel-shell-names. Also,
while "shell-mode" is a major-mode, it is not the mode used by the
source buffer -- it is the mode used for the interactive shell created
by the `shell' command.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-04  6:03       ` Jack Kamm
@ 2020-02-04  6:29         ` Tim Cross
  2020-02-04 17:57         ` Berry, Charles via General discussions about Org-mode.
  1 sibling, 0 replies; 11+ messages in thread
From: Tim Cross @ 2020-02-04  6:29 UTC (permalink / raw)
  To: Jack Kamm; +Cc: emacs-orgmode


Well there are exceptions to all rules aren't there?

Yes, strictly speaking, for shell scripts, only 'sh' fits with the
<lang>-mode rule. However, that mode is also slightly different from
other language modes in that it supports many shell 'dialects'.

The thing is, the more 'liberal' we are with what we allow as the name
of the source block language, the more complex any additional
functionality becomes - I think your original issue is an example of
this. Allowing 'elisp' seem reasonable, but then other functions which
work with source blocks now also need to know that 'elisp' is an alias
for 'emacs-lisp'.

There are probably other inconsistencies which will 'fail' in some
situations. For example, I wonder about 'javascript' and 'js2'.
Jack Kamm <jackkamm@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> All other language specifiers comply to the pattern of source block
>> languages being the language major mode name without the '-mode', but
>> there is no elisp-mode.
>
> Sorry to be pedantic, but I think shell source blocks are another
> exception here. They can use various synonyms for the source language,
> such as "shell", "sh", or any other name in org-babel-shell-names. Also,
> while "shell-mode" is a major-mode, it is not the mode used by the
> source buffer -- it is the mode used for the interactive shell created
> by the `shell' command.


--
Tim Cross

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-04  6:03       ` Jack Kamm
  2020-02-04  6:29         ` Tim Cross
@ 2020-02-04 17:57         ` Berry, Charles via General discussions about Org-mode.
  1 sibling, 0 replies; 11+ messages in thread
From: Berry, Charles via General discussions about Org-mode. @ 2020-02-04 17:57 UTC (permalink / raw)
  To: Jack Kamm; +Cc: Tim Cross, emacs-orgmode@gnu.org



> On Feb 3, 2020, at 10:03 PM, Jack Kamm <jackkamm@gmail.com> wrote:
> 
> Tim Cross <theophilusx@gmail.com> writes:
> 
>> All other language specifiers comply to the pattern of source block
>> languages being the language major mode name without the '-mode', but
>> there is no elisp-mode.
> 
> Sorry to be pedantic, but I think shell source blocks are another
> exception here. 

[snip]

FWIW, so are R and julia (ess-r-mode, ess-julia-mode) and c++ (cc-mode).

I suspect more examples are "out there".

Chuck

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 22:47     ` Tim Cross
       [not found]       ` <ZclaOPJYs9OChIJ0EmvuYezQf9yKAMMunMPz71gz74t9DKUs83QU20uf80bmCLIA8fvx-dQ_DP_89q6s5ddr1Q==@protonmail.internalid>
  2020-02-04  6:03       ` Jack Kamm
@ 2020-02-10  7:25       ` Bastien
  2020-02-10  8:00         ` Norman Tovey-Walsh
  2 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2020-02-10  7:25 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-orgmode

Hi Tim and Troy,

Tim Cross <theophilusx@gmail.com> writes:

> I came across this inconsistency a while back. I think the problem is
> that you should *not* be able to use elisp as a language specifier in
> source blocks.
>
> All other language specifiers comply to the pattern of source block
> languages being the language major mode name without the '-mode', but
> there is no elisp-mode.
>
> The problem now is that removing support for 'elisp' would break too
> much.

What I suggest for this particular issue is this: first be liberal
while staying consistent (thus allowing "elisp" as Troy suggest),
then be strict when a major release is issued (thus removing aliases
that are problematic, not just "elisp" but others.)

WDYT?  Troy, would you be able to prepare a patch for this?

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-10  7:25       ` Bastien
@ 2020-02-10  8:00         ` Norman Tovey-Walsh
  0 siblings, 0 replies; 11+ messages in thread
From: Norman Tovey-Walsh @ 2020-02-10  8:00 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

>> The problem now is that removing support for 'elisp' would break too
>> much.
>
> What I suggest for this particular issue is this: first be liberal
> while staying consistent (thus allowing "elisp" as Troy suggest),
> then be strict when a major release is issued (thus removing aliases
> that are problematic, not just "elisp" but others.)
>
> WDYT?  Troy, would you be able to prepare a patch for this?

My 2¢ from the peanut gallery.

Generally speaking, I’m in favor of consistency. A couple of months ago,
I stumbled over the fact that ‘elisp’ seemed to do syntax highlighting
correctly but didn’t tangle. I didn’t, at the time, work out the cause
of the problem, I just learned to use ‘emacs-lisp’ as the language name.

Looking at this thread, it seems like there are a bunch of exceptions to
the rule that the language is be the name of the mode without ‘-mode’.

Just off the top of my head, I can think of several languages supported
by multiple modes. If the rule is that the language is the mode name,
then if I use ‘extra-special-language-mode’ to edit ‘language’, do I
have to use ‘extra-special-language’ as the language name? Is that going
to seem natural? What burden does that put on the developer of
‘extra-special-language-mode’ to make tangle and other Org-mode features
work like they would for ‘language-mode’?

I wonder if it makes more sense to invent a mechanism for assigning
language synonyms that can be used throughout Org?

                                        Be seeing you,
                                          norm

P.S. Just to prove I can play devil’s advocate, I’m very conscious of
the fact that a few days ago, I invented an ‘xproc-mode’ as a vacuous
extension to ‘xml-mode’ precisely *because* I wanted to define different
org-babel-execute behavior.

--
Norman Tovey-Walsh <ndw@nwalsh.com> | Some disguised deceits
https://nwalsh.com/                 | counterfeit truth so perfectly
                                    | that not to be taken in by them
                                    | would be an error of
                                    | judgment.--La Rochefoucauld

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-03 17:30 org-babel-load-file support elisp Troy Hinckley
  2020-02-03 19:23 ` Bastien
@ 2020-02-12 21:42 ` Bastien
  2020-02-12 22:18   ` Troy Hinckley
  1 sibling, 1 reply; 11+ messages in thread
From: Bastien @ 2020-02-12 21:42 UTC (permalink / raw)
  To: Troy Hinckley; +Cc: emacs-orgmode

Hi Troy,

Troy Hinckley <troyhinckley@gmail.com> writes:

> I tracked down an issue trying to load a literate config file.
> org-babel-load-file calls org-babel-tangle-file with lang set to
> "emacs-lisp". This means that it won't tangle any blocks with
> language set to "elisp", which is equivalent.

This is now fixed in master, will be in Org 9.4.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-babel-load-file support elisp
  2020-02-12 21:42 ` Bastien
@ 2020-02-12 22:18   ` Troy Hinckley
  0 siblings, 0 replies; 11+ messages in thread
From: Troy Hinckley @ 2020-02-12 22:18 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Wow. Thanks for the quick resolution!
On Feb 12, 2020, 2:42 PM -0700, Bastien <bzg@gnu.org>, wrote:
> Hi Troy,
>
> Troy Hinckley <troyhinckley@gmail.com> writes:
>
> > I tracked down an issue trying to load a literate config file.
> > org-babel-load-file calls org-babel-tangle-file with lang set to
> > "emacs-lisp". This means that it won't tangle any blocks with
> > language set to "elisp", which is equivalent.
>
> This is now fixed in master, will be in Org 9.4.
>
> --
> Bastien

[-- Attachment #2: Type: text/html, Size: 1045 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-02-12 22:18 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-03 17:30 org-babel-load-file support elisp Troy Hinckley
2020-02-03 19:23 ` Bastien
2020-02-03 22:08   ` Troy Hinckley
2020-02-03 22:47     ` Tim Cross
     [not found]       ` <ZclaOPJYs9OChIJ0EmvuYezQf9yKAMMunMPz71gz74t9DKUs83QU20uf80bmCLIA8fvx-dQ_DP_89q6s5ddr1Q==@protonmail.internalid>
2020-02-04  6:03       ` Jack Kamm
2020-02-04  6:29         ` Tim Cross
2020-02-04 17:57         ` Berry, Charles via General discussions about Org-mode.
2020-02-10  7:25       ` Bastien
2020-02-10  8:00         ` Norman Tovey-Walsh
2020-02-12 21:42 ` Bastien
2020-02-12 22:18   ` Troy Hinckley

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.