Re: org-startup-folded does not work with directory local variables

[Ihor Radchenko]

Robert Pluim  writes:

> I was talking about #+STARTUP: (Iʼm assuming #+SETUPFILE: also works,
> but I haven't tried it).

FYI. #+SETUPFILE also does work.

Best,
Ihor

Re: Bug ? : No indentation for the text in inline tasks

[Ihor Radchenko]

Nicolas Odermatt-Lemay  writes:

> I say it isn't properly indented in the case of inline tasks because the
> text belonging to the inline task (not the header itself) isn't aligned
> with the first character of the header (see example below)
>
> * Header Level 1
>   The text belonging to level-1 header
>
>*** Inline Task
> Text belonging to inline task
>*** END
>
> This is what I would be expecting, but maybe this is not the desired
> behavior, in which case I am wrong to think it is a bug:
>
> * Header Level 1
>   The text belonging to level-1 header
>
>*** Inline Task
>Text belonging to inline task
>*** END

Indentation of text inside inlinetasks is intentionally the same with
the parent task. Inlinetasks are not considered headings. Rather a
special kind of paragraph.

For many years, Org is deliberately indenting text inside inlinetasks as
in the screenshot:

I say deliberate because there is a commit introducing exactly this
behaviour:

56cd178caebd061c992d4c7c682d0e4dc2c40f26
Author: Nicolas Goaziou 
AuthorDate: Fri Aug 21 14:44:26 2015 +0200
Commit: Nicolas Goaziou 
CommitDate: Fri Aug 21 14:44:26 2015 +0200

org-indent: Fix indentation in inline tasks

* lisp/org-indent.el (org-indent-add-properties): Indent inline tasks'
  contents according to current outline level, not inlinetask's.  This
  is consistent with hard indentation, using `org-indent-line'.

If others think that this default should be changed, they are free to
jump into the discussion.

Best,
Ihor

Re: from table to properties the inverse columview operation

[TRS-80]

Uwe Brauer  writes:

> Hi
>
> I have for example 
>
> * Grupos   :noexport:
>   :PROPERTIES:
>   :EXPORT_OPTIONS: num:t
>   :COLUMNS:  %10GRP(Grupos) %10HOJA(Hoja Nr) %10EJ(Ejericio Nr) %17DATE(Date) 
> %7STATUS(Status){X/}
>   :ID:   Grupos
>   :END:
>
> ** WAIT 1 <2022-02-03 jue 16:30> :Annu22: User
>:PROPERTIES:
>:ID:   6c53abda-5351-4651-8ec0-60138b248baa
>:Email:u...@gmail.com
>:Grp:  Gr1
>:Usuario1: User1
>:Email1:   us...@gmail.com
>:Usuario2: User2
>:Email2:   us...@gmail.com
>:StEnv1:   [X]
>:H1:   9 
>:P1:   5
>:End:
>
> ** <2022-03-06 dom 18:16> : Ejercicios elegidos de la Hoja1: quien puede 
> hablar el día <2022-03-07 lun>
>
> #+TBLNAME: hoja1
> #+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :indent nil :hlines 1  
> :format "%5TODO(Status) %5Grp(Grupo) %5Usuario1(Miembro1) %5H1(Ejercicio 
> elegido) %5P1(Porcentaje) %7StEnv1(Solución enviado){X/}"
>
> | Status | Grupo | Miembro1 | Ejercicio elegido | Porcentaje | Solución 
> enviado |
> |+---+--+---++--|
> ||   |  |   || [1/1]  
>   |
> | WAIT   | Gr1   | User1| 9 |  5 | [X]
>   |
> #+END
>
> So a table is generated based on earlier entries. 
>
> Is there the inverse operation? Given a table I recover the original
> properties?

I think it might be easier to do in awk than ELisp.  And I am better in
Elisp than awk, but awk was made for almost exactly this sort of thing.

Anyway, if some existing (Elisp) function exists for this, I would like
to know about it as well[0].

Cheers,
TRS-80

[0] I have already re-implemented too many things which already
existed, that I just did not know about at the time!  :D

Re: Org and multimedia (tips?)

[TRS-80]

Juan Manuel Macías  writes:

> Hi all,
>
> I've been trying for a while to use Org also to store and org-anize the
> data of my music and video files, so that I can conveniently access them
> via helm-org-ql and play them using EMMS.

I mean, I love Org just as much as anyone else on this list, but it does
not strike me as the right tool for this job?

In my mind anyway, I think first -- especially since you are storing
your files on an SBC on the network -- about some network based music
player like mpd or Mopidy (there are others, too).

There are many interfaces to those, including some in Emacs (maybe even
within EMMS, if I am recalling correctly).

But then you can also access your music from outside Emacs, too.  And
without needing to hack something up / re-invent the wheel in Org.

However, if you like to hack something up in Org instead, by all means,
continue!  :)

Cheers,
TRS-80

Re: Is there a maintained calf-calendar fork?

[TRS-80]

Ypo  writes:

> within a calendar: https://github.com/kiwanami/emacs-calfw
>
> But it seems to be unmaintained.
>
> Is there some *recommended *fork on Github with corrected bugs or new
> functions?

I don't know about *recommended*, however I do see at least a couple
names I recognize in the list of forks (jweigley, syohex)[0].

I do not know of a way, in the GitHub UI (or through their API) to see
which one of those forks might be ahead by the most number of
commits[1].  Which means instead clicking on each one manually and
looking at it.  If there is some better way, I would love to know about
it.

> Offtopic if the answer to the above question is affirmative: could it
> be on MELPA? Can MELPA change to new forks?

I also see emacsmirror in the list.  Maybe raise an issue there (or at
Emacs Orphanage, etc.), maybe they know something more.

Finally, there is always the option of picking up maintenance yourself.
It often begins simply enough, fixing something that broke for
yourself...  Next thing you know you are sharing those patches, before
you know it... you are suddenly maintaining a package.  :)

Just some food for thought.

Cheers,
TRS-80


[0] https://github.com/kiwanami/emacs-calfw/network/members

[1] Not that this is a guarantee of anything, but it is one indication.

Re: Citation glitch

[Alan Tyree]

I'm not sure.

citeproc-0.9
citeproc-org-0.2.4

On Thu, 5 May 2022 at 10:34, Bruce D'Arcus  wrote:

> It seems this should have been fixed late in citeproc-el in 2021:
>
> https://github.com/andras-simonyi/citeproc-el/issues/72
>
> Are you using the most up-to-date code?
>
> On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:
>
>> G'day,
>> I have a citation problem. The bibtex entry is:
>> @TechReport{name32:_some,
>>   author = {{Some Company Name}},
>>   title = {Some silly internal document},
>>   institution =  {Some Company Name Ltd},
>>   year = 1832}
>>
>> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>>
>> Org exports to html: Name, Some Company, *Some Silly Internal Document*
>> (Some Company Name Ltd, 1832).
>>
>> I thought it was a CSL problem, but pandoc exports it correctly as Some
>> Company Name, etc.
>>
>> Any help appreciated,
>> Alan
>>
>>
>> --
>> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>>
>>

-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: Google Docs now supports MarkDown, but not Org syntax

[TRS-80]

Ken Mankoff  writes:

> Google Docs now supports MarkDown, not Org syntax :(.
>
> https://workspaceupdates.googleblog.com/2022/03/compose-with-markdown-in-google-docs-on.html
>
>   -k.

There is a Free Software (AGPL3.0) alternative to Google Docs called
HedgeDoc.  We have used it a little bit (within Armbian project) and I
think it's pretty neat! [0]

>From their web page:

> HedgeDoc
> The best platform to write and share markdown.
>
> HedgeDoc (formerly known as CodiMD) is an open-source, web-based,
> self-hosted, collaborative markdown editor.
>
> You can use it to easily collaborate on notes, graphs and even
> presentations in real-time. All you need to do is to share your
> note-link to your co-workers and they’re ready to go.

Of course it does not do everything that Google Docs does.  But for
common use-case of simple documents, it works quite well for
collaboration.

Unfortunately, HedgeDoc does not support Org Mode markdown, either.  But
at least, in this case, thanks to F/LOSS, the possibility exists (at
least in theory) to add it.

Cheers,
TRS-80

[0] Even though I personally prefer Org over MD by quite a huge margin,
MD is what the Armbian project uses, so, 'when in Rome...'

Re: Citation glitch

[Bruce D'Arcus]

It seems this should have been fixed late in citeproc-el in 2021:

https://github.com/andras-simonyi/citeproc-el/issues/72

Are you using the most up-to-date code?

On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:

> G'day,
> I have a citation problem. The bibtex entry is:
> @TechReport{name32:_some,
>   author = {{Some Company Name}},
>   title = {Some silly internal document},
>   institution =  {Some Company Name Ltd},
>   year = 1832}
>
> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>
> Org exports to html: Name, Some Company, *Some Silly Internal Document*
> (Some Company Name Ltd, 1832).
>
> I thought it was a CSL problem, but pandoc exports it correctly as Some
> Company Name, etc.
>
> Any help appreciated,
> Alan
>
>
> --
> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>
>

Re: Organice with local WebDAV server on PinePhone

[TRS-80]

Neil Jerram  writes:

> I've been thinking about how to get nice Org access on my PinePhone. My
> current favoured option is Organice, with a local WebDAV server on the
> phone. My Org is mastered in a hosted git repo, and I already have a script
> for syncing between that and a local clone on various devices. I think I
> just need to enhance that script to pull from WebDAV to the local git
> working tree, before committing and syncing local updates, and to push to
> WebDAV after pulling in remote updates.
>
> Any thoughts, on whether that would work well, if it could be simplified or
> improved, or alternative solutions?
>
> Best wishes,
>   Neil

I keep thinking that the keyboard is going to be the key[0] to achieving
Emacs / Org Mode editing nirvana on my PinePhone.  But I will have let
you know if that's true or not, after it arrives.  :)

I already sync my Org Mode files (amongst other things) across all my
devices using Syncthing.  I use git for plenty of other things, but not
for Org files.  I edit them far too often, so I don't want to add any
friction to that process.

Cheers,
TRS-80

[0] No pun intended.

Citation glitch

[Alan Tyree]

G'day,
I have a citation problem. The bibtex entry is:
@TechReport{name32:_some,
  author = {{Some Company Name}},
  title = {Some silly internal document},
  institution =  {Some Company Name Ltd},
  year = 1832}

The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl

Org exports to html: Name, Some Company, *Some Silly Internal Document*
(Some Company Name Ltd, 1832).

I thought it was a CSL problem, but pandoc exports it correctly as Some
Company Name, etc.

Any help appreciated,
Alan


-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: Thanks for good docs

[TRS-80]

Eric S Fraga  writes:

> I'm in total agreement.  The indexing of the org info manual is
> excellent and generally gets me to what I want very quickly.

The Info format has really grown on me, too!

Once I learned I could quite easily export from Org to Info[0], I
started using it even more!  I even made an Info manual for my own
personal dotfiles repo!  :D

Cheers,
TRS-80

[0] Try for yourself and see!

[tip] direct specification of deadline warning days without editing text

[Samuel Wales]

in retrospect this solution is completely obvious but i thought i
would mention it in case somebody searches for it.

in agenda, i do c-u c-u c-d.  this allows me to remove deadline
warning days [RET, very convenient!] or specify them.

a good thing about this feature is that there is less chance of
manually creating a format error in the timestamp as would occur by
going to the ts and editing it manually.  also it seems nothing is
relative to the existing warning.  that is good.

the prompt, however, seems geared toward specifying a date.  you can
specify indirectly the deadline warning days by specifying the date
that would be the warning.  the question is, can we specify deadline
warning days directly?

here is where it is obvious in retrospect but as i was not thinking in
terms of default date it was not.

suppose i want deadline warning days of -2d but do not want to
manually edit the ts or calculate the corresponding date.

if the deadline is somewhat in the future but displayed in the
deadline section of the agenda, and i try c-u c-u c-d, the following
intuitive ideas do not work: 2, -2, 2d, -2d, and as desperation,
trying the in retrospect nonsensical . first.

i wasn't fully cogitating that the prompt was date oriented but that
the default date is the ts date and can work.

i read the manual for my obsolete version of org (info "(org) The
date/time prompt") and my brain did not find it.  i was looking at the
examples for things like -- even though they were mentioned in the
text.

solution seems to be --2d.  whether modern org needs to include a few
examples with -- or not, idk.

idk if that helps anybody [it is going to take much time to upgrade].

Re: Fixing the automatic generation of Tex info node names

[TRS-80]

Philip Kaludercic  writes:

> Ihor Radchenko  writes:
>
>> Philip Kaludercic  writes:
>>
>>> For some reason ox-texinfo removes periods from node names.  It seems
>>> this is not necessary as info can render these files without any issues,
>>> and in certain cases not intended (e.g. I had a node named "Emacs 28.1"
>>> and it was abbreviated to "Emacs 281").
>>
>> According to
>> https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Node-Line-Requirements
>>
 Unfortunately, you cannot reliably use periods, commas, or colons
 within a node name; these can confuse the Info reader. Also, a node
 name may not start with a left parenthesis preceding a right
 parenthesis, as in (not)allowed, since this syntax is used to specify
 an external manual. (Perhaps these limitations will be removed some
 day.)
>>
>> Not that we cannot work around this, but we need something different
>> than the proposed patch.
>
> Would you happen to know what the issue is?  As I said, the documents
> appear to render just as expected in my case, but it might just be due
> to the version or because I didn't hit some specific edge-case.

Personally, if I were interested, I think I would follow-up to the
texinfo mailing list (or whatever they have) and ask them?  As it even
says above:

> Perhaps these limitations will be removed some day

Maybe they already have been?  If not, worst case, I think you probably
learn more about what the problem might be.

Just a thought.

Cheers,
TRS-80

Re: org table: generate a weekly calendar with column that represents the hours

[TRS-80]

Uwe Brauer  writes:

> I am looking for  convenient method to generate a weekly calendar in
> table form that looks like
>
> #+begin_src 
>
> |   Hours | Mon | Tue | Wed | Thu | Fri |
> |   8:00-9:00 | | | | | |
> |  9:00-10:00 | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | | | | | | |
> | 19:00-20:00 | | | | | |
> #+end_src
>
> But, of course the missing hours should be inserted automatically.
>
> A poor man's solution would be to do it manually and to save the table
> as a template, but is there a way to generate it using org's table
> functionality?

Eric gave you a way that you asked (using Org table functionality), but
another way could be to simply use a bunch of insert statements.  Or
rather, 1-2 to insert the header, followed by a loop with a starting
time, interval, etc.

Two advantages to that approach:

1. You could specify start, end time and resolution (spacing) as
arguments (might not be needed).

2. You would not need a 'duration' column.

3. No need for formula (which leaves more room for your own, should you
need it).

Just another way to do the same thing.

Cheers,
TRS-80

Re: [tip] Org speed commands improved

[TRS-80]

Juan Manuel Macías  writes:

> Hi Ihor,
>
> Ihor Radchenko writes:
>
>> If you are going this far with speed commands, you might as well switch
>> to modal editing. What you are describing is basically a modal command
>> map with ability to switch to insert map.
>
> I'm not a fan of modal editing, rather the opposite. But in this
> particular case I have found that I spend very little time editing the
> raw content of the headers, once I set it. I spend more time editing the
> 'meta-content': TODO states, properties, tags, refile, attached folders,
> etc. And that with the speed commands can be achieved in a very agile
> way, so that a small dose of controlled modal editing and reduced only
> to the header, maybe it's worth it :-) If the speed commands were also
> activated in the content of the sections, here we would have a real
> modal editing, and that (in my case) would not be comfortable.

I agree with your assessment!  In fact, I think I will give your
functions a try.  Thanks for sharing them!

Cheers,
TRS-80

Re: [BUG] - Statistics cookie is part of the org heading title

[Nick Dokos]

Fabian  writes:

> Hi everybody,
>
> I would like to report his behaviour as a bug:

A crucial piece of information is missing here: this concerns the
behavior of the function `org-heading-components'.

> 
> Example:
>
> * Some Heading Title [0/1]  ;; cursor in this line when executing
> ** TODO Some Todo Item
>
> -> result is "Some Heading Title [0/1]"
>
> -> desired result would be "Some Heading Title"
> 
>
> I don't see any reason why the statistics cookie should be part of
> the title: it should be a separate component.
>
> The Topic has beend posted on Stack here:
> https://emacs.stackexchange.com/questions/71592/extract-org-heading-title-without-task-count-e-g-0-0?noredirect=1#comment115659_71592
>
> Best Regards, 
>
> Fabian
>
>

-- 
Nick

"There are only two hard problems in computer science: cache invalidation, 
naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH v3] org-encode-time compatibility and convenience helper

[Max Nikulin]

On 04/05/2022 16:56, Ihor Radchenko wrote:

Max Nikulin writes:

1 unexpected results:
FAILED  test-org-clock/clocktable/ranges


Thank you, Ihor. I run tests in containers with UTC timezone, so I did 
not notice such failure. So unit tests reveal a problem with tests.


`org-read-date-analyze' returns additional nil -1 nil now to allow 
passing its result directly to `encode-time'. 
`org-test-clock-create-timestamp' replaces nils by 0, so default 
timezone becomes UTC.


I will try to fix the test helper later.

Re: [org-contrib] Take over maintaining of org-contacts.el

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> Hi Danjou, Since the package org-contacts.el is not maintained for a long 
>> time. I would like to take
>> over maintaining of org-contacts.el. What do you think? I used to send you 
>> an email with asking. But
>> got no response.
>>
>> Hi Bastien, If org-contacts.el author is not response for a long time, can 
>> you remove
>> org-contacts.el out from org-contrib? I have already added a separated 
>> repository for org-contacts.el
>> https://repo.or.cz/org-contacts.git
>>
>> If approved, I will update on MELPA by adding a new recipe for 
>> org-contacts.el.
>
> I noticed that Bastien did put your repo as a new home for org-contacts:
> https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/org-contacts.el:
>>> homepage: https://github.com/stardiviner/org-contacts.el
>
> Note, however, that the repo is your (deleted?) github repo.
> Should we update the homepage repo in org-contrib to 
> https://repo.or.cz/org-contacts.git?
>
> Best,
> Ihor

Yes, please update to new place: https://repo.or.cz/org-contacts.git.
Thanks for checking this up, I have not realized missed migration of 
org-contacts repo.

-- 
[ 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

[PATCH] New LaTeX code export option: engraved

[Timothy]

Hi All,

I’ve been fairly busy as of late (hence my recent silence on this ML), however I
have a patchset that’s been in the works for a while that I’ve finally polished
up.

Short version: It adds a new (superior) option for exporting code blocks with
syntax highlighting to LaTeX.

The long version follows.

Currently there are four options for exporting code to LaTeX (ordered by
complexity/quality).
1. Verbatim, which simply includes the code unstyled
2. Custom, which puts the code in an enviroment of your choice
3. Listings, which uses the LaTeX package by this name. This is quick, but
   exceedingly basic.
4. Minted, which uses the LaTeX package by this name. This is slow, but produces
   better results than Listings

This patchset accomplishes two things:
1. It refactors the overly large `org-latex-src-block' function, and makes a few
   other improvements to pre-existing code
2. It adds a new option for exporting code, named (you guessed it!) “engraved”

What is this new option, and why do we want it?

About a year ago I started work on a package that generalises the functionality
of `htmlize.el', termed `engrave-faces'
(). It provides the ability to
extract font-lock information and export it to a number of formats: html, ansi,
and (crucially) LaTeX! Since the LaTeX export is built on the `fvextra' (LaTeX)
package (like pygments), the vast majority of the Minted options you’re used to
just carry over.

This allows for a result that is, I think, straight up better than all the
pre-existing options. For starters, you can now apply syntax highlighting to any
language you have a major mode for.

There are a number of optimisations unattempted, but it already significantly
outperforms Minted. Here are some timings from my `config.org':


 LaTeX code backend  Compile time  Overhead  Overhead ratio 

 verbatim12 s  00.0 
 lstlistings 15 s  3 s  0.2 
 Engrave 34 s  22 s 1.8 
 Pygments (Minted)   184 s 172 s   14.3 


Compared to Minted, we also no longer have to install `pygments' or pass the
`--shelll-escape' flag to LaTeX to generate passable code blocks.

Having an all-emacs system also allows for some nifty things, like having entire
documents/presentations based on your Emacs theme (see
). Demo images: 
,
.

Here are some more screenshots to see what the result can look like in practice:
• 
• 
• 

So, please take a look at the patches, give this a whirl, and let me know what
you think! 

All the best,
Timothy
>From 87872cc8f2fb1da1a03dc4aadfbd4af6541d8c13 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 1/4] ox-latex: Refactor `org-latex-src-block'

* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
 lisp/ox-latex.el | 339 ++-
 1 file changed, 185 insertions(+), 154 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..63855d2f6 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
 	   (float (plist-get attributes :float))
 	   (listings (plist-get info :latex-listings)))
   (cond
-   ;; Case 1.  No source fontification.
((or (not lang) (not listings))
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
-  (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
-  (if caption-above-p caption-str "")
-  verbatim
-  (if caption-above-p "" (concat "\n" caption-str
-(t verbatim
-   ;; Case 2.  Custom environment.
+(org-latex-src-block--verbatim 

Re: Reply to list from lists.gnu.org archives

[Ihor Radchenko]

Max Nikulin  writes:

>>> I replied to this bug report yesterday via the "reply via email to"
>>> button in
>>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
>>> assuming it would send it to the org-mode list, but now I see that it
>>> was only sent to Fabian.
>> 
>> It is not directly related to Org, though indeed annoying. I reported
>> this unexpected behaviour to mail...@gnu.org
>
> There is an old request:
>
> https://savannah.nongnu.org/support/?109873
> sr #109873: Consider adding "Reply to All/List" buttons to GNU mailing 
> list archives
> Fri 09 Aug 2019 06:30:18 AM UTC

FYI. I just got the following reply:

> Ihor Radchenko  writes:
> 
> > Hi,
> > We just got a confused user who tried to reply to a thread in
> [ 5 more citation lines. Click/Enter to hide. ]
> > https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00075.html
> > via web "Reply" button. The button provides a mailto:? link, but it only
> > sets the To: field to the current message author. The list is not CCed.
> >
> > Expected behaviour would mimic Reply All functionality of mail clients.
> >
> > Best,
> > Ihor
> 
> Thanks for mentioning this. We got a patch sent in recently to fix this
> and I just haven't had time to work on it. I expect to have time this week.
> 
> [ 4-line signature. Click/Enter to hide. ]
> -- 
> Ian Kelling | Senior Systems Administrator, Free Software Foundation
> GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
> https://fsf.org | https://gnu.org

Best,
Ihor

Reply to list from lists.gnu.org archives

[Max Nikulin]

On 04/05/2022 18:56, Ihor Radchenko wrote:

Ignacio Casso writes:


I replied to this bug report yesterday via the "reply via email to"
button in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
assuming it would send it to the org-mode list, but now I see that it
was only sent to Fabian.


It is not directly related to Org, though indeed annoying. I reported
this unexpected behaviour to mail...@gnu.org


There is an old request:

https://savannah.nongnu.org/support/?109873
sr #109873: Consider adding "Reply to All/List" buttons to GNU mailing 
list archives

Fri 09 Aug 2019 06:30:18 AM UTC

It seems only someone from Debian listmasters managed to configure 
MHonArc to add reply to list option. I am not familiar with the archive 
generator, so I am unsure if e.g. LIST resource is available out of the 
box or it is Debian customization. At least it is not mentioned in the 
docs. Unfortunately there is no e.g. a public repository with 
configuration of lists.debian.org.


In the case of lists.gnu.org it is necessary to update a python script 
that assembles mailto link from fragments (some anti-spam stuff).

Re: org-startup-folded does not work with directory local variables

[Robert Pluim]

> On Wed, 04 May 2022 22:46:56 +0800, Ihor Radchenko  
> said:

Ihor> Robert Pluim  writes:
Ihor> This is no different. org-startup-folded controls loading of Org mode.
Ihor> However, Emacs applies directory-local variables and file-local
Ihor> variables _after_ loading Org mode. Org cannot do much about it 
without
Ihor> hacking Emacs defaults.
>> 
>> Weʼre in agreement there. My point is that itʼs not a bug (although I
>> guess you could ask for a feature to apply local/directory variables
>> before applying the mode

Ihor> It's not exactly a bug, but feature request to Emacs is exactly what I
Ihor> was implying.

Right. My predictatron says itʼs unlikely to be greeted
enthusiastically.

>> , but in this case thereʼs an easy
>> workaround).

Ihor> I am not sure which workaround you are referring to.
Ihor> Setting org-startup-folded globally? On per-file basis? the former is
Ihor> global and will apply to broader scope than a directory-local 
variable.
Ihor> The latter only works in a single file (and works instead of 
file-local
Ihor> variable).

I was talking about #+STARTUP: (Iʼm assuming #+SETUPFILE: also works,
but I haven't tried it).

Robert
-- 

Re: org-startup-folded does not work with directory local variables

[Ihor Radchenko]

Robert Pluim  writes:

> Ihor> This is no different. org-startup-folded controls loading of Org 
> mode.
> Ihor> However, Emacs applies directory-local variables and file-local
> Ihor> variables _after_ loading Org mode. Org cannot do much about it 
> without
> Ihor> hacking Emacs defaults.
>
> Weʼre in agreement there. My point is that itʼs not a bug (although I
> guess you could ask for a feature to apply local/directory variables
> before applying the mode

It's not exactly a bug, but feature request to Emacs is exactly what I
was implying.

> , but in this case thereʼs an easy
> workaround).

I am not sure which workaround you are referring to.
Setting org-startup-folded globally? On per-file basis? the former is
global and will apply to broader scope than a directory-local variable.
The latter only works in a single file (and works instead of file-local
variable).

Best,
Ihor

Re: Recent changes in org-fold regarding emphasize visibility

[Ihor Radchenko]

Daniel Fleischer  writes:

> (setq org-fold-catch-invisible-edits 'show-and-error)
>
> in order to prevent accidental write in the following places:
>
> :PROPERTIES:|...
>
> But now, hidden emphasize symbols are considered "folded" so when I
> write:
>
> *Hello*|
>
> and about to press "space" I get a warning.
>
> I think this is a regression. I don't want to change the
> `org-fold-catch-invisible-edits' variable to something else because I
> worry more about accidental edits in real folded regions. I don't
> understand why emphasize markers are treated as folded text.
>
> `org-hide-emphasis-markers` is set to non-nil. 

Fixed on main by d2a459d25

Best,
Ihor

Re: org-startup-folded does not work with directory local variables

[Robert Pluim]

> On Wed, 04 May 2022 21:46:14 +0800, Ihor Radchenko  
> said:

Ihor> Robert Pluim  writes:
Ihor> I recommend reporting this to Emacs bug tracker.
>> 
>> I donʼt think this is a bug: directory-local variables are supposed to
>> behave the same as file-local variables, and setting
>> org-startup-folded in a local variable section also doesnʼt get
>> applied.

Ihor> This is no different. org-startup-folded controls loading of Org mode.
Ihor> However, Emacs applies directory-local variables and file-local
Ihor> variables _after_ loading Org mode. Org cannot do much about it 
without
Ihor> hacking Emacs defaults.

Weʼre in agreement there. My point is that itʼs not a bug (although I
guess you could ask for a feature to apply local/directory variables
before applying the mode, but in this case thereʼs an easy
workaround).

Robert
-- 

Re: org-startup-folded does not work with directory local variables

[Ihor Radchenko]

Robert Pluim  writes:

> Ihor> I recommend reporting this to Emacs bug tracker.
>
> I donʼt think this is a bug: directory-local variables are supposed to
> behave the same as file-local variables, and setting
> org-startup-folded in a local variable section also doesnʼt get
> applied.

This is no different. org-startup-folded controls loading of Org mode.
However, Emacs applies directory-local variables and file-local
variables _after_ loading Org mode. Org cannot do much about it without
hacking Emacs defaults.

Best,
Ihor

Re: [BUG] - Statistics cookie is part of the org heading title

[Alexander Adolf]

Cool! Thanks for the swift confirmation. 

  --alex

-- 
www.condition-alpha.com / @c_alpha
Sent from my iPhone; apologies for brevity and autocorrect weirdness. 

> On 4. May 2022, at 15:00, Ihor Radchenko  wrote:
> 
> Alexander Adolf  writes:
> 
>> Would “fixing” this also remove the statistics cookie from agenda views? 
>> That would be a pity as I find it very useful there for my ways of using 
>> Org. 
> 
> No
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: org-startup-folded does not work with directory local variables

[Robert Pluim]

> On Wed, 04 May 2022 18:37:47 +0800, Ihor Radchenko  
> said:

Ihor> Max Fujimoto  writes:
>> Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo 
version 1.17.6)
>> 
>> The variable org-startup-folded does not work expected in
>> .dir-locals.el.The option "#+startup: fold" works as expected.

Ihor> This is because Emacs loads directory-local variables _after_ Org mode
Ihor> is loaded. That is, you set org-startup-folded after startup is
Ihor> complete.

Ihor> I recommend reporting this to Emacs bug tracker.

I donʼt think this is a bug: directory-local variables are supposed to
behave the same as file-local variables, and setting
org-startup-folded in a local variable section also doesnʼt get
applied.

Robert
-- 

Recent changes in org-fold regarding emphasize visibility

[Daniel Fleischer]

There are some recent (week old) changes to org-fold that changes
fold/emphasize behavior. Before the changes, I used to have

(setq org-fold-catch-invisible-edits 'show-and-error)

in order to prevent accidental write in the following places:

:PROPERTIES:|...

But now, hidden emphasize symbols are considered "folded" so when I
write:

*Hello*|

and about to press "space" I get a warning.

I think this is a regression. I don't want to change the
`org-fold-catch-invisible-edits' variable to something else because I
worry more about accidental edits in real folded regions. I don't
understand why emphasize markers are treated as folded text.

`org-hide-emphasis-markers` is set to non-nil. 

Best,

-- 

Daniel Fleischer

Re: [BUG] - Statistics cookie is part of the org heading title

[Ihor Radchenko]

Alexander Adolf  writes:

> Would “fixing” this also remove the statistics cookie from agenda views? That 
> would be a pity as I find it very useful there for my ways of using Org. 

No

Re: [BUG] - Statistics cookie is part of the org heading title

[Alexander Adolf]

Would “fixing” this also remove the statistics cookie from agenda views? That 
would be a pity as I find it very useful there for my ways of using Org. 

Cheers,

  --alex

-- 
www.condition-alpha.com / @c_alpha
Sent from my iPhone; apologies for brevity and autocorrect weirdness. 

> On 4. May 2022, at 14:24, Ihor Radchenko  wrote:
> 
> Ignacio Casso  writes:
> 
>> I replied to this bug report yesterday via the "reply via email to"
>> button in
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
>> assuming it would send it to the org-mode list, but now I see that it
>> was only sent to Fabian.
> 
> It is not directly related to Org, though indeed annoying. I reported
> this unexpected behaviour to mail...@gnu.org
> 
>> Still, I think it might be interesting to compare this topic with the
>> one I linked in my reply,
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html,
>> which it's basically the same bug report but about COMMENT keywords. In
>> that regard, I have tested that org-capture targets do work regardless
>> of statistcs cookies. Could not something equivalent be done so that
>> they also work regardless of COMMENT keywords? Feel free to reply in
>> that other thread if you feel this is off-topic here.
> 
>> This bug is related with the issue I reported in
>> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The
>> problem is that `org-heading-components' uses
>> `org-complex-heading-regexp', which does not consider statistics
>> cookies, and neither COMMENT keywords as I reported. I think it should be
>> updated to consider both.
> 
> Note that org-complex-heading-regexp-format does consider statistics
> cookies, but only at the beginning/end of the headline title.
> Unfortunately, it is impossible to provide generic printf format to
> match a headline title with arbitrary statistics cookies inserted in the
> middle of it.
> 
> As for your other report, it is a hard one - org-complex-heading-regexp
> is hard to modify because we guarantee certain match groups and its hard
> to fit COMMENT in there without breaking backward-compatibility.
> 
> I generally dislike the idea of the available plethora of analytic
> regexps with numbered match groups. I am currently working on
> generalised Org element matcher that provides named groups for arbitrary
> Org syntax elements, including headlines.
> 
> Best,
> Ihor
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] - Statistics cookie is part of the org heading title

[Ihor Radchenko]

Ignacio Casso  writes:

> I replied to this bug report yesterday via the "reply via email to"
> button in
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
> assuming it would send it to the org-mode list, but now I see that it
> was only sent to Fabian.

It is not directly related to Org, though indeed annoying. I reported
this unexpected behaviour to mail...@gnu.org

> Still, I think it might be interesting to compare this topic with the
> one I linked in my reply,
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html,
> which it's basically the same bug report but about COMMENT keywords. In
> that regard, I have tested that org-capture targets do work regardless
> of statistcs cookies. Could not something equivalent be done so that
> they also work regardless of COMMENT keywords? Feel free to reply in
> that other thread if you feel this is off-topic here.

> This bug is related with the issue I reported in
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The
> problem is that `org-heading-components' uses
> `org-complex-heading-regexp', which does not consider statistics
> cookies, and neither COMMENT keywords as I reported. I think it should be
> updated to consider both.

Note that org-complex-heading-regexp-format does consider statistics
cookies, but only at the beginning/end of the headline title.
Unfortunately, it is impossible to provide generic printf format to
match a headline title with arbitrary statistics cookies inserted in the
middle of it.

As for your other report, it is a hard one - org-complex-heading-regexp
is hard to modify because we guarantee certain match groups and its hard
to fit COMMENT in there without breaking backward-compatibility.

I generally dislike the idea of the available plethora of analytic
regexps with numbered match groups. I am currently working on
generalised Org element matcher that provides named groups for arbitrary
Org syntax elements, including headlines.

Best,
Ihor

Re: How to export to markdown programmatically without the table of contents?

[Karl Voit]

* Jeremie Juste  wrote:
> Hello Karl,

Hi Jeremie,

> On Tuesday,  3 May 2022 at 11:15, Karl Voit wrote:
>>
>> I tried this neat code snippet today with Emacs 26.3 and Org-mode
>> 9.1.9 and I got an error:
>>
>> | org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export
>>
>> When I execute the following code, I get the same error:
>> | (setq region "/foo/ *bar* https://example.com baz")
>> | (org-export-string-as region 'md t '(:with-toc nil))
>>
>> Could it be that I don't have "md" as backend somehow? Is there a
>> hidden requirement?
>
> And I still work with (require 'ox-md).

Unfortunately, I did not write down why I thought this is not
necessary any more. However, with the require statement, the error
is gone and the function works now.

Thanks!

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Agenda without todos only if there is no other timestamp

[Karl Voit]

Hi,

* TRS-80  wrote:
>
>> On 2022-04-05 04:48, Karl Voit wrote:
>>> Hi,
>>> I've got following custom agenda for exporting:
>>> | ("n" "no TODO events +180d"
>>> |  ((agenda "no TODO events +180d"
>>> |   ((org-agenda-span 180)
>>> |(org-agenda-time-grid nil)
>>> |(org-agenda-entry-types '(:timestamp :sexp))
>>> |(org-agenda-skip-function
>>> | '(or
>>> |   (org-agenda-skip-entry-if 'todo 'any);; skip if any
>>> TODO state is found
>>> |   (org-agenda-skip-entry-if 'category "errors");; skip
>>> if any TODO state is found
>>> |   (my-skip-tag "lp")
>>> |   )
>>> |  nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
>>> (don't mind the stupid name - I may fix this as it is misleading
>>> here)
>>> This results in an HTML file that contains my appointments without
>>> the tasks.
>>> Unfortunately, I sometimes seem to schedule appointments within open
>>> todos such as:
>>> | * NEXT talk with Steve about the project X
>>> | SCHEDULED: <2022-04-05 Tue>
>>> |
>>> | - [X] ask him for a time-slot
>>> | - we settled for: <2022-04-05 Tue 14:00-15:00>
>>> Of course, those appointments are lost in my agenda export as
>>> specified above. This is a bummer and I want to fix this somehow.
>>> Tasks should be omitted only if there is no other time-stamp than
>>> deadline or scheduled.
>>> org-agenda-skip-if lists:
>>> | scheduled Check if there is a scheduled cookie
>>> | notscheduled  Check if there is no scheduled cookie
>>> | deadline  Check if there is a deadline
>>> | notdeadline   Check if there is no deadline
>>> | timestamp Check if there is a timestamp (also deadline or
>>> scheduled)
>>> | nottimestamp  Check if there is no timestamp (also deadline or
>>> scheduled)
>>> | regexpCheck if regexp matches
>>> | notregexp Check if regexp does not match.
>>> | todo  Check if TODO keyword matches
>>> | nottodo   Check if TODO keyword does not match
>>> How is it possible to accomplish this? I think this would require
>>> something like "Check if there is a timestamp (except deadline or
>>> scheduled)" which isn't available yet.
>>> Any ideas on that one?
>>
>> I think you will need to write a custom ~org-agenda-skip-function~.
>>
>
> I realized there is probably an even easier way (no custom ELisp
> required), simply by creating a separate child heading for the meeting,
> which should then show up.

Thanks for the idea. This is my current workaround. However, it
happens in longer headings that I insert a time/datestamp at the end
without realizing that I'm working in a todo heading. This is an
issue for me because I do have to check every time I'm using
timestamps. It's rather obvious that I fail from time to time and I
lose the entry on my non-todo-agenda.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: org-startup-folded does not work with directory local variables

[Ihor Radchenko]

Max Fujimoto  writes:

> Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 
> 1.17.6)
>
> The variable org-startup-folded does not work expected in .dir-locals.el.The 
> option "#+startup: fold" works as expected.

This is because Emacs loads directory-local variables _after_ Org mode
is loaded. That is, you set org-startup-folded after startup is
complete.

I recommend reporting this to Emacs bug tracker.

Best,
Ihor

Re: Bug ? : No indentation for the text in inline tasks

[Ihor Radchenko]

Nicolas Odermatt-Lemay  writes:

> Step to reproduce:
> 1- Enable (org-indent-mode) in an org buffer.
> 2- Use the command (org-inlinetask-insert-task)
> 3- Insert some text between the task's title and the keyword END
> 4- Notice that the text between the title and the keyword END isn't
> properly indented.

Could you elaborate what you mean by "isn't properly indented"?
It is supposed to be indented just like any other text in the containing
headline.

Best,
Ihor

Re: [PATCH v3] org-encode-time compatibility and convenience helper

[Ihor Radchenko]

Max Nikulin  writes:

> The attached patch set is assumed to be complete.

Thanks!

> I have no chance to thoroughly test it. Existing unit tests pass for 
> Emacs-26 and Emacs-27. Nothing has changed for Emacs-25, as for the 
> "main" branch one test fails. I have not tried Emacs-28 or the current 
> git version.

I tried to test your patch applied onto main with all the supported
Emacs versions (note that we do not need to support Emacs 25 anymore.
Emacs 28 is out). One test is failing:

Emacs 26, 27, 28, and 29:

1 unexpected results:
   FAILED  test-org-clock/clocktable/ranges

> In comparison to the previous patch version I have expanded the 
> docstring and added a bit more tests. I have tried to support recently 
> committed to Emacs 6-elements list for `encode-time', but I do not like 
> the following compile-time warning:
>
>> In toplevel form:
>> org-macs.el:1397:23:Warning: encode-time called with 1 argument, but requires
>> 6+

Since it is expected to fail in some Emacs versions, you can just wrap
the call into with-no-warnings:

(ignore-errors (with-no-warnings (encode-time '(0 0 0 1 1 1971

Best,
Ihor

Re: Agenda without todos only if there is no other timestamp

[Ihor Radchenko]

Karl Voit  writes:

> I've got following custom agenda for exporting:
>
> | ("n" "no TODO events +180d"
> |  ((agenda "no TODO events +180d"
> |   ((org-agenda-span 180)
> |(org-agenda-time-grid nil)
> |(org-agenda-entry-types '(:timestamp :sexp))
> |(org-agenda-skip-function
> | '(or
> |   (org-agenda-skip-entry-if 'todo 'any);; skip if any TODO 
> state is found
> |   (org-agenda-skip-entry-if 'category "errors");; skip if any 
> TODO state is found
> |   (my-skip-tag "lp")
> |   )
> |  nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
> ...
> Tasks should be omitted only if there is no other time-stamp than
> deadline or scheduled.
>
> Any ideas on that one?

(org-agenda-skip-function
 '(or
   (and (org-agenda-skip-entry-if 'todo 'any);; skip if any TODO state is found
(org-agenda-skip-entry-if 'deadline 'scheduled))
   (org-agenda-skip-entry-if 'category "errors");; skip if any TODO state is 
found
   (my-skip-tag "lp")))

Best,
Ihor

Re: [org-contrib] Take over maintaining of org-contacts.el

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Hi Danjou, Since the package org-contacts.el is not maintained for a long 
> time. I would like to take
> over maintaining of org-contacts.el. What do you think? I used to send you an 
> email with asking. But
> got no response.
>
> Hi Bastien, If org-contacts.el author is not response for a long time, can 
> you remove
> org-contacts.el out from org-contrib? I have already added a separated 
> repository for org-contacts.el
> https://repo.or.cz/org-contacts.git
>
> If approved, I will update on MELPA by adding a new recipe for 
> org-contacts.el.

I noticed that Bastien did put your repo as a new home for org-contacts:
https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/org-contacts.el:
>> homepage: https://github.com/stardiviner/org-contacts.el

Note, however, that the repo is your (deleted?) github repo.
Should we update the homepage repo in org-contrib to 
https://repo.or.cz/org-contacts.git?

Best,
Ihor

Re: [BUG] - Statistics cookie is part of the org heading title

[Ignacio Casso]

Ihor Radchenko  writes:

> Samuel Wales  writes:
>
>> some code removes it.  for example creating a link to a headline using 
>> capture.
>
> Yeah. org-link--normalize-string. But it is internal function, so I would
> not rely on it.
>
> Also, rather than relying on regexps, I would use
> org-element-headline-parser, extract parsed :title property, and filter
> out statistics-cookie objects.
>
> Best,
> Ihor

I replied to this bug report yesterday via the "reply via email to"
button in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
assuming it would send it to the org-mode list, but now I see that it
was only sent to Fabian. I copy my answer at the end of this email,
although when I wrote it I did not know that statistics cookies can
appear anywhere in the headline and not just at the end before tags, nor
about `org-element-headline-parser', so as a reply it may be no longer
relevant or correct.

Still, I think it might be interesting to compare this topic with the
one I linked in my reply,
https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html,
which it's basically the same bug report but about COMMENT keywords. In
that regard, I have tested that org-capture targets do work regardless
of statistcs cookies. Could not something equivalent be done so that
they also work regardless of COMMENT keywords? Feel free to reply in
that other thread if you feel this is off-topic here.

Regards,

--Ignacio

Original reply:

Hi Fabian,

> I would like to report his behaviour as a bug: 
> 
> Example:
> 
> * Some Heading Title [0/1]  ;; cursor in this line when executing
> ** TODO Some Todo Item
> 
> -> result is "Some Heading Title [0/1]"
> 
> -> desired result would be "Some Heading Title"
> 

You forgot to say that you use (nth 4 (org-heading-components)) when you
copied the example from emacs.stackexchange.com.


> I don't see any reason why the statistics cookie should be part of the title: 
> it should be a separate component.

I agree.

This bug is related with the issue I reported in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The
problem is that `org-heading-components' uses
`org-complex-heading-regexp', which does not consider statistics
cookies, and neither COMMENT keywords as I reported. I think it should be
updated to consider both.

In the meantime, I was going to suggest that you use the org parser,
with

  (org-element-property :title (org-element-context))

which solves the problem in the case of the COMMENT keywords. But I have
tested it and it does not solve it in the case of statistics cookies, so
I guess the problem should be fixed in org-element.el too.

Regards,

-- Ignacio

Re: [BUG] 67275f4 broke evil-search Re: [PATCH 10/35] Implement link folding

[Ihor Radchenko]

Tom Gillespie  writes:

> It seems that this patch (as commit
> 67275f4664ce00b5263c75398d78816e7dc2ffa6, found using git bisect to
> hunt down the issue) breaks search in evil mode when
> (evil-select-search-module 'evil-search-module 'evil-search) is set.
> The broken behavior is that evil-search no longer searches inside
> folded headings. I had a quick look at the changes but couldn't figure
> out why these changes might cause the issue. Best,

Evil re-implements isearch functionality and it does it only partially.
It appears to respect isearch-filter-predicate, but not
isearch-mode-end-hook.
I expect this to be a bug on evil side.

Meanwhile, you can try to set search-invisible to t. It should help (in
theory).

Best,
Ihor

[BUG] 67275f4 broke evil-search Re: [PATCH 10/35] Implement link folding

[Tom Gillespie]

Hi Ihor,
It seems that this patch (as commit
67275f4664ce00b5263c75398d78816e7dc2ffa6, found using git bisect to
hunt down the issue) breaks search in evil mode when
(evil-select-search-module 'evil-search-module 'evil-search) is set.
The broken behavior is that evil-search no longer searches inside
folded headings. I had a quick look at the changes but couldn't figure
out why these changes might cause the issue. Best,
Tom