Hi Prot,
I've been looking into Denote (hence the recent patches), to use as a
kind of microblogging system, sort of in the style of "Debian Micronews"
https://micronews.debian.org/.
Before trying anything out on my own, I wanted to ask you if you had any
comments on how to approach this, as I see that development is
proceeding quite quickly, and I didn't want to rely on any interface
that might change.
What I had in mind was a function like
(denote-export 'html "emacs" "/path/to/www/")
that would export all notes tagged with "emacs" to html and write the
results in the directory /path/to/www/. Optionally a RSS or Atom feed
could also be generated in this case.
All in all, this sounds like the job for a whole new package that would
depend on Denote. Or do you think that Denote would be the wrong
foundation for something like this?
Hi Philip,
Sorry for chiming in here. You could use ORG-PUBLISH for this. It is
built-in and does not require any dependencies (RSS can be done as well,
but is slightly more involved).
> (denote-export 'html "emacs" "/path/to/www/")>> that would export all notes tagged with "emacs" to html and write the> results in the directory /path/to/www/. Optionally a RSS or Atom feed> could also be generated in this case.
I'm not sure would it be possible to achieve a tag-based export that
easily with ORG-PUBLISH but I could imagine it might be with some
extra-function.
All the best,
Sven
--
Sven Seebeck
https://www.svenseebeck.me
Sven Seebeck <hello@svenseebeck.me> writes:
> Hi Philip,
Hi Sven,
> Sorry for chiming in here. You could use ORG-PUBLISH for this. It is> built-in and does not require any dependencies (RSS can be done as well,> but is slightly more involved).
I am familiar with Org-public, and have tried using it in the past, yet
I remain unsatisfied with it, precisely because it is based on Org.
>> (denote-export 'html "emacs" "/path/to/www/")>>>> that would export all notes tagged with "emacs" to html and write the>> results in the directory /path/to/www/. Optionally a RSS or Atom feed>> could also be generated in this case.>> I'm not sure would it be possible to achieve a tag-based export that> easily with ORG-PUBLISH but I could imagine it might be with some> extra-function.
Perhaps, but I still consider it a bit too clumsy for my purposes.
> All the best,> Sven
> From: Philip Kaludercic <philipk@posteo.net>> Date: Wed, 10 Aug 2022 14:28:36 +0000>>> Hi Prot,
Hello Philip,
> I've been looking into Denote (hence the recent patches), to use as a> kind of microblogging system, sort of in the style of "Debian Micronews"> https://micronews.debian.org/.
Good idea!
> Before trying anything out on my own, I wanted to ask you if you had any> comments on how to approach this, as I see that development is> proceeding quite quickly, and I didn't want to rely on any interface> that might change.
The movements you see in Git are mostly internal refinements. I just
published version 0.5.0. I think that going forward the goal should be
to provide a stable basis and formalise it as version 1.0.0. We will
slow down eventually.
> What I had in mind was a function like>> (denote-export 'html "emacs" "/path/to/www/")
What do you have in mind for the conversion to HTML? If this is a
microblog, I suppose it needs only basic markup?
I just tried 'M-x htmlfontify-buffer' in a ".txt" file and it produced the
expected output.
> that would export all notes tagged with "emacs" to html and write the> results in the directory /path/to/www/. Optionally a RSS or Atom feed> could also be generated in this case.>> All in all, this sounds like the job for a whole new package that would> depend on Denote. Or do you think that Denote would be the wrong> foundation for something like this?
I think Denote can be the right foundation, though it really depends on
what your specific requirements are. What will be the source file type?
Plain text, Markdown, Org? Do you need some specific entry in what we
call the "front matter", like Org's #+filetags:?
I can help you with the specifics. If there is something missing in
Denote, such as a way to filter files per file type, we can provide it.
I believe all the elements are in place.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> I've been looking into Denote (hence the recent patches), to use as a>> kind of microblogging system, sort of in the style of "Debian Micronews">> https://micronews.debian.org/.>> Good idea!>>> Before trying anything out on my own, I wanted to ask you if you had any>> comments on how to approach this, as I see that development is>> proceeding quite quickly, and I didn't want to rely on any interface>> that might change.>> The movements you see in Git are mostly internal refinements. I just> published version 0.5.0. I think that going forward the goal should be> to provide a stable basis and formalise it as version 1.0.0. We will> slow down eventually.
Good to hear.
>> What I had in mind was a function like>>>> (denote-export 'html "emacs" "/path/to/www/")>> What do you have in mind for the conversion to HTML? If this is a> microblog, I suppose it needs only basic markup?
You know what, there is no reason it should have to be a microblog.
Let's say we want to create any kind of blog, no matter what the content
is.
> I just tried 'M-x htmlfontify-buffer' in a ".txt" file and it produced the> expected output.
Generally speaking, I could imagine an alist option like
`denote-export-handlers' that might have a value like
'(("txt" . htmlfontify-buffer) ;call an Elisp function on a buffer
("md" . "cmark --smart")) ;filter a buffer through a shell command
Some extra handling would be necessary to integrate the front mater
information.
>> that would export all notes tagged with "emacs" to html and write the>> results in the directory /path/to/www/. Optionally a RSS or Atom feed>> could also be generated in this case.>>>> All in all, this sounds like the job for a whole new package that would>> depend on Denote. Or do you think that Denote would be the wrong>> foundation for something like this?>> I think Denote can be the right foundation, though it really depends on> what your specific requirements are. What will be the source file type?> Plain text, Markdown, Org? Do you need some specific entry in what we> call the "front matter", like Org's #+filetags:?
As I said, I am thinking about something generic here, perhaps even if I
find the time a package of it's own.
> I can help you with the specifics. If there is something missing in> Denote, such as a way to filter files per file type, we can provide it.> I believe all the elements are in place.
Ok, good to know.
> All the best,> Prot
> From: Philip Kaludercic <philipk@posteo.net>> Date: Thu, 11 Aug 2022 08:04:35 +0000>> [... 13 lines elided]>>> The movements you see in Git are mostly internal refinements. I just>> published version 0.5.0. I think that going forward the goal should be>> to provide a stable basis and formalise it as version 1.0.0. We will>> slow down eventually.>> Good to hear.
Just to elaborate on this point. The plan is to:
- simplify the code we have for the different file types;
- make it easier for the user to specify a file type, the front matter
it should use, and the extension it should have;
- make other refinements to the code.
Those will not break what we currently support.
>>> What I had in mind was a function like>>>>>> (denote-export 'html "emacs" "/path/to/www/")>>>> What do you have in mind for the conversion to HTML? If this is a>> microblog, I suppose it needs only basic markup?>> You know what, there is no reason it should have to be a microblog.> Let's say we want to create any kind of blog, no matter what the content> is.
Okay, better to design it this way.
>> I just tried 'M-x htmlfontify-buffer' in a ".txt" file and it produced the>> expected output.>> Generally speaking, I could imagine an alist option like> `denote-export-handlers' that might have a value like>> '(("txt" . htmlfontify-buffer) ;call an Elisp function on a buffer> ("md" . "cmark --smart")) ;filter a buffer through a shell command>> Some extra handling would be necessary to integrate the front mater> information.
Sounds good! I guess the tricky part is how to handle the 'denote:'
links. They will not work without some kind of expansion/translation
into HTML.
We had discussed this before with Frank Ehmsen.[1] Perhaps now is the
time to consider how best to handle this. Should "core Denote" have a
command or functions which expand links or does such functionality
belong somewhere else such as a theoretical denote-export.el?
Not that I expect an answer now. It is the kind of technicality a new
package would need to account for.
[1] <https://lists.sr.ht/~protesilaos/denote/%3C87a6acrg4q.fsf%40protesilaos.com%3E#%3Ca0396c48-5e84-be28-ccf5-e9646921d496@eh-is.de%3E>
--
Protesilaos Stavrou
https://protesilaos.com
Hi all,
Am 11.08.22 um 11:00 schrieb Protesilaos Stavrou:
>>> I just tried 'M-x htmlfontify-buffer' in a ".txt" file and it produced the>>> expected output.>>>> Generally speaking, I could imagine an alist option like>> `denote-export-handlers' that might have a value like>>>> '(("txt" . htmlfontify-buffer) ;call an Elisp function on a buffer>> ("md" . "cmark --smart")) ;filter a buffer through a shell command>>>> Some extra handling would be necessary to integrate the front mater>> information.> > Sounds good! I guess the tricky part is how to handle the 'denote:'> links. They will not work without some kind of expansion/translation> into HTML.
I like the idea of having an alist as option for export commands, as
mentioned above.
My notes are all in markdown-yaml. I have written a (simple) function to
call pandoc for export in different formats:
(with-eval-after-load 'markdown-mode
(defun fe-markdown-export-select-and-export ()
"Prompt user to pick a Pandoc export extension from a list.
Export to ./Export Directory. Directory must exist."
(interactive)
(unless (string= "markdown-mode" major-mode) (error "Not in
Markdown Mode!"))
(let ((choices '("html" "pdf" "docx" "pptx" "slidy")))
(shell-command (concat "pandoc --defaults=zettelkasten --from=markdown
-o ./Export/" (file-name-base (buffer-file-name)) "." (completing-read
"Export to ./Export:" choices) " " buffer-file-name))
)
)
)
As you can see, I am not an elisp expert ;-).
Of course, the denote:<identifier> links are not correct in the export.
Maybe a function in the denote code that expands the denote:<identifier>
links would be good. For example convert denote:<identifieer> to
denote:<filename> and write the result to a temporary file. In a
function (as mentioned it he alist above) the user can then call first
the function to convert the links and after that the export converter of
his choice (cmark, pandoc, 'enscript file.txt --output=- | ps2pdf - >
file.pdf', ...) on the temporary file. Would be nice if it is wrapped in
a denote-export command that can handle in dired selected files.
> > We had discussed this before with Frank Ehmsen.[1] Perhaps now is the> time to consider how best to handle this. Should "core Denote" have a> command or functions which expand links or does such functionality> belong somewhere else such as a theoretical denote-export.el?>
I like denote because of the simple, clear design and the use of already
existing tools.
I do not think we need full fleshed out export like in org-mode.
What is needed IMHO is a function that temporarily converts a denote
note to be compatible with the markup the note is written in. The markup
(md, org(?), txt) is in parts "broken" at the moment because of the link
format (denote:<identifier>). This is only a problem if we want to
export the notes and not a critic on the denote link format.
The function (convert denote links and write a temp file) should IMHO be
part of denote and not in an external package.
Best regards,
Frank
> From: Frank Ehmsen <frank@eh-is.de>> Date: Fri, 12 Aug 2022 20:55:11 +0200>> Hi all,
Hello Frank,
> Am 11.08.22 um 11:00 schrieb Protesilaos Stavrou:>>>>> I just tried 'M-x htmlfontify-buffer' in a ".txt" file and it produced the>>>> expected output.>>>>>> Generally speaking, I could imagine an alist option like>>> `denote-export-handlers' that might have a value like>>>>>> '(("txt" . htmlfontify-buffer) ;call an Elisp function on a buffer>>> ("md" . "cmark --smart")) ;filter a buffer through a shell command>>>>>> Some extra handling would be necessary to integrate the front mater>>> information.>> >> Sounds good! I guess the tricky part is how to handle the 'denote:'>> links. They will not work without some kind of expansion/translation>> into HTML.>> I like the idea of having an alist as option for export commands, as > mentioned above.>> My notes are all in markdown-yaml. I have written a (simple) function to > call pandoc for export in different formats:>> (with-eval-after-load 'markdown-mode> (defun fe-markdown-export-select-and-export ()> "Prompt user to pick a Pandoc export extension from a list. > Export to ./Export Directory. Directory must exist."> (interactive)> (unless (string= "markdown-mode" major-mode) (error "Not in > Markdown Mode!"))> (let ((choices '("html" "pdf" "docx" "pptx" "slidy")))> (shell-command (concat "pandoc --defaults=zettelkasten --from=markdown > -o ./Export/" (file-name-base (buffer-file-name)) "." (completing-read > "Export to ./Export:" choices) " " buffer-file-name))> )> )> )>> As you can see, I am not an elisp expert ;-).
Thanks for sharing! I think it is clear that there is value in such an
"export" facility. I would most probably use it as well.
> Of course, the denote:<identifier> links are not correct in the export.
Yes, this is the part that needs work. The links work in Emacs because
we do the conversion internally. Very simply, we take the identifier
and search for it among the files. This keeps files clean and
error-free, as we don't keep writing explicit file names. Though it
means that we are missing the counterparty conversion mechanism outside
Emacs.
> Maybe a function in the denote code that expands the denote:<identifier> > links would be good. For example convert denote:<identifieer> to > denote:<filename> and write the result to a temporary file. In a > function (as mentioned it he alist above) the user can then call first > the function to convert the links and after that the export converter of > his choice (cmark, pandoc, 'enscript file.txt --output=- | ps2pdf - > > file.pdf', ...) on the temporary file. Would be nice if it is wrapped in > a denote-export command that can handle in dired selected files.
We need to find an elegant solution for this. Better not implemented
something and then have to rework it. The reason I am writing this is
because such a feature has the potential to affect lots of files, so we
need to be careful.
But yeah, we need something along those lines.
>> We had discussed this before with Frank Ehmsen.[1] Perhaps now is the>> time to consider how best to handle this. Should "core Denote" have a>> command or functions which expand links or does such functionality>> belong somewhere else such as a theoretical denote-export.el?>> >> I like denote because of the simple, clear design and the use of already > existing tools.>> I do not think we need full fleshed out export like in org-mode.>> What is needed IMHO is a function that temporarily converts a denote > note to be compatible with the markup the note is written in. The markup > (md, org(?), txt) is in parts "broken" at the moment because of the link > format (denote:<identifier>). This is only a problem if we want to > export the notes and not a critic on the denote link format.>> The function (convert denote links and write a temp file) should IMHO be > part of denote and not in an external package.
I agree. A fully fledged exporter belongs to an companion package.
Though the link conversion may be part of core Denote. Assuming we
figure out its particularities and confirm this belief.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com