What do you think of the idea of having an emacs and org-mode equivalent
to gopher/gemini - a simple hypertext web where all the files are org
documents that link to other org documents? Has somone already done that?

The servers wouldn't have to do more than serve plain text files via
http, but maybe having some publication features from within emacs would
be nice (e.g., a command to copy or link the file to the server).

It would probably need a new URL method like org-http://, because
http:// is likely to try loading it in a web browser expecting html.
But maybe emacs and/or eww could be extended to handle a response type
of text/org?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Christie <shcv@sdf.org> writes:

What do you think of the idea of having an emacs and org-mode equivalent
to gopher/gemini - a simple hypertext web where all the files are org documents that link to other org documents? Has somone already done
that?

I'd give it a try if it were available, but I'm not sure if there are
enough possible users to make the effort worth-while.

The servers wouldn't have to do more than serve plain text files via
http, but maybe having some publication features from within emacs would
be nice (e.g., a command to copy or link the file to the server).

It would probably need a new URL method like org-http://, because
http:// is likely to try loading it in a web browser expecting html.
But maybe emacs and/or eww could be extended to handle a response type
of text/org?

I'd use a URL that matches the spec and I don't think '-' is allowed.
Emacs would have to map the URL to something a server could understand
and I think I'd want the underlying protocol to be https.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Christie <shcv@sdf.org> writes:

What do you think of the idea of having an emacs and org-mode equivalent
to gopher/gemini - a simple hypertext web where all the files are org documents that link to other org documents? Has somone already done that?

The servers wouldn't have to do more than serve plain text files via
http, but maybe having some publication features from within emacs would
be nice (e.g., a command to copy or link the file to the server).

It would probably need a new URL method like org-http://, because
http:// is likely to try loading it in a web browser expecting html.
But maybe emacs and/or eww could be extended to handle a response type
of text/org?

From management perspective there is a built-in feature called org-publish-project-alist. I use it for my little website
codeisgreat.org. I keep all the files in org mode and then run the
built-in export functionality to output content in HTML. It keeps all
the org interlinks intact. Here is my .dir-locals.el configuration for
the same,

--8<---------------cut here---------------start------------->8---
((nil
.
((mode . auto-fill)
(org-publish-project-alist
.
(("pages"
:base-directory "~/work/personal/codeisgreat/src/"
:publishing-directory "~/work/personal/codeisgreat/docs/"
:publishing-function org-html-publish-to-html
:html-head "<link rel=\"stylesheet\" type=\"text/css\" href=\"css/main.css\" />"
:with-toc nil
:html-preamble nil
:html-postamble t
:html-postamble-format (("en" "<p class=\"creator\">Created with %c</p>"))
:section-numbers nil
:html-indent t)
("notes"
:base-directory "~/work/personal/codeisgreat/src/notes"
:publishing-directory "~/work/personal/codeisgreat/docs/notes"
:publishing-function org-html-publish-to-html
:html-head "<link rel=\"stylesheet\" type=\"text/css\" href=\"../css/main.css\" />"
:with-toc nil
:html-preamble nil
:html-postamble t
:html-postamble-format (("en" "<p class=\"creator\">Created with %c</p>"))
:section-numbers nil
:html-indent t)
("css"
:base-directory "~/work/personal/codeisgreat/src/css"
:base-extension "css"
:publishing-directory "~/work/personal/codeisgreat/docs/css"
:publishing-function org-publish-attachment)
("images"
:base-directory "~/work/personal/codeisgreat/src/images"
:base-extension "jpeg\\|jpg\\|gif\\|png"
:publishing-directory "~/work/personal/codeisgreat/docs/images"
:publishing-function org-publish-attachment)
("other"
:base-directory "~/work/personal/codeisgreat/src/other"
:publishing-directory "~/work/personal/codeisgreat/docs/other"
:publishing-function org-publish-attachment)
("website"
:components ("pages" "notes" "images" "css" "other"))))))) --8<---------------cut here---------------end--------------->8---

Then I use org-publish from one of the source files,

--8<---------------cut here---------------start------------->8---
‘C-c C-e P p’ (‘org-publish-current-project’)
Publish the project containing the current file.
--8<---------------cut here---------------end--------------->8---

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to RFC3986,

scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

So '-' is allowed, but now that I think about it, I've seen more
compound schemes written with '+', so 'org+https://' would probably be better...
Of course, other lookup schemes could also be used, e.g. ipfs, ftp, news, etc.

But as always, the real hurdles are publication and discovery... maybe
it could be bootstrapped with a pastebin-style service with search, and
then an announce API so you can publish elsewhere but still get in the
search engine. IPFS might be better for storage.

I could actually see it being pretty useful as a more open and
extensible alternative to the Library of Babel[0] - easily sharing,
reading, and loading babel snippets could be pretty powerful.

---
[0]. https://orgmode.org/worg/library-of-babel.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pankaj Jangid <pankaj@xyz.invalid> writes:

From management perspective there is a built-in feature called org-publish-project-alist. I use it for my little website
codeisgreat.org. I keep all the files in org mode and then run the
built-in export functionality to output content in HTML. It keeps all
the org interlinks intact.

I agree that's probably the best way to share org content right now.

However, I was thinking it would be nice to be able to load org-mode
files with all of the functionality intact (and without needing an
external web browser or clunky html renderer for viewing from emacs); potentially even inclusion into agenda views etc. I'm not sure how much additional work would be required for that beyond the simple idea of
viewing remote org files though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Christie <shcv@sdf.org> writes:

According to RFC3986,

scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

So '-' is allowed, but now that I think about it, I've seen more
compound schemes written with '+', so 'org+https://' would probably be better...

Didn't know that. Thanks. Should have looked it up first!

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 01 Oct 2022 00:40:43 +0100, Ben Bacarisse wrote:

Samuel Christie <shcv@sdf.org> writes:

What do you think of the idea of having an emacs and org-mode
equivalent to gopher/gemini - a simple hypertext web where all the
files are org documents that link to other org documents? Has somone
already done that?

I'd give it a try if it were available, but I'm not sure if there are
enough possible users to make the effort worth-while.

The servers wouldn't have to do more than serve plain text files via
http, but maybe having some publication features from within emacs
would be nice (e.g., a command to copy or link the file to the server).

It would probably need a new URL method like org-http://, because
http:// is likely to try loading it in a web browser expecting html.
But maybe emacs and/or eww could be extended to handle a response type
of text/org?

I'd use a URL that matches the spec and I don't think '-' is allowed.
Emacs would have to map the URL to something a server could understand
and I think I'd want the underlying protocol to be https.

I think the idea is cool. and im sure it wouldn't be hard to do given the
fact that gemini exist. i never liked the idea of using markdown just due
to being used to org-mode.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Es schrieb Samuel Christie <shcv@sdf.org> am 30.09.22 um 10.02 Uhr:

What do you think of the idea of having an emacs and org-mode equivalent
to gopher/gemini - a simple hypertext web where all the files are org documents that link to other org documents? Has somone already done
that?

I realize this was written last year, but anyway. Two years ago I wrote
some code that makes Elpher open org-mode files served via Gemini as
read-only Org. Not exactly what you want, but maybe close enough without inventing a new protocol?

gemini://mederle.de/b/02-emacs-org-and-gemini.gmi

Seems to still work on Emacs 29.

Cheers,
Wolfgang

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hmmmmm...

- Can elpher and eww be merged?

- Can both (or the merged result) be taught to display org texts?

- Can we be sure source blocks will stay passive?
That'd be like unsandboxed JS.

I'm not a fan of this brave new one browser per protocol world.
Full-fat browsers now even drop FTP and more Smallnet browsers that only support one protocol exist than multi-protocol solutions, ... this all
was meant differently when browsers were a new thing:

One lens to view them all.

To keep future browsers that really deserve that name (in contrast to
networked single protocol file viewers) not so bloated, they just should
be the place where protocol and rendering plugins meet in a shared UI
frontend. So whoever wants a single protocol solution with only some
markups just would not install all plugins.

Emacs seems a good place to start all this?
Too nostalgic?
Too naive?

--
This stealth signature intentionally left blank.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

WM <walthervondervogelweide@gmx.de> writes:

Es schrieb Samuel Christie <shcv@sdf.org> am 30.09.22 um 10.02
Uhr:

What do you think of the idea of having an emacs and org-mode
equivalent to gopher/gemini - a simple hypertext web where all
the files are org documents that link to other org documents?
Has somone already done that?

I realize this was written last year, but anyway. Two years ago
I wrote some code that makes Elpher open org-mode files served
via Gemini as read-only Org. Not exactly what you want, but
maybe close enough without inventing a new protocol?

gemini://mederle.de/b/02-emacs-org-and-gemini.gmi

Seems to still work on Emacs 29.

Coincidentally, I happen to be checking Usenet again for the first
time in a while. (I had been using AIOE before, and got
disconnected when they went down.)

That idea is pretty cool; I do agree it's easier to build on
existing protocols than necessarily making a new one. A subset of
HTTP would probably work too (only need to implement GET, etc.).

It would be neat if we could dispatch to the appropriate viewer
based on the response content-type, perhaps in a similar way to
how some browsers have different viewers for html vs json, xml, or
pdf files these days. However, I had been expecting that the
dispatch was handled at the org-mode link layer, and therefore
using "org+http://" would be a good way to tell it "fetch with
http, but use org-mode to view the file".

But since your solution already exists, maybe that's the way to start.
Probably just need a few more tools to support publishing files and
sharing the elpher extension, and then trying to build a community that
uses it. Possibly by making a shared host that anyone can easily push a
file to with a simple emacs command.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

yeti <yeti@tilde.institute> writes:

Hmmmmm...

- Can elpher and eww be merged?

An interesting idea. Maybe it could be done through a generalized
fetch+view client that supports multiple protocols (gopher, gemini,
http, ftp, etc.) and then dispatches to different renderers based on the content-type of the resulting file. There may need to be some common
navigation commands in the view buffer, but otherwise it would be unique
to the file type. A meta-browser, if you will.

- Can both (or the merged result) be taught to display org texts?

This is probably easier; Wolfgang in his previous message showed how to
do it for elpher, and it's probably not that hard to extend eww in a
similar way (hijacking the render step to make an org-mode buffer
instead)

- Can we be sure source blocks will stay passive?
That'd be like unsandboxed JS.

Good question. I don't think org-mode runs the code blocks when you open
a file by default (babel isn't even enabled by default iirc), but even
if it is you should be able to turn off any pieces of org-mode that
would automatically run code.

I'm not a fan of this brave new one browser per protocol world.
Full-fat browsers now even drop FTP and more Smallnet browsers that only support one protocol exist than multi-protocol solutions, ... this all
was meant differently when browsers were a new thing:

One lens to view them all.

To keep future browsers that really deserve that name (in contrast to networked single protocol file viewers) not so bloated, they just should
be the place where protocol and rendering plugins meet in a shared UI frontend. So whoever wants a single protocol solution with only some
markups just would not install all plugins.

Emacs seems a good place to start all this?
Too nostalgic?
Too naive?

I'm in favor of this idea. It doesn't help that some content, like html+javascript is just so complicated that only giant organizations can
keep up with the development. But I do think a more flexible
architecture that decouples fetching from viewing (like the one I
described above) could be pretty cool, especially if it's easy to add
new viewer plugins. And yes, emacs seems like a good place to start for
most text-oriented content.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Es schrieb Samuel Christie <shcv@sdf.org> am 30.09.23 um 04.23 Uhr:

yeti <yeti@tilde.institute> writes:

- Can we be sure source blocks will stay passive?
That'd be like unsandboxed JS.

Good question. I don't think org-mode runs the code blocks when you open
a file by default (babel isn't even enabled by default iirc), but even
if it is you should be able to turn off any pieces of org-mode that
would automatically run code.

I did try to make the code safe in that regard, by setting org-confirm-babel-evaluate locally to t, but I have not tried to break
it or test if this is safe in all circumstances.

Cheers,

Wolfgang

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)