Karthik Chikmagalur writes:
>> I am looking at this and wonder why not simply change the whole
>> org-link-preview file to have (ov image-data-or-path &optional link align
>> width)
>> arguments. Then, we can make `org-link-preview-image-data' internal and
>> only expose `org-link-preview-file'
>> @@ -2178,23 +2178,39 @@ (defun org-link-preview-file (ov path link)
>>
>> This is intended to be used as the `:preview' link property of
>> file links, see `org-link-parameters'."
>> - (when (display-graphic-p)
>> -(require 'image)
>> (when-let* ((file-full (expand-file-name path))
Karthik Chikmagalur writes:
> I'm not sure about passing "align", as this should be read from the link
> attributes. I'm assuming the "width" specified in the link attributes
> will apply on top of the width argument to this function?
Instead. The idea is to provide overriding alignment/width i
> Hmm. Maybe we have a misunderstanding. I was talking about
> `org-link-preview-file' signature.
Yes, I misunderstood.
> With the new signature, (org-link-preview-file ov path link) will be
> still ok. The point is that other callers that want to use
> `org-link-preview-file' independently may u
Karthik Chikmagalur writes:
>> The new signature is (ov image-data-or-path &optional link align width)
>> So, LINK becomes optional in a sense that ALIGN+WIDTH may be provided
>> instead.
>>
>> Should be 100% backwards-compatible.
>
> Is this the new signature for the API, i.e. previewers of all
> The new signature is (ov image-data-or-path &optional link align width)
> So, LINK becomes optional in a sense that ALIGN+WIDTH may be provided instead.
>
> Should be 100% backwards-compatible.
Is this the new signature for the API, i.e. previewers of all kinds? I
don't follow how the preview f
Karthik Chikmagalur writes:
>> I am looking at this and wonder why not simply change the whole
>> org-link-preview file to have (ov image-data-or-path &optional link align
>> width)
>> arguments. Then, we can make `org-link-preview-image-data' internal and
>> only expose `org-link-preview-file'
> I am looking at this and wonder why not simply change the whole
> org-link-preview file to have (ov image-data-or-path &optional link align
> width)
> arguments. Then, we can make `org-link-preview-image-data' internal and
> only expose `org-link-preview-file' as the API function.
Is this witho
Björn Bidar writes:
>>> The thing that confused me, but I think I wasn't aware of not getting it
>>> yesterday was that org--create-inline-image creates the actual image
>>> object. I was thinking that the image object would have been created in the
>>> handler and then passed to the helper funct
Ihor Radchenko writes:
> Björn Bidar writes:
>
>> The thing that confused me, but I think I wasn't aware of not getting it
>> yesterday was that org--create-inline-image creates the actual image
>> object. I was thinking that the image object would have been created in the
>> handler and then pa
Björn Bidar writes:
> The thing that confused me, but I think I wasn't aware of not getting it
> yesterday was that org--create-inline-image creates the actual image
> object. I was thinking that the image object would have been created in the
> handler and then passed to the helper function.
Fe
Ihor Radchenko writes:
> Björn Bidar writes:
>
>>> IMHO, it would be best to pass image file name/raw image data to
>>> `org-link-preview-image-data', not an image object and call
>>> `org--create-inline-image' from inside `org-link-preview-image-data'.
>>> That way, we can automatically obey Or
Björn Bidar writes:
>> IMHO, it would be best to pass image file name/raw image data to
>> `org-link-preview-image-data', not an image object and call
>> `org--create-inline-image' from inside `org-link-preview-image-data'.
>> That way, we can automatically obey Org customization wrt image
>> ali
Ihor Radchenko writes:
> Björn Bidar writes:
>
>>> Both alignment and width are derived from LINK AST node.
>>> I am not sure what is the problem.
>>> AFAIU, Karthik is simply asking why you decided to calculate alignment
>>> from LINK, but not width.
>>
>> My question was because the width is s
Björn Bidar writes:
>> Both alignment and width are derived from LINK AST node.
>> I am not sure what is the problem.
>> AFAIU, Karthik is simply asking why you decided to calculate alignment
>> from LINK, but not width.
>
> My question was because the width is set through the width of the inline
Ihor Radchenko writes:
> Björn Bidar writes:
>
>>> It looks like you are respecting the alignment specifications, set via
>>> org-image-align or the :align property of #+attr_*, but not the :width
>>> property. Is the idea that the preview implementation that provides the
>>> image should indep
Björn Bidar writes:
>> It looks like you are respecting the alignment specifications, set via
>> org-image-align or the :align property of #+attr_*, but not the :width
>> property. Is the idea that the preview implementation that provides the
>> image should independently use org-display-inline-
Karthik Chikmagalur writes:
...
Considering this, it might be better to just split
`org-link-preview-file' into two public functions, where the "inside"
function accepts an image instead of a file.
>>>
>>> Agree.
>>> Would you be interested to create a patch?
>>
>> Did you thi
>>> ...
>>> Considering this, it might be better to just split
>>> `org-link-preview-file' into two public functions, where the "inside"
>>> function accepts an image instead of a file.
>>
>> Agree.
>> Would you be interested to create a patch?
>
> Did you think of something like this?
It looks li
Ihor Radchenko writes:
> Karthik Chikmagalur writes:
>
...
Considering this, it might be better to just split
`org-link-preview-file' into two public functions, where the "inside"
function accepts an image instead of a file.
>>>
>>> Agree.
>>> Would you be interested to creat
Björn Bidar writes:
> I'm also wondering how much could there be shared if the thing to be
> displayed on the overlay isn't an image.
>
> The org-image--align function talks about images but ultimately
> doesn't do anything specific to image.
> I think the alignment the only part which is generic
Karthik Chikmagalur writes:
>>> ...
>>> Considering this, it might be better to just split
>>> `org-link-preview-file' into two public functions, where the "inside"
>>> function accepts an image instead of a file.
>>
>> Agree.
>> Would you be interested to create a patch?
>
> Ihor, did you write
Björn Bidar writes:
> Anyway it would be a good improvement to include the org-mode api manual
> with org-mode similar to how Emacs includes the Elisp manual.
Maybe. But we need to write that org-element API manual first.
The WORG page is not a manual. It's a mixture of API reference (partial)
w
>> ...
>> Considering this, it might be better to just split
>> `org-link-preview-file' into two public functions, where the "inside"
>> function accepts an image instead of a file.
>
> Agree.
> Would you be interested to create a patch?
Ihor, did you write a patch for this already? I thought I s
Karthik Chikmagalur writes:
>> I don't think so, my package org-link-beautify ported to the new
>> :preview mechanism. The file preview not always image. Could be text, or
>> icon etc. So pass in image object is not a good idea. It will limit
>> preview functionality extensibility.
>
> The API wi
Ihor Radchenko writes:
> Karthik Chikmagalur writes:
>
>> ...
>> Considering this, it might be better to just split
>> `org-link-preview-file' into two public functions, where the "inside"
>> function accepts an image instead of a file.
>
> Agree.
> Would you be interested to create a patch?
Di
Ihor Radchenko writes:
> Björn Bidar writes:
>
>>> This is expected. See
>>> https://orgmode.org/worg/dev/org-element-api.html#org22c967a
>>> You can access the contents by looking at buffer text between
>>> :contents-begin and :contents-end. Either directly, or by invoking
>>> sub-parser on th
> I don't think so, my package org-link-beautify ported to the new
> :preview mechanism. The file preview not always image. Could be text, or
> icon etc. So pass in image object is not a good idea. It will limit
> preview functionality extensibility.
The API will not be changed. Org will provide
I don't think so, my package org-link-beautify ported to the new
:preview mechanism. The file preview not always image. Could be text, or
icon etc. So pass in image object is not a good idea. It will limit
preview functionality extensibility.
[stardiviner] GPG key ID: 47C32433
IRC(
Karthik Chikmagalur writes:
> ...
> Considering this, it might be better to just split
> `org-link-preview-file' into two public functions, where the "inside"
> function accepts an image instead of a file.
Agree.
Would you be interested to create a patch?
--
Ihor Radchenko // yantar92,
Org mod
Björn Bidar writes:
>> This is expected. See
>> https://orgmode.org/worg/dev/org-element-api.html#org22c967a
>> You can access the contents by looking at buffer text between
>> :contents-begin and :contents-end. Either directly, or by invoking
>> sub-parser on the text.
>
> Oh thanks, will look
>> Would it be possible to also handle image data in the function or
>> refactor the org-link-preview-file function in a way that the geometry
>> handling is done in a helper function which can be reused by other
>> handlers.
>
> There is such function: `org-display-inline-image--width'.
> We may c
Ihor Radchenko writes:
> Björn Bidar writes:
>
>> Would it be possible to also handle image data in the function or
>> refactor the org-link-preview-file function in a way that the geometry
>> handling is done in a helper function which can be reused by other
>> handlers.
>
> There is such funct
Björn Bidar writes:
> Would it be possible to also handle image data in the function or
> refactor the org-link-preview-file function in a way that the geometry
> handling is done in a helper function which can be reused by other
> handlers.
There is such function: `org-display-inline-image--wid
Karthik Chikmagalur writes:
>> The PR do port the package to this new handler property:
>> https://github.com/gaoDean/org-remoteimg/pull/4
>>
>> However it left me with a few questions:
>> - Who is supposed to take care of the scaling/width of the preview
>> image, the handler or the caller of
> The PR do port the package to this new handler property:
> https://github.com/gaoDean/org-remoteimg/pull/4
>
> However it left me with a few questions:
> - Who is supposed to take care of the scaling/width of the preview
> image, the handler or the caller of the handler?
The handler is respons
Hello,
I have a few question regarding the new link preview handler property
added recently. I ported the org-remoteimg package to it which was quite
easy, much cleaner with the new property.
The PR do port the package to this new handler property:
https://github.com/gaoDean/org-remoteimg/pull/
37 matches
Mail list logo
