folding day headings in org-agenda-mode?

[Matt Price]

I am very psyched to have started using Adam Porter's org-super-agenda, and
I really enjoy using origami-mode to fold section headings now.

However, I do really wish I could use the same keystroke to fold individual
days in the org agenda. I tried just invoking `origami-toggle-node from a
day header, and the results are unintuitive. in general, if I place the
cursor in a day header ("Friday 18 March 2022"), and invoke
`origami-toggle-node`, the header will disappear entirely, which is not the
behaviour I am looking for.

I imagine that, in order for folding to work, something has to be done to
make the folding mechanism aware of the syntactical units.

1) has anyone figured out a way to do this?
2) if not, does anyone have an idea of where I might look in the code for a
place to hack?
3) does this seem like something it would be worth having in org itself? It
feels like it would be a common use case.

thanks as always,

Matt

Re: profiling latency in large org-mode buffers (under both main & org-fold feature)

[Max Nikulin]

On 02/03/2022 22:12, Ihor Radchenko wrote:

Max Nikulin writes:

I tend to agree after reading the code again.
I tried to play around with that marker loop. It seems that the loop
should not be mindlessly disabled, but it can be sufficient to check
only a small number of markers in front of the marker list. The cached
temporary markers are always added in front of the list.


I did not try to say that the loop over markers may be just thrown away. 
By the way, for sequential scan (with no backward searches) single 
marker might work reasonably well.


Some kind of index for fast mapping between bytes and positions should 
be maintained at the buffer level. I hope, when properly designed, such 
structure may minimize amount of recalculations on each edit. I mean 
some hierarchical structure of buffer fragments and markers keeps 
relative offsets from beginning of the fragment they belong to. 
Hierarchy of fragments is enough to provide initial estimation of 
position for byte index. Only markers within the fragment that is 
changed need immediate update.



I am currently using a custom version of org-ql utilising the new
element cache. It is substantially faster compared to current
org-refile-get-targets. The org-ql version runs in <2 seconds at worst
when calculating all refile targets from scratch, while
org-refile-get-targets is over 10sec. org-ql version gives 0 noticeable
latency when there is an extra text query to narrow down the refile
targets. So, is it certainly possible to improve the performance just
using high-level org-element cache API + regexp search without markers.


It is up to you to choose at which level your prefer to optimize the 
code. And it is only my opinion (I do not insist) that benefits from 
changes in low level code might be much more significant. I like the 
idea of markers, but their current implementation is a source of pain.



(note that Nicolas did not use
markers to store boundaries of org elements).


E.g. export-related code certainly does need markers. You experienced 
enough problems with attempts to properly invalidate cache when lower 
level is not supposed to provide appropriate facilities.

Re: org-modern

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> It does not affect performance a lot. I almost can't feel the latency 
> difference between disable or
> enabled org-modern. I have 3M org file which has lot of source blocks and 
> tags list etc. (I know 3M
> is not very large.)
>
> I like this package indeed beatified org-mode a lot.

I can confirm that performance is not significantly affected (17M file).
AFAIU, org-modern does the right thing by utilising font-lock and not
forcing fontification of the whole file. So, jit-lock can do its job of
on-demand and asynchronous fontification.

Best,
Ihor

Re: org-modern

[Christopher M. Miles]

Tim Cross  writes:

> William Denton  writes:
>
>> I noticed org-modern in the list of new packages available:
>>
>> https://github.com/minad/org-modern
>>
>> Worth a look by any Org users, just for the screenshots comparing Org 
>> buffers normally and with
>> org-modern.  Fine work from Daniel Mendler, who I think is on this list.  
>> I'm trying it out
>> right now.
>>
>
> I was looking at this package and it looks interesting. However, I do
> wonder how much of an impact it has on org performance. I suspect it
> will have a significant impact on large org files. Would be interested
> in hearing how people find it with larger files.

It does not affect performance a lot. I almost can't feel the latency 
difference between disable or
enabled org-modern. I have 3M org file which has lot of source blocks and tags 
list etc. (I know 3M
is not very large.)

I like this package indeed beatified org-mode a lot.

-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: org-refile, org-capture byte-compiling failure with recent emacs-git

[Vladimir Lomov]

Hello,
** Kyle Meyer  [2022-03-02 23:11:53 -0500]:

> Kyle Meyer writes:

>> Kyle Meyer writes:
>>
>>> However, it seems unintended that with-demoted-errors would actually
>>> error here now rather than give a warning; again, will need to take a
>>> closer look.
>>
>> The patch at  demotes the error to the
>> intended warning.

> And Emacs's d52c929e3 has been ported to Org's bugfix branch to avoid
> these failures regardless of whether the patch there is applied.

Thank you Kyle, commit 91681fc03 compiles fine.

---
WBR, Vladimir Lomov

-- 
Nearly every complex solution to a programming problem that I
have looked at carefully has turned out to be wrong.
-- Brent Welch


signature.asc
Description: PGP signature

Re: org-cite and org-ref-cite

[Eric S Fraga]

On Sunday, 27 Feb 2022 at 10:38, Henrik Frisk wrote:
> I see. Didn't realize that. I will look into citar then, thanks!

citar works very well.  Recommended.

-- 
: Eric S Fraga, with org release_9.5.2-386-g77d942 in Emacs 29.0.50

Faulty SVG width in default HTML export style

[Yuchen Guo]

Currently the style specified for SVG images
in `org-html-style-default' variable is the following:

.org-svg { width: 90%; }

This causes a single image (math formula) to occupy almost the width of
the entire page, rendering the page unreadable.

In my experiment removing this line fixed the issue.

Two PNG screenshots demostrating the issue is available under the
following links:

https://w.wiki/4uQd
https://w.wiki/4uQe

-- 
Yuchen Guo