Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]

[ian martins]

Running org-map-entries on an org file with tags results in an infinite
loop.

Example function using org-map-entries:

(defun scrum-test ()
  (interactive)
  (org-map-entries '(lambda () (message "%s" (org-entry-properties
(point) 'standard
  (message "done"))

Example org file:

* one
* two
* three
 :noexport:

expected result: visit each headline once then print "done"
actual result: visits headlines in an infinite loop and never prints "done"

It fails with: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)
It works with: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/24.5/lisp/org/)
It also works if the org file has no tags.


Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-20 on lcy01-07, modified by Debian
Package: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)

current state:
==
(setq
 org-table-export-default-format "orgtbl-to-csv"
 org-hide-leading-stars 'hidestars
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-log-done t
 org-confirm-shell-link-function 'yes-or-no-p
 org-startup-folded 'content
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local]
   5 "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-babel-tangle-lang-exts '(("python" . "py") ("java" . "java")
  ("emacs-lisp" . "el") ("elisp" . "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("eww" :follow eww :store org-eww-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)
   ("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 :complete org-bbdb-complete-link
:store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
   ("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
(lambda (path) (browse-url (concat "https:" path
   ("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path)))
)
   ("news" :follow
(lambda (path) (browse-url (concat "news:; path
   ("shell" :follow org--open-shell-link))
 org-babel-load-languages '((java . t) (python . t) (emacs-lisp . t)
(calc . t) (org . t) (screen . t) (dot . t)
(plantuml . t) (gnuplot . t))
 

Fyi: this list, emacs-orgmode, just had it's subject [tag] and footer removed

[sysadmin]

The Free Software Foundation has changed the GNU Mailman settings on
this list. The short version is that any subject prefix or message
footer has been removed, allowing us to turn off DMARC from munging.
Any list administrator for this list is free to change these settings
back, instructions are below.

The change is to better deal with increased adoption of the DMARC email
standard. The default Mailman settings were causing messages sent from
users with strict DMARC policy domains like yahoo.com to be rejected
when sent to list subscribers by Mailman. See the end of this email for
a technical overview of DMARC and DKIM. There are two main ways to fix
the issue by changing Mailman list settings.

The first option, and the preferable way for discussion lists, is what
we call the "unmodified message fix." There are Mailman list settings
which modify the messages by adding a subject prefix (e.g. [list-name])
or a footer. Modifying the message breaks DKIM message signatures and
thus DMARC, so we just turn those off. Many lists are already this way
and there is no change for them. Instead of using the subject prefix to
identify a list, subscribers should use the List-Id, To, and Cc headers.
List footer information can also be be put in the welcome email to
subscribers and the list information page by list administrators.

We changed the default for new lists to send unmodified messages, and
are now updating existing discussion lists to the new default. We
emailed all list administrators and moderators and Savannah group admins
to allow them to opt in to the alternate fix before we made this
change. However, not all lists had a valid administrator contact.

The second option is for lists which want or need to continue to modify
the message, for example with subject prefix or footer settings. In this
case we turn on a Mailman list setting called dmarc_moderation_action:
"Munge From". With this, if a strict DMARC sender sends to the list, we
alter the headers of that message like so:

A message sent to the list:

From: Anne Example Person 

Is modified by Mailman and sent to subscribers as:

From: Anne Example Person via Alist 
Reply-To: Anne Example Person 

Without going into all of the details, here's a few points about why we
concluded the unmodified message fix is better for discussion
lists. Email clients don't all treat munged messages the same way as
unmunged, and humans read these headers so it can confuse people,
causing messages not to be sent to the expected recipients. GNU Mailman
has an option to do "Munge From" always, but does not recommend using
it[1]. While we're not bound by what others do, it's worth noting that
other very large free software communities like Debian GNU/Linux have
adopted the unmodified message fix[2]. The unmodified messages fix
avoids breaking DKIM cryptographic signatures, which show the message
was authorized by the signing domain and seems like a generally good
security practice. Tools to manage patches, for example patchew, use the
from field and are tripped up by from munging.

For any Mailman list administrator who wants to change or look over the
relevant settings: The dmarc_moderation_action setting is under "Privacy
Options" subsection "Sender Filters". The only options that should be
selected are "Accept" or "Munge From", along with corresponding changes
to the subject_prefix option under "General Options", and msg_footer is
under "Non-digest options".

If no list administrators or moderators are around for this list, anyone
should feel free to try to track them down or figure out who should
become one and explain in detail by replying to sysad...@gnu.org. Please
be patient, this process may take several weeks.

Please send any questions that should be public to mail...@gnu.org. For
private ones, just reply to sysad...@gnu.org.

For the general announcement of these changes, please read
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
and
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html


A short DMARC technical overview:

DMARC policy is a DNS txt record at a _dmarc subdomain. For example:

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100;
rua=mailto:address@hidden;;;

The only important thing there for our purpose is p=reject. p=reject
means that conforming mail servers that receive mail with a from header
of *@yahoo.com will reject that email unless it was either 1. sent from
Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM
signature[5] is a public key cryptographic signature of the email body
and some headers included in the message header "DKIM-Signature". A
verified DKIM signature means that email body and signed headers have
not been modified.

Comprehensive resources about DMARC tend to downplay or ignore its
problems, but some that have helped me are Wikipedia[6], the Mailman
wiki[1], dmarc.org wiki[7], and the DMARC rfc[8].

Bug: Org-babel can't capture the output of rg/ag/pt with org-babel on OS X [9.2.6 (9.2.6-4-ge30905-elpaplus @ /Users/maxflander/.emacs.d/elpa/org-plus-contrib-20191014/)]

[Max Flander]

I'm trying to capture the output of rg but I'm getting no output (I'm getting 
the message "Code block produced no output" in the minibuffer.  

I've also tried ag and pt which don't work either. It works with grep but this 
is too slow for my use-case.

Example:

#+BEGIN_SRC shell
mkdir -p myproject
pushd myproject
echo "something" > something.txt
rg something
popd
#+END_SRC

#+RESULTS:

I've tried the solutions from these similar questions, but they're not working 
here:

* 
https://stackoverflow.com/questions/27304469/capturing-the-output-of-diff-with-org-babel
* 
https://stackoverflow.com/questions/12771642/capture-output-from-a-shell-command-with-babel-in-org-mode?noredirect=1=1

Emacs  : GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.5.0, NS appkit-1671.40 
Version 10.14.4 (Build 18E226))
of 2019-08-30
Package: Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @ 
/Users/maxflander/.emacs.d/elpa/org-plus-contrib-20191014/)

current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function 'org-html-format-inlinetask-default-function
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-imenu-depth 8
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-mode-hook '(org-indent-mode #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 #[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 
toc-org-enable org-bullets-mode
 org-eldoc-load)
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-with-inline-images t
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-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
org-babel-load-languages '((shell . t))
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php) ("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-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees 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-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open) ("eww" :follow eww :store 
org-eww-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)
   ("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 
:complete org-bbdb-complete-link
:store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys") 
("file+emacs")
   ("orgit-rev" :store orgit-rev-store :follow 
orgit-rev-open :export orgit-rev-export
:complete orgit-rev-complete-link)
   ("orgit-log" :store orgit-log-store :follow 
orgit-log-open :export orgit-log-export
:complete orgit-log-complete-link)
   ("orgit" :store orgit-status-store :follow 
orgit-status-open :export orgit-status-export
:complete orgit-status-complete-link)
   ("doi" 

Re: [RFC] Document level property drawer

[Gustav Wikström]

Hi,

> One issue for me is the positioning of the level 0 property drawer.
> Having the requirement for that drawer starting in the very first
> line is too strong for me. I guess one would at least like to have
> the option to add some configuration with the ‘-*-...-*-’ construct
> which currently only works in the first line.

Hmm, that should work right now. 0..n comment lines are supposed to be
allowed anyways. I can debug that a bit later to see if something has
gone amiss.

> Further I think one would also like to place #+: configuration lines
> there in particular the #+title: line. What about allowing lines
> starting with character # above the level 0 property drawer? And put
> a newly created level 0 property drawer below the first line in the
> file that does not start with #?

The first patch allowed both coments ("# "-lines) and keyword lines
(#+...:) as well. But I removed keyword lines for now to start with a
bit more strict definition, per request from Nicolas. I think the
parser will be happy if there is as little information abouve the
drawer as possible, since it will have to retrace itself from the
first line of the buffer every time it needs to verify that the drawer
actually is the "proper" property drawer. If that makes sense. So the
more restrictive we can allow us to be, the better the performance and
the easier it will be to understand where the drawer goes. And less
complexity.

Happy to get more feedback on that decision though!

Thanks! Gustav

Repeating dates does not support business days

[Harry Giles]

Hey!

It would be great if repeating dates supported business days. So you could
have repeating date <2019-01-01 Mon +1b>. Is this request being worked on /
do you think it is worth implementing?

Thanks, Harry

Bug: Custom TODO fields not rendered when preceded by priority [9.1.14 (9.1.14-9-g131531-elpaplus @ /Users/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/)]

[Michael Dickens]

Hi,

It seems that org-mode does not correctly parse custom to-do states when
they are preceded by a priority. This example org-mode file demonstrates
the issue:

#+TODO: TODO BLOCKED DONE
* TODO [#A] this works
* BLOCKED [#A] this works
* [#A] TODO this works
* [#A] BLOCKED this does not work

On the first three lines, Emacs correctly recognizes the to-do state and
renders it as a different color, and commands to cycle the state work
correctly. But on the fourth line, Emacs doesn't understand that
'BLOCKED' is supposed to be a to-do state, and if I cycle the state with
C-c C-t, it adds the keyword to before the priority, like this:

* TODO [#A] BLOCKED this does not work

To make sure it wasn't an issue with my config, I asked an Emacs-using
coworker to replicate, and his didn't work either, but it behaved
incorrectly on both lines 3 and 4, whereas mine behaves correctly on
line 3 but not on line 4.

You could argue that this is expected behavior and the priority should
go after the to-do state, but IMO it should work either way because it
can still be unambiguously parsed. I have some Emacs extensions that
automatically put the priority before the to-do state, which then causes
Emacs to parse the header incorrectly.

Thanks,
Michael

Emacs  : GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.2.0, Carbon Version
158 AppKit 1671.1)
of 2018-12-13
Package: Org mode version 9.1.14 (9.1.14-9-g131531-elpaplus @
/Users/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/)

Question mark not supported in structured templates?

[Vladimir Nikishkin]

Hello, everyone.

I recently updated to org 9.2 from org-melpa, and I have the following issue:

I use org with org-babel to write a book with many examples and illustrations.

I use ob-plantuml and ob-scheme in particular.
The problem is that for ob-plantuml I need the value of point be right
after the :file header parameter, because plantuml always requires a
file name.

For scheme, however, there is no need to write a file name, there are no files.

Is there no way to specify where to put the point in the new version of org?

-- 
Yours sincerely, Vladimir Nikishkin

Re: Question mark not supported in structured templates?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 15:57, Vladimir Nikishkin wrote:
> The problem is that for ob-plantuml I need the value of point be right
> after the :file header parameter, because plantuml always requires a
> file name.

I don't see this in my configuration.  But it could be that I do not
understand what you are saying.  Maybe explain a bit further and/or give
a small example?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78

Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Vladimir Nikishkin]

I used org 8 until recently, and it used to be that I could type "<"
at the beginning of a line, and it would be still a single "<" (thus
allowing the expansion of structured templates with TAB)

In org 9.2 electric-pair-mode seems to be working all the time.

What is the recommended way of making paired parentheses in org 9.2?

Shall I inhibit electric-pair-mode somehow myself, and instead rely on
org-cdlatex-mode?

What would be the correct incantation to put in the .emacs file?

Thanks!

-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 16:09, Vladimir Nikishkin wrote:
> I used org 8 until recently, and it used to be that I could type "<"
> at the beginning of a line, and it would be still a single "<" (thus
> allowing the expansion of structured templates with TAB)

Expansion of structured templates is no longer done using < at the start
of a line.  A more general approach is now available,
org-insert-structure-template which is bound to C-c C-, for me at
least.  It prompts for what to insert and, most importantly, will wrap
the structure around any region that has been selected.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78

Re: Question mark not supported in structured templates?

[Vladimir Nikishkin]

In the version 8 of org-mode you could indicate where to put the point
after the template is expanded. In the template
(list "p" "#begin_src plantuml :file ? :export both \n#end_src"),
after the template is expanded, the point would be located after
:file, whereas in the template (list "SO" "#begin_src scheme :export
both \n?\n#end_src") the point would be located on the frist line
after the header.

At the moment, `org-insert-structure-template' just inserts the
question mark verbatim. I would consider this a regression, but maybe
there is some replacement mechanism?

вт, 29 окт. 2019 г. в 16:23, Fraga, Eric :
>
> On Tuesday, 29 Oct 2019 at 15:57, Vladimir Nikishkin wrote:
> > The problem is that for ob-plantuml I need the value of point be right
> > after the :file header parameter, because plantuml always requires a
> > file name.
>
> I don't see this in my configuration.  But it could be that I do not
> understand what you are saying.  Maybe explain a bit further and/or give
> a small example?
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78



-- 
Yours sincerely, Vladimir Nikishkin

Re: Bug: org-read-date ignores hours?

[Marco Wahl]

agzam.ibragi...@gmail.com writes:

> While fooling around with capture templates, I have also noticed this:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt t)
>   (read-date t)))
>
> When prompted, if you type something like "13:00" - it returns correct,
> expected datetime.
>
> But, if you do:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt nil)
>   (read-date t)))
>
> And again, type some time value in the prompt - it returns date with no
> time. This seems to be a bug.

I can confirm this behavior with org-read-date instead of read-date.
And at first glance I also think this is a bug.

I capture this issue for someday.  But of course anyone please feel free
to fix this.

The same holds for the idea to add "h" (hours) and possibly "M"
(minutes) as a further way to specify the hour via org-read-date.


Thanks!

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Vladimir Nikishkin]

No it is not, please, don't disinform people.

вт, 29 окт. 2019 г. в 17:03, Fraga, Eric :
>
> On Tuesday, 29 Oct 2019 at 16:50, Vladimir Nikishkin wrote:
> > I think, these are two different mechanisms. C-c C-, works as expected.
> > The "<" mechanism comes from org-tempo, and is faster, because you
> > don't have to choose anything.
>
> I don't know anything about org-tempo but, just to be clear, the old <
> at beginning of line mechanism that was available, by default, in org
> 8.x is no longer available.  It was replaced by C-c C-,.
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78



-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 17:06, Vladimir Nikishkin wrote:
> No it is not, please, don't disinform people.

Not intending to do so but please clarify: in which way am I
misinforming people?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 16:50, Vladimir Nikishkin wrote:
> I think, these are two different mechanisms. C-c C-, works as expected.
> The "<" mechanism comes from org-tempo, and is faster, because you
> don't have to choose anything.

I don't know anything about org-tempo but, just to be clear, the old <
at beginning of line mechanism that was available, by default, in org
8.x is no longer available.  It was replaced by C-c C-,.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78

Re: org-scrum

[Adam Porter]

ian martins  writes:

> Hello, I wrote some helper functions for generating a scrum board and
> reports that is built on top of org-mode. The project is currently
> emacs-scrum. I submitted it to melpa recently and got the suggestion
> to name the package org-scrum since it's based on org-mode. Is that
> fine?

Yes.

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Vladimir Nikishkin]

And this question is _not_ about the template expansion, but about the
electric-pair-mode.

вт, 29 окт. 2019 г. в 17:06, Vladimir Nikishkin :
>
> No it is not, please, don't disinform people.
>
> вт, 29 окт. 2019 г. в 17:03, Fraga, Eric :
> >
> > On Tuesday, 29 Oct 2019 at 16:50, Vladimir Nikishkin wrote:
> > > I think, these are two different mechanisms. C-c C-, works as expected.
> > > The "<" mechanism comes from org-tempo, and is faster, because you
> > > don't have to choose anything.
> >
> > I don't know anything about org-tempo but, just to be clear, the old <
> > at beginning of line mechanism that was available, by default, in org
> > 8.x is no longer available.  It was replaced by C-c C-,.
> >
> > --
> > Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin



-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Vladimir Nikishkin]

I think, these are two different mechanisms. C-c C-, works as expected.
The "<" mechanism comes from org-tempo, and is faster, because you
don't have to choose anything.

вт, 29 окт. 2019 г. в 16:21, Fraga, Eric :
>
> On Tuesday, 29 Oct 2019 at 16:09, Vladimir Nikishkin wrote:
> > I used org 8 until recently, and it used to be that I could type "<"
> > at the beginning of a line, and it would be still a single "<" (thus
> > allowing the expansion of structured templates with TAB)
>
> Expansion of structured templates is no longer done using < at the start
> of a line.  A more general approach is now available,
> org-insert-structure-template which is bound to C-c C-, for me at
> least.  It prompts for what to insert and, most importantly, will wrap
> the structure around any region that has been selected.
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78



-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Vladimir Nikishkin]

Please, consider visitiong M-x info-display-manual RET org RET section
15.2, paragraph 4.

вт, 29 окт. 2019 г. в 18:08, Fraga, Eric :
>
> On Tuesday, 29 Oct 2019 at 17:06, Vladimir Nikishkin wrote:
> > No it is not, please, don't disinform people.
>
> Not intending to do so but please clarify: in which way am I
> misinforming people?
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3



-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Julius Müller]

Am 29.10.19 um 16:08 schrieb Julius Müller:
> Am 29.10.19 um 15:57 schrieb Vladimir Nikishkin:
>> Please, consider visitiong M-x info-display-manual RET org RET section
>> 15.2, paragraph 4.
> 
> Well, there's at least something missing in that documentation. Without
> any config file active, but with org mode loaded, those abbreviations
> are not availlable to me (as I expected from discussions in this group).

Oops, I mistyped. My fault. Sorry for the noise.

Julius

Re: Discrepancy between documentation and implementation regarding comments

[Robert Pluim]

> On Tue, 29 Oct 2019 15:14:37 +0100, Thibault Polge  said:

Thibault> Robert Pluim writes:
>> end of line *is* a whitespace character, but Iʼm not going to argue
>> that. Iʼm going to argue that this doesnʼt cover the case of a '#' at
>> EOB without a newline, hence saying 'zero or more' would be better.

Thibault> But zero-or-more would mean that this line:

Thibault> #Alpha

Thatʼs the problem with human language, itʼs imprecise. I meant

^[ \t]*#[ \t]*$

Robert

Different exporters behave differently re exporter-specific lines

[Thibault Polge]

I'm not sure how this feature is called, but in Org you can restrict a line
to a given exporter by prepending it with, eg, #+latex:

There's a bug with some exporters f treat these lines as paragraph breaks,
some don't.  For example, the following input:

Hello
#+latex: \TeX{}
World
#+html: Wide Web
!

Is exported to LaTeX as a single line, "Hello TeX World !", but to HTML
as separate paragraphs:


Hello


World

Wide Web

!


I wouldn't except these lines to introduce any paragraphs break.

This is with Emacs built from Git, using Org 9.2.6.

Best regards,
Thibault


signature.asc
Description: PGP signature

Re: Discrepancy between documentation and implementation regarding comments

[Robert Pluim]

> On Mon, 28 Oct 2019 17:16:55 +0100, Nicolas Goaziou 
>  said:

Nicolas> Hello,
Nicolas> Thibault Polge  writes:

>> Thanks Nicolas, just a small detail though: unless this is a planned
>> (breaking) change, I believe the description you linked should read:
>> 
>> A “comment line” starts with *zero or more whitespace characters,
>> followed by* a hash sign, followed by a whitespace character or an end
>> of line.

Nicolas> True. I fixed that.

end of line *is* a whitespace character, but Iʼm not going to argue
that. Iʼm going to argue that this doesnʼt cover the case of a '#' at
EOB without a newline, hence saying 'zero or more' would be better.

(and if it really is *one* whitespace character, thatʼs a breaking
change from at least org-9.2.6, which allows zero-or-more).

Robert

Re: Discrepancy between documentation and implementation regarding comments

[Thibault Polge]

Robert Pluim writes:

> end of line *is* a whitespace character, but Iʼm not going to argue
> that. Iʼm going to argue that this doesnʼt cover the case of a '#' at
> EOB without a newline, hence saying 'zero or more' would be better.

But zero-or-more would mean that this line:

#Alpha

Is a comment, along with:

#+TITLE: My Org document

And virtually of all Org meta-lines. I've thought about the \n#
issue, but I haven't tested how the current implementation behaves in
this regard.  I think the recent changes in Pandoc would parse it as a
comment.

Regards,
Thibault


signature.asc
Description: PGP signature

Re: Refresher on including R/ggplot2 output via latex/pdf?

[Jack Kamm]

> Closing the loop. I can confirm that my example works on this commit
> (one before the relevant change) (thanks, Chuck!).
>
> commit ed9bdfd220b75233e5bae2ef39164d14624060fa (HEAD)
> Merge: 0954d4c25 0ae2e656d
> Author: Marco Wahl 
> Date:   Fri Oct 5 00:54:19 2018 +0200
>
> Completely stumped on how that works for you.

My version of org-mode is from September 30, shortly before this commit,
I guess that's why it still works for me. Though I'm confused why the
example didn't work for you on your older version of Org from June.

I guess I'll have to prepare for some breakage with ob-R next time I
update -- thanks for the heads up on this. I'll test it out and report
my findings when I get a chance.

Re: Refresher on including R/ggplot2 output via latex/pdf?

[John Hendy]

On Mon, Oct 28, 2019 at 12:46 PM Jack Kamm  wrote:
>
> > 2) why does this [still] work for Jack? (Jack, what's M-x org-version for 
> > you?)
>
> I tested on my laptop and desktop, both work for me, they are running the 
> following 2 versions of org:
>
> Org mode version 9.2.4 (9.2.4-13-g9a543b-elpaplus @ 
> /home/jack/.emacs.d/elpa/org-plus-contrib-20190729/)
> Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @ 
> /home/jack/.emacs.d/elpa/org-plus-contrib-20190930/)

Closing the loop. I can confirm that my example works on this commit
(one before the relevant change) (thanks, Chuck!).

commit ed9bdfd220b75233e5bae2ef39164d14624060fa (HEAD)
Merge: 0954d4c25 0ae2e656d
Author: Marco Wahl 
Date:   Fri Oct 5 00:54:19 2018 +0200

Completely stumped on how that works for you.

My final question; is the documentation accurate, or more accurately,
is it unambiguous?

14.8.2.2 :results
file Interpret as path to a file. Inserts a link to the file. Usage
example: :results value file.

14.8.2.3 :file
An external :file that saves the results of execution of the code
block... A link to the file is inserted.

As written, using :results file and :file both claim to insert a link
to the file. Should this be clarified?

Thanks all,
John

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Julius Müller]

Am 29.10.19 um 15:57 schrieb Vladimir Nikishkin:
> Please, consider visitiong M-x info-display-manual RET org RET section
> 15.2, paragraph 4.

Well, there's at least something missing in that documentation. Without
any config file active, but with org mode loaded, those abbreviations
are not availlable to me (as I expected from discussions in this group).

HTH,
Julius

Re: Refresher on including R/ggplot2 output via latex/pdf?

[John Hendy]

On Tue, Oct 29, 2019 at 9:51 AM Jack Kamm  wrote:
>
> > Closing the loop. I can confirm that my example works on this commit
> > (one before the relevant change) (thanks, Chuck!).
> >
> > commit ed9bdfd220b75233e5bae2ef39164d14624060fa (HEAD)
> > Merge: 0954d4c25 0ae2e656d
> > Author: Marco Wahl 
> > Date:   Fri Oct 5 00:54:19 2018 +0200
> >
> > Completely stumped on how that works for you.
>
> My version of org-mode is from September 30, shortly before this commit,
> I guess that's why it still works for me. Though I'm confused why the
> example didn't work for you on your older version of Org from June.

Chuck clarified offline that the commit is from Oct *2018*, not 2019.
Both 9.2.4 and 9.2.6 are much more recent.

At least I interpret your response as thinking this is a recent change
(which is exactly what I thought at first!)?

John

> I guess I'll have to prepare for some breakage with ob-R next time I
> update -- thanks for the heads up on this. I'll test it out and report
> my findings when I get a chance.

Re: Different exporters behave differently re exporter-specific lines

[Fraga, Eric]

Thibault,

in case you might find this useful, you can use the @@ construct to put
things inline, causing less issues with paragraphs.  For instance, you
can write @@latex:\TeX{}@@.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3

Re: Different exporters behave differently re exporter-specific lines

[Thibault Polge]

> I doubt it. There are 3 paragraphs, even for LaTeX, since there are
> empty lines.

I believe there may have been a communication issue somewhere, since you
cite my message with extra \n --- there are no empty lines in my
original message.  For reference, here's the exact input I've used:
.

The PDF output is at https://paste.thb.lt/test.pdf, the HTML output
here https://paste.thb.lt/test.html

As you can see, the LaTeX PDFs have everything in a single line, the
HTML output displays four separate paragraphs.

Best regards,
Thibault

Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

[John Kitchin]

I wrote about a potential solution to this issue at
https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch/52209#52209
.

You might find a solution that works for you there.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Tue, Oct 29, 2019 at 11:52 AM Vladimir Nikishkin 
wrote:

>
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  https://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org mailing list.
> 
>
> The MWE would be the following:
> #+begin_src scheme
> (display (< 1 3))
> #+end_src
>
> In this example, if you put the point on the "<" symbol, it is
> highlighted (fontified) together with the ")" following 3, which is
> incorrect, since
> in general, "<" is not a paired entity. (I.e. is a symbol "less" rather
> than an angular bracket.) If you put the point on the first "(", the
> notification area claims that "No closing parenthesis found", which is
> obviously wrong.
>
> C-h s has the following lines:
>  <  (>  which means: open, matches >
>  >  )<  which means: close, matches <
> Which seems to be not really correct for anything except noweb references.
>
>
> Emacs  : GNU Emacs 26.3 (build 1, x86_64-slackware-linux-gnu, GTK+ Version
> 3.24.10)
>  of 2019-08-30
> Package: Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @
> /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)
>
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
>  org-after-todo-state-change-hook '(org-checklist)
>  org-babel-after-execute-hook '((lambda nil
>  (if org-inline-image-overlays
>   (progn (org-redisplay-inline-images)))
>  )
> )
>  org-texinfo-format-headline-function
> 'org-texinfo-format-headline-default-function
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-html-format-inlinetask-function
> 'org-html-format-inlinetask-default-function
>  org-pretty-entities t
>  org-odt-format-headline-function 'org-odt-format-headline-default-function
>  org-agenda-files '("~/DevLinux/chibi-sicp/index.org"
> "~/Personal_Planner/Planner.org")
>  org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
>  org-reveal-start-hook '(org-decrypt-entry)
>  org-modules '(org-habits org-w3m org-bbdb org-bibtex org-docview org-gnus
> org-info org-irc
>org-mhe org-rmail org-eww)
>  org-plantuml-jar-path "/usr/local/bin/plantuml.jar"
>  org-mode-hook '(org-tempo-setup
>  #[0 "\301\211\207" [imenu-create-index-function
> org-imenu-get-tree] 2]
>  turn-on-org-cdlatex (lambda nil (imenu-add-to-menubar
> "Imenu"))
>  #[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-eldoc-load)
>  org-ref-insert-cite-function 'org-ref-insert-cite-link
>  org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
>  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-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-latex-compiler "lualatex"
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> org-babel-header-arg-expand)
>  org-babel-load-languages '((plantuml . t) (C . t) (scheme . t) (latex .
> t))
>  org-log-done 'time
>  org-ref-insert-label-function 'org-insert-link
>  org-checklist-export-function 'org-export-as-ascii
>  org-startup-align-all-tables t
>  org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
> WIDTH)"]
>  org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" .
> php) ("C" . c)
>   ("C++" . c++) ("asymptote" . asy) ("bash" . sh)
> ("beamer" . latex)
>   ("calc" . fundamental) ("cpp" . c++) ("ditaa" .
> artist)
>   ("dot" . fundamental) ("elisp" . emacs-lisp)
> ("ocaml" . 

Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

[Vladimir Nikishkin]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


The MWE would be the following:
#+begin_src scheme
(display (< 1 3))
#+end_src

In this example, if you put the point on the "<" symbol, it is
highlighted (fontified) together with the ")" following 3, which is incorrect, 
since
in general, "<" is not a paired entity. (I.e. is a symbol "less" rather
than an angular bracket.) If you put the point on the first "(", the
notification area claims that "No closing parenthesis found", which is
obviously wrong.

C-h s has the following lines:
 <  (>  which means: open, matches >
 >  )<  which means: close, matches <
Which seems to be not really correct for anything except noweb references.


Emacs  : GNU Emacs 26.3 (build 1, x86_64-slackware-linux-gnu, GTK+ Version 
3.24.10)
 of 2019-08-30
Package: Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @ 
/home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-checklist)
 org-babel-after-execute-hook '((lambda nil
 (if org-inline-image-overlays
  (progn (org-redisplay-inline-images)))
 )
)
 org-texinfo-format-headline-function 
'org-texinfo-format-headline-default-function
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-pretty-entities t
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-agenda-files '("~/DevLinux/chibi-sicp/index.org" 
"~/Personal_Planner/Planner.org")
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-reveal-start-hook '(org-decrypt-entry)
 org-modules '(org-habits org-w3m org-bbdb org-bibtex org-docview org-gnus 
org-info org-irc
   org-mhe org-rmail org-eww)
 org-plantuml-jar-path "/usr/local/bin/plantuml.jar"
 org-mode-hook '(org-tempo-setup
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 turn-on-org-cdlatex (lambda nil (imenu-add-to-menubar "Imenu"))
 #[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-eldoc-load)
 org-ref-insert-cite-function 'org-ref-insert-cite-link
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 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-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-latex-compiler "lualatex"
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-babel-load-languages '((plantuml . t) (C . t) (scheme . t) (latex . t))
 org-log-done 'time
 org-ref-insert-label-function 'org-insert-link
 org-checklist-export-function 'org-export-as-ascii
 org-startup-align-all-tables t
 org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php) 
("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 t
 org-occur-hook '(org-first-headline-recenter)
 org-ref-insert-link-function 'org-ref-insert-cite-link
 org-ref-insert-ref-function 'org-insert-link
 org-edit-src-auto-save-idle-delay 15
 org-agenda-include-diary t
 org-structure-template-alist '(("EL" . "src elisp :exports both :results 
output\n?\n")
("SV" . "src scheme :exports both :results 
value\n?\n")
("SO" . "src scheme :exports both :results 
output\n?\n")
("p" . "src plantuml :exports both :file ? \n ")
   

Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 23:50, Vladimir Nikishkin wrote:
> The MWE would be the following:
>
> #+begin_src scheme
> (display (< 1 3))
> #+end_src
>
> In this example, if you put the point on the "<" symbol, it is
> highlighted (fontified) together with the ")" following 3, which is
> incorrect, since in general, "<" is not a paired entity. (I.e. is a
> symbol "less" rather than an angular bracket.) 

I have the following 2 lines in my org-mode-hook to cater for this issue
which arises when using source blocks.

(modify-syntax-entry ?< ".")
(modify-syntax-entry ?> ".")

HTH
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3

Re: Question mark not supported in structured templates?

[Berry, Charles]

`org-tempo' is the replacement. It is mentioned in the docstring for 
`org-structure-template-alist'. 

Here is what I have in my `emacs-init.org' file:

(The letter `p' denotes where point should land. `n' is a newline. See the 
docstring for `tempo-define-template' for more details.)


#+begin_src emacs-lisp 

  (require 'org-tempo)


  (tempo-define-template "org-src_R"
 '("#+begin_src R" p  n
   n "#+end_src" )
 " n p
  n "\\end{eqnarray}" >)
 " n p
  n "\\end{equation}" >)
 " On Oct 29, 2019, at 1:59 AM, Vladimir Nikishkin  wrote:
> 
> In the version 8 of org-mode you could indicate where to put the point
> after the template is expanded. In the template
> (list "p" "#begin_src plantuml :file ? :export both \n#end_src"),
> after the template is expanded, the point would be located after
> :file, whereas in the template (list "SO" "#begin_src scheme :export
> both \n?\n#end_src") the point would be located on the frist line
> after the header.
> 
> At the moment, `org-insert-structure-template' just inserts the
> question mark verbatim. I would consider this a regression, but maybe
> there is some replacement mechanism?

Re: Different exporters behave differently re exporter-specific lines

[Nicolas Goaziou]

Hello,

Thibault Polge  writes:

> I'm not sure how this feature is called, but in Org you can restrict a line
> to a given exporter by prepending it with, eg, #+latex:
>
> There's a bug with some exporters f treat these lines as paragraph breaks,
> some don't.  For example, the following input:

This is not a bug in the exporters. The discrepancy exists in the output
languages, in particular in paragraphs. Org uses a definition of
a paragraph close to LaTeX's, so an Org paragraph isn't quite a HTML
paragraph.

> Hello
>
> #+latex: \TeX{}
> World
>
> #+html: Wide Web
> !
>
> Is exported to LaTeX as a single line, 

I doubt it. There are 3 paragraphs, even for LaTeX, since there are
empty lines.

> "Hello TeX World !", but to HTML
> as separate paragraphs:
>
> 
> Hello
> 
> 
> World
> 
> Wide Web
> 
> !
> 
>
> I wouldn't except these lines to introduce any paragraphs break.

Of course they should. You should look at the definition of a paragraph,
per Org syntax. Keywords cannot belong to a paragraph.

Regards,

-- 
Nicolas Goaziou

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 22:57, Vladimir Nikishkin wrote:
> Please, consider visitiong M-x info-display-manual RET org RET section
> 15.2, paragraph 4.

You must have a different version of the manual than I have.  For me,
this section is on header arguments for working with source code and the
4th paragraph says nothing relevant as far as I can tell.  Anyway, no
worries.  I hope you get what you want sorted.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3

Re: Different exporters behave differently re exporter-specific lines

[Nicolas Goaziou]

Thibault Polge  writes:

> As you can see, the LaTeX PDFs have everything in a single line, the
> HTML output displays four separate paragraphs.

This is because the definition of a paragraph in HTML, or LaTeX,isn't
the same as in Org. In this particular case, HTML matches Org
definition. LaTeX is more lax.

Regards,

Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

[Vladimir Nikishkin]

That's probably a working solution, but I still wonder why org 8
doesn't have this problem.

Thanks anyway.

ср, 30 окт. 2019 г. в 00:40, Fraga, Eric :
>
> On Tuesday, 29 Oct 2019 at 23:50, Vladimir Nikishkin wrote:
> > The MWE would be the following:
> >
> > #+begin_src scheme
> > (display (< 1 3))
> > #+end_src
> >
> > In this example, if you put the point on the "<" symbol, it is
> > highlighted (fontified) together with the ")" following 3, which is
> > incorrect, since in general, "<" is not a paired entity. (I.e. is a
> > symbol "less" rather than an angular bracket.)
>
> I have the following 2 lines in my org-mode-hook to cater for this issue
> which arises when using source blocks.
>
> (modify-syntax-entry ?< ".")
> (modify-syntax-entry ?> ".")
>
> HTH
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3



-- 
Yours sincerely, Vladimir Nikishkin

Re: Question mark not supported in structured templates?

[Vladimir Nikishkin]

What is the canonical difference between org-insert-structure-template
and org-tempo then?

I think, emacs skeleton libraries (M-x info-display-manual RET
autotype RET) support placing the point (with a "_" marker)

ср, 30 окт. 2019 г. в 00:43, Berry, Charles :
>
> `org-tempo' is the replacement. It is mentioned in the docstring for 
> `org-structure-template-alist'.
>
> Here is what I have in my `emacs-init.org' file:
>
> (The letter `p' denotes where point should land. `n' is a newline. See the 
> docstring for `tempo-define-template' for more details.)
>
>
> #+begin_src emacs-lisp
>
>   (require 'org-tempo)
>
>
>   (tempo-define-template "org-src_R"
>  '("#+begin_src R" p  n
>n "#+end_src" )
>  "
>   (tempo-define-template "org-src-named-R"
>  '("#+name: " p  n
>"#+begin_src R"   n
>   n "#+end_src" )
>  "
>   (tempo-define-template "org-eqnarray"
>  '("\\begin{eqnarray} " '> n p
>   n "\\end{eqnarray}" >)
>  "
>   (tempo-define-template "org-equation"
>  '("\\begin{equation} " '> n p
>   n "\\end{equation}" >)
>  "
>   (tempo-define-template "org-displaymath"
>  '("# begin math" n
>"\\["  p n
>"\\]" n
>"# end math" n)
>  "
> #+end_src
>
> HTH,
>
> Chuck
>
>
> > On Oct 29, 2019, at 1:59 AM, Vladimir Nikishkin  wrote:
> >
> > In the version 8 of org-mode you could indicate where to put the point
> > after the template is expanded. In the template
> > (list "p" "#begin_src plantuml :file ? :export both \n#end_src"),
> > after the template is expanded, the point would be located after
> > :file, whereas in the template (list "SO" "#begin_src scheme :export
> > both \n?\n#end_src") the point would be located on the frist line
> > after the header.
> >
> > At the moment, `org-insert-structure-template' just inserts the
> > question mark verbatim. I would consider this a regression, but maybe
> > there is some replacement mechanism?
>
>


-- 
Yours sincerely, Vladimir Nikishkin

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Nick Dokos]

"Fraga, Eric"  writes:

> On Tuesday, 29 Oct 2019 at 16:50, Vladimir Nikishkin wrote:
>> I think, these are two different mechanisms. C-c C-, works as expected.
>> The "<" mechanism comes from org-tempo, and is faster, because you
>> don't have to choose anything.
>
> I don't know anything about org-tempo but, just to be clear, the old <
> at beginning of line mechanism that was available, by default, in org
> 8.x is no longer available.  It was replaced by C-c C-,.

Not quite: there is still an emulation of the old mechanism if you

(require 'org-tempo)

which Vladimir probably does. That modifies the following hook:

,
| org-tab-before-tab-emulation-hook is a variable defined in ‘org.el’.
| Its value is (org-tempo-complete-tag)
`

The hook is run close to the end of org-cycle (which is bound to TAB). So
when you type

Re: Good way to pre/view LaTeX-lines?

[Dmitrii Korobeinikov]

>> https://ivanaf.com/Automatic_Latex_Fragment_Toggling_in_org-mode.html

Exactly what I wanted. I will be using this.

BTW just as a minor point, no need for setq when byte-compiling,
https://www.gnu.org/software/emacs/manual/html_node/elisp/Compilation-Functions.html#Compilation-Functions
/This function byte-compiles the function definition of symbol, replacing
the previous definition with the compiled one./

And thank you!

Regards,
Dmitrii

пн, 28 окт. 2019 г. в 07:22, Ivan Tadeu Ferreira Antunes Filho <
iva...@mit.edu>:

> for 2 I have adapted a solution from jkitchin:
>
> https://ivanaf.com/Automatic_Latex_Fragment_Toggling_in_org-mode.html
>
> 
> *Ivan Tadeu Ferreira Antunes Filho*
>
>
> On Sun, Oct 27, 2019 at 3:29 PM Dmitrii Korobeinikov 
> wrote:
>
>> > https://orgmode.org/org.html#Previewing-LaTeX-fragments
>>
>> Thank you, William! This is great.
>>
>> After some digging, I still gotta wonder about a few things though.
>> 1. Is there some sort of live-editing feature? By that I mean, being able
>> to view the result (in a seperate buffer or minibuffer or even on the next
>> line) as you type out the expression. In particular, it would be nice to
>> know how to show an image in the minibuffer (and if possible at all) and
>> how to effectively feed what's under cursor to the latex backend and get
>> the image.
>> 2. It would be handy to autoremove the image overlay when the cursor is
>> on the fragment (and restore it when goes outside). I think no redraw
>> should be necessary unless the the formula is edited.
>>
>> I guess I would have to dig into org-toggle-latex-fragment to know how to
>> do these, but any help/pointers would be appreciated.
>>
>> Regards,
>> Dmitrii
>>
>> вс, 27 окт. 2019 г. в 21:07, William Denton :
>>
>>> On 27 October 2019, Dmitrii Korobeinikov wrote:
>>>
>>> > I am looking for a comfortable way to view LaTeX (for math formulas) in
>>> > org-mode.
>>>
>>> This shows how:
>>>
>>> https://orgmode.org/org.html#Previewing-LaTeX-fragments
>>>
>>> I don't use it often, but it works very nicely.
>>>
>>> Bill
>>> --
>>> William Denton :: Toronto, Canada   ---   Listening to Art:
>>> https://listeningtoart.org/
>>> https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
>>> Caveat lector.  ---   STAPLR: https://staplr.org/
>>>
>> ___
>> Ita mailing list
>> i...@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/ita
>>
>

Re: Good way to pre/view LaTeX-lines?

[Dmitrii Korobeinikov]

Cool, I didn't know about maxima. I will look into trying it out. Thanks!

Regards,
Dmitrii

пн, 28 окт. 2019 г. в 07:08, briangpowell . :

> * Suggest reviewing these free software packages:
> https://itsfoss.com/latex-editors-linux/
>
> ** LyX and/or Kile are my faves
>
> ** Suggest trying these free software packages too
>
> apt-get install imaxima
> apt-get install maxima
> apt-get install maxima-emacs
> apt-get install texlive
> apt-get install texlive-math-extra
>
>
>
>
>
>
>
> On Sun, Oct 27, 2019 at 3:29 PM Dmitrii Korobeinikov 
> wrote:
>
>> > https://orgmode.org/org.html#Previewing-LaTeX-fragments
>>
>> Thank you, William! This is great.
>>
>> After some digging, I still gotta wonder about a few things though.
>> 1. Is there some sort of live-editing feature? By that I mean, being able
>> to view the result (in a seperate buffer or minibuffer or even on the next
>> line) as you type out the expression. In particular, it would be nice to
>> know how to show an image in the minibuffer (and if possible at all) and
>> how to effectively feed what's under cursor to the latex backend and get
>> the image.
>> 2. It would be handy to autoremove the image overlay when the cursor is
>> on the fragment (and restore it when goes outside). I think no redraw
>> should be necessary unless the the formula is edited.
>>
>> I guess I would have to dig into org-toggle-latex-fragment to know how to
>> do these, but any help/pointers would be appreciated.
>>
>> Regards,
>> Dmitrii
>>
>> вс, 27 окт. 2019 г. в 21:07, William Denton :
>>
>>> On 27 October 2019, Dmitrii Korobeinikov wrote:
>>>
>>> > I am looking for a comfortable way to view LaTeX (for math formulas) in
>>> > org-mode.
>>>
>>> This shows how:
>>>
>>> https://orgmode.org/org.html#Previewing-LaTeX-fragments
>>>
>>> I don't use it often, but it works very nicely.
>>>
>>> Bill
>>> --
>>> William Denton :: Toronto, Canada   ---   Listening to Art:
>>> https://listeningtoart.org/
>>> https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
>>> Caveat lector.  ---   STAPLR: https://staplr.org/
>>>
>>

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Fraga, Eric]

On Tuesday, 29 Oct 2019 at 16:17, Nick Dokos wrote:
> Not quite: there is still an emulation of the old mechanism if you
>
> (require 'org-tempo)

Ah, thanks for clarifying.
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78