Re: [BUG] All drawers except property drawers are open at startup

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Matt Lundin  writes:

> Matthew Lundin  writes:
>
>> Nicolas Goaziou  writes:
>>
>>> Matt Lundin  writes:
>>>
 All drawers default to open at startup except for property drawers. This
 includes :LOGBOOK: drawers, which can be quite long and block view of an
 entry.
>>>
>>> I think all drawers are opened at startup, including property drawers.
>>>
 I ran a git bisect and discovered that the bug was introduced with
 commit 8b05c06d427e850d45684f69c5165cd7684e1071 on May 9. 
>>>
>>> Isn't it related to 88f5ed91c5cf9cb6962c1b441eac7dbab9a4734e instead?
>>>
>> No. I have the following in my emacs file:
>>
>> (setq org-startup-folded t)
>>
>
> I did some more investigating and it seems my initial git bisect was off
> by one commit. (I think I forgot to reload org files on the last
> bisect.)
>
> The commit that introduced this bug was
> 1027e0256903bc2c4ef9edfb1f7279294fa3f195.
>
> In the function org-set-startup-visibility, that commit replaced
>
> (org-cycle-hide-drawers 'all)
>
> with
>
> (org-cycle-hide-property-drawers 'all)
>
> Thus, only property drawers are hidden at startup.
>

I have same problem. Glad you found the problem commit.

> Best,
>
> Matt


- -- 
[ 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
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7bDsMUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsONQwgAvgeSgmZuX5lnmgUP30dzVgpVA0vS
O5cKfYD3aMwd5hkCzwUXFfc+LotKBFZJHJy1lRAesHHZclKRyNLpdQHWHwLbhbKM
jBRLnaFQhVHa12QqPplF7/cBMfv41RFYcqiGcwfY+F8ZOrHe++7dOdcmxRKdZtVb
f3WUwZDMQTfKhLLKj44kcKOcah32Utg/3WDG5ovUMiNQ8PUJryOR1eLTW1w//hI5
bLoJGFI69UW6F/MOMBmWyY9BEZyONYGpIWvTqLt/189F0+6VedDbbIlMbjjcNQ8n
VykVGnVqo5Ca5AUbsLysg3Me6ddyiZXh8FzliCobUmAblLTsEi1yRW1B9g==
=DIgk
-END PGP SIGNATURE-

Re: [BUG] All drawers except property drawers are open at startup

[Matt Lundin]

Matthew Lundin  writes:

> Nicolas Goaziou  writes:
>
>> Matt Lundin  writes:
>>
>>> All drawers default to open at startup except for property drawers. This
>>> includes :LOGBOOK: drawers, which can be quite long and block view of an
>>> entry.
>>
>> I think all drawers are opened at startup, including property drawers.
>>
>>> I ran a git bisect and discovered that the bug was introduced with
>>> commit 8b05c06d427e850d45684f69c5165cd7684e1071 on May 9. 
>>
>> Isn't it related to 88f5ed91c5cf9cb6962c1b441eac7dbab9a4734e instead?
>>
> No. I have the following in my emacs file:
>
> (setq org-startup-folded t)
>

I did some more investigating and it seems my initial git bisect was off
by one commit. (I think I forgot to reload org files on the last
bisect.)

The commit that introduced this bug was
1027e0256903bc2c4ef9edfb1f7279294fa3f195.

In the function org-set-startup-visibility, that commit replaced

(org-cycle-hide-drawers 'all)

with

(org-cycle-hide-property-drawers 'all)

Thus, only property drawers are hidden at startup.

Best,

Matt

Re: issue tracker?

[Mario Frasca]

On 02/06/2020 06:57, Bastien wrote:

Please go ahead.  Readhttps://orgmode.org/worg/org-contribute.html
and submit your first patch following the rules we have for the commit
messages (they are not easily understood for newcomers).  After a few
well-formatted useful patches, we can perhaps add you as a committer.


I sent the pdf for contributing, and I have a question on how to use 
this email-based issue tracker:


how do I get the list of open issues?  complete with the status 
accepted/wont-fix/whatever?


best regards

Re: tables, positioning of `#+Plot:' lines

[Nicolas Goaziou]

> point is: as far as I can see, org-plot currently only recognizes its
> `#+' lines if they are immediately before the table.  being new to
> this world, I a not aware of other `#+:' lines other than TBLFM
> and PLOT.

#+name: #+header: #+caption: #+results: #+attr_latex: #+attr_html: …

They all live right before the element, not necessarily a table, they
refer to.

> which is the name you give to these lines?  def lines? table-meta-data
> lines?

Affiliated keywords.

> there isn't any global function for matching them, is there?

The parser captures their value.

Before overloading affiliated keywords, such as PLOT, or HEADER, you may
want to consider using a dedicated Gnuplot source block for advanced
drawings is the way to go.

Re: 27.0.91; Avoid error on org-html-fontify-code

[pierre . techoueyres]

Hi Kyle,

Kyle Meyer writes:

> pierre.techouey...@gmail.com writes:
>
>> Some time ago I tried to export in html form an org file containing many
>> src blocks and ended with the following message :
>>
>> org-html-do-format-code: Buffer is read-only: #
>>
>> After narrowing down my file here are the steps to reproduce :
>>
>> emacs -q
>> (require 'htmlize) ;; this is important else `org-html-fontify-code`
>>;; will keep the wrong branch
>>
>> ;; open the ecm-org-src-ro.org ([1])
>> ;; try to export as html
>
> Thanks for narrowing the issue and providing an example to trigger it
> (not to mention a patch).
>
>> Subject: [PATCH] ox-html.el: Fix read-only error when export src bloc
>
> Looks good to me.  Applied (c631afd35), with a couple of minor tweaks to
> the commit message.

Hi kyle,
Many thanks for that. If I've well understood it's on master.  Do you
know (or guess) how long will this take to land in the next release ?

I had also open bugs #41641, may be will you close it ?

Re: tables, positioning of `#+Plot:' lines

[Mario Frasca]

On 05/06/2020 15:08, Nicolas Goaziou wrote:

Since TBLFM lines are the odd ones, the mistake was to allow them after
the table, while every other affiliated keyword in the Org universe goes
before the object it applies to.


ah, I did not know that.  that's good.  and we don't want to correct 
that, I guess.


point is: as far as I can see, org-plot currently only recognizes its 
`#+' lines if they are immediately before the table.  being new to this 
world, I a not aware of other `#+:' lines other than TBLFM and PLOT.


which is the name you give to these lines?  def lines? table-meta-data 
lines?  there isn't any global function for matching them, is there?


On 05/06/2020 15:08, Nicolas Goaziou wrote:

What kind of meta information?


I mean other lines matching `^#\+[A-Z]+:' … as said, I don't know how to 
call them, and I guessed "meta information".


best regards, MF

Re: tables, positioning of `#+Plot:' lines

[Nicolas Goaziou]

Hello,

Mario Frasca  writes:

> I was wondering about the position of the `#+plot:' lines.  we have
> a table, and if we want to have formulas, we put these in a `#+TBLFM:'
> line following the table.  the documentation of org-plot states that
> `#+PLOT:' lines are looked for: following, or preceding the table

Then the documentation needs to be fixed.

> but then only the "preceding" strategy is implemented.  I tried just
> out of curiosity, what happens if I put my `#+PLOT:' lines following
> the table but before the `#+TBLFM:' line.  in this case also the
> `#+TBLFM:' line is not found.
>
> I see a couple of problems with this approach and in the current
> implementation:
>
> - only one single `#+TBLFM:' line is recognized,

IIRC, this was a feature request, even though we could allow multiple
TBLFM lines. Why some users requested to have only one active TBLFM line
at a time, I don't know.

> it must follow the table, there cannot be any other meta information
> in between the table and the `#+TBLFM:' line.

What kind of meta information?

You don't need to create monster-tables. You may simply write a table,
and use it as input in a dedicated gnuplot source block.

> my main doubt is that if we acknowledge meta lines at both ends, we
> end up with an unmanageable mess, where similar information can be
> very distant in the document.  I think it was a mistake to let PLOT
> directives be placed elsewhere than formulas, but I don't know if it's
> still worth changing this.

Since TBLFM lines are the odd ones, the mistake was to allow them after
the table, while every other affiliated keyword in the Org universe goes
before the object it applies to.

IOW, I don't think also allowing PLOT affiliated keyword at the end of
the table is a good idea, and I'm sure that allowing it on both ends is
a bad one.

Regards,

-- 
Nicolas Goaziou

[BUG] org-agenda-filter and hyphens in category names

[Matt Lundin]

Hi everyone,

I'm just getting around to exploring the function org-agenda-filter
introduced last year. (Due to busyness, I was running an older version
of Org Mode last year for fear of breaking features I relied on.)

I like the tab completion. However, I'm finding that the completion for
categories often fails because of hyphens in my file and category names.
Let's say I have a file named "my-file.org" with active todos. The
function org-agenda-filter will suggest "my-file" as a possible category
completion. However, if I tab complete "my-file," org-agenda-filter
errors out with the following messages:

  ‘+my’ filter ignored because tag/category is not represented
  ‘-file’ filter ignored because tag/category is not represented

The same thing occurs when I put hyphens in filetags.

Looking at the Org Manual, I see that Org Mode restricts tags to
alphanumeric characters, "@", and "_". And org-set-tags-command will
sanitize tag names when entering them, replacing forbidden characters
with ":".

However, there are no guidelines about forbidden characters in
categories. And filetags at the top of file allow for arbitrary
characters. Both org-agenda-filter-by-category ("<") and
org-agenda-filter-by-tag ("\") work with categories and filetags
containing "-" or "+" in the name.

Would it be possible for org-agenda-filter to escape the set of special
characters [-+<>=/] in category and filetag names when offering them for
completion? 

Best,

Matt

tables, positioning of `#+Plot:' lines

[Mario Frasca]

I was wondering about the position of the `#+plot:' lines.  we have a 
table, and if we want to have formulas, we put these in a `#+TBLFM:' 
line following the table.  the documentation of org-plot states that 
`#+PLOT:' lines are looked for: following, or preceding the table, but 
then only the "preceding" strategy is implemented.  I tried just out of 
curiosity, what happens if I put my `#+PLOT:' lines following the table 
but before the `#+TBLFM:' line.  in this case also the `#+TBLFM:' line 
is not found.


I see a couple of problems with this approach and in the current 
implementation:


- only one single `#+TBLFM:' line is recognized, it must follow the 
table, there cannot be any other meta information in between the table 
and the `#+TBLFM:' line.


- other programs can't add meta information to the table, or must choose 
to stay after the `#+TBLFM:' line or before the `#+PLOT:' lines.


- you have meta information at the two ends of the table, instead of all 
on the same side.


I would like to implement the 'plot meta lines after the table', and 
some way to comment meta lines.


any thoughts?

my main doubt is that if we acknowledge meta lines at both ends, we end 
up with an unmanageable mess, where similar information can be very 
distant in the document.  I think it was a mistake to let PLOT 
directives be placed elsewhere than formulas, but I don't know if it's 
still worth changing this.


best regards, MF

Re: Bug: org-babel-ref-resolve does not find refs in a COMMENT'ed section [9.3.7 (9.3.7-elpaplus @ /home/kdm/.emacs.d/DEBUG/elpa/org-plus-contrib-20200602/)]

[Nicolas Goaziou]

Hello,

Ken Mankoff  writes:

> I think this is a recent change in behavior. I can no longer eval Babel 
> blocks that expect table inputs via :var when they are in a section with a 
> COMMENT status.
>
>
>
> Here is an MWE org file:
>
> === BEGIN ===
>
> * COMMENT Tables not found when section is commented
>
> #+NAME: table
> | foo |
>
> (org-babel-ref-resolve "table")
>
> === END ===
>
>
>
>
> When I try to eval (org-babel-ref-resolve "table"), Org reports:
>
> org-babel-ref-resolve: Reference ‘table’ not found in this buffer
>
> If I remove the "COMMENT" state on the heading, then the table is
> found.

This sounds correct. A commented section is dead code, after all.

Regards,

-- 
Nicolas Goaziou

Bug: org-babel-ref-resolve does not find refs in a COMMENT'ed section [9.3.7 (9.3.7-elpaplus @ /home/kdm/.emacs.d/DEBUG/elpa/org-plus-contrib-20200602/)]

[Ken Mankoff]

Hello,

I think this is a recent change in behavior. I can no longer eval Babel blocks 
that expect table inputs via :var when they are in a section with a COMMENT 
status.



Here is an MWE org file:

=== BEGIN ===

* COMMENT Tables not found when section is commented

#+NAME: table
| foo |

(org-babel-ref-resolve "table")

=== END ===




When I try to eval (org-babel-ref-resolve "table"), Org reports:

org-babel-ref-resolve: Reference ‘table’ not found in this buffer

If I remove the "COMMENT" state on the heading, then the table is found.

I do not recall this happening in earlier versions of Org, but does now with 
the latest version from melpa.





Tested with /usr/bin/emacs -Q -l ~/.emacs.d/DEBUG.el ~/.emacs.d/DEBUG.org with 
DEBUG.org above and DEBUG.el containing:


(setq package-user-dir (expand-file-name "elpa" "~/.emacs.d/DEBUG"))
(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/;) t)
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/;) t)
(package-initialize)
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(setq package-enable-at-startup nil)
(defvar use-package-verbose t)
(require 'use-package)
(setq use-package-always-ensure t)

(use-package org
  :ensure org-plus-contrib
  :config
  (setq org-confirm-babel-evaluate nil)
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((shell . t


  -k.

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Bastien  writes:

> Dear all,
>
> with Kyle's help, I've set up a new mailing list archive:
>
> https://orgmode/list/
>
> References in https://orgmode.org and https://orgmode.org/list
> that pointed to gmane.org are now using this, so many links are
> functional again.

Cool! I note that there's also NNTP access at news.yhetil.org, in
addition to gmane.io. Does yhetil have a search interface, or are there
other mechanisms for searching the archives (ideally in Gnus :))?

Re: New mailing list archive at https://orgmode/list/

[Bastien]

Hi Diego,

Diego Zamboni  writes:

> I noticed that I am getting in master the following error when I do
> "make doc":

thanks for reporting this -- it was a problem in the ox-texinfo.el
exporter, not escaping the "@" char correctly.

This is now fixed in maint.

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Nicolas Goaziou]

Ihor Radchenko  writes:

>> See also `gensym'. Do we really need to use it for something else than
>> `invisible'? If not, the tool doesn't need to be generic.
>
> For now, I also use it for buffer-local 'invisible stack. The stack is
> needed to preserve folding state of drawers/blocks inside folded
> outline. Though I am thinking about replacing the stack with separate
> text properties, like 'invisible-outline-buffer-local +
> 'invisible-drawer-buffer-local + 'invisible-block-buffer-local.
> Maintaining stack takes a noticeable percentage of CPU time in profiler.
>
> org--get-buffer-local-text-property-symbol must take care about
> situation with indirect buffers. When an indirect buffer is created from
> some org buffer, the old value of char-property-alias-alist is carried
> over. We need to detect this case and create new buffer-local symbol,
> which is unique to the newly created buffer (but not create it if the
> buffer-local property is already there). Then, the new symbol must
> replace the old alias in char-property-alias-alist + old folding state
> must be preserved (via copying the old invisibility specs into the new
> buffer-local text property). I do not see how gensym can benefit this
> logic.

`gensym' is just a shorter, and somewhat standard way, to create a new
uninterned symbol with a given prefix. You seem to re-invent it. What
you do with that new symbol is orthogonal to that suggestion, of course.

>> OK, but this may not be sufficient if we want to do slightly better than
>> overlays in that area. This is not mandatory, though.
>
> Could you elaborate on what can be "slightly better"? 

IIRC, I gave examples of finer control of folding state after a change.
Consider this _folded_ drawer:

  :BEGIN:
  Foo
  :END:

Inserting ":END" in it should not unfold it, as it is currently the case
with overlays,

  :BEGIN
  Foo
  :END
  :END:

but a soon as the last ":" is inserted, the initial drawer could be
expanded.

  :BEGIN
  Foo
  :END:
  :END:

The latter case is not currently handled by overlays. This is what
I call "slightly better".

Also, note that this change is not related to opening and closing lines
of the initial drawer, so sticking text properties on them would not
help here.

Another case is modifying those borders, e.g.,


  :BEGIN:   :BEGIN:
  Foo -->   Foo  
  :END: :ND:

which should expand the drawer. Your implementation catches this, but
I'm pointing out that current implementation with overlays does not.
Even though that's not strictly required for compatibility with
overlays, it is a welcome slight improvement.

>> As discussed before, I don't think you need to use `modification-hooks'
>> or `insert-behind-hooks' if you already use `after-change-functions'.
>>
>> `after-change-functions' are also triggered upon text properties
>> changes. So, what is the use case for the other hooks?
>
> The problem is that `after-change-functions' cannot be a text property.
> Only `modification-hooks' and `insert-in-front/behind-hooks' can be a
> valid text property. If we use `after-change-functions', they will
> always be triggered, regardless if the change was made inside or outside
> folded region.

As discussed, text properties are local to the change, but require extra
care when moving text around. You also observed serious overhead when
using them.

OTOH, even if `a-c-f' is not local, you can quickly determine if the
change altered a folded element, so the overhead is limited, i.e.,
mostly checking for a text property at a given buffer position.

To be clear, I initially thought that text properties were a superior
choice, but I changed my mind a while ago, and I thought you had, too.
IOW, `after-change-functions' is the way to go, since you have no strong
reason to stick to text properties for this kind of function.

>>> :asd:
>>> :drawer:
>>> lksjdfksdfjl
>>> sdfsdfsdf
>>> :end:
>>>
>>> If :asd: was inserted in front of folded :drawer:, changes in :drawer:
>>> line of the new folded :asd: drawer would reveal the text between
>>> :drawer: and :end:.
>>>
>>> Let me know what you think on this.
>
>> I have first to understand the use case for `modification-hook'. But
>> I think unfolding is the right thing to do in this situation, isn't it?
>
> That situation arises because the modification-hooks from ":drawer:"
> (they are set via text properties) only have information about the
> :drawer:...:end: drawer before the modifications (they were set when
> :drawer: was folded last time). So, they will only unfold a part of the
> new :asd: drawer. I do not see a simple way to unfold everything without
> re-parsing the drawer around the changed text.

Oh! I misread your message. I withdraw what I wrote. In this case, we
don't want to unfold anything. The situation is not worse than what we
have now, and trying to fix it would have repercussions down in the
buffer, e.g., expanding drawers screen below.

As a rule of thumb, I think we can pay 

Re: [bug] Display issue with broken links

[Karl Voit]

* Nicolas Goaziou  wrote:
> Hello,

Hi Nicolas,

> Karl Voit  writes:
>
>> I've found an issue that leads to broken Org mode syntax without
>> noticing. Considering the following example:
>>
>> : foo [[https://Karl-Voit.at][bar]] baz
>>
>> When I put my cursor right after "foo" and press the DEL key, my Org
>> mode shows this:
>>
>> : foo bar baz
>>
>> ... as if the link was removed properly, keeping only the
>> description text.
>>
>> However, in reality, the remaining thing is different:
>>
>> : foo [https://Karl-Voit.at][bar]] baz
>>
>> This snippet is displayed properly at least after reloading the file
>> or switching to text-mode and back to org-mode.
>
> FWIW I cannot reproduce it.

Oh. Good to know.

>> I've made a screencast to demo this:
>> https://karl-voit.at/temp/2020-06-05T11.28.16_Org_mode_display_issue_with_broken_link_--_emacs_screencasts.gif
>
> Proofs including an animated Nyan Cat are not considered valid, sorry.

Don't discriminate my horizontal scroll bar cat! :-)

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

How to annotate past clock entries so the note shows in agenda?

[Tory S. Anderson]

Hello all,

When I clock out of an entry I have a pop up from (org-add-log-note); I can add 
a note which will appear in my agenda right after the clock item. Often times, 
though, I want to go back through my day's agenda and add these; for example, 
upon marking "done" on a task it automatically clocks me out and does not 
invite me to take a note. Or at journaling time at day's end I'd like to add 
such a note that would be visible in my agenda.

The prompt comes from org-store-log-note called by org-add-log-note. The latter 
checks org-log-note-purpose. That's as far as my sleuthing has been able to go, 
though; I can manually call the function to receive the prompt for adding a 
clock-out note, but it doesn't stick it anywhere useful.

How can I add clock-out notes after the event? Must I manually go to the clock 
event and type in my note there, or can I utilize the same prompt somehow?

Thanks for any help!

- Tory

Re: a couple of items

[Eric S Fraga]

On Friday,  5 Jun 2020 at 20:09, TEC wrote:
> What I like about org-plot is that it basically allows for use of big
> templates :) you'll see more on this in my upcoming PR ;-)

I look forward to it! 

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

Re: a couple of items

[TEC]

Eric S Fraga  writes:
Sometimes, or often, a translator is too constraining.  I find 
it
easier/faster to write my own gnuplot code directly as it gives 
me the

fine control I need for publication quality figures.

The great thing about gnuplot is that *everything* can be 
tweaked.  The
bad thing about gnuplot is that everything *can* be tweaked. ;-) 
Sort of

like Emacs actually.


What I like about org-plot is that it basically allows for use of 
big

templates :) you'll see more on this in my upcoming PR ;-)

Timothy.

p.s. See https://tecosaur.github.io/emacs-config/config.html#org 
for a

preview (radar plot)

Re: [bug] Display issue with broken links

[Nicolas Goaziou]

Hello,

Karl Voit  writes:

> I've found an issue that leads to broken Org mode syntax without
> noticing. Considering the following example:
>
> : foo [[https://Karl-Voit.at][bar]] baz
>
> When I put my cursor right after "foo" and press the DEL key, my Org
> mode shows this:
>
> : foo bar baz
>
> ... as if the link was removed properly, keeping only the
> description text.
>
> However, in reality, the remaining thing is different:
>
> : foo [https://Karl-Voit.at][bar]] baz
>
> This snippet is displayed properly at least after reloading the file
> or switching to text-mode and back to org-mode.

FWIW I cannot reproduce it.

> I've made a screencast to demo this:
> https://karl-voit.at/temp/2020-06-05T11.28.16_Org_mode_display_issue_with_broken_link_--_emacs_screencasts.gif

Proofs including an animated Nyan Cat are not considered valid, sorry.

Regards,

-- 
Nicolas Goaziou

Re: a couple of items

[Eric S Fraga]

On Thursday,  4 Jun 2020 at 16:29, Mario Frasca wrote:
> hi.  thank you.  seeing hand written code in the target language is
> always useful, when writing a translator.  :+1:  :-)

Sometimes, or often, a translator is too constraining.  I find it
easier/faster to write my own gnuplot code directly as it gives me the
fine control I need for publication quality figures.

The great thing about gnuplot is that *everything* can be tweaked.  The
bad thing about gnuplot is that everything *can* be tweaked. ;-) Sort of
like Emacs actually.
  
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

Re: New mailing list archive at https://orgmode/list/

[Diego Zamboni]

Hi Bastien,

> > On Friday,  5 Jun 2020 at 09:47, Bastien wrote:
> >> with Kyle's help, I've set up a new mailing list archive:
> >>
> >> https://orgmode/list/

Thanks for setting this up.

I noticed that I am getting in master the following error when I do "make doc":

> make doc
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C doc info
makeinfo --no-split org.texi -o org
org.texi:18233: unknown command `somewhere'
make[1]: *** [org] Error 1

This seems to be caused by commit
fa4dddf8d29063dbd2161b7f33a776e2c063ed10, which introduced the
following change in a link to a list message (I don't know enough texi
syntax to suggest a fix):

--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17104,7 +17104,7 @@ cause unexpected results.

-reasons why, see http://thread.gmane.org/gmane.emacs.orgmode/79046.
+reasons why, see https://orgmode.org/list/86fvqqc8jb@somewhere.org

Best,
--Diego

Re: Disambiguate internal links?

[Diego Zamboni]

I personally find CUSTOM_ID's easier since I can make them
unequivocally unique, and by using them the links don't break if I
change something in the headline title.

On Thu, Jun 4, 2020 at 5:26 PM Budiman Snowman  wrote:
>
> On Wed, Jun 3, 2020 at 9:21 PM Diego Zamboni  wrote:
>>
>> I almost always use a CUSTOM_ID property for this, e.g.
>>
>> * topic1
>> See topic [[#topic2][topic2]].
>> See glossary [[#glossary_topic2][topic2]].
>>
>> * topic2
>> :PROPERTIES:
>> :CUSTOM_ID: topic2
>> :END:
>>
>> * glossary
>> ** topic1
>> :PROPERTIES:
>> :CUSTOM_ID: glossary_topic2
>> :END:
>> ** topic2
>> :PROPERTIES:
>> :CUSTOM_ID: glossary_topic2
>> :END:
>>
>
> Are there advantages to using CUSTOM_ID instead of dedicated target? I'll 
> stick with dedicated target for now, because it's shorter to type.
>
> Regards,
> BS
>

Re: New mailing list archive at https://orgmode/list/

[Bastien]

Eric S Fraga  writes:

> On Friday,  5 Jun 2020 at 09:47, Bastien wrote:
>> with Kyle's help, I've set up a new mailing list archive:
>>
>> https://orgmode/list/
>
> For the record, I guess you meant https://orgmode.org/list

Sure, sorry for the typo!

-- 
 Bastien

[bug] Display issue with broken links

[Karl Voit]

Hi!

I've found an issue that leads to broken Org mode syntax without
noticing. Considering the following example:

: foo [[https://Karl-Voit.at][bar]] baz

When I put my cursor right after "foo" and press the DEL key, my Org
mode shows this:

: foo bar baz

... as if the link was removed properly, keeping only the
description text.

However, in reality, the remaining thing is different:

: foo [https://Karl-Voit.at][bar]] baz

This snippet is displayed properly at least after reloading the file
or switching to text-mode and back to org-mode.

I've made a screencast to demo this:
https://karl-voit.at/temp/2020-06-05T11.28.16_Org_mode_display_issue_with_broken_link_--_emacs_screencasts.gif

This happens with Emacs 26.1 as well as 26.3 with Org mode from
maint git (9.3.6).


Fun fact: I initially thought, this is a hidden feature which I
started to use happily ;-)
Considering
https://www.reddit.com/r/orgmode/comments/gwa2i4/i_want_to_remove_the_link_and_preserve_the_text/
I would love to see something like
org-remove-link-and-keep-description-text built-in.

-- 
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: New mailing list archive at https://orgmode/list/

[Eric S Fraga]

On Friday,  5 Jun 2020 at 09:47, Bastien wrote:
> with Kyle's help, I've set up a new mailing list archive:
>
> https://orgmode/list/

For the record, I guess you meant https://orgmode.org/list

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

Re: New mailing list archive at https://orgmode/list/

[Marco Wahl]

Hi!

> with Kyle's help, I've set up a new mailing list archive:
>
> https://orgmode/list/
>
> References in https://orgmode.org and https://orgmode.org/list
> that pointed to gmane.org are now using this, so many links are
> functional again.

Thanks!

May I take the occasion to ask naively about the "Archived-At:" line in
the header of mails on the orgmode mailing list, please?

E.g. I see the line

Archived-At: 

Could this line be forged to point to the newly created location within
https://orgmode.org/list?

I think this would be beneficial since

1. there is nothing at
http://permalink.gmane.org/gmane.emacs.orgmode/129773 AFAICS.

2. one could easily reference emails.


Best regards and thanks again,
-- Marco

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> See also `gensym'. Do we really need to use it for something else than
> `invisible'? If not, the tool doesn't need to be generic.

For now, I also use it for buffer-local 'invisible stack. The stack is
needed to preserve folding state of drawers/blocks inside folded
outline. Though I am thinking about replacing the stack with separate
text properties, like 'invisible-outline-buffer-local +
'invisible-drawer-buffer-local + 'invisible-block-buffer-local.
Maintaining stack takes a noticeable percentage of CPU time in profiler.

org--get-buffer-local-text-property-symbol must take care about
situation with indirect buffers. When an indirect buffer is created from
some org buffer, the old value of char-property-alias-alist is carried
over. We need to detect this case and create new buffer-local symbol,
which is unique to the newly created buffer (but not create it if the
buffer-local property is already there). Then, the new symbol must
replace the old alias in char-property-alias-alist + old folding state
must be preserved (via copying the old invisibility specs into the new
buffer-local text property). I do not see how gensym can benefit this
logic.

> OK, but this may not be sufficient if we want to do slightly better than
> overlays in that area. This is not mandatory, though.

Could you elaborate on what can be "slightly better"? 

> As discussed before, I don't think you need to use `modification-hooks'
> or `insert-behind-hooks' if you already use `after-change-functions'.
>
> `after-change-functions' are also triggered upon text properties
> changes. So, what is the use case for the other hooks?

The problem is that `after-change-functions' cannot be a text property.
Only `modification-hooks' and `insert-in-front/behind-hooks' can be a
valid text property. If we use `after-change-functions', they will
always be triggered, regardless if the change was made inside or outside
folded region.

>> :asd:
>> :drawer:
>> lksjdfksdfjl
>> sdfsdfsdf
>> :end:
>>
>> If :asd: was inserted in front of folded :drawer:, changes in :drawer:
>> line of the new folded :asd: drawer would reveal the text between
>> :drawer: and :end:.
>>
>> Let me know what you think on this.

> I have first to understand the use case for `modification-hook'. But
> I think unfolding is the right thing to do in this situation, isn't it?

That situation arises because the modification-hooks from ":drawer:"
(they are set via text properties) only have information about the
:drawer:...:end: drawer before the modifications (they were set when
:drawer: was folded last time). So, they will only unfold a part of the
new :asd: drawer. I do not see a simple way to unfold everything without
re-parsing the drawer around the changed text.

Actually, I am quite unhappy with the performance of modification-hooks
set via text properties (I am using this patch on my Emacs during this
week). It appears that setting the text properties costs a significant
CPU time in practice, even though running the hooks is pretty fast.
I will think about a way to handle modifications using global
after-change-functions.

> `org--get-element-region-at-point' is certainly faster, but it is also
> wrong, unfortunately.
>
> Org syntax is not context-free grammar. If you try to parse it locally,
> starting from anywhere, it will fail at some point. For example, your
> function would choke in the following case:
>
> [fn:1] Def1
> #+begin_something
>
> [fn:2] Def2
> #+end_something

I see. 

> AFAIK, the only proper way to parse it is to start from a known position
> in the buffer. If you have no information about the buffer, the headline
> above is the position you want. With cache could help to start below.
> Anyway, in this particular case, you should not use
> `org--get-element-region-at-point'.

OK

Best,
Ihor

Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>> [The patch itself will be provided in the following email]
>
> Thank you.
>
>> I have found char-property-alias-alist variable that controls how Emacs
>> calculates text property value if the property is not set. This variable
>> can be buffer-local, which allows independent 'invisible states in
>> different buffers.
>
> Great. I didn't know about this variable!
>
>> All the implementation stays in
>> org--get-buffer-local-text-property-symbol, which takes care about
>> generating unique property name and mapping it to 'invisible (or any
>> other) text property.
>
> See also `gensym'. Do we really need to use it for something else than
> `invisible'? If not, the tool doesn't need to be generic.
>
>> I simplified the code as suggested, without using pairs of before- and
>> after-change-functions.
>
> Great!
>
>> Handling text inserted into folded/invisible region is handled by a
>> simple after-change function. After testing, it turned out that simple
>> re-hiding text based on 'invisible property of the text before/after the
>> inserted region works pretty well.
>
> OK, but this may 

New mailing list archive at https://orgmode/list/

[Bastien]

Dear all,

with Kyle's help, I've set up a new mailing list archive:

https://orgmode/list/

References in https://orgmode.org and https://orgmode.org/list
that pointed to gmane.org are now using this, so many links are
functional again.

Best,

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> [The patch itself will be provided in the following email]

Thank you.

> I have found char-property-alias-alist variable that controls how Emacs
> calculates text property value if the property is not set. This variable
> can be buffer-local, which allows independent 'invisible states in
> different buffers.

Great. I didn't know about this variable!

> All the implementation stays in
> org--get-buffer-local-text-property-symbol, which takes care about
> generating unique property name and mapping it to 'invisible (or any
> other) text property.

See also `gensym'. Do we really need to use it for something else than
`invisible'? If not, the tool doesn't need to be generic.

> I simplified the code as suggested, without using pairs of before- and
> after-change-functions.

Great!

> Handling text inserted into folded/invisible region is handled by a
> simple after-change function. After testing, it turned out that simple
> re-hiding text based on 'invisible property of the text before/after the
> inserted region works pretty well.

OK, but this may not be sufficient if we want to do slightly better than
overlays in that area. This is not mandatory, though.

> Modifications to BEGIN/END line of the drawers and blocks is handled via
> 'modification-hooks + 'insert-behind-hooks text properties (there is no
> after-change-functions analogue for text properties in Emacs). The
> property is applied during folding and the modification-hook function is
> made aware about the drawer/block boundaries (via apply-partially
> passing element containing :begin :end markers for the current
> drawer/block). Passing the element boundary is important because the
> 'modification-hook will not directly know where it belongs to. Only the
> modified region (which can be larger than the drawer) is passed to the
> function. In the worst case, the region can be the whole buffer (if one
> runs revert-buffer).

As discussed before, I don't think you need to use `modification-hooks'
or `insert-behind-hooks' if you already use `after-change-functions'.

`after-change-functions' are also triggered upon text properties
changes. So, what is the use case for the other hooks?

> It turned out that adding 'modification-hook text property takes a
> significant cpu time (partially, because we need to take care about
> possible existing 'modification-hook value, see
> org--add-to-list-text-property). For now, I decided to not clear the
> modification hooks during unfolding because of poor performance.
> However, this approach would lead to partial unfolding in the following
> case:
>
> :asd:
> :drawer:
> lksjdfksdfjl
> sdfsdfsdf
> :end:
>
> If :asd: was inserted in front of folded :drawer:, changes in :drawer:
> line of the new folded :asd: drawer would reveal the text between
> :drawer: and :end:.
>
> Let me know what you think on this.

I have first to understand the use case for `modification-hook'. But
I think unfolding is the right thing to do in this situation, isn't it?

> My simplified implementation of element boundary parser
> (org--get-element-region-at-point) appears to be much faster and also
> uses much less memory in comparison with org-element-at-point.
> Moreover, not all the places where org-element-at-point is called
> actually need the full parsed element. For example, org-hide-drawer-all,
> org-hide-drawer-toggle, org-hide-block-toggle, and
> org--hide-wrapper-toggle only need element type and some information
> about the element boundaries - the information we can get from
> org--get-element-region-at-point.

[...]

> What do you think about the idea of making use of
> org--get-element-region-at-point in org code base?

`org--get-element-region-at-point' is certainly faster, but it is also
wrong, unfortunately.

Org syntax is not context-free grammar. If you try to parse it locally,
starting from anywhere, it will fail at some point. For example, your
function would choke in the following case:

[fn:1] Def1
#+begin_something

[fn:2] Def2
#+end_something

AFAIK, the only proper way to parse it is to start from a known position
in the buffer. If you have no information about the buffer, the headline
above is the position you want. With cache could help to start below.
Anyway, in this particular case, you should not use
`org--get-element-region-at-point'.

Hopefully, we don't need to parse anything. In an earlier message,
I suggested a few checks to make on the modified text in order to decide
if something should be unfolded, or not. I suggest to start from there,
and fix any shortcomings we might encounter. We're replacing overlays:
low-level is good in this area.

WDYT?


Regards,

-- 
Nicolas Goaziou