Kyle Meyer writes:
> I've applied this (a8df7670c) with two minor changes (shown in the diff
> at end): s/with with/with/ in a docstring and move an element to its own
> line to avoid the warning from lisp-mode's lisp--match-hidden-arg.
Thanks :)
> This thread has gone on long enough that
TEC writes:
> TEC writes:
>
> Sorry about that, here's an actual revision.
Thanks, this series is a good improvement as far as I can tell. And
thank you Jens for all of the careful reviews.
I've applied this (a8df7670c) with two minor changes (shown in the diff
at end): s/with with/with/ in a
On 2021-01-14, TEC wrote:
> TEC writes:
>
>>> Sorry, I still see the flycheck warning and "amp;" for "&".
>> Maybe I accidently sent you the old patches? I'll check tomorrow.
>
> Hah, I check and guess what I see? The changes were unstaged .
>
> Sorry about that, here's an actual revision.
This thread has dragged on ages, and if no-one else is following this
chain I wouldn't blame them in the slightest.
To help indicate that this is actually ready (at last) now, I'm just
going to add that info the the subject line in the hope it helps Bastien
or any others notice that this is
TEC writes:
>> Sorry, I still see the flycheck warning and "amp;" for "&".
> Maybe I accidently sent you the old patches? I'll check tomorrow.
Hah, I check and guess what I see? The changes were unstaged .
Sorry about that, here's an actual revision.
--
Timothy
>From
Jens Lechtenboerger writes:
> Sorry, I still see the flycheck warning and "amp;" for "&".
Maybe I accidently sent you the old patches? I'll check tomorrow.
--
Timothy.
On 2021-01-10, TEC wrote:
> Jens Lechtenboerger writes:
>
>> On line 1432 I get this suggestion from flycheck:
>> There should be two spaces after a period (emacs-lisp-checkdoc)
>>
>> More importantly, I just realized that for author information,
>> org-html-plain-text is applied twice, leading
Jens Lechtenboerger writes:
> On line 1432 I get this suggestion from flycheck:
> There should be two spaces after a period (emacs-lisp-checkdoc)
>
> More importantly, I just realized that for author information,
> org-html-plain-text is applied twice, leading to "amp;" when
> translating "&".
On 2021-01-04, TEC wrote:
> Jens Lechtenboerger writes:
>
>> org-html--build-meta-entry and org-html--build-meta-info include some long
>> lines.
>
> Hehe. We've had a lot of back-and-forth haven't we.
> At least it feels like it's coming to a close now.
On line 1432 I get this suggestion from
Jens Lechtenboerger writes:
> org-html--build-meta-entry and org-html--build-meta-info include some long
> lines.
Hehe. We've had a lot of back-and-forth haven't we.
At least it feels like it's coming to a close now.
> For org-html-meta-tags-default, I suggest this as last line for the doc
>
On 2021-01-03, TEC wrote:
> Jens Lechtenboerger writes:
>
>> The doc strings of org-html-meta-tags and org-html-meta-tags-default
>> need to be updated, they still mention author and title.
>
> Ah, yep. Fixed.
>
>> Also, please try checkdoc ;)
>
> Ahhh yes.
Actually, I use flycheck
Jens Lechtenboerger writes:
> The doc strings of org-html-meta-tags and org-html-meta-tags-default
> need to be updated, they still mention author and title.
Ah, yep. Fixed.
> Also, please try checkdoc ;)
Ahhh yes. Checkdoc, my old ~enemy~ /friend/.
I may have shied away from using this
On 2021-01-03, TEC wrote:
> After considering the information passed to a meta info generation
> function, I'm now in agreement with you that just passing `info' is the
> most sensible way forward.
Hi Timothy,
great, thanks :-)
> Attached is a (final?) set of patches, which is as described.
After considering the information passed to a meta info generation
function, I'm now in agreement with you that just passing `info' is the
most sensible way forward.
Attached is a (final?) set of patches, which is as described.
--
Timothy.
>From e8c9646ae6c5083417a927bd2b23bb0f837930d2 Mon Sep
On 2020-12-20, TEC wrote:
> Jens Lechtenboerger writes:
>
>>> For people who want to customise this to add metadata, the page title is
>>> something they're probably interested in.
>>
>> What metadata would you derive from the title?
>
> In my earlier example, I use the "og:title" property.
I
Jens Lechtenboerger writes:
>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?
In my earlier example, I use the "og:title" property.
>> If so, I think it's work giving the
Jens Lechtenboerger writes:
>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?
In my earlier example, I use the "og:title" property.
>> If so, I think it's work giving the
On 2020-12-16, TEC wrote:
> Jens Lechtenboerger writes:
>>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
>>> I'm not sure.
>>
>> I’m not sure either. Maybe people expect their typed characters,
>> maybe not. This might call for a new variable.
>
> I'm tempted to
Jens Lechtenboerger writes:
> I like this!
:)
>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
>> I'm not sure.
>
> I’m not sure either. Maybe people expect their typed characters,
> maybe not. This might call for a new variable.
I'm tempted to leave the current
Hello everyone,
On 2020-12-15, TEC wrote:
> Jens Lechtenboerger writes:
>
>> [title export being dodgy, how about treating like author?]
>
> Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it
> in ~org-html-plain-text~ seems better again though, as it encodes
> entities
Hi Timothy,
I understand now. Having a way to implement this in the config is
a good thing as it covers a slightly different set of use cases and
workflows than always using a common #+setupfile: line. That way if
you are working with files that don't have a #+setupfile: specified
you can
Hi Tom,
> Why not just use #+html_head:
> possibly with a macro to fill in variable values? That is fully
> extensible and doesn't overload keywords. For title, date, author,
> etc. those can have clearly defined mappings to the html, but
> everything else seems to be handled more sanely with
A question from the slightly uninformed. Why not just use #+html_head:
possibly with a macro to fill in variable values? That is fully
extensible and doesn't overload keywords. For title, date, author,
etc. those can have clearly defined mappings to the html, but
everything else seems to be
Thanks for testing Jens. I think I've managed to resolve the issues
you've raised.
Jens, Bastien, you can find the latest revision of the patches attached :)
Jens Lechtenboerger writes:
> [title export being dodgy, how about treating like author?]
Yep, ~org-element-interpret-data~ is
Hi everybody,
On 2020-12-14, Bastien wrote:
> Hi Timothy,
>
> TEC writes:
>
>> Thanks for testing this :) I haven't forgotten about this.
>
> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.
I exported this:
#+begin_src org
,#+TITLE: A title with *bold*
Bastien writes:
> Can we approach this with two patches, one with the refactoring and
> one with the added functionality?
Sure :) I'll take care of this when I get home in a few hours.
> This sounds useful.
Glad to hear!
> I think "Org Export" as the default is counter-intuitive, let's
Hi Timothy,
TEC writes:
>> In a nutshell, can you restate what problem is this patch fixing?
>
> There are two things I intend to achieve with this patch:
> 1. DRY* out the existing code. The existing code is quite repetitive in
>structure, and easily lends itself to being extracted to a
Bastien writes:
> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.
Assuming Jens responds as he usually has (relatively promptly), this
sounds good to me :)
> In a nutshell, can you restate what problem is this patch fixing?
There are two things I
Hi Timothy,
TEC writes:
> Thanks for testing this :) I haven't forgotten about this.
Let's wait for Jens feedback on this patch, since he took care of
testing it so far.
In a nutshell, can you restate what problem is this patch fixing?
Is a new option really necessary here?
Are there
Jens Lechtenboerger writes:
> Without the second argument I get an error “Wrong type argument:
> stringp,” when evaluating regular expressions against the cons cell
> that is returned as title.
>
> As I see now, author and title are cons cells, which is why
> org-element-interpret-data is
On 2020-09-28, TEC wrote:
> Jens Lechtenboerger writes:
>
>> On 2020-09-28, TEC wrote:
>>
>>> Jens Lechtenboerger writes:
Also, in org-html--build-meta-info you call
org-html-encode-plain-text with two arguments, but it just accepts
one.
>>>
>>> ? No I don't.
>>
>> Your patch
Jens Lechtenboerger writes:
On 2020-09-28, TEC wrote:
Jens Lechtenboerger writes:
Also, in org-html--build-meta-info you call
org-html-encode-plain-text with two arguments, but it just
accepts
one.
? No I don't.
Your patch contains this:
+ (let* ((title
On 2020-09-28, TEC wrote:
> Jens Lechtenboerger writes:
>> Also, in org-html--build-meta-info you call
>> org-html-encode-plain-text with two arguments, but it just accepts
>> one.
>
> ? No I don't.
Your patch contains this:
+ (let* ((title (org-html-encode-plain-text (plist-get info :title)
Jens Lechtenboerger writes:
Currently the only element handled differently to
`org-html-encode-plain-text' is "author". I don't know why so I
don't
want to touch it.
I believe that was also the previous conclusion. However, as
this
is not documented, maybe now could be the chance to
On 2020-09-26, TEC wrote:
> @Maintainers I think this is ready for a review.
>
> Jens Lechtenboerger writes:
>
>> My suggestion would be to go with the handling of description in all
>> cases, including the title.
>
> Currently the only element handled differently to
>
@Maintainers I think this is ready for a review.
Jens Lechtenboerger writes:
> My suggestion would be to go with the handling of description in all
> cases, including the title.
Currently the only element handled differently to
`org-html-encode-plain-text' is "author". I don't know why so I
On 2020-09-18, TEC wrote:
> Jens Lechtenboerger writes:
> [...]
> I was not aware of org-element-interpret-data, and I can't say I can
> really tell what it does. If you'd care to elaborate that would be
> helpful.
Hi Timothy,
I don’t know why that is used. For this test case:
#+begin_src
Jens Lechtenboerger writes:
> Hi Timothy,
Hi Jens! Thanks for responding.
> yes, I agree that org-html--build-meta-info needs work, and the HTML
> backend would benefit from more documentation. Back then [1], I
> wondered which parts of meta data need to be treated how. That was
>
On 2020-09-17, TEC wrote:
> Hi All,
>
> This just replaces the current `org-html--build-meta-info' with a
> cleaner, more extensible (I also added a new variable)
> version. Please give it a look and let me know what you think!
Hi Timothy,
yes, I agree that org-html--build-meta-info needs work,
TEC writes:
> <#part type=“text/x-patch”
> filename=“home/tec.emacs.d/.local/straight/repos/org-mode/0001-lisp-ox-html.el-make-html-meta-func-nicer.patch”
> disposition=inline>
> <#/part>
I have no idea what I need to do to get Mu4e to attach files, but I'm
clearly not doing it right. Here's
Hi All,
This just replaces the current `org-html--build-meta-info' with a
cleaner, more
extensible (I also added a new variable) version. Please give it a look
and let
me know what you think!
Timothy.
<#part type="text/x-patch"
41 matches
Mail list logo
