date:20211203

Timothy  writes:

> ⁃ Elements
>   • Greater Elements
>   • (other) Elements
>
> to
>
> ⁃ Elements
>   • Greater Elements
>   • Lesser Elements

This sounds reasonable. We can change

- Three categories are used to classify these environments: “Greater
  elements”, “elements”, and “objects”, from the broadest scope to the
  narrowest. The word “element” is used for both Greater and non-Greater
  elements, the context should make that clear.
+ Two main categories are used to classify these environments:
  "elements" and "objects", from the broadest scope to the narrowest.
  "Elements" consist of "greater elements" that can contain other
  elements and objects and "lesser elements" that can only contain
  objects.

>> [Comments on headings and sections]
>
> This accords with my reading of the document and the way I’ve implemented 
> things
> in OrgMode.jl (see 
> ).

One small clarification. The headline structure is actually
(headline (optional whitespace) (optional section) (optional repeat 
nester-headlines))

Section may not start immediately after the first newline but also after
you skip blank chars in front.

For example:

* This is a headline _without_ section, even though it contains some newlines


* Another headline

Section starts at the word "section" and spans all the way to the next headline 
or EOB


* Next headline

Best,
Ihor

Re: On zero width spaces and Org syntax

Marcin Borkowski  writes:
> 2. We modify Emacs itself to somehow highlight the ZWS.  There is (kind
> of) a precedent – a no-breaking space is already fontified with
> =nobreak-space= face.  At the very least, make whitespace-mode somehow
> show ZWSs (which it doesn't now, and I'd probably say it's a bug).
>
> I know that my point 2. is a bit controversial, since it could lead to
> alignment issues where a ZWS is displayed as something with a positive
> width. OTOH, even now changing the face of a ZWS leads to a narrow
> (1-pixel wide) line of a different color.  Is there a way to make it
> a bit stronger?

We can try to create an accent. Try the following:
1. Open new empty org buffer
2. Disable font-lock-mode
3. M-: (insert (compose-string "a" nil nil (list ?a '(bl . tl) ?␣)))

The result will look like on the attached image.

Best,
Ihor

Re: Some commentary on the Org Syntax document

2021-12-03 Thread Timothy

Hi Ihor,

Because your reply is shorter, you get my first response .

>> [Renaming parts of the Hierarchy]
> I am against renaming this. We should rather improve the syntax document
> keeping the key concepts consistent with Elisp code.

This is certainly something to be conservative about, but I think some small
tweaks could be beneficial. See my comment below.

> Org parser distinguish two principal types of syntax structures:
> 1. Elements
> 2. Objects
>
> Neither elements nor objects can intersect their boundaries, but they
> can be nested.
>
> An object is always a part of some element or other object.
> Greater element can contain other elements and objects.
> Element that is not greater element can only contain objects.

A thought has just occurred to me, how about instead of having
“elements” which are split into “Greater Elements” and other “Elements”, what if
we simply added the prefix “lesser” to the later?

I.e. go from

⁃ Elements
  • Greater Elements
  • (other) Elements

to

⁃ Elements
  • Greater Elements
  • Lesser Elements

I think having something explicit like this could reduce the chance of
confusion.

> [Comments on headings and sections]

This accords with my reading of the document and the way I’ve implemented things
in OrgMode.jl (see 
).

All the best,
Timothy

Re: [PATCH] org-src.el: add option `org-src-native-defun-movements'

2021-12-03 Thread Sébastien Miquel


Hi,

Thank you for having a look.

Tim Cross writes:

This also seems like an edge case and I'm not convinced yet another
option is justified. Why have eilisp in org blocks rather than an
emacs-lisp block?


By org src blocks I meant an org emacs-lisp src block. The point of
the patch is to be able to eval-defun some lisp code in an emacs-lisp
src block from the org-buffer.


As this is a breaking change, it should not be on by default.

Currently eval-defun errors out, and fixing that will break things
sooner or later, I think.

I do not mind updating the patch to set the new option to nil by
default, although I'll wait for a second opinion on this.

Regards,

--
Sébastien Miquel

Re: On zero width spaces and Org syntax

2021-12-03 Thread Marcin Borkowski

On 2021-12-03, at 13:48, Juan Manuel Macías  wrote:

> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks are not recognized (for example
> =[/literature/]=). I believe that as a puntual workaround it is not bad;
> however, I find it problematic that this character is part, more or less
> de facto, of the Org syntax. For two main reasons:
>
> 1. It is an invisible character, and therefore it is difficult to
> control and manage. I think it is not good practice to introduce this
> type of characters implicitly in a plain text document.
>
> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'. In the input it is better to introduce
> them not implicitly but through their representation. For example, in
> LaTeX (with LuaTeX) using the command '\char"200B{}' (or '200b'),
> '' in HTML, etc.
>
> In any case, as an implicit character, I do not see it appropriate for
> the syntax of a markup language. The marks should be simply ascii
> characters, IMHO. So what if Org had a specific delimiter mark for the
> scenarios described above? For example, something like that:

Hi all,

I've skimmed through this discussion.  FWIW, I also use zero-width
spaces in my Org files for this precise reason.  However, I agree that
extending syntax is dangerous.

How about a solution (or maybe it's only a "solution"...) where:

1. We take care to modify the "official" exporters to throw out the ZWSs.
Or even better, convert them to something reasonable, e.g. with LaTeX
they can be discarded or converted to some command – possibly even one
defined in the preamble – so that nothing is lost.  I'd even say that an
option deciding what to do with those could be nice.

2. We modify Emacs itself to somehow highlight the ZWS.  There is (kind
of) a precedent – a no-breaking space is already fontified with
=nobreak-space= face.  At the very least, make whitespace-mode somehow
show ZWSs (which it doesn't now, and I'd probably say it's a bug).

I know that my point 2. is a bit controversial, since it could lead to
alignment issues where a ZWS is displayed as something with a positive
width. OTOH, even now changing the face of a ZWS leads to a narrow
(1-pixel wide) line of a different color.  Is there a way to make it
a bit stronger?

Just some random ideas,

-- 
Marcin Borkowski
http://mbork.pl

Re: Some commentary on the Org Syntax document

Timothy  writes:

> So, the hierarchy appears to be something like.
>
> 1. (Headline / Section / Greater Element / Element / Object)
> 2. Headline
> 3. Section
> 4. Greater Element
> 5. (Greater Element / Element)
> 6. Element
> 7. Object
> 8. Pattern / Form
> 9. Term

> We could say call (1) Components, (7) Units, (6) Objects, (5) Element or
> Object (why not spell it out to avoid telling people to remember
> something).

I am against renaming this. We should rather improve the syntax document
keeping the key concepts consistent with Elisp code.

Org parser distinguish two principal types of syntax structures:
1. Elements
2. Objects

Neither elements nor objects can intersect their boundaries, but they
can be nested.

An object is always a part of some element or other object.
Greater element can contain other elements and objects.
Element that is not greater element can only contain objects.

Headings are an example of greater element with the following structure
(headline (optional section) (optional repeat nested-headline))

Sections can only exist inside headings or top-level document (org-data
element):
1. (org-data (optional whitespace) (section) (optional repeat headline))
2. (headline (optional section) ...)

Best,
Ihor

[BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]

Hi,

I noticed that make test became extremely slow recently.
The first bottleneck can be seen in

make BTEST_RE="^test-org-cite/adjust-note" test

passed  1/1  test-org-cite/adjust-note (12.321278 sec)

The test takes 12sec!
Moreover, subsequent tests (even not related to org-cite) become slower,
presumably because we overuse Emacs memory.

I am not using org-cite much myself, but I imagine that ordinary users
may also suffer from a similar performance issues after multiple
exports.

The profiler report shows that org-cite-get-processor may be the cause:

5794  91%- ert-run-test
5794  91% - ert--run-test-internal
5794  91%  - #
4813  75%   - let
4813  75%- let*
4813  75% - condition-case
4813  75%  - let
4813  75%   - list
4813  75%- cons
4813  75% - mapcar
 516   8%  - #
 516   8%   + test-org-cite--export-with-rule
 497   7%  - #
 497   7%   + test-org-cite--export-with-rule
 417   6%  - #
 417   6%   + test-org-cite--export-with-rule
 398   6%  - #
 398   6%   + test-org-cite--export-with-rule
 397   6%  - #
 397   6%   + test-org-cite--export-with-rule
 393   6%  - #
 393   6%   + test-org-cite--export-with-rule
 389   6%  - #
 389   6%   + test-org-cite--export-with-rule
 377   5%  - #
 377   5%   + test-org-cite--export-with-rule
 377   5%  - #
 377   5%   + test-org-cite--export-with-rule
 368   5%  - #
 368   5%   + test-org-cite--export-with-rule
 347   5%  - #
 347   5%   + test-org-cite--export-with-rule
 337   5%  - #
 337   5%   + test-org-cite--export-with-rule
 981  15%   - let*
 981  15%- condition-case
 981  15% - let
 981  15%  - list
 981  15%   - test-org-cite--export-with-rule
 981  15%- let
 981  15% - let
 981  15%  - save-current-buffer
 981  15%   - unwind-protect
 981  15%- progn
 942  14% - let
 942  14%  - let
 942  14%   - org-trim
 942  14%- org-export-as
 398   6% - 
org-cite-store-export-processor
 224   3%  - 
org-cite-processor-has-capability-p
 224   3% org-cite-get-processor
 174   2%org-cite-get-processor
 232   3% - org-cite-finalize-export
 232   3%org-cite-get-processor
 214   3% - org-cite-process-citations
 214   3%  - org-cite-export-citation
 214   3% org-cite-get-processor
  30   0% + org-export-copy-buffer
  29   0% + org-babel-exp-process-buffer
  20   0% + run-hook-with-args
  10   0%   org-set-regexps-and-options
   9   0% + org-export-data
  20   0% + org-mode
  19   0% + font-lock-ensure
  62   0%+ #
  20   0%+ #

Best,
Ihor

Re: On zero width spaces and Org syntax

Tom Gillespie writes:

> I don't mean to be dismissive of the suggestion, but a lot of
> time is spent on this list walking back ideas that have not
> had sufficient time put into understanding what the
> unintended consequences would be, so I wouldn't say
> that it is irresponsible, I would say instead that it lacks
> sufficient rigor and depth to be seriously considered. If you
> can add those to this proposal (e.g. in the form of a patch)
> then I suspect it would get a much warmer reception.

I am afraid that I am explaining myself wrong, and it is not my
intention that this matter becomes entangled to infinity.

I have no intention of proposing any patch on this. I'm not strongly
requesting this feature be included, and I am not interested in starting
a crusade to defend this (and as for lack of rigor and depth, well, it's your
subjective opinion). But it's more simple. Since a thread on these
questions came up recently, it occurred to me to suggest this idea as a
*possibility*, in case anyone could find it interesting and would like
to explore it. Nothing more. In fact, I don't think I was going to use
this probable feature much, if it was implemented, because for these
scenarios I prefer to use Org macros or other resources that I have
implemented for my workflow. But maybe users would prefer this to insert
a zero-whith space character (which is a tricky and quite ugly
workaround and should not be recommended). Or maybe not. I really don't
know. I don't know all Org users in the world, do you know them?

Anyway, I want to point out one thing, again. The scenarios and contexts
that are being described here are far from "very narrow use case". And I
don't think it's very appropriate to hide the lack of something with the
excuse that no one is going to need it. Intra-word emphasis is used (for
example) a lot in linguistics books and texts, grammars, etc. That you
*ignore* this fact does not mean that does not exist.

regards,

jm

Re: Some commentary on the Org Syntax document

2021-12-03 Thread Tom Gillespie

Hi Timothy,
   Replies in line. Some things might seem a bit out of order
because I responded from bottom to top. Best,
Tom

> from heading to bed, so to quote Pascal "I have only made this letter
> longer because I have not had the time to make it shorter".

Likewise, and I've heard it as Mark Twain :D

> I think a a big problem is the mix of implicit and explicit information.
> Some components are rigorously specified in terms of the characters they
> may contain, elements and objects that are recognised inside them, and
> even the order in which different parts of the pattern are parsed.

I agree completely.

> As mentioned originally, the current Dynamic Blocks description doesn't
> even mention the CONTENTS part of the pattern, and relies on the reader
> inferring that it operates similarly to the CONTENTS part of Drawers.

Indeed this should be fixed.

> Forcing the reader to start making inferences like this is a treacherous
> path, and I think I can blame for some of the other issues I've
> experienced. Take for instance the "surely X can't contain a newline?"
> comments I've made. In the Node Properties and Entities descriptions you
> have statements along the lines of "X can contain any character [...]
> except a newline". In my mind this then sets up the reader to interpret
> a similar statement without the "except a newline" clause to mean that
> newlines are permitted.

I agree completely and had almost the exact same experience as you
when I was working on it. As I mention below, my responses were to
illustrate why the explicit information is missing, not to suggest that it
should be left out. We should definitely work to make everything more
explicit so that future readers don't have to go through the same issues
we have.

> I'm also thinking that the term "element" is overworked in the document.
> It's basically pulling tripple duty: you have Elements, Greater
> Elements, and elements which are Elements and/or Greater Elements .

In extreme agreement.

> 3. Section

Technically This isn't part of the syntax, rather it is part of
elisp Org mode's internal representation. I'm not sure I would
even mention sections at all, because they have to do with
the interpretation of the syntax. In a section on the internal
representation for Org sections definitely belong, but they
are incidental. That said, I suspect we will find that they are
useful for talking about the behavior of the file under transformation,
e.g. "headings are not reordered when pressing M-up or M-down,
sections are reordered" this allows us to make it possible to
talk about an Org implementation that has commands that allow
one to switch the headings without moving their associated
sections.

> 5. (Greater Element / Element)

There are issues here with forms that are part of the syntax vs
forms that are part of the intermediate representation. A line
based parser for Org syntax that assembles greater blocks
after the fact and a parser that uses arbitrary lookahead to
truncate on headings won't have the exact same surface
syntax, however they will both have an equivalent in their
intermediate representation that corresponds to a greater
block. Again, very deep in implementation details here,
but trying to force things like sections into the syntax
hierarchy seems confusing to me.

> 7. Object

Paragraph element maybe? Might seem odd for heading titles
to have paragraph scope, but on the other hand it certainly
simplifies the explanation of the grammar. And you can put
an inline footnote in a heading title.

> 8. Pattern / Form

Don't know what to make of this one. Like "Term" these are
incredibly generic.

> 9. Term

Use of "Term" is super confusing to me.

> We could say call (1) Components, (7) Units, (6) Objects, (5) Element or
> Object (why not spell it out to avoid telling people to remember
> something).

I'm not sure we are ready to specify this. One way that we
might try to manage this would be to create a taxonomy of
element types, e.g. top-level elements, paragraph elements,
etc. This would be consistent with the fact that the elisp
implementation of org-element has all of these as an instance
of element.

> I could have put more thought into this, but it should do for
> illustrating my line of thinking. Let me know if you have any good
> ideas.

Let's leave the terminology as is right now. I'm expecting that there
will be quite a few new terms that we will want to introduce and we
will want to separate syntax and intermediate representation.

With progress on using org-element for fontification and on laundry
we should be able to come up with language that can be used to
distinguish between concepts that are needed for syntax, (tokens,
parser) and for intermediate representations. Things like basic syntax
highlighting need only the language for syntax to be specified, but more
complex syntax such as babel font-locking either requires a more
advanced tokenizer or it requires that we talk about it at the level
of the

[BUG] Indirect buffer of indirect buffer is truncated [9.5.1 (9.5.1-g36086a @ /home/nisan/.emacs.d/elpa/org-9.5.1/)]

2021-12-03 Thread Nisan Stiennon

If I run org-tree-to-indirect-buffer twice with a prefix argument, I get a
buffer that's too narrow and omits the text of the last heading in the
tree. In this state, tree operations can result in data loss.

To reproduce, open a file containing the following data:

* I
** A
** B
* II

Follow these steps:

1. S-tab to fold everything.
2. With point on the "I" heading, C-u C-c C-x b to open an indirect buffer.
3. With point on the "I" heading in the new buffer, C-u C-c C-x b to open
another indirect buffer.

The buffer created in step 3 will look like:

* I
** A
**

Note that the text "B" is missing from the last heading. Expected behavior
is

* I
** A
** B

4. With point on the last, blank heading in the buffer created in step 3,
M-up to move the heading. The heading will disappear, resulting in:

* I
** A

If you write the file, it will look like this:

* I
** A
B
* II

Expected behavior from steps 1-4 is:

* I
** B
** A
* II

I can reproduce on both the version of org that shipped with emacs 27.2,
and with the gnu elpa package.

Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
 of 2021-11-04
Package: Org mode version 9.5.1 (9.5.1-g36086a @
/home/nisan/.emacs.d/elpa/org-9.5.1/)

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-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-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
 org-babel-header-arg-expand)
 org-agenda-loop-over-headlines-in-active-region nil
 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)
  ("eww" :follow org-eww-open :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") ("shell" :follow org-link--open-shell)
  ("news" :follow
#[514 "\301\300\302 Q \"\207"
 ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("mailto" :follow
#[514 "\301\300\302 Q \"\207"
 ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("https" :follow
#[514 "\301\300\302 Q \"\207"
 ["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("http" :follow
#[514 "\301\300\302 Q \"\207"
 ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("ftp" :follow
#[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"]
 6 "\n\n(fn URL ARG)"]
)
  ("help" :follow org-link--open-help)
  ("file" :complete org-link-complete-file)
  ("elisp" :follow org-link--open-elisp)
  ("doi" :follow org-link--open-doi))
 org-link-elisp-confirm-function 'yes-or-no-p
 )

Re: On zero width spaces and Org syntax

2021-12-03 Thread Tom Gillespie

An important note: for intra-word markup you probably want to
use word joiner U+2060 and not zero width space, because a
zero width space allows layout to break the word, whereas a
word joiner does not. We may need to check to make sure that
U+2060 counts as whitespace for the purposes of markup.

> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'.

That is not relevant in this case. However, Org export should not be
emitting byte-literal zero width spaces either, that causes as NASTY
surprise for the user. All that Org does in this pass is pass something
along for the user. The kludge is a kluge because it just happens to
be compatible with Org syntax, that is all. I agree that significant
whitespace is decidedly undesirable, unfortunately Org already
has some, though it is nowhere near as bad as markdown with
the trailing whitespace. There also happen to be ways to mitigate
issues with non-printing chars via font-locking etc. to make them
print/visible when authoring. This is another good reason to use
macros as well --- they can be documented.

> As for the matter of emphasis marks between words. I believe that this
> is not the underlying problem, but rather the (little) inconsistency of
> the markup on certain contexts. Think, for example, of a text where you
> have to put many words in italics, enclosed between brackets. I don't
> care if that type of text is 'typical' or 'non-typical', 'majority' or
> 'non-majority'. It is simply a kind of scenario absolutely legitimate
> and feasible, and right now I could quote you more than a type of text
> in that direction.

The problem here is that there is an unbalanced design tradeoff.
Supporting intra-word markup using Org's simple markup syntax
actually introduces more inconsistencies elsewhere (see my
note at the end about where the burden of proof lies with
regard to statements like this).

Further, we also have to consider the impact of such a change
across the whole population of Emacs users and use cases.
Adding complexity to support a very narrow use case, and one
that will produce inconsistencies elsewhere means that the
whole community is forced to bear the burden of that complexity.

This is the principle that I think Tim touches on in terms of keeping
simple things simple. Complexity in pursuit of niche use cases is
never worth the cost when it has to be borne by 99% of users that
will never need such things.

Further, Org provides not only a single solution to these cases, but
multiple solutions. Worst case it is also possible to fail over to
text macros, which are an absurdly powerful escape hatch for users
that have advanced (read niche) needs.

> My proposal here also does not arise from an irrepressible desire to add
> more complexity to the syntax. If it's recommended that the user, in
> certain contexts, enter implicitly a zero-width space (which, I insist,
> is a practice that should be avoided as much as possible in a plain text
> document), why not at least offer a graphical alternative, a *real* mark
> whose role is *exactly* the same as that of the zero-with space? Is that
> adding more complexity??? Honestly I think that's exactly the opposite.

This has the same problems as other proposals about this, whether
they are escape chars, or other syntactic additions. It complicates
the syntax for the community as a whole. It may simplify it for your
particular use case, but not when averaged out with everyone else.

I think one approach is to encourage the use of \emph{a}b and friends.
They are printable and hide nothing. I would also suggest that we work
to update other export backends to support \emph where possible.

> In any case, I have suggested that new mark as a possibility, in case it
> is interesting to implement it, since a thread has emerged these days
> about the topic of the intra-words syntax. Discussions and threads
> arised about these questions and any other are perfectly legitimate and
> natural and welcome. Please: there are no issues more 'important' than
> others; no two users are the same in Org. What you do not find useful,
> another user may perhaps finds it indispensable. And vice versa. And I
> think no one is in willingness to state what the average Org user does
> or does not want, given that we do not know even 1% of Org users.

I think we have a fairly good idea in this particular case. If someone
wanted to do a more thorough study of existing org files in the wild
to see whether they are using a workaround it would certainly be
interesting, if unlikely to reject the null hypothesis. Take a survey
of all the html in the world and see how many documents make
use of intra-word markup that use any markup at all. I'm guessing
it is a vanishingly small percentage.

If we could figure out how to implement intra-word markup in a way
that didn't induce complexity it would be done, and probably
would already have been done, and I suspect people might use it.

Re: BUG?: Link to inline-task not working

Michael Dauer  writes:

> Where are the links/href are built? There should be the error that excludes
> inline-tasks.

A quick search through the code yields: org-export-resolve-id-link
It explicitly check headlines, but not inlinetasks.
The fix should not be too hard. Feel free to send a patch ;)

Best,
Ihor

Re: quotation marks in table cell vs. org-babel-ref-resolve

hi, Tim,

> The key question is what is the use case for having this 'mixed' content
> in a table cell?

in my case, i am putting RFC822('ish) e-mail addresses in a column of an
org-mode table.  and, i want to extract them.

| oxymo...@example.com  |
| Greg Oxymoron   |
| "Greg G. Oxymoron"  |

for the third row returns =Greg G. Oxymoron=, rather than my desired
="Greg G. Oxymoron" =.

by the way, do you know the use case for the current behavior for
strings that start with a ="=?  i couldn't find anything in the manual.

i wonder if maybe the existing parameter =inhibit-lisp-eval= (which, in
the path i am exercising, is non-nil) could also be used to not do the
check for a ="=?  (maybe that's also a hack, but i think it would solve
my problem. :)

cheers, Greg

Re: On zero width spaces and Org syntax

Tim Cross writes:

> I think I am in agreement regarding most of your points about the use of
> the zero-width character. I see it as a type of escape hatch which
> provides a solution in some less frequent situations. It is a somewhat
> clever kludge to enable markup in some situations not supported by the
> basic markup syntax I'm happy with its status as a kludge and would not
> want to see it become an official part of the syntax. Where we may
> differ is in whether we actually want to add inner word markup support
> at all. 
>
> I'm somewhat surprised and more than a little concerned at how much
> interest and focus on modifying the markup syntax of org the question of
> inner word markup has generated. This seems to be a symptom of a more
> general trend towards adding and extending org mode to meet the needs of
> everyone and I'm concerned this is overlooking the key strength of org
> mode - simplicity.
>
> Consider how many times we have had requests for inner word markup in
> the last 18 years. I've seen such requests only a very few times.
> Certainly not frequently enough to consider modification of the markup
> syntax to accommodate such a requirement.
>
> A key philosophy of org mode is simplicity - it makes the easy stuff
> simple and the hard stuff possible. The thing about simple solutions is
> that they will inevitably have limitations. If you don't want those
> limitations, then you use a more complex feature rich markup, such as
> Latex, HTML, XML etc. Ideally, your system will provide some escape
> hatches to allow you to do things not supported by the base markup
> syntax. Those escape hatches will usually be less convenient and often
> look quite ugly, but that is fine because they are an escape hatch
> which is used infrequently. Better still is if the system provides some
> way to make a specific escape hatch easier to use in a document (such as
> via a macro). The basic org markup syntax has worked remarkably well for
> 18 years. Nearly all the proposed additions or alterations to support
> inner word markup with complicate the syntax or introduce potential new
> ambiguities and/or complexity in processing to support a feature which
> has been rarely asked for and which has other, less convenient and often
> ugly, solutions which work.
>
> One of org's strengths has been the ability to export documents to
> multiple formats. One way this has been made possible is by keeping the
> markup syntax simple - a basic markup which is well supported by all
> export back ends. Once you start adding more complex markup support, you
> see a blow out of complexity in the export back ends. Worse yet, you get
> results which are surprising to the end user or which simply don't work
> correctly with some formats. to avoid this, it is critical to keep the
> markup syntax as simple and straight-forward as possible, even if that
> means some limitations on what can be done with the markup. 
>
> My vote is to simply maintain the status quo. Don't modify the syntax,
> don't make the zero space character somewhat special or processed in any
> special way during export. In short, accept that inner word markup has
> only limited support and if that is a requirement which is critical to
> your use case, accept that org mode may not be the right solution for
> your requirements. 

Thank you very much for the detailed and precise exposition of your
point of view. I appreciate it.

First of all, a point that I consider important and essential in this
and other debates that are generated here, is that there is no single
conception of Org that should prevail as (say) "the canon". Org is so
polyhedral and so multifaceted that there are as many conceptions of Org
as there are users of Org. Well, what I have said is in itself one more
conception of Org. But I assume that other users may think that Org is
not all the things that I say it is. At the end of the day, what matters
is only one thing, for on top of theories and doctrines: if Org is
useful to you and helps you to do your work, so great. A few months ago
(and I think I already shared it here) I finished the typesetting and
layout of a dictionary of almost 1000 pages, and I did it using a
workflow that I have developed which is a merge between Org/Org-Publish
and LuaTeX. And now, using the same method, I am working on an
ancient-Greek/Spanish bilingual critical edition. So I believe I'm not
suspicious of thinking that Org doesn't cover the needs of my workflow.

As for the matter of emphasis marks between words. I believe that this
is not the underlying problem, but rather the (little) inconsistency of
the markup on certain contexts. Think, for example, of a text where you
have to put many words in italics, enclosed between brackets. I don't
care if that type of text is 'typical' or 'non-typical', 'majority' or
'non-majority'. It is simply a kind of scenario absolutely legitimate
and feasible, and right now I could quote you more than a type of text
in

Re: Org-syntax: Intra-word markup

Tom Gillespie  writes:

> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane way to parse something
> like *hello world*/hrm/oh no*. The other issue is that this will
> degrade parsing performance because almost every
> character could precede the start of a markup section.
>
> I recommend anyone suggesting solutions try to implement
> something that can parse the markup unambiguously with
> lots of nasty test cases. You will likely find that it is impossible
> to consistently tokenize markup, and that you have to hand
> write a whole bunch of heuristics, making Org syntax even
> harder to implement correctly.
>
> Any solution that suggests extending how =/*~+_  can be
> used gets a hard no from me. I could see teaching other
> exporters how to interpret \emph{hello}world, but trying for
> to have any sane behavior for something like
> why *hello*world oh no a wild askterisk*
> is not worth it.
>

+infinity!

Please, please can we stop trying to satisfy every edge case or extend
the markup to satisfy every possible scenario.

Org's big strength is in its simplicity. This comes at a price -
limitations in what can be done. If those limitations are unacceptable,
then use a richer markup format like Latex, XML, HTML etc.

The point about back end exporter support is very relevant. The 'richer'
the markup, the harder it is to get a consistent mapping for back end
exporters. things quickly become more complex and difficult to maintain.

In 18 years, I've seen requests for inner word markup less than 4 times.
this is not a feature we should even be considering adding to the markup
syntax. 

Org provides a light weight markup, not a fully flexible rich markup
designed to meet any need. It makes the easy stuff simple.

Re: quotation marks in table cell vs. org-babel-ref-resolve

Greg Minshall  writes:

> fwiw, tracing, the problem appears to be this line
> 
> ((eq (string-to-char cell) ?\") (read cell))
> 
> in =org-babel-read=.
>
> presumably there are many cases where this is the right thing to do.
>
> but, maybe look for a simple =^"[^"]*"$= (i.e., a quotation mark, some
> other stuff, a quotation mark, and *nothing* else in the cell)?
>
> or (heaven help us), something more complicated, with random escaped
> quotation marks inside the "cell"?
>
> cheers, Greg

The key question is what is the use case for having this 'mixed' content
in a table cell?

I really don't like the idea of adding even more regexp processing of
contents in order to resolve complexities in data formats which are
rare.  the benefit of the line you identified is that it is simple and
easy to maintain. There may be edge cases where it does not work
correctly, but perhaps the right solution in those situations is fix the
format of the data in the table rather than complicate the functions
used to extract the data from a table.

Re: [PATCH] org-src.el: add option `org-src-native-defun-movements'



Sébastien Miquel  writes:

> Hi,
>
> The attached patch adds a new option ~org-src-native-defun-movements~
> that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work
> natively when called from inside an org src block : those functions
> are called from an org src edit buffer, in the appropriate language
> mode. Without this patch, calling =eval-defun= on elisp code fails.
>
> With this option set to t by default, this is a breaking change. To
> get to the beginning/end of a src block you'd have to call
> ~org-backward-element~ or ~org-forward-element~ directly, instead of
> ~beginning-of-defun~. Or you could disable the new behaviour by
> setting ~org-src-native-defun-movements~ to nil.
>

As this is a breaking change, it should not be on by default.

This also seems like an edge case and I'm not convinced yet another
option is justified. Why have eilisp in org blocks rather than an
emacs-lisp block?

Re: On zero width spaces and Org syntax

Juan Manuel Macías  writes:

> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks are not recognized (for example
> =[/literature/]=). I believe that as a puntual workaround it is not bad;
> however, I find it problematic that this character is part, more or less
> de facto, of the Org syntax. For two main reasons:
>
> 1. It is an invisible character, and therefore it is difficult to
> control and manage. I think it is not good practice to introduce this
> type of characters implicitly in a plain text document.
>
> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'. In the input it is better to introduce
> them not implicitly but through their representation. For example, in
> LaTeX (with LuaTeX) using the command '\char"200B{}' (or '200b'),
> '' in HTML, etc.
>
> In any case, as an implicit character, I do not see it appropriate for
> the syntax of a markup language. The marks should be simply ascii
> characters, IMHO. So what if Org had a specific delimiter mark for the
> scenarios described above? For example, something like that:
>
> #+begin_example
>
> /meta/''literature
>
> *meta*''literature
>
> [''*literature*'']
>
> #+end_example
>
> WDYT?
>
> Best regards,
>
> Juan Manuel 

I think I am in agreement regarding most of your points about the use of
the zero-width character. I see it as a type of escape hatch which
provides a solution in some less frequent situations. It is a somewhat
clever kludge to enable markup in some situations not supported by the
basic markup syntax I'm happy with its status as a kludge and would not
want to see it become an official part of the syntax. Where we may
differ is in whether we actually want to add inner word markup support
at all. 

I'm somewhat surprised and more than a little concerned at how much
interest and focus on modifying the markup syntax of org the question of
inner word markup has generated. This seems to be a symptom of a more
general trend towards adding and extending org mode to meet the needs of
everyone and I'm concerned this is overlooking the key strength of org
mode - simplicity.

Consider how many times we have had requests for inner word markup in
the last 18 years. I've seen such requests only a very few times.
Certainly not frequently enough to consider modification of the markup
syntax to accommodate such a requirement.

A key philosophy of org mode is simplicity - it makes the easy stuff
simple and the hard stuff possible. The thing about simple solutions is
that they will inevitably have limitations. If you don't want those
limitations, then you use a more complex feature rich markup, such as
Latex, HTML, XML etc. Ideally, your system will provide some escape
hatches to allow you to do things not supported by the base markup
syntax. Those escape hatches will usually be less convenient and often
look quite ugly, but that is fine because they are an escape hatch
which is used infrequently. Better still is if the system provides some
way to make a specific escape hatch easier to use in a document (such as
via a macro). The basic org markup syntax has worked remarkably well for
18 years. Nearly all the proposed additions or alterations to support
inner word markup with complicate the syntax or introduce potential new
ambiguities and/or complexity in processing to support a feature which
has been rarely asked for and which has other, less convenient and often
ugly, solutions which work.

One of org's strengths has been the ability to export documents to
multiple formats. One way this has been made possible is by keeping the
markup syntax simple - a basic markup which is well supported by all
export back ends. Once you start adding more complex markup support, you
see a blow out of complexity in the export back ends. Worse yet, you get
results which are surprising to the end user or which simply don't work
correctly with some formats. to avoid this, it is critical to keep the
markup syntax as simple and straight-forward as possible, even if that
means some limitations on what can be done with the markup. 

My vote is to simply maintain the status quo. Don't modify the syntax,
don't make the zero space character somewhat special or processed in any
special way during export. In short, accept that inner word markup has
only limited support and if that is a requirement which is critical to
your use case, accept that org mode may not be the right solution for
your requirements.

ob-plantuml: Proposal to add 'jar-args' customizable variable

2021-12-03 Thread Dejan Josifović


Hi all,

I use PlantUML integration in org-mode for years now, but only
recently I came across some unwanted behavior.

Using PlantUML from jar (org-plantuml-jar-path variable) and latest 
org-mode, I wanted to render a diagram containing some Unicode 
characters (such as '⊥' and '∀'), but the end image had some gibberish 
instead. However,
trying this from a standalone file using plantuml-mode[1], the end image 
rendered correctly. Here is some sample code which can reproduce the issue:


#+BEGIN_SRC plantuml :file ./test.png
A -> B: ∀ characters display correctly is ⊥
#+END_SRC

Comparing ob-plantuml.el and plantuml-mode.el files I found what is the 
problem. plantuml-mode has a customizable variable for specifying 
arguments when using PlantUML from jar (plantuml-jar-args (list 
"-charset" "UTF-8" ). The charset arguments is what is needed for

the images to render correctly (I confirmed it by implementing it locally).

I was wondering why such variable doesn't exist in ob-plantuml. I have
searched the mailing list archives, confirmed bugs and help page and 
couldn't find anything related.


Does anyone from the community know if such variable was deliberately 
omitted? If so, what is the reason?


If this is indeed a wanted feature, I will be more than happy to provide 
a patch.


[1] https://github.com/skuro/plantuml-mode

Thanks and regards,

--
Dejan Josifović | Дејан Јосифовић
Software engineer | Софтверски инжењер
https://theparanoidtimes.org

()  ascii ribbon campaign
/\  www.asciiribbon.org

Re: On zero width spaces and Org syntax

Hi Greg, thank you for your comment,

Greg Minshall writes:

> in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
> file.  some sort of "visible" sequence would be great.  backwards
> compatibility might be a problem.

Yes I agree. I think that in this case, a new mark would not compromise
backward compatibility, as this presumed new mark would do the same
function as zero width space: i.e. delimit to preserve emphasis. Of
course one could go on using a zero-width space, though I keep thinking
that this is rather a puntual workaround and should not form part of the
syntax.

> your last example
>
> : [''*literature*'']
>
> seems a bit of sleight-of-hand, though.  iiuc, text inside square
> brackets isn't highlighted currently, and ZWNBSP doesn't (afaict) turn
> on highlighting.  (maybe there's been recent discussion, modifications
> of this?)

The idea would be to use a kind of 'protection mark', to allow something
in a context where it is not allowed: a passport ;-). As the emphasis
marks are recognized before and after a single quote, I thought that
maybe a sequence of two single quotes could function here as a
protection mark (screenshot: https://i.imgur.com/cPIH9qa.png). For
example:

#+begin_example
| Some examples where emphasis marks are not allowed | Protected emphasis marks 
|
|+--|
| /meta/literature   | /meta/''literature   
|
| [/literature/] | [''/literature/'']   
|
| <*literature*> | <''*literature*''>   
|
| meta/*literature*  | meta/''*literature*  
|
#+end_example

With the protection marks we get (in LaTeX for example):

\emph{meta}literature
[\emph{literature}]
<\textbf{literature}>
meta/\textbf{literature}

Best regards,

Juan Manuel

Re: On zero width spaces and Org syntax

Juan Manuel,

> however, I find it problematic that this character is part, more or
> less de facto, of the Org syntax. For two main reasons:

in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
file.  some sort of "visible" sequence would be great.  backwards
compatibility might be a problem.

your last example

: [''*literature*'']

seems a bit of sleight-of-hand, though.  iiuc, text inside square
brackets isn't highlighted currently, and ZWNBSP doesn't (afaict) turn
on highlighting.  (maybe there's been recent discussion, modifications
of this?)

i.e., if the goal is to *expand* the realm of highlighting, might that
not be a separate issue?

cheers, Greg

[PATCH] org-src.el: add option `org-src-native-defun-movements'

2021-12-03 Thread Sébastien Miquel


Hi,

The attached patch adds a new option ~org-src-native-defun-movements~
that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work
natively when called from inside an org src block : those functions
are called from an org src edit buffer, in the appropriate language
mode. Without this patch, calling =eval-defun= on elisp code fails.

With this option set to t by default, this is a breaking change. To
get to the beginning/end of a src block you'd have to call
~org-backward-element~ or ~org-forward-element~ directly, instead of
~beginning-of-defun~. Or you could disable the new behaviour by
setting ~org-src-native-defun-movements~ to nil.

Regards,

--
Sébastien Miquel
From 51675d8bbea54db7daf3dcc88a77ccad5174854f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Fri, 27 Aug 2021 21:41:29 +0200
Subject: [PATCH] org-src.el: add option `org-src-native-defun-movements'

* lisp/org-src.el (org-src-native-defun-movements): New option. If t,
`beginning-of-defun', `end-of-defun' and `eval-defun' act natively
when called from inside a src block.
(org-beginning-of-defun):
(org-end-of-defun): New functions.  If
`org-src-native-defun-movements' is t and point is in a src block,
call `beginning-of-defun' or `end-of-defun' from the src edit buffer.

The main goal is to make `eval-defun' work from the org buffer. For
this to work, if point is at the beginning of an #+end_src line,
`org-beginning-of-defun' has to work natively.  To get to the
beginning of the src block, call `org-backward-element` instead.
---
 etc/ORG-NEWS| 20 ++
 lisp/org-src.el |  7 +++
 lisp/org.el | 54 ++---
 3 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index eb5a5d40d..379870d44 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -60,6 +60,26 @@ list of various table options (between brackets in LaTeX export),
 since certain tabular environments, such as longtblr of the
 tabularray LaTeX package, provides this structure.
 
+*** ~beginning-of-defun~ and ~eval-defun~ now work natively in src blocks
+
+To get to the beginning or end of a src block, use
+~org-backward-element~ and ~org-forward-element~ instead, or disable
+this new behaviour by setting ~org-src-native-defun-movements~ to nil.
+
+** New options
+
+*** New option =org-src-native-defun-movements=
+
+This option, t by default, makes ~beginning-of-defun~, ~end-of-defun~
+and ~eval-defun~ work natively inside src blocks : the corresponding
+function is called from an org src block edit buffer in the language
+specific mode.
+
+For ~eval-defun~ to work natively from the org buffer, if point is at
+the beginning of an #+end_src line, `org-beginning-of-defun` will work
+natively as well.  To get to the beginning of the src block, call
+`org-backward-element` instead.
+
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 46fed052d..8feced080 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -246,6 +246,13 @@ green, respectability.
   :package-version '(Org . "9.4")
   :group 'org-babel)
 
+(defcustom org-src-native-defun-movements t
+  "If non-nil, the effect of `beginning-of-defun' and
+`end-of-defun' in a code block is as if they were issued in the
+language major mode buffer."
+  :type 'boolean
+  :package-version '(Org . "9.6")
+  :group 'org-babel)
 
 
 ;;; Internal functions and variables
diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..1ff0d6f87 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4892,13 +4892,8 @@ The following commands are available:
  org-element-use-cache)
 (org-persist-read 'org-element--cache (current-buffer)))
   ;; Beginning/end of defun
-  (setq-local beginning-of-defun-function 'org-backward-element)
-  (setq-local end-of-defun-function
-	  (lambda ()
-		(if (not (org-at-heading-p))
-		(org-forward-element)
-		  (org-forward-element)
-		  (forward-char -1
+  (setq-local beginning-of-defun-function 'org-beginning-of-defun)
+  (setq-local end-of-defun-function 'org-end-of-defun)
   ;; Next error for sparse trees
   (setq-local next-error-function 'org-occur-next-match)
   ;; Make commit log messages from Org documents easier.
@@ -21525,6 +21520,51 @@ Move to the previous element at the same level, when possible."
 			   (<= (org-element-property :end prev) beg))
 		 (goto-char (org-element-property :begin prev)))
 
+(defun org-beginning-of-defun ()
+  "If point is in a src block and `org-src-native-defun-movements'
+is non-nil, call `beginning-of-defun' in the src block edit
+buffer, otherwise call `org-backward-element'."
+  (interactive)
+  (if (and org-src-native-defun-movements
+   (let* ((element (save-excursion (beginning-of-line)
+   (org-element-at-point)))
+	  (type

Re: quotation marks in table cell vs. org-babel-ref-resolve

fwiw, tracing, the problem appears to be this line

((eq (string-to-char cell) ?\") (read cell))

in =org-babel-read=.

presumably there are many cases where this is the right thing to do.

but, maybe look for a simple =^"[^"]*"$= (i.e., a quotation mark, some
other stuff, a quotation mark, and *nothing* else in the cell)?

or (heaven help us), something more complicated, with random escaped
quotation marks inside the "cell"?

cheers, Greg

quotation marks in table cell vs. org-babel-ref-resolve

hi.  i'm trying to use =org-babel-ref-resolve= to access the values of a
column in a table.  it all works fine for many cases.  however, if the
contents of an entry in the column starts with quotation marks, those
quotation marks disappear, and anything outside the quoted part of the
cell "disappears" (in the result).  see below.

would this be intentional?  a bug?

or, if there's a better way to retrieve the contents of a table column,
i'd love to hear.

cheers, Greg

ps -- it doesn't seem to matter that "35" can be considered an integer;
i.e., "a35" seems to behave the same.


#+name: foo
| this | is |  a | header   |
|--+++--|
|   33 | 42 | 32 | "35" |
|   33 | 42 | 32 | "35" thirtyfive  |
|   33 | 42 | 32 | 35 thirtyfive|
|   33 | 42 | 32 | thirtyfive "35"  |
|   33 | 42 | 32 | thirtyfive "35" post-thirty-five |

#+begin_src elisp
  (org-babel-ref-resolve "foo")
#+end_src

#+RESULTS:
| this | is |  a | header   |
|--+++--|
|   33 | 42 | 32 | 35   |
|   33 | 42 | 32 | 35   |
|   33 | 42 | 32 | 35 thirtyfive|
|   33 | 42 | 32 | thirtyfive "35"  |
|   33 | 42 | 32 | thirtyfive "35" post-thirty-five |

Re: citeproc-org and org-ref 3

2021-12-03 Thread Joseph Vidal-Rosset

Le 03/12/2021 à 16:24, John Kitchin a écrit : > I have seen this happen at
times, and I think it is style and maybe > browser dependent. > > Could you
send me a small example (including the csl file you use) that > I could look
at? Dear John, In attachment, two small examples, the same text exported with
biochimica-et-biophysica-acta.csl and with ieee-with-url.csl Best wishes, Jo.

biochimica-et-biophysica-acta.csl
Description: application/vnd.citationstyles.style

ieee-network.csl
Description: application/vnd.citationstyles.style
Title: Another sequent calculus prover in Prolog: leanseq.pl

Joseph Vidal-Rosset - Personal Blog

Home
About
Contact
Educasup
Arguments
Provers
Code

Another sequent calculus prover in Prolog: leanseq.pl

2021-12-03, updated 2021-12-03 next - previous

A note about the prover published by
Philip Zucker from
Jens Ottenâs lectures.

The following Prolog code can be considered as an implementation of
Wangâs algorithm [1]

[1]H. Wang, Toward mechanical mathematics, Ibm J. Res. Dev., 4 (1960) 2â22.

Created: 2021-12-03 ven. 17:46
Validate

Title: Another sequent calculus prover in Prolog: leanseq.pl

Joseph Vidal-Rosset - Personal Blog

Home
About
Contact
Educasup
Arguments
Provers
Code

Another sequent calculus prover in Prolog: leanseq.pl

2021-12-03, updated 2021-12-03 next - previous

A note about the prover published by
Philip Zucker from
Jens Ottenâs lectures.

The following Prolog code can be considered as an implementation of
Wangâs algorithm [1]

[1]H. Wang, âToward mechanical mathematics,â Ibm j. res. dev., vol. 4, no. 1, pp. 2â22, Jan. 1960 [Online]. Available: https://doi.org/10.1147/rd.41.0002

Created: 2021-12-03 ven. 17:44
Validate

Re: citeproc-org and org-ref 3

2021-12-03 Thread John Kitchin

I have seen this happen at times, and I think it is style and maybe
browser dependent.

Could you send me a small example (including the csl file you use) that
I could look at?

Joseph Vidal-Rosset  writes:

> Hi John,
>
> A detail about exporting with org-ref 3 in html when the csl style is
> for numeric references. With org-ref 2 + citeproc-org, I got this:
>
> [1] R. Descartes, Meditations on First Philosophy: with Selections from
> the Objections and Replies. Oxford: OUP Oxford, 2008.
>
> (see the references here :
> https://www.vidal-rosset.net/descartess_first_proof_of_gods_existence_in_first-order_logic.html
> )
>
> With org-ref 3, with apparently any numeric style, I get this:
>
> [1]
> R. Descartes, Meditations on First Philosophy: with Selections from the
> Objections and Replies. Oxford: OUP Oxford, 2008.
>
> I mean that each bibliographical reference is below its number link, and
> it is not very nice. I wonder about the reason of this difference of
> output, and a possible solution.
>
> Best wishes,
>
> Jo.
>
> Le 02/12/2021 à 18:35, John Kitchin a écrit :
>> Glad to hear it is working again for you! Best wishes,
>>
>> Joseph Vidal-Rosset  writes:
>>
>>> Dear all,
>>>
>>>
>>> I just succeeded in solving my problem.
>>>
>>> l-210-235 of myblogexporter.el, I changed the code for:
>>>
>>> (defun org-export-head-export-headers (directory-name backend)
>>> "Exports each heading to directory-name using backend"
>>> (if (equal backend "html")
>>> (org-export-head--run-on-each-heading
>>>  #'(lambda ()
>>>  (org-set-property
>>>   "EXPORT_FILE_NAME"
>>>   (concat directory-name (org-export-head--escaped-headline)))
>>>  (deactivate-mark)
>>>  (let ((org-export-before-parsing-hook
>>> '(org-ref-csl-preprocess-buffer)))
>>>   (cl-letf (((symbol-function 'org-export-get-reference)
>>> (symbol-function 'org-export-get-reference-custom)))
>>> (if org-export-head-click-toc-h2
>>> (cl-letf ((
>>>;(symbol-function 'org-html-toc)
>>>(symbol-function
>>> 'org-export-head--custom-toc)))
>>>   (org-html-export-to-html nil t)
>>>  (set-buffer-modified-p t)) "-noexport-noreexport"))
>>> (if (equal backend "pdf")
>>> (org-export-head--run-on-each-heading
>>>  #'(lambda ()
>>>  (org-set-property
>>>   "EXPORT_FILE_NAME"
>>>   (concat directory-name (org-export-head--escaped-headline)))
>>>  (deactivate-mark)
>>>  (org-latex-export-to-pdf nil t)
>>>  (set-buffer-modified-p t)) "-noexport-noreexport")))
>>>
>>> and it works with org-ref 3.
>>>
>>> Best wishes,  I attach myblogexporter.el
>>>
>>> Jo.
>>>
>>> Le 02/12/2021 à 14:17, Joseph Vidal-Rosset a écrit :
 Dear John (cc. Ivan),

 First, thanks for your help and for your patience, that's very kind of you.

 The good news is that indeed, org-ref 3 exports nicely the  html
 bibliography with my CSL file, it works well with your org file and your
 bibliography. My error was simple: I did not use the specific org-ref
 keys but the ordinary h-o keys.. A stupid mistake.

 The bad news is that this new function for exporting with org-ref 3 is
 not included in org-export-head, a nice org mode to blog exporter, made
 by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a
 different file, I find this exporter very convenient. I had no problem
 with this org-ref 2 to use this blog-exporter, but it org-ref 3 is
 unfortunately not still adapted to its use. Nevertheless, I believe that
 it should be possible to find the lines to include this function
 (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
(org-open-file  (org-html-export-to-html)))
 in org-export-head. I tried, but without success, because I am simply
 not expert enough. I see the best, that is to export both with org-ref 3
 (i.e. "r h") and org-export-head, but I am unable to code it.

 No doubt that it should be for you and Ivan a piece of cake, but please
 do it only if you think that it is interesting and if you find the time
 to do it.

 Best wishes,

 Jo.

 PS in attachment, myblogexporter.el in my ~/.emacs.d/personal  (usual
 path with Prelude Emacs).

 Le 01/12/2021 à 23:16, John Kitchin a écrit :
>
> Joseph Vidal-Rosset  writes:
>
>> Dear Andras,
>>
>> You are very probably right. I will have a look on this entry in my
>> default bibliography file.
>>
>> The code
>>
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>(org-open-file  (org-html-export-to-html)))
>>
>> put in

Re: Org-syntax: Intra-word markup

Hi Maxim,

Max Nikulin writes:

> More explicit markup leaves less room for ambiguities, and I like the
> idea due to this reason. On the other hand it diverges from principle
> of lightweight markup. The almost only special character in TeX is
> "\", HTML has three ones "&<>" with simple escape rules. Org uses many 
> special characters to avoid verbosity and requires some tricks to
> escape them. Markers like "\{" make Org more verbose but do not make
> it more strict, a lot of things still rely on heuristics.

Excellent explanation. Thanks for the clarification. 

> I have an idea what can be done when some special markup is required
> that is not fit into current syntax. Unfortunately some new constructs 
> should be introduced anyway: inline objects and multiline elements
> that represent simplified result of parsed Org structures:
>
> ((italic "intra") "word")
>
> wrapped with some markup. It should satisfy any special needs (and
> even should allow to create invalid impossible constructs). Maybe idea
> of combination of lightweight markup and low-level blocks better suits
> for some other project with more expressive internal representation.
> In Org it may become the most hated feature.

I really would like a solution in this direction. In LaTeX there is a
command called \protect (which has nothing to do with this topic and is
used for other things, but I like the 'protection' concept); we could
perhaps think of a type of mark to protect the 'usual' marks when syntax
consistency is compromised in some way by the context. Maybe something
like enclosing the normal marks between two double single quotes ''...''
---or a single set of single quotes before the leading marker--- as I
proposed in another thread:

#+begin_example
''*protected emphasis*''
#+end_example

Best regards,

Juan Manuel

Re: Org-syntax: Intra-word markup

2021-12-03 Thread Max Nikulin


On 03/12/2021 01:11, Tom Gillespie wrote:


I recommend anyone suggesting solutions try to implement
something that can parse the markup unambiguously with
lots of nasty test cases. You will likely find that it is impossible
to consistently tokenize markup, and that you have to hand
write a whole bunch of heuristics, making Org syntax even
harder to implement correctly.


Tom, I see and share you point, however sometimes more specific and 
convincing arguments are necessary.


Why unconstrained markup ("//") does not cause problems in asciidoc? 
Maybe it does but they are not immediately obvious. I don know since I 
have never used asciidoc. Maybe parser behaves in a different way than 
org-element. Maybe plain text links are not allowed at all. Almost any 
URL contains such pair of markers: https://orgmode.org/, so it should be 
addressed somehow.


Examples of corner cases that are used for tests should be more visible 
to users otherwise it is hard to use such samples in discussions. They 
should be annotated (arbitrary examples from recent discussions):


- input: [[https://first/-/url/][pre]] text [[https://second-url/?][post]]
  parsed: (
(link :target "https://first/-/url/; :description "pre")
" text "
(link :target "https://second-url/?; :description "post"))
  comment: "Regexp-based syntax highlighting falsely finds italic text 
because URLs have slashes similar start and end of italics"


- input: A _b =c_ d= e_ f
  parsed: (
"A "
(underline "b =c")
" d= e_ f")
  comment: "Users of markdown may falsely expect that c_ is protected 
by verbatim markers and underlined text is ended at e_"

Re: Org-syntax: Intra-word markup

2021-12-03 Thread Max Nikulin


On 03/12/2021 02:03, Nicolas Goaziou wrote:

Denis Maier writes:


As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?


I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous situations.


I suppose, some more general solution is required.


I do think the marker + zero-width space is one way to go. We could, as
an improvement, consider zero-width spaces around emphasis markers to be
part of the markup, and replace them along during export.


Zero-space characters adjacent to emphasis markers is a better idea than 
replacing any zero space. However I agree with Juan Manuel that white 
space characters, especially completely invisible (I am not Eli who sees 
such special characters by moving cursor through them) should not be 
overloaded. From my point of view, it is acceptable to use zero width 
spaces as a workaround but they should not become official part of Org 
syntax.



Another solution is to introduce a less-subtle, but less prone to
ambiguity, syntax, e.g.,

   /{bold}/markup   or   /|bold|/markup

where /{ }/  or /|  |/ become "extended" markers.


More explicit markup leaves less room for ambiguities, and I like the 
idea due to this reason. On the other hand it diverges from principle of 
lightweight markup. The almost only special character in TeX is "\", 
HTML has three ones "&<>" with simple escape rules. Org uses many 
special characters to avoid verbosity and requires some tricks to escape 
them. Markers like "\{" make Org more verbose but do not make it more 
strict, a lot of things still rely on heuristics.


I have an idea what can be done when some special markup is required 
that is not fit into current syntax. Unfortunately some new constructs 
should be introduced anyway: inline objects and multiline elements that 
represent simplified result of parsed Org structures:


((italic "intra") "word")

wrapped with some markup. It should satisfy any special needs (and even 
should allow to create invalid impossible constructs). Maybe idea of 
combination of lightweight markup and low-level blocks better suits for 
some other project with more expressive internal representation. In Org 
it may become the most hated feature.

Re: BUG?: Link to inline-task not working

2021-12-03 Thread Michael Dauer

Ihor, thank you for the quick workaround.

Unfortunately storing links is not much of an issue for me. The real issue
is how I can get the internal links working in the exported html.

I could not find the right places to deactivate and
re-activate inline-tasks during export.

I have a custom org-html-format-inlinetask-function. If I
deactivate inline-tasks outside this formatter is never called, otherwise
the links are not generated.

Where are the links/href are built? There should be the error that excludes
inline-tasks.

thx,
m

Am Fr., 3. Dez. 2021 um 11:50 Uhr schrieb Ihor Radchenko :

> Michael Dauer  writes:
>
> > Before (require 'org-inlinetask) all is fine. But after executing
> (require
> > 'org-inlinetask) the following happens:
> > 1. With point on/in t1 (org-store-link) stores *h2.
> > 2. The manually created link below h1 works in the buffer. But it is
> > exported as BROKEN LINK.
>
> Confirmed.
>
> > Any ideas how to get fully working links to inline-tasks?
>
> I have the following in my config to mitigate this problem:
>
> (defun org-inlinetask-store-link (oldfun  args)
>   "Store link to inlinetask at point."
>   (if (and (derived-mode-p 'org-mode)
>(org-inlinetask-in-task-p))
>   (let ((org-inlinetask-min-level 1000))
> (apply oldfun args))
> (apply oldfun args)))
>
> (advice-add 'org-store-link :around #'org-inlinetask-store-link)
>
> Best,
> Ihor
>

On zero width spaces and Org syntax

Hi all,

It is usually recommended, as you know, to insert a zero width space
character (Unicode U+200B) as a sort of delimiter mark to solve the
scenarios of emphasis within a word (for example, =/meta/literature=)
and others contexts where emphasis marks are not recognized (for example
=[/literature/]=). I believe that as a puntual workaround it is not bad;
however, I find it problematic that this character is part, more or less
de facto, of the Org syntax. For two main reasons:

1. It is an invisible character, and therefore it is difficult to
control and manage. I think it is not good practice to introduce this
type of characters implicitly in a plain text document.

2. It is more natural that this type of space characters are part of the
'output' and not of the 'input'. In the input it is better to introduce
them not implicitly but through their representation. For example, in
LaTeX (with LuaTeX) using the command '\char"200B{}' (or '200b'),
'' in HTML, etc.

In any case, as an implicit character, I do not see it appropriate for
the syntax of a markup language. The marks should be simply ascii
characters, IMHO. So what if Org had a specific delimiter mark for the
scenarios described above? For example, something like that:

#+begin_example

/meta/''literature

*meta*''literature

[''*literature*'']

#+end_example

WDYT?

Best regards,

Juan Manuel

Re: frustrations

2021-12-03 Thread Dr. Arne Babenhauserheide

Jan Ulrich Hasecke  writes:

> There are some more issues. Startup time of my emacs is more than 30
> seconds even after optimizing something with esup. I have 10.000+ files
> in my org-roam and fear that I hit some limitation either of org-roam or
> my hardware.

I use use-package with the :defer option for everything that I don’t
always need at startup. That gives me sub-second startup, which is OK,
and at first idle it adds more packages.

The other main focus I have there nowadays is to stay close to vanilla
Emacs: Only change what I really need different. The main advantage of
that is that when I need an editor that is there *at once*, I just use
emacs -Q

That avoids all customizations, even those from the distribution, and it
is roughly instant (if you need more, then add -nw to open it purely in
the terminal).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

signature.asc
Description: PGP signature

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

2021-12-03 Thread Max Nikulin


On 03/12/2021 11:36, Ihor Radchenko wrote:

Max Nikulin  writes:


Unfortunately currently it fails in Emacs-26.3 event without "#+startup:
indent":

Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing
list (M-x org-submit-bug-report).
The buffer is: new.org
   Current command: (nil 163 167)
   Chars modified: 163
   Buffer modified: 167
   Backtrace:
nil


I am unable to reproduce on my side also using Emacs 26.3. Are you sure
that you are running a clean Emacs?


make clean
make autoloads
git log -1 --format=short
commit 8ca254696b002f5079e31ac12a1ad87c003f673d (HEAD -> main, origin/main)
Merge: 521c53410 0acd2fed2
Author: Kyle Meyer 

Merge branch 'bugfix'

git diff HEAD
# nothing
LANG=en_US.UTF-8 emacs -Q -L ~/src/org-mode/lisp/ ~/examples/org/new2.org &

 >8 
* A
B
 8< 

C-c C-* while cursor is at the end of second line

Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing 
list (M-x org-submit-bug-report).

The buffer is: new2.org
 Current command: (nil 26 30)
 Chars modified: 26
 Buffer modified: 30
 Backtrace:
nil

Re: BUG?: Link to inline-task not working