Max Nikulin writes:
>> May you elaborate? I am not talking about implementation details, but
>> about the reasonable defaults for the export. Not necessary ASCII, but
>> other backends as well.
> I am rather skeptical concerning a variant that is pleasant to read in
> all cases. That is why I
On 12/10/2023 18:35, Ihor Radchenko wrote:
Max Nikulin writes:
I like more how ox-ascii (without the
proposed diff) handles the situation via footnote-like link.
That is why I believe that extracting fragments of code into helper
functions is important. If ox-ascii.el had a function that
Max Nikulin writes:
>> I like more how ox-ascii (without the
>> proposed diff) handles the situation via footnote-like link.
>
> That is why I believe that extracting fragments of code into helper
> functions is important. If ox-ascii.el had a function that adds an item
> to link list then
Ihor Radchenko writes:
> I am not sure if I like it.
Me neither. The problem is in the parentheses, IMHO. The Lisp
expression is enclosed in parentheses and so is the description:
(message "Hello") (Message Hello)
That indeed looks confusing! How about we swap the sides and remove one
On 09/10/2023 19:12, Ihor Radchenko wrote:
Valid, but I am more concerned about the whole idea. I _feel_ that
code (description)
does not look nice in html export.
It is minor in comparison with invalid HTML that may be generated by
current code. I am unsure if a better variant
Max Nikulin writes:
>> +(defun org-link--export-code (path description _ info lang)
>
> I think, the fragment above should be a public function that is a
> building block for users who want to override export of links having
> descriptions.
Sure, but that's minor.
>> + (when description
On 08/10/2023 16:48, Ihor Radchenko wrote:
+++ b/lisp/ol.el
@@ -1377,7 +1377,29 @@ (defun org-link--open-elisp (path _)
(call-interactively (read path
(user-error "Abort")))
-(org-link-set-parameters "elisp" :follow #'org-link--open-elisp)
+(defun
Rudolf Adamkovič writes:
>> Still, it would be nice to have _a_ variant compared to the current
>> state of affairs.
>
> Agreed. If the link has no description, we can do a great job on
> exporting it. Half of the victory, right there!
>
> Also, how about the following /simple/ idea for the
Ihor Radchenko writes:
> Still, it would be nice to have _a_ variant compared to the current
> state of affairs.
Agreed. If the link has no description, we can do a great job on
exporting it. Half of the victory, right there!
Also, how about the following /simple/ idea for the description:
Max Nikulin writes:
> I am afraid, there is no variant that fits for all cases even in a
> particular document.
Still, it would be nice to have _a_ variant compared to the current
state of affairs.
As for extra customization, it totally depends on the interest in this
functionality. If not
On 23/09/2023 06:43, Rudolf Adamkovič wrote:
Ihor Radchenko writes:
Another idea: use code as description displayed in the tooltip (in html).
Copy-on-clip also makes sense.
Yet another idea: export code inside a footnote. This will work across
all the backends.
Yet another, another idea:
Ihor Radchenko writes:
> Another idea: use code as description displayed in the tooltip (in html).
> Copy-on-clip also makes sense.
>
> Yet another idea: export code inside a footnote. This will work across
> all the backends.
Yet another, another idea: export the description as a Lisp comment,
Max Nikulin writes:
>> As a user, I would expect
>>
>>[[elisp:(identity "a")]]
>>
>> to be export-equivalent to
>>
>>src_elisp[:exports code]{(identity "a")}
>>
>> across all backends.
Makes sense.
>>> What is your expectation for links having description?
>>>
>>>
On 19/09/2023 07:10, Rudolf Adamkovič wrote:
Max Nikulin writes:
Do you think a label specifying language should be added to code
snippets, e.g. (identity "a") or it is
useless and may cause undesired noise for screen reader users? What
about LaTeX?
As a user, I would expect
Max Nikulin writes:
> Do you think a label specifying language should be added to code
> snippets, e.g. (identity "a") or it is
> useless and may cause undesired noise for screen reader users? What
> about LaTeX?
As a user, I would expect
[[elisp:(identity "a")]]
to be export-equivalent
On 18/09/2023 05:08, Rudolf Adamkovič wrote:
Max Nikulin writes:
From my point of view, e.g. should be exported
as plain text (identity "a") rather than an (invalid due to
not escaped quotes inside href) link (identity
"a").
This would be a very welcome fix! I avoid
'elisp' links, even in
16 matches
Mail list logo
