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
15 matches
Mail list logo
