Re: [ANN] Org mode 9.7 is out

[JD Smith]

> On Jun 6, 2024, at 4:41 PM, Juergen Fenn  wrote:
> 
> 
> 
> Am 06.06.24 um 17:17 Uhr schrieb Ihor Radchenko:
>> Juergen Fenn  writes:
>> 
>>> Am 06.06.24 um 08:20 Uhr schrieb Visuwesh:
 Thanks for the analysis.  Given that Alan says GNUStep cannot handle
 non-text clipboard items, I cannot propose anything myself.  It would be
 nice if a Mac user can write a report and send it to the Emacs
 developers.  Perhaps Juergen can do it?
>>> 
>>> Of course, I /could/ do this, but given the fact that you have already
>>> found out about /some/ internals wouldn't it be better a macOS/NextStep
>>> developer would look into this in the first place and hence write the
>>> report with some somre insight?
>> 
>> Unfortunately, there are no MacOS developers among Org mode maintainers.
>> I personally do not even have access to MacOS for testing.
>> 
>> Since you at least can test things on MacOS, it would be helpful if you
>> can create the recipe suitable for Emacs devs to reproduce the
>> problem. They may also ask extra information from your MacOS.
>> 
> 
> I see. Thanks for explaining. So, I will write a bug report that draws
> on our discussion and send it to emacs-devel over the weekend.
> 
> My switch from Ventura to Sonoma shortly may make things more
> complicated, as I cannot foresee in howmuch the two platforms differ
> under the hood, but I'm afraid I cannot postpone the upgrade.

A few years ago, I wrote a small package for pasting PNG and PDF data from the 
Mac clipboard into org documents as attachments, which I still use:  
https://github.com/jdtsmith/org-mac-image-paste. 

With the recent work on yank-media I'm hopeful I can retire this package soon.  
I found I could pull PDF data to file from the clipboard via AppleScript (and 
display in the emacs-mac build using its image-io backend), but used 
pngpaste[1] tool for PNG data.  When an image is on the clipboard, PNG data are 
indeed available from the clipboard («class PNGf»), as can be seen via 
AppleScript.  You can use AppleScript to inquire about the state of the 
clipboard.  For example, after taking a screenshot, I see:

% osascript -e "clipboard info"
«class PNGf», 121849, «class 8BPS», 401974, GIF picture, 21636, «class jp2 », 
21831, JPEG picture, 35062, TIFF picture, 369790, «class BMP », 366218, «class 
TPIC», 285265

On copying an image from a website, I get:

% osascript -e "clipboard info"
TIFF picture, 91686, URL, 81, «class urln», 6, «class utf8», 81, «class rtfd», 
2652, «class weba», 5679, «class HTML», 800, «class 8BPS», 103154, GIF picture, 
681, «class jp2 », 5455, JPEG picture, 1059, «class PNGf», 6282, «class BMP », 
44298, «class TPIC», 8066, «class ut16», 164, string, 81, Unicode text, 162

For images grabbed from web-pages, you can actually get the URL information if 
you like and include that in or near the attachment link.  

Here's after copying a GIF file from the Finder:

% osascript -e "clipboard info"
«class furl», 41, «class ut16», 24, «class utf8», 11, «class icns», 1137764, 
Unicode text, 22, string, 11, «class 8BPS», 1295026, GIF picture, 74698, «class 
jp2 », 110628, JPEG picture, 62209, TIFF picture, 4198020, «class PNGf», 
305211, «class BMP », 4194442, «class TPIC», 796024

Notice the file-URL there, which you can get (here using the JXA=javascript 
flavor of AppleScript, with a UTI for the file-url, which is apparently the 
more modern way to do it):

% osascript -l JavaScript -e 'ObjC.import("AppKit"); 
$.NSPasteboard.generalPasteboard.stringForType("public.file-url");'
file:///Users/xxyz/Desktop/output.gif

You can even coerce the clipboard to be in a certain format:

% osascript -e "clipboard info"
TIFF picture, 35766, URL, 37, «class urln», 7, «class utf8», 37, «class rtfd», 
1082, «class weba», 3643, «class HTML», 820, «class 8BPS», 9884, GIF picture, 
434, «class jp2 », 4617, JPEG picture, 1268, «class PNGf», 1527, «class BMP », 
32538, «class TPIC», 2446, «class ut16», 76, string, 37, Unicode text, 74

% osascript -e "set the clipboard to (the clipboard as JPEG picture)"

% osascript -e "clipboard info"  
JPEG picture, 1268, «class 8BPS», 8622, GIF picture, 687, «class jp2 », 4671, 
TIFF picture, 27704, «class PNGf», 2508, «class BMP », 24534, «class TPIC», 4372

My knowledge doesn't go any deeper than that but thought I'd share what I know. 
 

[1] The code for pngpaste might be informative: 
https://github.com/jcsalterego/pngpaste/blob/main/pngpaste.m.   

Re: [ANN] Org mode 9.7 is out

[JD Smith]

> On Jun 6, 2024, at 4:41 PM, Juergen Fenn  wrote:
> 
> 
> 
> Am 06.06.24 um 17:17 Uhr schrieb Ihor Radchenko:
>> Juergen Fenn  writes:
>> 
>>> Am 06.06.24 um 08:20 Uhr schrieb Visuwesh:
 Thanks for the analysis.  Given that Alan says GNUStep cannot handle
 non-text clipboard items, I cannot propose anything myself.  It would be
 nice if a Mac user can write a report and send it to the Emacs
 developers.  Perhaps Juergen can do it?
>>> 
>>> Of course, I /could/ do this, but given the fact that you have already
>>> found out about /some/ internals wouldn't it be better a macOS/NextStep
>>> developer would look into this in the first place and hence write the
>>> report with some somre insight?
>> 
>> Unfortunately, there are no MacOS developers among Org mode maintainers.
>> I personally do not even have access to MacOS for testing.
>> 
>> Since you at least can test things on MacOS, it would be helpful if you
>> can create the recipe suitable for Emacs devs to reproduce the
>> problem. They may also ask extra information from your MacOS.
>> 
> 
> I see. Thanks for explaining. So, I will write a bug report that draws
> on our discussion and send it to emacs-devel over the weekend.
> 
> My switch from Ventura to Sonoma shortly may make things more
> complicated, as I cannot foresee in howmuch the two platforms differ
> under the hood, but I'm afraid I cannot postpone the upgrade.

A few years ago, I wrote a small package for pasting PNG and PDF into org 
documents as attachments, which I still use: org-mac-image-paste:  
https://github.com/jdtsmith/org-mac-image-paste. 

With the recent work on yank-media I'm hopeful I can retire this tool soon (see 
the bottom of that page).  I found I could pull PDF data from the clipboard via 
AppleScript (and display in the emacs-mac build using its image-io backend), 
but had to use the pngpaste tool for PNG data.  PNG data are indeed included on 
the clipboard («class PNGf»), and can be seen via AppleScript.

The code for pngpaste might be informative: 
https://github.com/jcsalterego/pngpaste/blob/main/pngpaste.m.

Better support admonitions blocks

[JD Smith]

Pandoc recently added read/write support 
 for "admonitions", which are a GFM 
construct  already 
supported by other org-exporters, and on GH in markdown.  This refcard 

 references an org #{begin,end}_{note,warning,tip,caution,important} syntax 
which pandoc now follows (though it does not support the extra admonitions like 
danger/error/etc.). 

It would be nice to add org support for these 5 admonition blocks to the C-c 
C-, org block structure templates, and perhaps allow block face styling for 
these as well (ala org-src-block-faces).

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[JD Smith]

> On Feb 8, 2024, at 6:01 PM, Stefan Kangas  wrote:
> 
> Adam Porter  writes:
> 
>> Since transient.el is part of Emacs now, these kinds of menus should
>> probably be implemented with it.
> 
> IIUC, this is not a menu, but a reminder of key bindings that are usable
> in that context.  Other keybindings here are self-inserting keys, which
> are equally useful, and they wouldn't be available in a transient.

Also recall we had a discussion in bug#68236 
 about 
expanding quick-help to include mode-local personalized binding shortcuts (with 
org as a particular target of interest).  

Re: [BUG] Hard lockup on org-display-inline-images

[JD Smith]

> On Dec 5, 2023, at 7:26 AM, Ihor Radchenko  wrote:
> 
> JD Smith  writes:
> 
>> Eli and I recently patched a problem 
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67533> with pixel position 
>> reporting with inline images (which I had discovered in a large org buffer 
>> with latex-preview).  With this patch installed, now on master as of this 
>> evening, org-display-inline-images freezes emacs when a larger image is 
>> included in an org file, if org-indent is enabled. 
>> 
>> I’ve confirmed such images are fine in regular buffers by text-property or 
>> overlay, so I suspect this is a “revealed bug” in org-indent or the element 
>> cache.
> 
> I just tried to create a simple Org file with a png image link (on
> main, latest Emacs master), enabled org-indent-mode, and displayed the
> images. I see no problem.
> 
> Please provide more detailed instructions to reproduce the problem.


Apologies for not following up.  The problem was in recent display code 
improvements.  Eli fixed the introduced bug quite quickly in:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7a7d41e07c4627c5de08a66368309b478c88edfc

[BUG] Hard lockup on org-display-inline-images

[JD Smith]

Eli and I recently patched a problem 
 with pixel position 
reporting with inline images (which I had discovered in a large org buffer with 
latex-preview).  With this patch installed, now on master as of this evening, 
org-display-inline-images freezes emacs when a larger image is included in an 
org file, if org-indent is enabled. 

I’ve confirmed such images are fine in regular buffers by text-property or 
overlay, so I suspect this is a “revealed bug” in org-indent or the element 
cache.

Org 9.6.11

Thanks for your work on org!

Re: org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

[JD Smith]

> On Nov 13, 2023, at 3:37 AM, Ihor Radchenko  wrote:
> 
> JD Smith  writes:
> 
>> When `org-edit-src-content-indentation’ is non-nil (default: 2), editing SRC 
>> blocks preserves this amount of extra indentation space at the beginning of 
>> each line of the block, removing and then re-adding it on round trips 
>> through `org-edit-src-code’.
>> 
>> But `org-src-font-lock-fontify-block' does not consider this extra space. 
>> Instead it simply copies the full block verbatim into e.g.  
>> *org-src-fontification:python-mode*, as if the extra indent space were a 
>> legitimate part of the source.  Normally this wouldn’t be a problem, as 
>> faces are attached to keywords.  But for any fontification that depends 
>> explicitly on indentation, this leads to incorrect results.  For example, my 
>> indent-bars package adds indentation bars via text properties based on 
>> absolute column position.  These bars are then offset in the displayed org 
>> src block by 2 columns from their correct locations, due to the extra space 
>> org has put there.
> 
> Duplicate of
> https://list.orgmode.org/orgmode/CAOn=hbevUMGS0-qMTy8kB4-db65s1Tmn0cQJcw8b++PZZ=v...@mail.gmail.com/
> Handled.

Great.  In Org 9.7?

org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

[JD Smith]

When `org-edit-src-content-indentation’ is non-nil (default: 2), editing SRC 
blocks preserves this amount of extra indentation space at the beginning of 
each line of the block, removing and then re-adding it on round trips through 
`org-edit-src-code’.

But `org-src-font-lock-fontify-block' does not consider this extra space. 
Instead it simply copies the full block verbatim into e.g.  
*org-src-fontification:python-mode*, as if the extra indent space were a 
legitimate part of the source.  Normally this wouldn’t be a problem, as faces 
are attached to keywords.  But for any fontification that depends explicitly on 
indentation, this leads to incorrect results.  For example, my indent-bars 
package adds indentation bars via text properties based on absolute column 
position.  These bars are then offset in the displayed org src block by 2 
columns from their correct locations, due to the extra space org has put there.

A sensible solution might be for fontify-block to strip 
`org-edit-src-content-indentation’ worth of space from the beginning of each 
line, just as is done for src block editing, then perform the fontification, 
then add that space back to the fontified text for display.

Thanks for all your work on org.

Re: Mention outli, and h speed-key

[JD Smith]

> It is more visible, but I am trying to understand what o you consider better 
> then outline-minor-mode 

It sets up headline regexps automatically and consistently, and adds 
configurable styling and org-inspired speed keys on headings.  At core it is 
still outline mode.  Think of it like org-ified outshine-light.  

Mention outli, and h speed-key

[JD Smith]

Outli  is a small mode I wrote which very 
closely follows org in style and uses the same speed-keys on 
comments-as-headlines.  Basically if you know org, outli will be usable “out of 
the box”.  It might be good to mention outli in the Worg page 
 on org 
capabilities outside of org.

To quote from the README:

> • How does this relate to outline-minor-mode?
> 
> outli is mostly a convenient wrapper around functionality that is already 
> built-in to outline, adding a few things like narrow-to-subtree and 
> insert-heading-respect-content (ala org). And of course the speed-key 
> bindings, automatic comments-as-header patterns, and styling.

One speed key I added to outli I really miss in org, so I added it:

(if-let ((pos (cl-position '("Outline Visibility") org-speed-commands :test 
#'equal)))
  (cl-pushnew '("h" . outline-hide-sublevels) (nthcdr (1+ pos) 
org-speed-commands)))

Basically h=outline-hide-sublevels.  This allows you to quickly collapse the 
entire tree to the level [h]ere.  It’s a wonderful, fast compromise between the 
ease of Shift-Tab and org’s more targeted folding capabilities.

Thanks for your work on org!

Indenting a blank definition list item leaves point at beginning of line

[JD Smith]

Org 9.5.4 (point at `X’):

- foo :: bar X [M-Ret]
- X :: [M-right]

leaves point at beginning of line:

- foo :: bar
X  - :: 

If you add content first, point stays put.