emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Babel Forth
@ 2025-01-22 20:41 Thomas S. Dye
  2025-01-23  8:16 ` Joost Kremers
  2025-01-23 19:29 ` Ihor Radchenko
  0 siblings, 2 replies; 8+ messages in thread
From: Thomas S. Dye @ 2025-01-22 20:41 UTC (permalink / raw)
  To: emacs-orgmode

Aloha all,

I'm drafting ob-doc-forth.org and haven't been able to get 
ob-forth.el to recognize a working GForth in Spacemacs.  I get 
"Symbol's function definition is void: forth-proc" when I evaluate 
a Forth source block.

In ob-forth.el there is this: (declare-function forth-proc 
"ext:gforth" ())

My hunch is that the ext: part of ext:gforth expects that 
forth-mode is setup to use the forth-mode distributed with GForth. 
Spacemacs appears to use forth-mode from Elpa, instead, and I find 
forth-mode.el in the elpa subdirectory of my Spacemacs.

I don't program in Forth and given my limited grasp of elisp, I 
don't look forward to debugging this just to draft some 
documentation, so I'd like to ask for help.

Have I diagnosed the problem correctly?

If so, could ob-forth.el be patched to enable all Emacs 
users--plain, Spacemacs, Doom, Prelude, Scimax, etc.--to evaluate 
Forth code blocks?  Or, should ob-doc-forth give instructions how 
to setup forth-mode to use the one distributed with GForth?

What is the best way forward here?

All the best,
Tom
-- 
Thomas S. Dye
https://tsdye.online/tsdye


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

* Re: Babel Forth
  2025-01-22 20:41 Babel Forth Thomas S. Dye
@ 2025-01-23  8:16 ` Joost Kremers
  2025-01-23  8:22   ` Joost Kremers
  2025-01-23 18:36   ` Thomas S. Dye
  2025-01-23 19:29 ` Ihor Radchenko
  1 sibling, 2 replies; 8+ messages in thread
From: Joost Kremers @ 2025-01-23  8:16 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: emacs-orgmode

On Wed, Jan 22 2025, Thomas S. Dye wrote:
> Aloha all,
>
> I'm drafting ob-doc-forth.org and haven't been able to get ob-forth.el to
> recognize a working GForth in Spacemacs.  I get "Symbol's function
> definition is void: forth-proc" when I evaluate a Forth source block.
>
> In ob-forth.el there is this: (declare-function forth-proc "ext:gforth" ())
>
> My hunch is that the ext: part of ext:gforth expects that forth-mode is
> setup to use the forth-mode distributed with GForth.

No. `declare-function` doesn't do anything except silence the
byte-compiler. It's used when you use a function in your Elisp source that
may not be loaded into your running Emacs session while editing the .el
file. In such a case, the byte compiler cannot find the function, so it
issues a warning. With `declare-function`, you tell the byte compiler where
to look for the function. The prefix "ext:" indicates that the file is an
external file (i.e., doesn't come with Emacs), so it may not even be found
at all, and that if that happens, the byte compiler still shouldn't complain.

The important thing to note is that `declare-function` doesn't make the
function available for *running* the code, it really is meant *just* for
the byte compiler. To make sure `gforth.el` is loaded, you need to use a
`require` in your source code.

> Spacemacs appears to
> use forth-mode from Elpa, instead, and I find forth-mode.el in the elpa
> subdirectory of my Spacemacs.

The `declare-function` call says that `forth-proc` can be found in
`gforth.el`, so the fact that you have `forth-mode.el` installed is
(probably) irrelevant. What you need is the file `gforth.el`. Where it
comes from is irrelevant, it just needs to be on Emacs' `load-path`. (And
it needs to actually provide `forth-proc`, of course, and make it
autoloadable, but I assume that's the case.)

What I don't understand, though, is why there's no `(require 'gforth)` in
`ob-forth.el`. It seems that `forth-proc` is essential for running Forth
source blocks, so a `require` seems in order.

The point is that `declare-function` is usually only used to declare
functions that are optional, meaning that `ob-forth.el` should check if
it's available and gracefully handle the case where it's not.

> What is the best way forward here?

What does the documentation for `ob-forth.el` say? Does it say `gforth.el`
needs to be installed? Otherwise perhaps ask the Org mailing list or the
ob-forth maintainer directly?

-- 
Joost Kremers
Life has its moments


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

* Re: Babel Forth
  2025-01-23  8:16 ` Joost Kremers
@ 2025-01-23  8:22   ` Joost Kremers
  2025-01-23 18:36   ` Thomas S. Dye
  1 sibling, 0 replies; 8+ messages in thread
From: Joost Kremers @ 2025-01-23  8:22 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: emacs-orgmode

On Thu, Jan 23 2025, Joost Kremers wrote:
> On Wed, Jan 22 2025, Thomas S. Dye wrote:
>> What is the best way forward here?
>
> What does the documentation for `ob-forth.el` say? Does it say `gforth.el`
> needs to be installed? Otherwise perhaps ask the Org mailing list

Oh, silly me, this *is* the Org mailing list... :D I thought I was still
reading help-gnu-emacs...


-- 
Joost Kremers
Life has its moments


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

* Re: Babel Forth
  2025-01-23  8:16 ` Joost Kremers
  2025-01-23  8:22   ` Joost Kremers
@ 2025-01-23 18:36   ` Thomas S. Dye
  2025-01-23 19:13     ` Ihor Radchenko
  1 sibling, 1 reply; 8+ messages in thread
From: Thomas S. Dye @ 2025-01-23 18:36 UTC (permalink / raw)
  To: Joost Kremers; +Cc: emacs-orgmode

Joost Kremers <joostkremers@fastmail.fm> writes:

> The `declare-function` call says that `forth-proc` can be found 
> in
> `gforth.el`, so the fact that you have `forth-mode.el` installed 
> is
> (probably) irrelevant. What you need is the file `gforth.el`. 
> Where it
> comes from is irrelevant, it just needs to be on Emacs' 
> `load-path`. (And
> it needs to actually provide `forth-proc`, of course, and make 
> it
> autoloadable, but I assume that's the case.)
>
> What I don't understand, though, is why there's no `(require 
> 'gforth)` in
> `ob-forth.el`. It seems that `forth-proc` is essential for 
> running Forth
> source blocks, so a `require` seems in order.
>
> The point is that `declare-function` is usually only used to 
> declare
> functions that are optional, meaning that `ob-forth.el` should 
> check if
> it's available and gracefully handle the case where it's not.
>
>> What is the best way forward here?
>
> What does the documentation for `ob-forth.el` say? Does it say 
> `gforth.el`
> needs to be installed? Otherwise perhaps ask the Org mailing 
> list or the
> ob-forth maintainer directly?

No one is maintaining ob-forth.el.

I found gforth.el in emacs/site-lisp and confirm that forth-proc 
is there.

Here is the relevant part of ob-forth.el:

    ;; Requires the gforth forth compiler and `forth-mode' (see 
    below).
    ;; https://www.gnu.org/software/gforth/

    ;;; Requirements:

    ;; Session evaluation requires the gforth forth compiler as 
    well as
    ;; `forth-mode' which is distributed with gforth (in 
    gforth.el).

    ;;; Code:

    (require 'org-macs)
    (org-assert-version)

    (require 'ob)
    (require 'org-macs)

    (declare-function forth-proc "ext:gforth" ())

It does not (require 'gforth), but strangely (to me) requires 
org-macs twice.

Perhaps ob-forth.el is broken?

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye


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

* Re: Babel Forth
  2025-01-23 18:36   ` Thomas S. Dye
@ 2025-01-23 19:13     ` Ihor Radchenko
  0 siblings, 0 replies; 8+ messages in thread
From: Ihor Radchenko @ 2025-01-23 19:13 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: Joost Kremers, emacs-orgmode

"Thomas S. Dye" <tsd@tsdye.online> writes:

> It does not (require 'gforth), but strangely (to me) requires 
> org-macs twice.
>
> Perhaps ob-forth.el is broken?

No. gforth.el "provides" forth-mode feature, which we do require.
Everything should be fine in this regard.

See https://git.savannah.gnu.org/cgit/gforth.git/tree/gforth.el

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


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

* Re: Babel Forth
  2025-01-22 20:41 Babel Forth Thomas S. Dye
  2025-01-23  8:16 ` Joost Kremers
@ 2025-01-23 19:29 ` Ihor Radchenko
  2025-01-23 20:05   ` Thomas S. Dye
  2025-01-24  0:17   ` Thomas S. Dye
  1 sibling, 2 replies; 8+ messages in thread
From: Ihor Radchenko @ 2025-01-23 19:29 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: emacs-orgmode

"Thomas S. Dye" <tsd@tsdye.online> writes:

> My hunch is that the ext: part of ext:gforth expects that 
> forth-mode is setup to use the forth-mode distributed with GForth. 

Yes. Our policy is to support the official distribution when
possible. Supporting non-standard packages is optional.

> Spacemacs appears to use forth-mode from Elpa, instead, and I find 
> forth-mode.el in the elpa subdirectory of my Spacemacs.

I would be surprised if such a name clash happened on ELPA. Indeed, it
does not. There is no such package on ELPA. Nonstandard forth-mode that
overrides the official gforth distribution is on MELPA:
https://melpa.org/#/forth-mode

Overriding the namespace is a bug. It must be fixed on
https://github.com/larsbrinkhoff/forth-mode/ side.

> If so, could ob-forth.el be patched to enable all Emacs 
> users--plain, Spacemacs, Doom, Prelude, Scimax, etc.--to evaluate 
> Forth code blocks?  Or, should ob-doc-forth give instructions how 
> to setup forth-mode to use the one distributed with GForth?
>
> What is the best way forward here?

forth-mode from MELPA is grabbing the official namespace.
This problem has been reported in
https://github.com/larsbrinkhoff/forth-mode/issues/19 but was not acted
upon.

It is honestly not our job to fix such things. I suggest emphasizing
that ob-forth expects forth-mode distributed officially.

ob-forth broken with Spacemacs/Doom/etc is a problem of
Spacemacs/Doom/etc. Distributing a package does not follow the basic
lisp conventions is not nice.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


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

* Re: Babel Forth
  2025-01-23 19:29 ` Ihor Radchenko
@ 2025-01-23 20:05   ` Thomas S. Dye
  2025-01-24  0:17   ` Thomas S. Dye
  1 sibling, 0 replies; 8+ messages in thread
From: Thomas S. Dye @ 2025-01-23 20:05 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

Aloha Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> "Thomas S. Dye" <tsd@tsdye.online> writes:
>
>> My hunch is that the ext: part of ext:gforth expects that 
>> forth-mode is setup to use the forth-mode distributed with 
>> GForth. 
>
> Yes. Our policy is to support the official distribution when
> possible. Supporting non-standard packages is optional.
>
>> Spacemacs appears to use forth-mode from Elpa, instead, and I 
>> find 
>> forth-mode.el in the elpa subdirectory of my Spacemacs.
>
> I would be surprised if such a name clash happened on ELPA. 
> Indeed, it
> does not. There is no such package on ELPA. Nonstandard 
> forth-mode that
> overrides the official gforth distribution is on MELPA:
> https://melpa.org/#/forth-mode
>
> Overriding the namespace is a bug. It must be fixed on
> https://github.com/larsbrinkhoff/forth-mode/ side.
>
>> If so, could ob-forth.el be patched to enable all Emacs 
>> users--plain, Spacemacs, Doom, Prelude, Scimax, etc.--to 
>> evaluate 
>> Forth code blocks?  Or, should ob-doc-forth give instructions 
>> how 
>> to setup forth-mode to use the one distributed with GForth?
>>
>> What is the best way forward here?
>
> forth-mode from MELPA is grabbing the official namespace.
> This problem has been reported in
> https://github.com/larsbrinkhoff/forth-mode/issues/19 but was 
> not acted
> upon.

Eight years ago!

> It is honestly not our job to fix such things. I suggest 
> emphasizing
> that ob-forth expects forth-mode distributed officially.

OK, will do.

> ob-forth broken with Spacemacs/Doom/etc is a problem of
> Spacemacs/Doom/etc. Distributing a package does not follow the 
> basic
> lisp conventions is not nice.

Agreed.  Thanks for tracking this down.

I'll get rid of my Spacemacs Forth support and set it up manually 
instead.

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye


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

* Re: Babel Forth
  2025-01-23 19:29 ` Ihor Radchenko
  2025-01-23 20:05   ` Thomas S. Dye
@ 2025-01-24  0:17   ` Thomas S. Dye
  1 sibling, 0 replies; 8+ messages in thread
From: Thomas S. Dye @ 2025-01-24  0:17 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

Aloha Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> It is honestly not our job to fix such things. I suggest 
> emphasizing
> that ob-forth expects forth-mode distributed officially.

I pushed Forth documentation to the Worg repo, but saw a build 
error that I don't know how to fix.

Let me know if you have questions.

Tom
-- 
Thomas S. Dye
https://tsdye.online/tsdye


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

end of thread, other threads:[~2025-01-24  0:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-22 20:41 Babel Forth Thomas S. Dye
2025-01-23  8:16 ` Joost Kremers
2025-01-23  8:22   ` Joost Kremers
2025-01-23 18:36   ` Thomas S. Dye
2025-01-23 19:13     ` Ihor Radchenko
2025-01-23 19:29 ` Ihor Radchenko
2025-01-23 20:05   ` Thomas S. Dye
2025-01-24  0:17   ` Thomas S. Dye

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).