Re: extra space at the end of lines in source

[Greg Minshall]

Sébastien Miquel,

thanks for the reply.

> > it's long-term emacs behavior to eliminate spaces
> > at the end of lines, at least in programming modes.

(Tim -- i guess i should have said, "it's my long-term experience with
emacs...".)

> As for the `org-src--content-indentation' spaces, they are quite
> peculiar. Note that they are removed when you call =C-c '= and when
> you tangle (they should, but I haven't tested it), so strictly
> speaking, they are removed in programming modes. What if your org
> block itself is indented, do you also expect blank lines to be
> entirely empty ?

there are two "practical" issues, plus one aesthetic issue, for me:

- because of the changes to source blocks i've edited, but not, in fact,
  tried to change, i'm getting loads of diffs when checking in a new
  version of the .org file

- the next time i open the Org Src buffer, whatever lint-like process is
  running for that language may complain about extra spaces at the end
  of a line.  (does that mean my experience is different from yours, or
  at least from your expectation?)

- "aesthetically" (or, "conditioned", by years of some expected
  behavior), i find the thought that there may be lines like these in
  the file somewhat distressing.

i'm resigned to the extra spaces when an org block is indented, so
wouldn't find the existence of spaces there any more worrisome.
(though, i would expect the spaces to be up to the indentation of the
org block, not all the way up to "the programming level".)

i do think the default should be to *not* add these spaces.  if
possible.

cheers, Greg

Re: extra space at the end of lines in source

[Tim Cross]

Greg Minshall  writes:

> hi, Sebastien,
>
> thanks for the reply.  i remember that thread, but obviously i wasn't
> paying enough attention.
>
>> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
>> when editing a src block, every empty line will be indented with
>> spaces (according to ~org-edit-src-content-indentation~ + the
>> indentation of the #+begin_src line). I think this is reasonable, but
>> perhaps some might disagree.
>
> indeed.  i disagree.  it's long-term emacs behavior to eliminate spaces
> at the end of lines, at least in programming modes.  i don't know what
> would be involved to keep the fix for the original problem (which i was
> also seeing), without adding these extra spaces.  but, i suspect it
> would be worth it, if feasible.
>

I'm not sure that is correct. Elimination of spaces at the end of lines
has always been something you could enable (either directly as a setting
in the mode, which might be enabled by default, or via a package like
whitespace.el. I think it would be going against Emacs philosophy to
have a mode automatically remove end of line spaces - this should be
something the user controls.

Of course, the converse is also true. It would be a mistake to have an
Emacs mode add additional whitespace at the end of lines which is not
requested by the user as well. This could also cause issues/conflicts
with packages like whitespace.el or diffs and VCS etc. It may also make
source blocks 'ugly' if you have your Emacs configured to show
additional whitespace at eol. 

-- 
Tim Cross

Bug: table editor documentation [9.4.6 (9.4.6-7-gc09356-elpa @ /Users/alanwehmann/.emacs.d/elpa/org-20210621/)]

[Alan Wehmann]

--text follows this line--

Info node "(org) Built-in Table Editor"

says:

> ‘M-’ (‘org-table-wrap-region’)
>  Split the current field at point position and move the rest to the
>  line below.  If there is an active region, and both point and mark
>  are in the same column, the text in the column is wrapped to
>  minimum width for the given number of lines.  A numeric prefix
>  argument may be used to change the number of desired lines.  If
>  there is no region, but you specify a prefix argument, the current
>  field is made blank, and the content is appended to the field
>  above.

But M- is mapped to "org-meta-return".  That function's documentation says:

> When called with
> an argument, unconditionally call ‘org-insert-heading’.
> 

which conflicts with what the Info node says.  Using M- with a prefix 
argument and no region does not work as described by the Info node.  Instead of 
using the key mapping, one can evaluate (org-table-wrap-region '(4)) and that 
will work as described.

My setup:

Emacs  : GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 
Version 10.14.6 (Build 18G95))
 of 2020-08-12
Package: Org mode version 9.4.6 (9.4.6-7-gc09356-elpa @ 
/Users/alanwehmann/.emacs.d/elpa/org-20210621/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-modules '(ol-bbdb ol-bibtex ol-docview ol-eww ol-gnus ol-info ol-irc ol-mhe
   ol-rmail ol-w3m ol-vm)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append local] 
5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-adapt-indentation nil
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-load-hook '((lambda nil (define-key org-mode-map (kbd "M-q") 
#'fill-region)))
 org-agenda-loop-over-headlines-in-active-region nil
 org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino" . arduino)
  ("C" . c) ("C++" . c++) ("asymptote" . asy) ("bash" . sh)
  ("beamer" . latex) ("calc" . fundamental) ("cpp" . c++)
  ("ditaa" . artist) ("dot" . fundamental)
  ("elisp" . emacs-lisp) ("ocaml" . tuareg)
  ("screen" . shell-script) ("shell" . sh) ("sqlite" . sql))
 org-catch-invisible-edits 'show-and-error
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("vm-imap" :follow org-vm-imap-open)
   ("vm" :follow org-vm-open :store org-vm-store-link)
   ("w3m" :store org-w3m-store-link)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export 
:store
org-info-store-link)
   ("gnus" :follow org-gnus-open :store org-gnus-store-link)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export
   

Re: extra space at the end of lines in source

[Sébastien Miquel]

For the record, the original issue is that with 
`org-src-tab-acts-natively' set
to t (which is the new default) you couldn't use tab to indent an empty 
line, and

electric-indent-mode wouldn't work properly.

Greg Minshall writes:

i don't know what
would be involved to keep the fix for the original problem (which i was
also seeing), without adding these extra spaces.  but, i suspect it
would be worth it, if feasible.


I think the only way would be to change 
`org-src--contents-for-write-back' to

keep track of where the point was in the edit buffer, and clean up spaces in
other lines. Doesn't seem difficult ; maybe you could replace the 
`buffer-string`

call by two calls, to get the part before point and the one after, then work
with that.


it's long-term emacs behavior to eliminate spaces
at the end of lines, at least in programming modes.
As for the `org-src--content-indentation' spaces, they are quite 
peculiar. Note
that they are removed when you call =C-c '= and when you tangle (they 
should,
but I haven't tested it), so strictly speaking, they are removed in 
programming
modes. What if your org block itself is indented, do you also expect 
blank lines

to be entirely empty ?

As for additional indentation in a blank line, it will indeed never get 
cleaned

up by org, which isn't ideal. But then, spaces at the end of non blank lines
don't get cleaned up either (I think) and never were. It's up to the user to
remove them, in the appropriate language mode.

Despite these arguments, I have no opinion on the matter.

Regards,

--
Sébastien Miquel

Re: publishing: no default publishing function, or symbol is not defined

[Christopher W. Ryan]

Juan Manuel--

Thanks. I understand no pages in a web document; I thought (hoped?) that
section/subsection numbers, perhaps multiple, would appear next to the
entries in the index.  I will try to be more specific with the ! syntax

Any advice for how to get *both* theindex.html and my main document in
html? So far I can only get one or the other, depending on whether I
include a non-nil value for a :makeindex option.

Thanks.

--Chris

Juan Manuel Macías wrote:
> Hi Christopher,
> 
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
> 
>> I would expect each named entry in an index to appear once, with, if
>> necessary, multiple links next to it for all the places that index tag
>> occurs in the main document. At least, that's how the indices in books
>> work.  Can the same be done in org mode?
> 
> I'm afraid that in HTML that is not possible. Page numbers are used in
> books to refer to an index entry, but on a web site we don't have page
> numbers: Where would we apply the links? What I usually do with my web
> index is: use first-level entries for the general concept and second or
> third level entries for concepts more concrete.
> 
> P.ej:
> 
> In document A:
> 
> #+INDEX: GNU Emacs!external packages!projectile
> 
> In document B:
> 
> #+INDEX: GNU Emacs!external packages!helm
> 
> Links to document A and B go to projectile and Helm
> 
> Anyway, I think in this scenario it's better to use tags, but
> org-publish doesn't provide tags out of the box. You need to do some
> elisp hacking to get something like blog tags in your web site.
> 
> Best regards,
> 
> Juan Manuel 
> 

[SOLVED] (was: some progress matlab-kernel, a python path problem?)

[Uwe Brauer]

>>> "JK" == John Kitchin  writes:

> I would see if you can open a jupyter notebook and start a notebook with
> the mat lab kernel. If not, it either isn’t installed, or maybe is
> installed in a different jupyter.

> If you get errors here, the issue is outside of org mode. For example, the
> hylang kernel quit working for me a while ago.

> See
> https://github.com/Calysto/matlab_kernel#kernel-times-out-while-starting
> for some troubleshooting tips.

It turned out that I need to install
pip3 install --user numpy
pip3 install --user pymatbridge

Where pip3 is the MaCOS 10.15 version

Now everything is fine.

Thanks 

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: extra space at the end of lines in source

[Greg Minshall]

hi, Sebastien,

thanks for the reply.  i remember that thread, but obviously i wasn't
paying enough attention.

> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
> when editing a src block, every empty line will be indented with
> spaces (according to ~org-edit-src-content-indentation~ + the
> indentation of the #+begin_src line). I think this is reasonable, but
> perhaps some might disagree.

indeed.  i disagree.  it's long-term emacs behavior to eliminate spaces
at the end of lines, at least in programming modes.  i don't know what
would be involved to keep the fix for the original problem (which i was
also seeing), without adding these extra spaces.  but, i suspect it
would be worth it, if feasible.

cheers, Greg

Re: table: problem with nan and if

[Nick Dokos]

Uwe Brauer  writes:

>> Uwe Brauer  writes:
>
>
>> I'm not very familiar with calc, but am wondering if the issue is the
>> 'nan'. In many languages, a nan is a 'polluting' variable i.e. once you
>> have a nan as a form anywhere in your calculation, the result will
>> always be a nan. Many languages actually have a special function to test
>> for a nan because it isn't actually a 'value'. Don't know if this is the
>> case with calc. 
>
> Yeah, when I googled, I found complains about nan using in calc but I
> did not really found an working alternative.
>
>> Perhaps an alternative strategy might help. Could you address what is
>> generating the nan and change that so that it generates something else,
>> possibly even a blank string and avoid the nan altogether? 
>
> I tried nil and other expressions but non really worked, so maybe a calc
> guru could clarify?
>

Could you write the formulas in lisp instead? You might be able to control
things more easily:

  (info "(org) Formula syntax for Lisp")

-- 
Nick

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

Re: [wip-cite-new] experimental citeproc-el based activation processor

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

>> - As suggested by Bruce D'Arcus, we might move `org-cite-get-boundaries'
>>   in `oc.el' proper, since it is also used elsewhere (at least in
>>   "oc-basic.el").
>
> sure, it makes more sense there, especially because I took the
> fragment from your code IIRC (apologies for the lack of explicit
> attribution)

No problem: I stole it back from you! ;) I added `org-cite-boundaries'
to "oc.el", so your library can make use of it (after a rebase).

>> - Nitpick: (car element) => (org-element-type element)
>
> I was actually wondering about this when I wrote the code and if I may
> nitpick on the nitpick, I find the documentation a bit confusing in
> this respect. If the list representation is meant to be
> internal/private only (I guess that is the case), then maybe this
> should be more explicit in the docstrings, because now the docstring
> of `org-element-context' says
>
> "Return smallest element or object around point.
>
> Return value is a list like (TYPE PROPS) [...]"
>
> Omitting the second part or having something like "Internally, return
> value is [...]" would go a long way toward conveying the message that
> one shouldn't rely on the list representation.

It's not that one shouldn't rely on the list representation, but the
expressiveness of `car' is very low, whereas `org-element-type' is
explicit. I was merely suggesting to lean towards expressiveness here.

Regards,
-- 
Nicolas Goaziou

Re: prettify-symbols-mode in org agenda?

[William Xu]

Ihor Radchenko  writes:

> Oops. Forgot to rebase the patch to current master. The correct version
> is attached.

Thanks for the fix!

I need to make below additional change, otherwise it works perfectly. I
can't reproduce the original issue any more.

Looking at the changes, I see you changed below `concat' call to
`format'. Is this in the end some bug in the `concat' implementation?

-8<- 
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 299f9ccf1..36a8443c1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7181,7 +7181,7 @@ The optional argument TYPE tells the agenda type."
   x)
  (when (match-end 1)
(setq x
- (format "%s%s%s"
+ (format "%s%s%s%s"
  (substring x 0 (match-end 1))
   (unless (string-empty-p 
org-agenda-todo-keyword-format)
(format org-agenda-todo-keyword-format
-8<- 

-- 
William

Re: allow HTML block to escape from outline-text div? WAS: BUG? unable to surround subtrees with html tag

[Matt Price]

On Tue., Jun. 22, 2021, 4:30 a.m. Richard Lawrence, <
richard.lawre...@uni-tuebingen.de> wrote:

> Hi Matt,
>
> Matt Price  writes:
>
> >> I would like to be able to surround some portion of a subtree with a
> tag,
> >> e.g.:
> >>
> >> * parent
> >>   some text
> >> #+HTML: 
> >> ** child 2
> >>   some boxed content
> >> ** child 2
> >>more boxed content
> >>  #+HTML:
> >> ** child 3
> >>   unboxed content
>
> > I don't know if there is a way to somehow slide my own html in between
> the
> > outine-text element and the outline-container element for a child
> subtree.
> > If someone knows a way to do this, I'd appreciate a pointer, but for now
> I
> > think I have to find another way to accomplish this.
>
> Is it important that your two headlines in the boxed content export as
> ?
>
> If not, you could just use a structure like
>
> * Parent
> ** Box
> *** Boxed Child 1
> *** Boxed Child 2
> ** Unboxed Child
>
> and use something like the ignoreheading filter (see Worg's "Org Hacks"
> page) to prevent "Box" from producing a separate header, and maybe
> various properties (e.g. UNNUMBERED?) to keep the boxed children from
> appearing as part of the main outline.
>
> Otherwise, #+INCLUDE comes to mind as a possible solution.
>
> Would one of those options work for you?
>

I think the :ignore: hack will not work quite right, but the others I had
not thought of at all, and I will try them out! Thank you,

Matt

>
> --
> Best,
> Richard
>

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

William Xu  writes:
> On which commit is the patch based? When I try to apply it, somehow I
> get failures:

Oops. Forgot to rebase the patch to current master. The correct version
is attached.

Best,
Ihor

>From 924375994e110ba06ea6ed3fa9aa1ecab9380d5b Mon Sep 17 00:00:00 2001
Message-Id: <924375994e110ba06ea6ed3fa9aa1ecab9380d5b.1624376467.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 22 Jun 2021 23:38:29 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda

* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width.  The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'.  The visibility settings of current buffer
are taken into account.

(org--string-from-props): Removed.  It was only used by old
`org-string-width' code.

(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.

(org-looking-at-fontified): New function.  Like `looking-at', but make
sure that the match is fontified.

* lisp/org.el (org-get-heading): Make sure that heading is fontified.

(org--get-local-tags, org-get-tags, org-scan-tags): Add optional
argument `fontified'.  When non-nil, the returned tags are fontified.

* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks, org-tags-view, org-agenda-list, org-todo-list,
org-agenda-highlight-todo): Make sure that fontification is the same
with original Org buffers.  All the buffer-substring and match-data
queries are changed to ensure that region of interest is fontified.
Also, preserve composition properties, used i.e. by
`prettify-symbols-mode'.  The composition is usually set to be removed
on text change, so we do the changes inside
`with-silent-modifications'.

(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.

(org-agenda-highlight-todo): Use `format' instead of `concat' to
update the headline in agenda.  `concat' may sometimes copy
composition property (see the C code) breaking the composed regions in
agenda view.

Preserve fontification and composition of headlines and tags in
agenda.  If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.

In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers.  The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
 lisp/org-agenda.el | 146 +++--
 lisp/org-macs.el   | 134 +
 lisp/org.el|  36 +++
 3 files changed, 181 insertions(+), 135 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..299f9ccf1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
 		  (put-text-property (point-at-bol) (point-at-eol)
  'tags
  (org-with-point-at mrk
-   (org-get-tags
+   (org-get-tags nil nil t
 	(setq org-agenda-represented-tags nil
 	  org-agenda-represented-categories nil)
 	(when org-agenda-top-headline-filter
@@ -,9 +,12 @@ (defun org-agenda-list ( arg start-day span with-hour)
 	(put-text-property s (1- (point)) 'org-today t))
 	  (setq rtnall
 		(org-agenda-add-time-grid-maybe rtnall ndays todayp))
-	  (when rtnall (insert ;; all entries
-			(org-agenda-finalize-entries rtnall 'agenda)
-			"\n"))
+  (with-silent-modifications
+;; Composition property in entries may be self-destructed
+;; on change.  Suppress the self-destruction.
+	(when rtnall (insert ;; all entries
+			  (org-agenda-finalize-entries rtnall 'agenda)
+			  "\n")))
 	  (put-text-property s (1- (point)) 'day d)
 	  (put-text-property s (1- (point)) 'org-day-cnt day-cnt)))
   (when (and org-agenda-clockreport-mode clocktable-start)
@@ -4778,10 +4781,11 @@ (defun org-search-view ( todo-only string edit-at)
   (and (eq org-agenda-show-inherited-tags t)
    (or (eq org-agenda-use-tag-inheritance t)
 	   (memq 'todo org-agenda-use-tag-inheritance
-			  tags (org-get-tags nil (not inherited-tags))
+			  tags (org-get-tags
+nil (not inherited-tags) t)
 			  txt (org-agenda-format-item
    ""
-   (buffer-substring-no-properties
+   (org-buffer-substring-fontified
 beg1 (point-at-eol))
 	

Re: prettify-symbols-mode in org agenda?

[William Xu]

Ihor Radchenko  writes:

> William Xu  writes:
>> Thanks. At least not something weird in my emacs config. :)
>>
>> I think your patch is ready to be merged into orgMode. Hopefully it can be
>> merged soon. 
>
> I believe that I managed to fix the problem you observe, though I do not
> understand how. Can you test the attached updated patch?

On which commit is the patch based? When I try to apply it, somehow I
get failures:

-8<- 
$ git am ./0001-Make-sure-that-fontification-is-preserved-in-agenda
Applying: Make sure that fontification is preserved in agenda
.git/rebase-apply/patch:269: space before tab in indent.
   'display))
error: patch failed: lisp/org-agenda.el:7142
error: lisp/org-agenda.el: patch does not apply
Patch failed at 0001 Make sure that fontification is preserved in agenda
-8<- 

-- 
William

Re: org-edit-src-exit randomizes / mixes up code in source-buffer on exit

[mcg]

Hello,

thank you very much! Update to 27 solved the problem.

All the best,

Michael


Am 22.06.2021 um 15:33 schrieb Sébastien Miquel:

Hi,

This has been reported before.

There's a patch that fixes this here : 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html


To fix this bug, you can can either apply this patch, downgrade org, 
or update emacs to 27.


Could anyone with commit access have a look and apply this patch to 
master ?


Regards,

Re: extra space at the end of lines in source

[Sébastien Miquel]

Hi Greg,

Greg Minshall writes:

hi.  i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.


See https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00867.html

The goal of the change was to fix some (electric) indentation issues when
editing a src block directly.

As I write in the linked thread, setting `org-src--preserve-indentation' 
should

revert this behaviour.

Regards,

--
Sébastien Miquel

Re: org-edit-src-exit randomizes / mixes up code in source-buffer on exit

[Sébastien Miquel]

Hi,

This has been reported before.

There's a patch that fixes this here : 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html


To fix this bug, you can can either apply this patch, downgrade org, or 
update emacs to 27.


Could anyone with commit access have a look and apply this patch to 
master ?


Regards,

--
Sébastien Miquel

Re: Large source block causes org-mode to be unusable

[Léo Ackermann]

Neither do I (concerning the special fontification).
Nevertheless, if you look at the profiler report (1st mail), the
fontification process differ from the usual one (see attached screenshot)
*because* the proof is considered as a block by org-mode.

[image: image.png]

Best,

Le mar. 22 juin 2021 à 15:03, Eric S Fraga  a écrit :

> On Tuesday, 22 Jun 2021 at 14:32, Léo Ackermann wrote:
> > Do you see what I mean ?
>
> I do but I guess I must have a differently configured system as I do not
> see any special fortification due to being in a special block.
>
> However, I see nothing in my configuration that affects special blocks.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-567-g22bf80
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>

Re: Large source block causes org-mode to be unusable

[Eric S Fraga]

On Tuesday, 22 Jun 2021 at 14:32, Léo Ackermann wrote:
> Do you see what I mean ?

I do but I guess I must have a differently configured system as I do not
see any special fortification due to being in a special block.

However, I see nothing in my configuration that affects special blocks.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-567-g22bf80
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: 404

[Timothy]

Hi Rémy,

Thanks for bringing this up. This reminds me that we want to get the
French/Japanese translations fleshed out...

All the best,
*Timothy*

Re: Large source block causes org-mode to be unusable

[Léo Ackermann]

> I am not sure what you are asking.  What specific treatment are you
referring to?

I suggest that special block in LateX export (
https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html) may be
treated differently. Once again, I'm new to org-mode, but here is my
intuition:
- What is happening now. The #+BEGIN_proof / #+END_proof keywords cause my
proof to be seen as a block. Therefore, babel fontification is called to
highlight syntax of my proof within my buffer. Timothy already discussed
here how inefficient the babel fontification is.
- What could happen. Changing (somewhere) the treatment of #BEGIN_proof &
co the following way: Assign them to a new face "latex_export_sugar" and
ignore them while editing. Doing this, the fontification of the org proof
will be made as usual and will be fast enough. While exporting, replace
#+BEGIN_proof by \begin{proof} and so on...

Do you see what I mean ?

Best,

Le mar. 22 juin 2021 à 14:13, Eric S Fraga  a écrit :

> On Tuesday, 22 Jun 2021 at 13:20, Léo Ackermann wrote:
> > I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
> > and other org-latex-special-block are treated as block ?
>
> I am not sure what you are asking.  What specific treatment are you
> referring to?
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-567-g22bf80
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>

Re: Bug: clock-in from org-agenda freezes thread when enforce + todo keywords [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

[Ihor Radchenko]

web...@toryanderson.com (Tory S. Anderson) writes:
> Steps to reproduce:
>
> 1. load emacs with the use-package declaration below
> 2. visit =M-x org-agendaa3. Clock in to the "Parent" item on the agenda 
> by highlighting it and doing =C-c C-x-- thread will freeze 
> indefinitely, although in toy example you can break free with C-g   

Confirmed

The patch is attached.

Best,
Ihor

>From 5c4a699e5a8d9ce6045d0ce710dcf14b9a92d2d8 Mon Sep 17 00:00:00 2001
Message-Id: <5c4a699e5a8d9ce6045d0ce710dcf14b9a92d2d8.1624364038.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 22 Jun 2021 20:10:16 +0800
Subject: [PATCH] Avoid infinite loop in org-agenda-dim-blocked-tasks

* lisp/org-agenda.el (org-agenda-dim-blocked-tasks): When the blocked
task is the last line in agenda buffer and no trailing newline is
present, (move-beginning-of-line 2) would not move the point causing
infinite loop.  Now, such case is handled correctly.
---
 lisp/org-agenda.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..b5fc0179a 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4107,7 +4107,9 @@ (defun org-agenda-dim-blocked-tasks ( _invisible)
 	(overlay-put ov 'face 'org-agenda-dimmed-todo-face))
 	  (when invisible
 	(org-agenda-filter-hide-line 'todo-blocked)))
-	(move-beginning-of-line 2
+(if (= (point-max) (line-end-position))
+(goto-char (point-max))
+	  (move-beginning-of-line 2)
   (when (called-interactively-p 'interactive)
 (message "Dim or hide blocked tasks...done")))
 
-- 
2.31.1

Re: Large source block causes org-mode to be unusable

[Eric S Fraga]

On Tuesday, 22 Jun 2021 at 13:20, Léo Ackermann wrote:
> I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
> and other org-latex-special-block are treated as block ?

I am not sure what you are asking.  What specific treatment are you
referring to?

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-567-g22bf80
: Latest paper written in org: https://arxiv.org/abs/2106.05096

org-edit-src-exit randomizes / mixes up code in source-buffer on exit

[mcg]

Hello,

org-edit-src-exit suddenly completely destroys my code after coming back 
from vacation. No known recent changes in configuration. Very strange 
error!


EXAMPLE: here a simple code before editing

#+BEGIN_SRC R

mtcars

sum(mtcars$mpg, na.rm = TRUE)

mean(mtcars$disp)

#+END_SRC

I enter to edit (org-edit-special), change the order of two lines and 
add a number:


Result I should get in source buffer after exiting:

#+BEGIN_SRC R

mtcars

mean(mtcars$disp)

123456789

sum(mtcars$mpg, na.rm = TRUE)

#+END_SRC

What I get in source buffer on org-edit-src-exit: (no joke!)

#+BEGIN_SRC R
rmtcars
s
ean(m
sums$di(p)mt123456789

cars$mpg, na.rm = TRUE)

mean

#+END_SRC


Came back from vacation and suddenly this happens. Only updates to 
server, elpa / melpa has not been updated the last three weeks. Emacs 
reinstallation did not help, launching without


Emacs 26.1 build 2 (2021-01-31) modified by debian

org version 9.4.6

extra space at the end of lines in source

[Greg Minshall]

hi.  i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.

i.e., the second line in each of the following source blocks is empty,
but if i =C-c '= then =C-c '=, each will end up with a few spaces on it.

#+BEGIN_SRC R
  cat("hello, world\n")

  23
#+END_SRC


#+BEGIN_SRC bash
  echo hello, world

  echo 23
#+END_SRC

i'm running
: Org mode version 9.4.6 (release_9.4.6-559-g5e4815 @ 
/home/minshall/.emacs.d/straight/build/org/)
via
: emacs -Q --eval "(add-to-list 'load-path \"~/.emacs.d/straight/build/org\")" 
foo.org

any thoughts?

cheers, Greg

Re: Large source block causes org-mode to be unusable

[Léo Ackermann]

Hi all,
Many thanks for those advices!

I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
and other org-latex-special-block are treated as block ?
I mean; those #+... aim, as far as I understand, to give tips to org-export
for prettier exports but nothing else (between those #+... you still need
to write in org). I highlight that org-latex-special-block have nothing to
do (in my point of view) with #+BEGIN_latex / #+END_latex that allow a user
to insert some LaTeX within the document (e.g. Tikz pictures).
Therefore, it might a great idea to take #+BEGIN_proof & co into account
only when it comes to export the document. The proofs/definitions/theorems
will no longer be considered as block, and fast fontification may follow :)

What do you think of this ?

Best,
Leo

Le mar. 22 juin 2021 à 09:55, Eric S Fraga  a écrit :

> On Monday, 21 Jun 2021 at 14:36, John Hendy wrote:
> > [...] or split the block into a number of more reasonably sized
> > cells.
>
> This is what I do in practice.  I then use noweb syntax to bring
> everything together.  In my case, the long LaTeX blocks tend to be tikz
> pictures.
>
> Using (native) for org-highlight-latex-and-related also helps in most
> cases.
>
> For me, the remaining performance issue is working with big tables and
> I've not found a solution to this.
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-566-gf0198e
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>
>

Re: Bug: Org async export fails with invalid read syntax “#” [9.4.4 (release_9.4.4 @ /Users/iostapyshyn/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Nicolas Goaziou]

Hello,

Illia Ostapyshyn  writes:

> When exporting asynchronously with an essentially empty 
> org-export-async-init-file, the
> process fails with this backtrace:
>
> Debugger entered--Lisp error: (invalid-read-syntax "#" 1 0)
>   read(#)
>   
> load-with-code-conversion("/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..."
>  "/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..." nil t)
>   command-line-1(("-l" "/Users/iostapyshyn/.emacs.d/org-export.el" "-l" 
> "/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..."))
>   command-line()
>   normal-top-level()

Thanks. There was another report about this a while ago.

> -  (lambda (file) (org-latex-compile file)
> +  '(lambda (file) (org-latex-compile file)

What happens if you replace 

  (lambda ...)

with

  #'org-latex-compile 

Regards,
-- 
Nicolas Goaziou

Feature request: M-u M-x org-babel-mark-block -> mark block including block definition

[Karl Voit]

Hi,

I'd like to propose a new universal argument functionality for
org-babel-mark-block: it should mark the block content (as without
universal argument) and the whole block definition as well.

Current behavior with and without universal argument:

#+NAME: my-example
#+BEGIN_SRC python
print('hello world!') <-- marked
#+END_SRC

Proposed behavior:

Without universal argument:

#+NAME: my-example
#+BEGIN_SRC python
print('hello world!')<-- marked
#+END_SRC

With universal argument:

#+NAME: my-example   <-- marked
#+BEGIN_SRC python   <-- marked
print('hello world!')<-- marked
#+END_SRC<-- marked


Personal background/motivation:

I often add blocks of all kind to list items:

- foobar
  #+BEGIN_SRC python
  print('hello world!') <-- marked
  #+END_SRC

This enables me to collapse and expand the list item together with
the block.

So far, my process of adding a block to a list item was:

- create list item
- press RET (which goes to column 1, not the indented list column)
- create the block (by using custom yankpad snippets, simulating the
  outdated quick templates(?) with, e.g.,  THIS should be addressed
  here
- move block to the right to match the desired column
  - so far, I'm using "C-x r t SPC SPC RET" but I should switch to
indent-rigidly which I covered on
https://karl-voit.at/2021/04/10/GLT21-emacs-org-features/

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

404

[Rémy Chagnollaud]

Dear Org,

 

There’s a broken link on the french homepage. The « Installation » link goes
to https://orgmode.org/fr/install.html and probably should go to
https://orgmode.org/install.html...

Not critical but easy to fix ;-)

 

Best, 

Rémy

 

 

 

Re: Large source block causes org-mode to be unusable

[Timothy]

Hi Léo,

I think I can actually speak a bit on this. As it stands, babel fontification
operates by:
- sending the src block to a dedicated buffer
- turning on the relevant major mode for the language
- forcing font-lock of the entire buffer
- cloning the font-lock information for the entire buffer back to Org

In essence, every keystroke in a babel block causes font-lock lag equal to
opening the file for the first time. As you can imagine, this adds up.

I think ideally Org would monitor which block you're executing keystrokes in,
and if there are a few in a row in the same org-src block keep the font-lock
buffer alive and incrementally update the content and intelligently copy back
font-lock changes. This has the potential to be much lower latency, but is also
going to be hard to get right.

In the meantime, you could try executing something like this in your Org
buffer ([source]):
,
| (setq-local jit-lock-defer-time 0.05
| jit-lock-stealth-time 1)
`

This sacrifices immediate font-lock accuracy for responsiveness.

All the best,
*Timothy*


[source] 

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 21.06.2021 um 10:45 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Using a space for this is perhaps too subtle as you say. Also, the
question is which one should be the default. I'd actually suggest to
turn it around:

"A quotation ending without punctuation"[cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

Reason for this: People who don't care for this distinction---either
because they use en-us only, or because they never switch from in-text
to notes styles---will probably prefer to have a space between
quotation and citation (in input and output).


People who don't care for this distinction can write

"A quotation ending without punctuation" [cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

So I guess the default doesn't matter in this case?


That's probably correct.




What about some sort of escaping for punctuation that should stay
outside the quotation marks?
"A quotation ending without punctuation" [cite: @hoel-71-whole]\.

But, of course, that's imperfect as well. Don't know which option is
less odd.


Actual usage may tell. I implemented the spacing-tweak in
"wip-cite-new". You (and others) may want to try it out on real
documents and see if it feels somewhat natural.


Ok, let's see if others have comments. I can for now at least confirm 
that the mechanism seems to work as intended.


Thanks for all your work on this!

Best,
Denis

Bug: Org async export fails with invalid read syntax “#” [9.4.4 (release_9.4.4 @ /Users/iostapyshyn/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Illia Ostapyshyn]

When exporting asynchronously with an essentially empty 
org-export-async-init-file, the
process fails with this backtrace:

Debugger entered--Lisp error: (invalid-read-syntax "#" 1 0)
  read(#)
  
load-with-code-conversion("/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..."
 "/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..." nil t)
  command-line-1(("-l" "/Users/iostapyshyn/.emacs.d/org-export.el" "-l" 
"/var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/o..."))
  command-line()
  normal-top-level()

I have tracked the issue down to this bit in org-export-process tmpfile:

(or (ignore-errors (funcall '#
"paper.tex")) ...

Read doesn't like the '# syntax, seems like it should have been #' instead. I 
have quoted
the post-process lambda in org-latex-export-to-pdf (see attached diff) and it 
seems to
have fixed the issue for me. However it doesn't seem like a proper solution.

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS 
appkit-2022.50 Version 11.4 (Build 20F71))
 of 2021-06-20
Package: Org mode version 9.4.4 (release_9.4.4 @ 
/Users/iostapyshyn/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)

diff -u --label /Users/iostapyshyn/emacs/lisp/org/ox-latex.el --label /Users/iostapyshyn/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-latex.el.gz /Users/iostapyshyn/emacs/lisp/org/ox-latex.el /var/folders/1q/6syg63894h5bqlwp2jdh8r44gn/T/jka-comShObnq
--- /Users/iostapyshyn/emacs/lisp/org/ox-latex.el
+++ /Users/iostapyshyn/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/ox-latex.el.gz
@@ -3633,7 +3633,7 @@
   (let ((outfile (org-export-output-file-name ".tex" subtreep)))
 (org-export-to-file 'latex outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  '(lambda (file) (org-latex-compile file)
 
 (defun org-latex-compile (texfile  snippet)
   "Compile a TeX file.

Diff finished.  Sun Jun 20 12:22:50 2021

Re: table: problem with nan and if

[Uwe Brauer]

>>> "t" == tbanelwebmin   writes:

> About the E format setting, you may look at documentation here:
> [[info:org#Formula syntax for Calc]]



Thanks I tried, but I think the core of the problem is that $7 needs two
ifs with two commands

#+begin_src elisp

Case I $6 empty
#+NAME: test
| Name  | E1 | E2 |  E3 | Result1 | Result2 | Final |
|---+++-+-+-+---|
| User1 ||| | |   8 |   nan |
| User2 ||| | | |   |
| User3 |  1 |  0 | 3.5 | 4.5 | 5.8 |   4.8 |
|---+++-+-+-+---|
#+TBLFM: $5=if(typeof(vsum($2..$4)) == 12, string(" "),vsum($2..$4));E 
f-1::$7=if("$6" == "nan", string(" "),0.3*$5+0.6*$6);E f-1

Case II $5 empty
#+NAME: test2
| Name  | E1 | E2 |  E3 | Result1 | Result2 | Final  |
|---+++-+-+-+|
| User1 ||| | |   8 | #ERROR |
| User2 ||| | | | #ERROR |
| User3 |  1 |  0 | 3.5 | 4.5 | 5.8 | #ERROR |
|---+++-+-+-+|
#+TBLFM: $5=if(typeof(vsum($2..$4)) == 12, string(" "),vsum($2..$4));E 
f-1::$7=if("$5" == "nan", 0.6*$6),0.3*$5+0.6*$6);E f-1

#+end_src

But even the second case does not work, sigh


smime.p7s
Description: S/MIME cryptographic signature

Re: table: problem with nan and if

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> Uwe,
> what if you change the E in each equation with N?  You'll get 0 entries
> when the calculations involve all empty cells which might not be what
> you want, of course.

In that case I obtain a 0, which I don't want


smime.p7s
Description: S/MIME cryptographic signature

Re: allow HTML block to escape from outline-text div? WAS: BUG? unable to surround subtrees with html tag

[Richard Lawrence]

Hi Matt,

Matt Price  writes:

>> I would like to be able to surround some portion of a subtree with a tag,
>> e.g.:
>>
>> * parent
>>   some text
>> #+HTML: 
>> ** child 2
>>   some boxed content
>> ** child 2
>>more boxed content
>>  #+HTML:
>> ** child 3
>>   unboxed content

> I don't know if there is a way to somehow slide my own html in between the
> outine-text element and the outline-container element for a child subtree.
> If someone knows a way to do this, I'd appreciate a pointer, but for now I
> think I have to find another way to accomplish this.

Is it important that your two headlines in the boxed content export as ?

If not, you could just use a structure like

* Parent
** Box
*** Boxed Child 1
*** Boxed Child 2
** Unboxed Child

and use something like the ignoreheading filter (see Worg's "Org Hacks"
page) to prevent "Box" from producing a separate header, and maybe
various properties (e.g. UNNUMBERED?) to keep the boxed children from
appearing as part of the main outline. 

Otherwise, #+INCLUDE comes to mind as a possible solution.

Would one of those options work for you?

-- 
Best,
Richard

Re: Large source block causes org-mode to be unusable

[Eric S Fraga]

On Monday, 21 Jun 2021 at 14:36, John Hendy wrote:
> [...] or split the block into a number of more reasonably sized
> cells.

This is what I do in practice.  I then use noweb syntax to bring
everything together.  In my case, the long LaTeX blocks tend to be tikz
pictures.

Using (native) for org-highlight-latex-and-related also helps in most
cases.

For me, the remaining performance issue is working with big tables and
I've not found a solution to this.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-566-gf0198e
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: table: problem with nan and if

[tbanelwebmin]

About the E format setting, you may look at documentation here:
[[info:org#Formula syntax for Calc]]


Le 22/06/2021 à 09:44, Eric S Fraga a écrit :
> Uwe,
>
> what if you change the E in each equation with N?  You'll get 0 entries
> when the calculations involve all empty cells which might not be what
> you want, of course.

Re: table: problem with nan and if

[Eric S Fraga]

Uwe,

what if you change the E in each equation with N?  You'll get 0 entries
when the calculations involve all empty cells which might not be what
you want, of course.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-566-gf0198e
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: table: problem with nan and if

[Uwe Brauer]

> Uwe Brauer  writes:


> I'm not very familiar with calc, but am wondering if the issue is the
> 'nan'. In many languages, a nan is a 'polluting' variable i.e. once you
> have a nan as a form anywhere in your calculation, the result will
> always be a nan. Many languages actually have a special function to test
> for a nan because it isn't actually a 'value'. Don't know if this is the
> case with calc. 

Yeah, when I googled, I found complains about nan using in calc but I
did not really found an working alternative.

> Perhaps an alternative strategy might help. Could you address what is
> generating the nan and change that so that it generates something else,
> possibly even a blank string and avoid the nan altogether? 

I tried nil and other expressions but non really worked, so maybe a calc
guru could clarify?

Regards


smime.p7s
Description: S/MIME cryptographic signature