Re: Handling conversion of fields with spaces to tables

[Loris Bennett]

Eric S Fraga  writes:

> On Monday,  6 Dec 2021 at 15:43, Loris Bennett wrote:
>> That's solves the problem of the field being split, but gives me the new
>> problem that the output is no longer a table :-)
>
> Ah, yes, sorry: you need to have each line of the output start with a
> "|" as well.  If your external script can do that, it should work.
>
> As in:
>
>   #+BEGIN_SRC sh :results output raw
>   echo "|marie|Curie|123"
>   echo "|louis|De Broglie|456"
>   #+END_SRC
>
>   #+RESULTS:
>   | marie | Curie  | 123 |
>   | louis | De Broglie | 456 |

For what ever reason, the external script has an option to add "|" at
the end of each line, but not at the beginning.  However, I can just
pipe the output through 'sed' to get one at the beginning, so all is
well.

Thanks for the help!

Cheers,

Loris
-- 
This signature is currently under construction.

bug#44687: 26.3; Link broken in inline comment

[Kyle Meyer]

tags 44687 wontfix
close 44687
quit

YH Tan writes:

> In org-mode,
>
> ```
> [[link]]@@comment:[[link]]@@
> # [[link]]
>
> * link
> ```
>
> I get the message "No Link Found" when clicking on the [[link]] within
> the inline @@comment:[[link]]@@.
>
> The link works fine with emacs -Q, but breaks after evaluating some
> init.el code.
>
> Problem is, I cannot pinpoint to the exact code that broke the link.

I'm sorry you didn't get a response at the time.

Your recipe starts complaining "No Link Found" as of Org's d3774fba7,
which was a part of the 9.2 release:

  Limit `org-open-at-point'
  
  * lisp/org.el (org-open-at-point): Do not open everything that looks
like a link, in particular in verbatim or code objects.  However,
still conveniently open links in comments, node properties and
keywords.

The Org bundled with Emacs 26.3 was 9.1.9, so the difference you
reported between your regular environment and 'emacs -Q' is very likely
explained by the above commit being included in the Org available from
ELPA but not yet included in the Org that shipped with Emacs 26.3.

My understanding is that no longer being able to open a link (or rather
text that resembles a link) in an export snippet is an intentional
consequence of that commit, so I'm closing this as wontfix.  (But fwiw
calling org-open-at-point-global rather than org-open-at-point should
give the behavior you're after.)

Re: Looking for extensions of [[file:~/xx.org::My Target]]

[Eduardo Ochs]

...also here:
https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org#example-links

Very good, thanks! =)
  E.

On Mon, 6 Dec 2021 at 23:45, John Kitchin  wrote:
>
> You might find the scimax-notebook project 
> (https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org) 
> interesting for this. It builds on projectile and defines a link 
> (https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org#notebookproject-links)
>  similar to what you describe. You can learn more about it here:
>
> https://www.youtube.com/watch?v=H4sK5ld6Bw0
>
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Mon, Dec 6, 2021 at 8:44 PM Eduardo Ochs  wrote:
>>
>> Hi people,
>>
>> this node of the Org manual
>>
>>   (info "(org)Search Options")
>>   http://www.gnu.org/software/emacs/manual/html_node/org/Search-Options.html
>>
>> explains that we can use links like this one
>>
>>   [[file:~/xx.org::My Target]]
>>
>> to point to a string like "<>" in the file ~/xx.org.
>>
>> Where can I find extensions of that syntax that allow using several
>> "projects"? I am thinking of something like this: after telling the
>> extension that in the local filesystem
>>
>>   the project "dn6" is at ~/LATEX/dednat6/, and
>>   the project "edrxrepl" is at ~/edrxrepl/
>>
>> then the links
>>
>>   [[file:dn6/stacks.lua:Stack-tests]] and
>>   [[file:edrxrepl/edrxpcall.lua:Class]]
>>
>> would point to:
>>
>>   the string "<>" in ~/LATEX/dednat6/stacks.lua and
>>   the string "<>" in ~/edrxrepl/edrxpcall.lua,
>>
>> and I imagine that every such extension would also allow telling the
>> HTML exporter where these "projects" are in the web...
>>
>> Thanks in advance!
>>   Eduardo Ochs
>>   http://angg.twu.net/#eev
>>
>>
>>
>> P.S.: I still know far less Org than I should, but I am trying to
>> remedy this...
>>
>> P.P.S.: eev uses this trick to point to anchors in "projects":
>>   http://angg.twu.net/eev-intros/find-eev-quick-intro.html#8.5
>>   http://angg.twu.net/eev-intros/find-eev-quick-intro.html#9.2
>> I need to add to its docs references to how other packages do
>> similar things.
>>

Re: Looking for extensions of [[file:~/xx.org::My Target]]

[John Kitchin]

You might find the scimax-notebook project (
https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org)
interesting for this. It builds on projectile and defines a link (
https://github.com/jkitchin/scimax/blob/master/scimax-notebook.org#notebookproject-links)
similar to what you describe. You can learn more about it here:

https://www.youtube.com/watch?v=H4sK5ld6Bw0


John

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



On Mon, Dec 6, 2021 at 8:44 PM Eduardo Ochs  wrote:

> Hi people,
>
> this node of the Org manual
>
>   (info "(org)Search Options")
>
> http://www.gnu.org/software/emacs/manual/html_node/org/Search-Options.html
>
> explains that we can use links like this one
>
>   [[file:~/xx.org::My Target]]
>
> to point to a string like "<>" in the file ~/xx.org.
>
> Where can I find extensions of that syntax that allow using several
> "projects"? I am thinking of something like this: after telling the
> extension that in the local filesystem
>
>   the project "dn6" is at ~/LATEX/dednat6/, and
>   the project "edrxrepl" is at ~/edrxrepl/
>
> then the links
>
>   [[file:dn6/stacks.lua:Stack-tests]] and
>   [[file:edrxrepl/edrxpcall.lua:Class]]
>
> would point to:
>
>   the string "<>" in ~/LATEX/dednat6/stacks.lua and
>   the string "<>" in ~/edrxrepl/edrxpcall.lua,
>
> and I imagine that every such extension would also allow telling the
> HTML exporter where these "projects" are in the web...
>
> Thanks in advance!
>   Eduardo Ochs
>   http://angg.twu.net/#eev
>
>
>
> P.S.: I still know far less Org than I should, but I am trying to
> remedy this...
>
> P.P.S.: eev uses this trick to point to anchors in "projects":
>   http://angg.twu.net/eev-intros/find-eev-quick-intro.html#8.5
>   http://angg.twu.net/eev-intros/find-eev-quick-intro.html#9.2
> I need to add to its docs references to how other packages do
> similar things.
>
>

Re: From macros to elisp programming?

[Eduardo Ochs]

On Mon, 6 Dec 2021 at 10:43, Ypo  wrote:
>
> Hi
>
> I am able to make macros, but I think I am far away from Lisp programming.
>
> Is there a path to go from macros to elisp programming? For example, the last 
> macro I've made is for transforming the name of some headlines, adding in 
> front of them a part from the previous headline. This is the elisp code of 
> the macro:
>
> #+BEGIN_SRC
> (fset 'SanzTema5
>(kmacro-lambda-form [?\C-a ?\M-f ?\M-b ?\C-  ?\M-f ?\M-f ?\M-f ?\M-f ?\M-f 
> ?\M-f ?\M-f ?\M-f ?\M-f ?\M-w ?\C-c ?\C-n ?\C-a ?\M-f ?\M-b ?\C-y ?  ?- ?  
> ?\C-e ?\M-b ?\M-f ?\"] 0 "%d"))
> #+END_SRC
>
>
> Using that code, from these headlines:
>
> *** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez Balaña" 
> (pp. 95-118)
>  INTRODUCCIÓN
>
> I get modified the second headline:
>
> *** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez Balaña" 
> (pp. 95-118)
>  Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos - INTRODUCCIÓN"
>
>
> Are macros near to elisp programming or they are two different worlds?
>
> Ypo


Hi Ypo,

here's a suggestion. If you run this

  (setq last-kbd-macro [?\C-a ?\M-f ?\M-b ?\C- ?\M-f ?\M-f ?\M-f ?\M-f
?\M-f ?\M-f ?\M-f ?\M-f ?\M-f ?\M-w ?\C-c ?\C-n ?\C-a ?\M-f ?\M-b
?\C-y ? ?- ? ?\C-e ?\M-b ?\M-f ?\"])

and then type `C-x C-k C-e' (`kmacro-edit-macro-repeat') you will get
a temporary buffer that contains this:

C-a ;; move-beginning-of-line
M-f ;; forward-word
M-b ;; backward-word
C-SPC   ;; set-mark-command
9*M-f   ;; forward-word
M-w ;; kill-ring-save
C-c C-n
C-a ;; move-beginning-of-line
M-f ;; forward-word
M-b ;; backward-word
C-y ;; yank
SPC ;; self-insert-command
-   ;; self-insert-command
SPC ;; self-insert-command
C-e ;; move-end-of-line
M-b ;; backward-word
M-f ;; forward-word
"   ;; self-insert-command

If you convert that by hand - suggestion: use keyboard macros for
that! =) - to a defun like this one,

  (defun SanzTema5 ()
(interactive)
(move-beginning-of-line)   ; C-a
(forward-word) ; M-f
(backward-word); M-b
(set-mark-command) ; C-SPC
(dotimes 9 (forward-word)) ; 9*M-f
;; ^ or: (forward-word 9)
(kill-ring-save)   ; M-w
;; What here? I don' have a:   ; C-c C-n
(move-beginning-of-line)   ; C-a
(forward-word) ; M-f
(backward-word); M-b
(yank) ; C-y
(insert " - ") ; SPC - SPC
(move-end-of-line) ; C-e
(backward-word); M-b
(forward-word) ; M-f
(insert "\"")  ; "
)

Then you will get a defun that does something that is clearly useful
to you... you can start by creating and debugging a handful of defuns
like that one and then learn what most people consider as "real
Elisp"...

  Cheers =),
Eduardo Ochs
http://angg.twu.net/#eev

bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

bruce robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
> ** TODO [#0] test line
>
> 3. from M-x view-lossage:
>  C-c , ;; org-priority
>
> 4. mini-buffer displays:
> "Priority 0-31, SPC to remove: "
>
> 5. further in view-lossage:
> SPC   ;; self-insert-command
>;; exit-minibuffer
>
> 4. from *Messages* (and mini-buffer):
> Priority of current item set to 0
>
> 5. PROBLEM:
> I wanted to remove priority.
>
> 6. WORK-AROUND:
> set priority to 32. Then priority disappears. Perhaps this is because 32
> is space code or because I've set org-priority-default to 32.
> ( I spent a medium amount of time to find this behavior. )
>
> 7. SUGGESTION:
> rewrite org-priority to have a clear distinction between numbers and
> characters and whatever will be used to remove the priority.
> ( I gave a look at this but my emacs-fu is too weak. Or my time-fu is
> too small. )

Right, this stems from org-priority feeding " " to string-to-number and
ending up with 0 instead of the ?\s (32) that's used downstream to
signal "remove".  The problem goes back to when support for numeric
priorities was added in Org v9.4's 4f98694bf (Allow numeric values for
priorities, 2020-01-30).

I suppose one solution would be to check for " " and translate that to
the ?\s so that the remove is triggered.  I'll plan to apply the change
below to Org's bugfix branch in a day or two unless the author of the
above commit (+cc) or someone else has another suggestion.

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..998da0656 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11323,13 +11323,14 @@ (defun org-priority ( action show)
(setq
 new
 (if nump
- (let ((msg (format "Priority %s-%s, SPC to remove: "
-   (number-to-string org-priority-highest)
-   (number-to-string org-priority-lowest
-   (if (< 9 org-priority-lowest)
-  (string-to-number (read-string msg))
- (message msg)
- (string-to-number (char-to-string 
(read-char-exclusive)
+ (let* ((msg (format "Priority %s-%s, SPC to remove: "
+ (number-to-string org-priority-highest)
+ (number-to-string org-priority-lowest)))
+(s (if (< 9 org-priority-lowest)
+   (read-string msg)
+ (message msg)
+ (char-to-string (read-char-exclusive)
+   (if (equal s " ") ?\s (string-to-number s)))
   (progn (message "Priority %c-%c, SPC to remove: "
   org-priority-highest org-priority-lowest)
  (save-match-data

Looking for extensions of [[file:~/xx.org::My Target]]

[Eduardo Ochs]

Hi people,

this node of the Org manual

  (info "(org)Search Options")
  http://www.gnu.org/software/emacs/manual/html_node/org/Search-Options.html

explains that we can use links like this one

  [[file:~/xx.org::My Target]]

to point to a string like "<>" in the file ~/xx.org.

Where can I find extensions of that syntax that allow using several
"projects"? I am thinking of something like this: after telling the
extension that in the local filesystem

  the project "dn6" is at ~/LATEX/dednat6/, and
  the project "edrxrepl" is at ~/edrxrepl/

then the links

  [[file:dn6/stacks.lua:Stack-tests]] and
  [[file:edrxrepl/edrxpcall.lua:Class]]

would point to:

  the string "<>" in ~/LATEX/dednat6/stacks.lua and
  the string "<>" in ~/edrxrepl/edrxpcall.lua,

and I imagine that every such extension would also allow telling the
HTML exporter where these "projects" are in the web...

Thanks in advance!
  Eduardo Ochs
  http://angg.twu.net/#eev



P.S.: I still know far less Org than I should, but I am trying to
remedy this...

P.P.S.: eev uses this trick to point to anchors in "projects":
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#8.5
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#9.2
I need to add to its docs references to how other packages do
similar things.

Re: From macros to elisp programming?

[Tim Cross]

Ypo  writes:

> Hi
>
> I am able to make macros, but I think I am far away from Lisp programming.
>
> Is there a path to go from macros to elisp programming? For example, the last 
> macro I've made is for transforming the name of some
> headlines, adding in front of them a part from the previous headline. This is 
> the elisp code of the macro:
>
> #+BEGIN_SRC
> (fset 'SanzTema5
>(kmacro-lambda-form [?\C-a ?\M-f ?\M-b ?\C-  ?\M-f ?\M-f ?\M-f ?\M-f ?\M-f 
> ?\M-f ?\M-f ?\M-f ?\M-f ?\M-w ?\C-c ?\C-n ?\C-a ?\M-f ?\M-b ?\C-y
> ?  ?- ?  ?\C-e ?\M-b ?\M-f ?\"] 0 "%d"))
> #+END_SRC
>
> Using that code, from these headlines:
>
> *** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez Balaña" 
> (pp. 95-118)
>  INTRODUCCIÓN
>
> I get modified the second headline:
>
> *** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez Balaña" 
> (pp. 95-118)
>  Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos - INTRODUCCIÓN"
>
> Are macros near to elisp programming or they are two different worlds?
>

Unfortunately, the term 'macro' is somewhat overloaded and can mean
different things depending on the language. For example, C has
pre-processor 'macros' which are essentially simple string replacement
mechanisms and very different from macros as used in lisp languages like
elisp, common lisp or clojure. In a similar vain, what you are referring
to above is a keyboard macro, which is not an elisp macro. A keyboard
macro is essentially a simple 'replay' facility where you can capture a
set of keyboard input actions, give them a name and then repeat those
actions by running the macro with that name again. This is very
different from an elisp macro. An elisp macro (or a common lisp macro,
or a clojure macro etc) is a facility which allows you to manipulate
source code and can be very useful in defining new low level language
constructs which are largely indistinguishable from the built-in
constructs of the language. For example, if elisp did not have a 'when'
statement, you could define it as a macro and it would operate at the
same level as other built in functions. For this reason, macros are
often used a lot when defining a 'domain specific language' (DSL-)  a type of
language dialect which has operators specific to a specialised domain. 

While others would likely disagree, I would not consider using keyboard
macros as programming in emacs lisp. Keyboard macros are an end user
facility which can be used to automate repetitive tasks and which can be
used by anyone using Emacs - you don't need to know any emacs lisp to
create and use a keyboard macro. 

Macros as used in lisp languages are a wonderful, extremely powerful
facility that allow the programmer to do things which are near
impossible in other languages. However, they should be used very
judiciously. There is an old adage which states that if you can do it
with a function, then use a function, not a macro. A common error made
by those new to macros is that they are so amazed at their power, they
now think it is the solution to all problems.

It is difficult to recommend resources as a lot depends on your own
experience, what level you want to dive into and what you want to be
able to do. There is a big difference in knowing enough emacs lisp to
tweak your Emacs configuration and knowing enough emacs lisp to write
the next great package. The good news is that there are some great free
resources out there, so the main investment will be in time.

If you have not yet read it, a good starting point is Mastering Emacs by
Mickey Petersen  https://www.masteringemacs.org/

There is also an Introduction to Emacs Lisp, which is part of the GNU
Emacs distribution.

For getting to understand lisp programming at a much deeper level, there
are some excellent resources out there, many of which are free. The
trick is to not limit yourself to searching just for Emacs lisp. Emacs
lisp is a dialect of lisp - a domain specific language for an editor if
you like. Most of the concepts associated with lisp are applicable to
emacs lisp. almost any resource teaching lisp will teach you things
applicable to emacs lisp. Therefore, if you really want to learn how to
program in emacs lisp, search for resources on learning to program in
lisp.

There is a somewhat famous book called 'The Structure and Interpretation
of Computer Programs" (SCIP), which is based on a course in computer
science taught at MIT. It is an excellent book. Even better, videos from
the course are also available on-line. While the focus is on
programming, it uses a lisp dialect to demonstrate the core principals,
which it makes very clear. A must watch for anyone really keen to
understand programming.

Another great book about lisp which is also freely available is Paul
Graham's 'On Lisp', which I think gives a pretty good overview of the
power and flexibility of lisp and functional programming. 

A book which I really like and which I think really shows off the power
of lisp macros is 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Karl Voit]

Hi,

* Ihor Radchenko  wrote:
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
> 2. Non-emacs users interested in plain text markup
> 3. Non-emacs users interested in GTD/project management, etc
>"Org mode: your life in plain text" is somewhat relevant when people
>are looking to manage "life" (typically true for GTD enthusiasts).
> 4. Researchers looking for ipython-like environment
> 5. ??? (Suggestions are welcome)

I don't think that you can come up with a good website that is able
to serve all of them properly.

For Orgdown I had in mind number 2 and 3. For supporting the idea
for Orgdown, I thought of number 1. (Well, that turned out in a
mixed way[1]).

If you do want to have a go-to for people who should use the
Org-mode syntax without the GNU/Emacs tool, you need to have a
separate site.

[1] https://karl-voit.at/2021/12/02/Orgdown-feedback

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

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Timothy]

Hi Russell,

> To my esteemed colleague, I have a few comments for your comments on
> my comments. ;]

Lovely. I happen to have one or two remarks on your comments^{2} :P

> I’m all for the idea of tightening up documentation to make Org a more
> polished product. The issue is when the justification for that effort
> is interoperability with tools outside Emacs.

I think this is always a good thing. Regarding the motivation, I’m not sure how
crucial it is. The idea I have had and am yet to articulate (hopefully I’ll sit
down and do so this week) is originally motivated by considerations for people
who want to make tools that work with Org, but upon reflection I think has
broader benefits. I think the framing is also rather important here, not
changing Org to fit other tools, but making it easier for other tools to shape
themselves to be interoperable with org-mode — which I see as the crux of this
topic.

> My goal is to remind everyone that maintainer and coder time is a
> scarce resource, and I’m very protective of asking them to commit to
> anything. An indirect commitment can still feel like a commitment,
> even if it’s only implied by popular opinion and not agreed to.

It’s always nice to see you advocating for consideration of maintainers and
contributors free time. With this specific topic though, given that we have one
maintainer/significant contributor (Ihor) asking for feeback on proposed changes
w/ motivation and another one (me) very interested in it , I’m not sure that
this concern is particularly relevant.

All the best,
Timothy

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Karl Voit]

Hi,

* Ihor Radchenko  wrote:
>
> The fact is that e.g. Github already provides support for Org markup.
> They do it for their own profit and we cannot stop them. If we have a
> controlled criteria about quality of third-party Org mode support, there
> will be means to interfere with non-free software attempting to makes
> profits out of Org mode. For example, if Github do not integrate our
> recommended test suite (with all the legal consequences defined in
> GPLv3), we will be able to have a list of third-party tools and, among
> free alternatives, mention that Github support for Org is not verified
> and most likely not consistent with other _free_ tools. We cannot do it
> now.

This is the main reason why I came up with the concept of Orgdown
levels in the first place. Tools may choose their featureset
independently and Orgdown assessments show the users the amount of
features they can get.

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

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Tue, Dec 07, 2021 at 02:47:28AM +0800, Timothy wrote:
> I have a few comments on your comments :)

To my esteemed colleague, I have a few comments for your comments on
my comments. ;]

> > How many syntax documents are we supposed to maintain outside of the working
> > implementation in Emacs and the manual?
>
> Just the one. I have some ideas on this that need to be written up, but I see
> this more as polishing our syntax specification such that it’s is more
> approachable for someone interested in supporting Org. IMO this leads to a
> syntax document which is just better, period.

I'm all for the idea of tightening up documentation to make Org a more
polished product. The issue is when the justification for that effort
is interoperability with tools outside Emacs.

> > Discussions are often fruitful for all involved and shouldn’t be a
> > problem when conducted in a respectful manner. Expect critical
> > opinions at times, but we should keep it civil.
>
> Indeed. I do find myself wishing that some discussions stayed more on-topic
> though…

My goal is to remind everyone that maintainer and coder time is a
scarce resource, and I'm very protective of asking them to commit to
anything. An indirect commitment can still feel like a commitment,
even if it's only implied by popular opinion and not agreed to.

As a free program with free and plain text results, anyone can code
anything they want to work with it. Asking Org volunteers to do
something outside the scope of Emacs should be critically examined
before we can justify asking for volunteer time. That doesn't mean
topics shouldn't be discussed, that discussion is the process of
critical examination. There's also plenty of room for "fluff", but not
flame.

For instance, Karl clearly spent a lot of time on his proposal. I
thought he was trying to clearly articulate issues from the recent
discussions regarding interoperability. I appreciate his efforts even
when I don't agree with every conclusion (I vote "Orgish"!). I wish I
knew enough about the underlying code to make an informed opinion so I
have abstained from on commenting on the details.

I don't have to agree or disagree with every point, I'm just watching
the debate and trying to place some gentle reminders in the discussion
to keep it civil and remember our volunteers are just that,
volunteers.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Org Mode "Contribute", "Maintenance" pages don't give repository.

[Karl Fogel]

On 05 Dec 2021, Daniel Fleischer wrote:
You're right; I'll think of a way to present the git repo link, 
i.e. the
code earlier and more prominently for those who just want to jump 
and

examine the code.


+1, and thanks!

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Gerry Agbobada]

Hello everybody,

On Mon, Dec 6, 2021, at 18:59, Tom Gillespie wrote:
> I follow this list, I keep the community up to date with my work,
> I have no idea where to look for other Org related dicussions,
> nor frankly do I have time to look for them. I suspect I am not
> alone in this.

Just not to leave this be a wild guess or a lone data-point, I want to say that 
I’m exactly in the same case, and I really don’t want to bring up anything I do 
related to org-mode here because of this kind of backlash without which I feel 
really better. Too bad I guess, I’ll just try to communicate here and there 
through github issues as I’ve been doing until now.

Regards,
G
-- 
Gerry Agbobada

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Timothy]

Hi Russell,

I have a few comments on your comments :)

> These kind of issues snowball because we are also indirectly asking
> for our coders and maintainers to consider those external tools while
> continuing to support Org.

As I read it, considering other tools was just in the respect of indicating what
degree of support different tools have for Org as defined by org-mode. Not
changing anything we do based on those tools.

> How many syntax documents are we supposed to maintain outside of the working
> implementation in Emacs and the manual?

Just the one. I have some ideas on this that need to be written up, but I see
this more as polishing our syntax specification such that it’s is more
approachable for someone interested in supporting Org. IMO this leads to a
syntax document which is just better, period.

> The topic of software freedom comes up because by definition, other
> tools are outside of Emacs and may be non-free. It’s important to
> consider, but isn’t a reason to not discuss features. The key is our
> volunteers should not be required to code features for non-free tools
> outside of Emacs.

I don’t think anybody has proposed this. Personally I’m not even sure how we
went from making the website/docs more approachable to supporting 3rd party
tools ourselves, or changing anything in org-mode itself for them…

> An implied support requirement to preserve interoperability with
> external tools is a large commitment, and could also run into the
> non-free software issue. Expect people to have strong opinions about
> these matters.

With regards to this, by the very nature of things, any change that would break
interoperability with external tools would have to be a breaking change to the
syntax (with all the relevant implications for org-mode itself). In such a
situation, this would be the major concern, not external tools, so I see this
line of reasoning as being a bit moot.

> Discussions are often fruitful for all involved and shouldn’t be a
> problem when conducted in a respectful manner. Expect critical
> opinions at times, but we should keep it civil.

Indeed. I do find myself wishing that some discussions stayed more on-topic
though…

All the best,
Timothy

Re: From macros to elisp programming?

[Ypo]

Lovable!!

Thanks!
Ypo

El 06/12/2021 a las 19:08, András Simonyi escribió:

Dear All,

On Mon, 6 Dec 2021 at 14:43, Ypo  wrote:


I am able to make macros, but I think I am far away from Lisp programming. [...]
Is there a path to go from macros to elisp programming?

there is a package called 'elmacro' (https://github.com/Silex/elmacro)
which you can look into. Apparently, it can convert  (most?) macros
into interactive Elisp functions, and might even provide a good
starting point  for learning Elisp.

best wishes,
András

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[John Kitchin]

It is a "feature" of other completion tools that differentiate between the
selected candidate (usually the highlighted one) and the current input
(which may be incomplete, and usually not what you want to select, but
sometimes is (e.g. when you want an empty string, or to choose something
that is not a candidate but similar to one e.g. with fuzzy matching)). That
happens with helm and ivy, probably selectrum, and other backends that try
to improve on the vanilla completing-read interface.

John

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



On Mon, Dec 6, 2021 at 1:42 PM Daniel Nemenyi  wrote:

>
> Nicolas Goaziou  wrote (on Mon 06 Dec 2021 17:58):
>
> > The prompt displays : "" to exit, which means you have to select the
> > empty value to exit. How you do select that value depends on the
> > completion UI.
> >
> > I admit it is not particularly clear. Maybe we should spell out the
> > "empty value" part of the prompt.
>
> I sort of got that -- though I must admit I did try entering two double
> quotes just in case! -- but the issue is that it's not clear how one
> inserts an empty value.
>
> Couldn't the top value one could select simply be ""? Or is this just a
> problem with helm?
>
>

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Sun, Dec 05, 2021 at 03:35:39PM +0800, Ihor Radchenko wrote:
> Dear Fellow Orgers,
>
> The recent spike of discussions following Karl's presentation in
> Emacsconf 2021 revealed a lot of controversy among Org and Emacs
> enthusiasts. Yet, Karl named a number of very real problems surrounding
> Org mode usage outside Emacs.

On a lighter note, I preferred the format be named "Orgish".

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Mon, Dec 06, 2021 at 07:25:02PM +0100, M. ‘quintus’ Gülker wrote:
>
> We started with an interoperability topic and now we are discussing
> whether the intent is to take away software freedom from Emacs org
> users. I cannot help but to find this connection far-fetched. Nobody
> is suggesting to hamper org-mode-in-emacs' further development. All
> that was asked was if there is interest in someone outside of
> org-mode-in-emacs writing up “compatibility levels” for the org
> markup.

These kind of issues snowball because we are also indirectly asking
for our coders and maintainers to consider those external tools while
continuing to support Org. How many syntax documents are we supposed
to maintain outside of the working implementation in Emacs and the
manual?

The topic of software freedom comes up because by definition, other
tools are outside of Emacs and may be non-free. It's important to
consider, but isn't a reason to not discuss features. The key is our
volunteers should not be required to code features for non-free tools
outside of Emacs.

An implied support requirement to preserve interoperability with
external tools is a large commitment, and could also run into the
non-free software issue. Expect people to have strong opinions about
these matters.

> ... not be banned from discussion on this mailing list.

I don't think banning topics is appropriate. I think we were reminded
that this is an Emacs list and FSF software ethics apply. Any official
stance Org maintainers take would have to be in line with that moral
code.

Discussions are often fruitful for all involved and shouldn't be a
problem when conducted in a respectful manner. Expect critical
opinions at times, but we should keep it civil.


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Daniel Nemenyi]

Nicolas Goaziou  wrote (on Mon 06 Dec 2021 17:58):

> The prompt displays : "" to exit, which means you have to select the
> empty value to exit. How you do select that value depends on the
> completion UI.
>
> I admit it is not particularly clear. Maybe we should spell out the
> "empty value" part of the prompt.

I sort of got that -- though I must admit I did try entering two double quotes 
just in case! -- but the issue is that it's not clear how one inserts an empty 
value.

Couldn't the top value one could select simply be ""? Or is this just a problem 
with helm?

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Mon, Dec 06, 2021 at 09:59:42AM -0800, Tom Gillespie wrote:
> I think it is a major strategic mistake to exclude discussions
> about interoperability from this list.

I don't think discussion on the list (or irc) is a problem. It's all
on topic if it's related to Org-mode. As you said, users and
developers share the mailing list. Just understand as an Emacs mode,
it's Emacs oriented and Emacs is the priority. The truth is Org
doesn't work outside Emacs.

The issue is when non-Emacs enhancements or feature requests are made
to the maintainers and coders. I don't think anyone is hostile to
interoperability, but hostile to additional workload.

I've watched Org since shortly after it's creation snowball features
nonstop until it burned out coders. I feel like every power user with
a new edge case feature wants it added to the Org core, and that's
just not sustainable. That's why I'm very cautious about advocating
for new features, or potential burdens external interoperability may
place on our volunteers.

> I follow this list, I keep the community up to date with my work,
> I have no idea where to look for other Org related dicussions,

IRC. #org-mode on Libera.

> Whether a certain portion of the Org community likes it or not,
> there is another portion for whom Org syntax already has a life
> beyond Org mode (e.g. academic papers and computation notebook
> style workflows).

Ideally written with Emacs, and the source blocks processed by
Emacs. I can't imagine any of the data science source blocks working
in any environment outside Emacs today.

If other programs try to replicate Org's features that's fine in the
spirit of open source, but what support do we owe their
implementations? At what point does their project impose a maintenance
burden on our volunteers? That's what we need to be careful of.

Perhaps it's worth noting the clear distinction between Org's plain
text format and the Org experience inside Emacs. I think that the
plain text format in it's simplest forms may be interpreted by
external tools (ie: README.org on Github is HTML formatted). I don't
expect any tools outside of Emacs to provide the Org editing
experience.

> The plain text nature of Org syntax and the freedom that it enables
> also means freedom from Emacs. Empowering users to own and control
> their own data to use with their own tools is the whole point. The
> fact that this means that it works outside Emacs is a critical
> feature for many data preservation use cases.

Certainly Org is future proof because it's plain text. There's a big
difference between future proofed and openly legible versus
programming two way interoperability between Emacs and an external
tool. Just ask any synchronization tool. ;]

In summary, don't assume hostility to interoperability. Please respect
the limited time of our coders and maintainers, and the additional
burdens on them that may be implied by supporting external programs.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[M . ‘quintus’ Gülker]

Am Montag, dem 06. Dezember 2021 schrieb Tom Gillespie:
> [On not excluding discussions about org markup from the mailing list]

Thank you for writing this up. I agree with it. This discussion has
taken routes which I would never have expected. We started with an
interoperability topic and now we are discussing whether the intent is
to take away software freedom from Emacs org users. I cannot help but to
find this connection far-fetched. Nobody is suggesting to hamper
org-mode-in-emacs' further development. All that was asked was if there
is interest in someone outside of org-mode-in-emacs writing up
“compatibility levels” for the org markup. Whether or not that is a
daunting task is up to those who want to pick it up, and it certainly is
not "owed" by the org developers to cater for them. If there are
synergies -- there appear to be some, since the org formalising efforts
do predate Karl Voit's proposal apparently -- they should be taken
advantage of and not be banned from discussion on this mailing list.

I do not expect the permissal of such discussions to turn this mailing
list into a hub for help requests for non-org, or, heaven forbid,
non-free software implementing org markup.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[John Kitchin]

You could consider something like this:

The insert processors provided by org-cite use depend only on Emacs and use
completing-read to select one or more citation keys for insertion.
Completing-read is intended for selecting a single item, and org-cite
compensates for this by letting you select multiple keys, and exiting
when the selected candidate is an empty string. With a vanilla Emacs
installation, you can press Tab to see a list of possible candidates, and
use Tab for completion. Each time you press return with a completed
candidate in the minibuffer that key is added to a list to be inserted.
Press return with an empty minibuffer to finish and insert the selected
keys.

If you use an alternate completion-backend like helm, ivy, selectrum, etc.
you will see different behavior because they have a different concept of
the selected candidate vs the current input to select the current input
(which must be empty).

With helm, you cannot mark candidates, and there are no alternate actions.
You press return on each entry you want to select, and when you are done
selecting them you press C-return or M-return (bound to
helm-cr-empty-string) to insert all the entries at once.

With ivy, you press return on each entry you want to select, and when you
are done selecting them you press C-M-j (exits with current input instead
of the current candidate) to insert them.

With Selectrum, ... (don't know what the keybinding here is)

(not sure if there are other ones that should also be included)

Other insert processors may use these backends natively, so this
information may not apply to them.

John

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



On Mon, Dec 6, 2021 at 9:43 AM Bruce D'Arcus  wrote:

> On Mon, Dec 6, 2021 at 9:33 AM Daniel Nemenyi  wrote:
> > Apologies, I did ('Thanks org-ref I'm done...'), slip of the tongue.
>
> Oh, I missed that; sorry John.
>
> > Could have a go though if someone could give me a pointer? But if this
> is left to the user, perhaps we should include a line in the documentation
> telling them?
>
> The completion UIs have different keybindings for this. What should
> the documentation say?
>
> Bruce
>
>

Re: From macros to elisp programming?

[András Simonyi]

Dear All,

On Mon, 6 Dec 2021 at 14:43, Ypo  wrote:

> I am able to make macros, but I think I am far away from Lisp programming. 
> [...]
> Is there a path to go from macros to elisp programming?

there is a package called 'elmacro' (https://github.com/Silex/elmacro)
which you can look into. Apparently, it can convert  (most?) macros
into interactive Elisp functions, and might even provide a good
starting point  for learning Elisp.

best wishes,
András

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tom Gillespie]

Hi all,
I have a much longer mail in the works, a quick one for now.

I think it is a major strategic mistake to exclude discussions
about interoperability from this list. As Bastien pointed out in
his talk at Emacsconf there is only a single list for both users
and developers. Discussion about interoperability with tools for
working with Org are entirely valid subjects for the user
list. Obviously help and support for other tools is not valid for
the list, but questions about interoperability or incorrectness
of some external tool should always be valid.

We must provide strong technical leadership for all tools that
want to work with Org syntax otherwise we risk it spiraling out
of control. Forcing discussions off list will split the community
and I think the fact that Karl's work made it to this list so
late in the process shows the danger of trying to exclude certain
discussions.

I follow this list, I keep the community up to date with my work,
I have no idea where to look for other Org related dicussions,
nor frankly do I have time to look for them. I suspect I am not
alone in this.

Whether a certain portion of the Org community likes it or not,
there is another portion for whom Org syntax already has a life
beyond Org mode (e.g. academic papers and computation notebook
style workflows). For some workflows documents written in Org
syntax are a primary exchange format and format of record, not
just an internal format from which documents for sharing are
generated. The plain text nature of Org syntax and the freedom
that it enables also means freedom from Emacs. Empowering users
to own and control their own data to use with their own tools is
the whole point. The fact that this means that it works outside
Emacs is a critical feature for many data preservation use cases.

Enough for now. Best!
Tom

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Nicolas Goaziou]

Hello,

Daniel Nemenyi  writes:

> I'm finding myself stuck in the `HELM Org Cite Insert` buffer that
> lists possible citations after calling org-cite-insert using Helm.
> After selecting a reference I am prompted to select more, and there
> isn't an obvious way to say, 'Thanks org-ref I'm done, kill this
> minibuffer and insert the refs I have chosen.'

The prompt displays : "" to exit, which means you have to select the
empty value to exit. How you do select that value depends on the
completion UI.

I admit it is not particularly clear. Maybe we should spell out the
"empty value" part of the prompt.

Regards,
-- 
Nicolas Goaziou

incorrect indentation of new item inserted with capture template

[Ian Garmaise]

I have had this problem for several months.

I keep a daily journal.  Each morning I add a new entry in a journal file
using a capture template.  The journal file is always loaded.
On some occasions the indentation of the new entry is incorrect.

Here's an example of incorrect indentation:

*** 2021-12-05 Sunday

- item 1
- item 2

* 2021-12-06 Monday

What I usually do is undo the insertion and reissue the command.
This always works.

I had thought this might have been due to a mixed org installation, but
recently, I deleted org and reinstalled from org elpa with emacs -q

I have no other current issues.
This is the capture template:

 ("j" "Journal entry" plain
  (file+olp+datetree "~/Dropbox/org/journal.org")
  "%i\n%?\n" :time-prompt 1 :jump-to-captured 1)

I am happy to do any other testing that is needed.

Running on Windows 10


Emacs  : GNU Emacs 27.2 (build 1, i686-w64-mingw32)
 of 2021-03-26
Package: Org mode version 9.5 (9.5-g0a86ad @
c:/users/ian/.emacs.d/elpa/org-9.5/)

current state:
==
(setq
 org-link-abbrev-alist '(("gmail" . "
https://mail.google.com/mail/?view=cm=1=%s;))
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-babel-load-languages '((emacs-lisp . t) (latex . t) (dot . t) (org .
t) (plantuml . t))
 org-agenda-time-grid '((daily today require-timed) (600 800 1000 1200 1400
1600 1800 2000) ".."
"")
 org-babel-results-keyword "results"
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-html-format-headline-function
'org-html-format-headline-default-function
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-capture-templates '(("z" "Toefl school entry" entry
 (file+olp "~/Dropbox/org/nowtutoradmin.org" "Tasks (billable)"
  "Contact schoools, consultants re B2B service" "Toefl Schools in NYC")
 "*** %^{School}\n:PROPERTIES\n:web_site: %^{web site}\n:Email_address:
%^{email address}\n:Gmail_link: [[gmail:%\\3]]\n:FirstName: %^{first
name}\n:LastName: %^{last name}\n:Position: %^{position}\n:datecreated:
%u\n:END\n" :jump-to-captured 1)
("n" "Candidate entry" entry
 (file+olp "~/Dropbox/org/nowtutoradmin.org" "datastores" "candidates")
 "** %^{Candidate} %^g\n:PROPERTIES:\n:Position: %^{Select
position|Portuguese Voice|In-China online}\n:Status: \n:Email_address:
[[gmail:%^{email
address}]]\n:Pronunciation_test_id:\n:LinkedInAddress:\n:ScreeningResult:\n:Datecreated:
%u\n:Skype:
\n:Ranking:\n:Video_url:\n:University_grad:\n:Certified:\n:Years_of_experience:\n:Open_to_onsite:\n:Resume_location:\n:Resume_link:\n:Citizenship:\n:Country:\n:END:\n***
%\\1   :sendScreener:\nDEADLINE:
%(org-insert-time-stamp (org-read-date nil t \"+3\"))\n" :jump-to-captured
1)
("s" "Submission entry" entry
 (file+olp "~/Dropbox/org/nowtutoradmin.org" "datastores" "submissions")
 "** TOSUBMIT %^{Client|Aston|Chengxun|Daqing EF|EF Xuzhou|Jing|Lin
Qiu|Micro-Language|Smilekid|Super Small Translation|Wowtalk}
%a\n:PROPERTIES:\n:Client: %\\1\n:Candidate: %a\n:Datecreated: %U\n:END:\n"
:jump-to-captured 1)
("j" "Journal entry" plain (file+olp+datetree "~/Dropbox/org/journal.org")
"%i\n%?\n"
 :time-prompt 1 :jump-to-captured 1)
("m" "meeting log entry" plain
 (file+olp+datetree "~/Dropbox/org/nowtutoradmin.org" "work log") "\n\n%?"
:clock-in 1
 :empty-lines 1 :jump-to-captured 1)
("w" "Web site" entry (file "") "* %a :website:\n\n%U %?\n\n%:initial")
("p" "Protocol" entry (file+headline (\, (concat org-directory "notes.org"))
"Inbox")
 "* %^{Title}\nSource: %u, %c\n #+BEGIN_QUOTE\n%i\n#+END_QUOTE\n\n\n%?")
("L" "Protocol Link" entry (file+headline (\, "~/Dropbox/org/inbox.org")
"Web captures")
 "* %? [[%:link][%(transform-square-brackets-to-round-ones
\"%:description\")]]\nCaptured On: %U")
("g" "Goals")
("ge" "Epic goals" entry (file+olp buffer-file-name "Goals" "Epic goals")
 (file "~/Dropbox/org/tpl-goal.txt") :empty-lines-after 1)
("gl" "Long term goal (2-5 years from now)" entry
 (file+olp buffer-file-name "Goals" "Long term goals")
 (file "~/Dropbox/org/tpl-goal.txt") :empty-lines-after 1)
("gm" "Medium term goal (6 months up to 2 years)" entry
 (file+olp buffer-file-name "Goals" "Medium term goals")
 (file "~/Dropbox/org/tpl-goal.txt") :empty-lines-after 1)
("gs" "Short term goals (next 6 months)" entry
 (file+olp buffer-file-name "Goals" "Short term goals")
 (file "~/Dropbox/org/tpl-goal.txt") :empty-lines-after 1)
)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
 org-optimize-window-after-visibility-change)
 org-clock-report-include-clocking-task t
 org-link-from-user-regexp "\\"
 org-log-into-drawer t
 org-babel-tangle-lang-exts '(("latex" . "tex") ("emacs-lisp" . "el")
("elisp" . "el"))
 org-directory "~/Dropbox/org"
 org-clock-sound "/program files/itunes/itunes.resources/complete.wav"
 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Juan Manuel Macías writes:

> I would suggest, however, not to use the term 'italics [...blah blah...]'

Sorry for the noise! I think I messed myself up...

Naturally, 'italic' (or 'bold') is required: (italic () \"inter\")

Best regards,

Juan Manuel 

Re: On zero width spaces and Org syntax

[Greg Minshall]

Robert,

> Thereʼs no need to modify Emacs: see
> `glyphless-char-display-control'. ZWS falls under 'format-control'.

very nice.  thanks!

cheers, Greg

Re: On zero width spaces and Org syntax

[Robert Pluim]

> On Sat, 04 Dec 2021 07:43:35 +0100, Marcin Borkowski  
> said:
Marcin> 2. We modify Emacs itself to somehow highlight the ZWS.  There is 
(kind
Marcin> of) a precedent – a no-breaking space is already fontified with
Marcin> =nobreak-space= face.  At the very least, make whitespace-mode 
somehow
Marcin> show ZWSs (which it doesn't now, and I'd probably say it's a bug).

Thereʼs no need to modify Emacs: see
`glyphless-char-display-control'. ZWS falls under 'format-control'.

Robert
-- 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Max Nikulin writes:

> John, thank you for the reminding me of Juan Manuel's idea that
> everything missed in Org may be polyfilled (ab)using links.
> It is enough for proof of concept, special markers may be introduced
> later. After some time spent exercising in monkey-typing,
> I have got some code that illustrates my idea.
>
> So the goal is to mitigate demand to extend current syntax.
> While simple cases should be easy,
> special cases should not be impossible.
>
> - Raw AST snippets should be processed without ~eval~ to give
>other tools such as =pandoc= a chance to support the feature.
>If you desperately need ~eval~ then you can use source blocks.
> - The idea is to use existing backends by passing structures
>similar to ones generated by ~org-element~ parser.
> - I would prefer to avoid "@@" for link prefix since such sequences
>are already a part of Org syntax. In the following example
>export snippet is preliminary terminated by such link:
>
>#+begin_src elisp :results pp
>  (org-element-parse-secondary-string
>   "@@latex:[[@@:(italics \"i\")]]@@"
>   (org-element-restriction 'paragraph))
>#+end_src
>
>
>#+RESULTS:
>: ((export-snippet
>:   (:back-end "latex" :value "[[" :begin 1 :end 13 :post-blank 0 
> :parent #0))
>:  #(":(italics \"i\")]]@@" 0 18
>:(:parent #0)))
>
> Let's take some link prefix that makes it clear that the proposal
> is a draft and a sane variant will be chosen later when agreement
> concerning details of such feature is achieved. Till that moment
> it is named "orgia".
>
> #+begin_src elisp :results silent
>(defun orgia-export (path desc backend)
>  (if (not (eq ?\( (aref path 0)))
>   path
>(let ((tree (read path))
>   (info (org-export-get-environment backend nil nil)))
>   (org-no-properties
>(org-export-data-with-backend tree backend info)
>
>(org-link-set-parameters
> "orgia"
> :export #'orgia-export)
> #+end_src
>
>
> Either [[orgia:("inter" (bold () "word"))]]
> or 
> links may be used. Certainly plain text may be outside:
>
> #+begin_src elisp
>(org-export-string-as "A word" 'html t)
> #+end_src
>
> #+RESULTS:
> : 
> : A interword
>
> - Error handling is required.
> - Elements (blocks) should be considered as an error
>in object (inline) context.
> - Passed tree should be preprocessed to glue strings split to
>avoid interpreting them as terminating outer construct or link itself
>(=]]= =][= should be ="]" "]"= ="]" "["= inside bracket links).
>It is especially important for property values.
> - For convenience =parse= element may be added to parse a string
>accordingly to Org markup.
> - There should be a similar element (block-level markup structure).
> - Symbols and structures used by ~org-element~ becomes a part of
>public API, but they are already are since they are used
>by export backends.
> - ~org-cite~ is likely will be a problem.

Hi Maxim,

I understand that with this method the emphases could be nested, which
it seems also very productive. I like it.

I would suggest, however, not to use the term 'italics', since is a
'typographic' term, but a term that is agnostic of format and
typography, something like as 'emphasis' or 'emph'. For example, in a
format agnostic environment like Org, which is concerned only with
structure, an emphasis is always an emphasis. But in a typographic
environment that emphasis may or may not be be in italics. That is why
in LaTeX you can write constructions like:

#+begin_src latex
\emph{The Making Off of \emph{Star Wars}}
#+end_src

In this context 'Star Wars' would appear in upright font. Naturally,
these things are only possible in LaTeX, but it's nice to keep in Org a
typographic agnosticism.

Anyway, I find all this very interesting as proof of concept, although
in my workflow I prefer to use macros for these types of scenarios (yes,
a rare case where I don't use links! :-D):

#+begin_src emacs-lisp
  (defun my-macro-emph (arg)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
   (concat "@@latex:\\emph{@@" arg "@@latex:}@@"))
  ((org-export-derived-backend-p org-export-current-backend 'html)
   (concat "@@html:@@" arg "@@html:@@"))
  ((org-export-derived-backend-p org-export-current-backend 'odt)
   (concat "@@odt:@@" arg 
"@@odt:@@"

  (setq org-export-global-macros
'(("emph" . "(eval (my-macro-emph $1))")))
#+end_src

{{{emph(The Making Off of {{{emph(Star Wars)}}})}}}

Best regards,

Juan Manuel 

Re: Handling conversion of fields with spaces to tables

[Eric S Fraga]

On Monday,  6 Dec 2021 at 15:43, Loris Bennett wrote:
> That's solves the problem of the field being split, but gives me the new
> problem that the output is no longer a table :-)

Ah, yes, sorry: you need to have each line of the output start with a
"|" as well.  If your external script can do that, it should work.

As in:

  #+BEGIN_SRC sh :results output raw
  echo "|marie|Curie|123"
  echo "|louis|De Broglie|456"
  #+END_SRC

  #+RESULTS:
  | marie | Curie  | 123 |
  | louis | De Broglie | 456 |

-- 
: Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [BUG] Orgmode error prompted to submit [9.6 (9.6-??-27edae8 @ /home/chris/.emacs.d/.local/straight/build-27.2/org/)]

[Ihor Radchenko]

"christopher.pingitore"  writes:

> Apologies for delay, I have not been able to reproduce the error message on 
> my desktop or my laptop.
> If you would like me to do anything additional please let me know. 

Just let us know and share the warning text if you see the same or
similar warning again. This warning is our try to debug rare issues with
a complex asynchronous caching code we have enabled recently. We need
help from users like you to make sure that things are stable.

Thank you!

Best regards,
Ihor

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Hi Greg,

Greg Minshall writes:

> i hope we don't adopt such an "official policy" regarding discussions on
> this list.  i don't think we've had any problems where non-FSF/GNU
> topics have somehow swamped our discussions.

Not that I want to put on a censor hat, far from it :-). But this is
still an 'official' list. It's not reddit or anything like that. I think
it is necessary for the user to know what to expect here and what not to
expect. And I think there is a border between offtopic and explicitly
discussing extending Org beyond its natural limits or even flirting with
applications and software that do not respect user freedom and are
outside of GNU ethics and philosophy. And for the record, I am not
talking about Ihor's specific proposals in this thread --- which, as I
have already said, seems to me to be a commendable conciliatory effort,
although I do not share some points--- but rather from the previous
debate on the "new" name of the Org syntax, and other such things. I
think things like the 'orgdown' topic, which are not productive here,
should have their own place and forums outside here.

Best regards,

Juan Manuel 

Re: Handling conversion of fields with spaces to tables

[Loris Bennett]

Hi Eric,

Eric S Fraga  writes:

> This might work for you:
>
>   #+BEGIN_SRC sh :results output raw

That's solves the problem of the field being split, but gives me the new
problem that the output is no longer a table :-)

To elaborate: My goal is to combine this output with data from another
table to create a third table.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 9:33 AM Daniel Nemenyi  wrote:
> Apologies, I did ('Thanks org-ref I'm done...'), slip of the tongue.

Oh, I missed that; sorry John.

> Could have a go though if someone could give me a pointer? But if this is 
> left to the user, perhaps we should include a line in the documentation 
> telling them?

The completion UIs have different keybindings for this. What should
the documentation say?

Bruce

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

[Ihor Radchenko]

Kaushal Modi  writes:

> FWIW, the tests runs in about the same time for me.
>
> Running 1 tests (2021-12-06 08:59:31-0500, selector
> ‘"^test-org-cite/adjust-note"’)
>passed  1/1  test-org-cite/adjust-note (1.333928 sec)
>
> I just rebuild Org from main branch and I am on emacs-28 branch built last
> Friday:

Thanks for providing the extra data point. I did more research on my
system and figured that the latest problem on my side is by bad. I was
playing with data structure used to store org-element-cache and the
slowdown was a side effect of breaking change in org-persist format
(elisp reader did extremely poorly with the new datastructure).

I confirm that the slowness is resolved on clean system.

Best,
Ihor

Re: Handling conversion of fields with spaces to tables

[Eric S Fraga]

This might work for you:

  #+BEGIN_SRC sh :results output raw


-- 
: Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Daniel Nemenyi]

Bruce D'Arcus  wrote (on Mon 06 Dec 2021 13:09):

> Presumably you're using the default "basic" org-cite-insert-processor?

Yes, am indeed. My only customization is org-cite-global-bibliography.

> Perhaps you could customize the keybinding for exiting to get the behavior 
> you want?

Could have a go though if someone could give me a pointer? But if this is left 
to the user, perhaps we should include a line in the documentation telling them?

Just to confirm, all of this is in helm; no ivy or anything.

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Daniel Nemenyi]

Bruce D'Arcus  wrote (on Mon 06 Dec 2021 14:21):

> Certainly not, but I don't believe anyone mentioned org-ref in this thread?

Apologies, I did ('Thanks org-ref I'm done...'), slip of the tongue. I meant 
org-cite.

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 8:51 AM John Kitchin  wrote:

> org-ref should not get any credit for this.

Certainly not, but I don't believe anyone mentioned org-ref in this thread?

Bruce

Handling conversion of fields with spaces to tables

[Loris Bennett]

Hi,

I have a script which I call on a remote server which produces
pipe-separated data like:

  marie|Curie|123
  louis|De Broglie|456

However, when I output this to an org table, the field with a space gets
split into two cells in the result.

The same effect can be seen with the following:  

  #+BEGIN_SRC sh 
  echo "marie|Curie|123"
  echo "louis|De Broglie|456"
  #+END_SRC

  #+RESULTS:
  | marie | Curie | 123 | |
  | louis | De| Broglie | 456 |

What's the best way of dealing with this situation?

Cheers,

Loris

Emacs 26.1, Org 9.4.6

-- 
This signature is currently under construction.

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

[Ihor Radchenko]

Michael Dauer  writes:

> Shouldn't be org-export-resolve-fuzzy-link the relevant function, at least
> for my use case?
>
> But there it looks like it is searching through all elements including
> inlinetasks, which is in org-element-all-elements:
> (append pseudo-types '(target) org-element-all-elements)

Maybe. Further it also calls org-export-search-cells, which does not
consider inlinetasks even if they are matched.

Best,
Ihor

[BUG] Manual says +2h works for date entry, but it doesn't

[Robert Nikander]

Hi,

The manual here: https://orgmode.org/manual/The-date_002ftime-prompt.html

says that you can use syntax like `+2h` when entering timestamps. It doesn’t 
seem to work, but `+2d` does. Is the manual simply out of sync with the
implementation?


Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 
Version 10.14.6 (Build 18G95))
 of 2021-11-18
Package: Org mode version 9.5.1 (9.5.1-g36086a @ 
/Users/rob/.emacs.d/elpa/org-9.5.1/)

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

[Kaushal Modi]

On Sun, Dec 5, 2021 at 4:12 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Ihor Radchenko  writes:
>
> > Sorry, but tests are still slow for me after the update.
> > If I run the test from inside Emacs with ert, things got better, but
> > make BTEST_RE="^test-org-cite/adjust-note" test
> > still takes 12sec.
>
> I cannot reproduce it. The test went down from 4.5s to 1.5s. I am using
> Emacs 27.2.
>

Ihor,

FWIW, the tests runs in about the same time for me.

Running 1 tests (2021-12-06 08:59:31-0500, selector
‘"^test-org-cite/adjust-note"’)
   passed  1/1  test-org-cite/adjust-note (1.333928 sec)

I just rebuild Org from main branch and I am on emacs-28 branch built last
Friday:

Emacs version: GNU Emacs 28.0.90 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12)
 of 2021-12-03, built using commit 7282e492d5c3ed8c856d92a121d143f6a70db244.

Maybe strace would help identify a disk IO issue if any?

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 8:09 AM Bruce D'Arcus  wrote:

> Perhaps you could customize the keybinding for exiting to get the
> behavior you want?

Or perhaps a better solution is for someone to write an
insert-processor for helm-bibtex.

It's not hard to write them.

Bruce

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

Hi Nicolas,

I have added few tests in the updated patch pasted in this email.
I have made the tests for (call-interactive #'default-indent-new-line)
because that the interactive function M-j is bound to by default.

Can you please review and commit it? The machine I am on right now does not
allow external ssh access.



>From de607dff518eaa91149ff1aa8c255f67fb6ee887 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.
* testing/lisp/test-org.el (test-org/default-indent-new-line): Add
tests for M-j behavior when point is inside or outside an Org comment.

This fixes the `M-j' binding issue reported by Richard Lawrence in
.
---
 lisp/org.el  | 17 ++---
 testing/lisp/test-org.el | 19 +++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function ( soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 056ea7d87..de4ac7ea9 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1200,6 +1200,25 @@
 (org-indent-region (point-min) (point-max))
 (buffer-string)

+(ert-deftest test-org/default-indent-new-line ()
+  "Test behavior of default binding `M-j'."
+  ;; Calling `M-j' when point is not in an Org comment:
+  (should
+   (equal "* Some heading\n"
+  (org-test-with-temp-text "* Some heading"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  ;; Calling `M-j' when point is in an Org comment:
+  (should
+   (equal "# Some Org comment\n# "
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string
+  (should
+   (equal "# Some Org\n# comment"
+  (org-test-with-temp-text "# Some Org comment"
+   (call-interactively #'default-indent-new-line)
+   (buffer-string)


 ;;; Editing
-- 
2.34.0





--
Kaushal Modi


On Mon, Dec 6, 2021 at 8:17 AM Richard Lawrence <
richard.lawre...@uni-tuebingen.de> wrote:

> Kaushal Modi  writes:
>
> > On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:
> >
> >> Given that Nicholas cannot remember the reason for the original function
> >> and suspects it was meant to be an internal only function, I think this
> >> patch is probably the best way forward and should be applied.
> >
> > Thanks. Nicolas asked me to add tests for this patch. But I need to look
> > into how to add tests for behavior of bindings. Need to add tests for M-j
> > binding behavior when cursor is within a comment or outside.
>
> FWIW I have been running the equivalent of Kaushal's patch (I just
> removed the local binding of comment-line-break-function to
> 'org-comment-line-break-function without deleting the function) and have
> also set
>
> (debug-on-entry 'org-comment-line-break-function)
>
> I've been running this for at least a week with no issues, and have
> never been dropped into the debugger. So at least 

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[John Kitchin]

org-ref should not get any credit for this. That is a feature of the built
in org-cite library, which uses completing-read for that behavior.
completing-read is only for reading one thing at a time, and org-cite works
around that in a way that leads to the behavior you see.

It looks like helm (if you use helm-mode), but it is actually the helm
version of completing read, and not a helm selection command.

Other completion backends use different bindings, e.g. ivy uses C-M-j I
think.

John

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



On Mon, Dec 6, 2021 at 7:57 AM Daniel Nemenyi  wrote:

>
> Hello,
>
> I'm finding myself stuck in the `HELM Org Cite Insert` buffer that lists
> possible citations after calling org-cite-insert using Helm. After
> selecting a reference I am prompted to select more, and there isn't an
> obvious way to say, 'Thanks org-ref I'm done, kill this minibuffer and
> insert the refs I have chosen.'
>
> I was eventually told on Stack Overflow that M-RET does the job, but I
> would have expected either the first option in the HELM buffer to do this,
> or else there to be an option in the HELM Select Action list?
>
> Thanks!
> Daniel
>
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.24, cairo version 1.16.0)
> Package: Org mode version 9.5.1 (9.5.1-g36086a @
> /home/dan/.emacs.d/elpa/org-9.5.1/). Helm (20211205.)
>
>

Re: [PATCH] Fix org-comment-line-break-function

[Richard Lawrence]

Kaushal Modi  writes:

> On Sat, Dec 4, 2021, 5:25 PM Tim Cross  wrote:
>
>> Given that Nicholas cannot remember the reason for the original function
>> and suspects it was meant to be an internal only function, I think this
>> patch is probably the best way forward and should be applied.
>
> Thanks. Nicolas asked me to add tests for this patch. But I need to look
> into how to add tests for behavior of bindings. Need to add tests for M-j
> binding behavior when cursor is within a comment or outside.

FWIW I have been running the equivalent of Kaushal's patch (I just
removed the local binding of comment-line-break-function to
'org-comment-line-break-function without deleting the function) and have
also set

(debug-on-entry 'org-comment-line-break-function)

I've been running this for at least a week with no issues, and have
never been dropped into the debugger. So at least the testing through my
normal work indicates there are no problems with the patch.

-- 
Best,
Richard

From macros to elisp programming?

[Ypo]

Hi

I am able to make macros, but I think I am far away from Lisp programming.

Is there a path to go from macros to elisp programming? For example, the 
last macro I've made is for transforming the name of some headlines, 
adding in front of them a part from the previous headline. This is the 
elisp code of the macro:


#+BEGIN_SRC
(fset 'SanzTema5
   (kmacro-lambda-form [?\C-a ?\M-f ?\M-b ?\C-  ?\M-f ?\M-f ?\M-f ?\M-f 
?\M-f ?\M-f ?\M-f ?\M-f ?\M-f ?\M-w ?\C-c ?\C-n ?\C-a ?\M-f ?\M-b ?\C-y 
?  ?- ?  ?\C-e ?\M-b ?\M-f ?\"] 0 "%d"))

#+END_SRC


Using that code, from these headlines:

*** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez 
Balaña" (pp. 95-118)

 INTRODUCCIÓN

I get modified the second headline:

*** Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos, Menéndez 
Balaña" (pp. 95-118)

 Sanz Aparicio et al. (2019) "5 Los Motivos Adquiridos - INTRODUCCIÓN"


Are macros near to elisp programming or they are two different worlds?

Ypo

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

[Michael Dauer]

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

Shouldn't be org-export-resolve-fuzzy-link the relevant function, at least
for my use case?

But there it looks like it is searching through all elements including
inlinetasks, which is in org-element-all-elements:
(append pseudo-types '(target) org-element-all-elements)

Am Sa., 4. Dez. 2021 um 04:18 Uhr schrieb Ihor Radchenko :

> 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: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

Presumably you're using the default "basic" org-cite-insert-processor?

If yes, that's just how it's designed, using completing-read.

Perhaps you could customize the keybinding for exiting to get the
behavior you want?

On Mon, Dec 6, 2021 at 7:56 AM Daniel Nemenyi  wrote:
>
>
> Hello,
>
> I'm finding myself stuck in the `HELM Org Cite Insert` buffer that lists 
> possible citations after calling org-cite-insert using Helm. After selecting 
> a reference I am prompted to select more, and there isn't an obvious way to 
> say, 'Thanks org-ref I'm done, kill this minibuffer and insert the refs I 
> have chosen.'
>
> I was eventually told on Stack Overflow that M-RET does the job, but I would 
> have expected either the first option in the HELM buffer to do this, or else 
> there to be an option in the HELM Select Action list?
>
> Thanks!
> Daniel
>
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
> cairo version 1.16.0)
> Package: Org mode version 9.5.1 (9.5.1-g36086a @ 
> /home/dan/.emacs.d/elpa/org-9.5.1/). Helm (20211205.)
>

Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Daniel Nemenyi]

Hello,

I'm finding myself stuck in the `HELM Org Cite Insert` buffer that lists 
possible citations after calling org-cite-insert using Helm. After selecting a 
reference I am prompted to select more, and there isn't an obvious way to say, 
'Thanks org-ref I'm done, kill this minibuffer and insert the refs I have 
chosen.'

I was eventually told on Stack Overflow that M-RET does the job, but I would 
have expected either the first option in the HELM buffer to do this, or else 
there to be an option in the HELM Select Action list?

Thanks!
Daniel

Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
Package: Org mode version 9.5.1 (9.5.1-g36086a @ 
/home/dan/.emacs.d/elpa/org-9.5.1/). Helm (20211205.)

Re: On zero width spaces and Org syntax

[Eric S Fraga]

On Saturday,  4 Dec 2021 at 08:48, Tim Cross wrote:
> My vote is to simply maintain the status quo. 

A very strong +1 on this.  Org has enough /escape mechanisms/, as you
call them, to cater for special cases, and these include @@...@@, babel,
and filters, amongst others.  The simplicity of org is a major
advantage.

-- 
: Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Max Nikulin]

On 05/12/2021 14:35, Ihor Radchenko wrote:


The recent spike of discussions following Karl's presentation in
Emacsconf 2021 revealed a lot of controversy among Org and Emacs
enthusiasts. Yet, Karl named a number of very real problems surrounding
Org mode usage outside Emacs.

WDYT?


Ihor, I like your ideas and, I hope, they may be expressed in a way that 
does not cause such irritation and negative reaction.


After all, I suppose, nobody is regretting that it is possible to 
convert text from a set of formats to Org using pandoc which it is not a 
part of Emacs.

Raw Org AST snippets for "impossible" markup

[Max Nikulin]

On 05/12/2021 01:37, John Kitchin wrote:
Along these lines (and combining the s-exp suggestion from Max) , you 
can achieve something like this with links.


#+BEGIN_SRC emacs-lisp :results silent
(defun italic (s)
   (pcase backend ;; lexical
     ('latex (format "{\\textit{%s}}" s))
     ('html (format "%s" s))
     (_ s)))

(defun @@-export (path desc backend)
   (eval `(concat ,@(read path

(org-link-set-parameters
  "@@"
  :export #'@@-export)
#+END_SRC


John, thank you for the reminding me of Juan Manuel's idea that
everything missed in Org may be polyfilled (ab)using links.
It is enough for proof of concept, special markers may be introduced
later. After some time spent exercising in monkey-typing,
I have got some code that illustrates my idea.

So the goal is to mitigate demand to extend current syntax.
While simple cases should be easy,
special cases should not be impossible.

- Raw AST snippets should be processed without ~eval~ to give
  other tools such as =pandoc= a chance to support the feature.
  If you desperately need ~eval~ then you can use source blocks.
- The idea is to use existing backends by passing structures
  similar to ones generated by ~org-element~ parser.
- I would prefer to avoid "@@" for link prefix since such sequences
  are already a part of Org syntax. In the following example
  export snippet is preliminary terminated by such link:

  #+begin_src elisp :results pp
(org-element-parse-secondary-string
 "@@latex:[[@@:(italics \"i\")]]@@"
 (org-element-restriction 'paragraph))
  #+end_src

  #+RESULTS:
  : ((export-snippet
  :   (:back-end "latex" :value "[[" :begin 1 :end 13 :post-blank 0 
:parent #0))

  :  #(":(italics \"i\")]]@@" 0 18
  :(:parent #0)))

Let's take some link prefix that makes it clear that the proposal
is a draft and a sane variant will be chosen later when agreement
concerning details of such feature is achieved. Till that moment
it is named "orgia".

#+begin_src elisp :results silent
  (defun orgia-export (path desc backend)
(if (not (eq ?\( (aref path 0)))
path
  (let ((tree (read path))
(info (org-export-get-environment backend nil nil)))
(org-no-properties
 (org-export-data-with-backend tree backend info)

  (org-link-set-parameters
   "orgia"
   :export #'orgia-export)
#+end_src

Either [[orgia:("inter" (bold () "word"))]]
or 
links may be used. Certainly plain text may be outside:

#+begin_src elisp
  (org-export-string-as "A word" 'html t)
#+end_src

#+RESULTS:
: 
: A interword

- Error handling is required.
- Elements (blocks) should be considered as an error
  in object (inline) context.
- Passed tree should be preprocessed to glue strings split to
  avoid interpreting them as terminating outer construct or link itself
  (=]]= =][= should be ="]" "]"= ="]" "["= inside bracket links).
  It is especially important for property values.
- For convenience =parse= element may be added to parse a string
  accordingly to Org markup.
- There should be a similar element (block-level markup structure).
- Symbols and structures used by ~org-element~ becomes a part of
  public API, but they are already are since they are used
  by export backends.
- ~org-cite~ is likely will be a problem.

Re: Org-syntax: Intra-word markup

[Denis Maier]

Hi Tom

Am 04.12.2021 um 18:53 schrieb Tom Gillespie:

Hi all,
 After a bunch of rambling (see below if interested), I think I have
a solution that should work for everyone. The key realization is that
what we really want is the ability to have a "parse me separately"
type of syntax. This meets the intra-word syntax needs and might
meet some other needs as well.

The solution is to make @@org:...@@ "parse me separately"
block! It nearly works that way already too! To minimize typing
we could have @@:...@@ the empty type default to org.

This seems like a winner to me. The syntax for it already exists
and won't conflict. It requires relatively minimal additional typing
the implication is clear, and there are other places where such
behavior could be useful.

This syntax seems like a winner to me
@@org:/hello/@@world
@@:/hello/@@world

You can also do things like
#+begin_src org
I want a number in this number@@org:src_elisp{(+ 1 2)}@@word!
#+end_src

Which would render to
#+begin_src org
I want a number in this number3word!
#+end_src

Thoughts?

Best!
Tom



Thanks for the suggestion. I think that sounds like a good idea. Of 
course not as terse as the asciidoc inspired suggestion, but entirely 
appropriate for a case like this one! I also like that there might be 
other cases where case might be handy.


Best,
Denis

Re: Org-syntax: Intra-word markup

[Max Nikulin]

On 05/12/2021 04:48, Tom Gillespie wrote:

Since org is a valid export backend though, perhaps this behaviour should be
reserved for @@:…@@, i.e. no export backend, which I think semantically fits
fairly nicely.


This ends up being even more convenient than I initially realized.


It is a bright idea. The only drawback I see is that it is impossible to 
put new "@@:@@" fragment inside export snippet "@@latex:some 
@@:special@@thing@@ or vice versa.

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Greg Minshall]

Ihor,

> Search result is just an entrance for users to be curious about the
> new beast of "Org mode". The website front page is the means to make
> users try. And the Org mode itself is the way to make users fall in
> love with Org in one way or another (even unrelated to Emacs [at least
> initially]).

i *do* agree that our hope is that people will see the great benefit of,
and use, "emacs org mode".  however, along with others, i don't want
people to fall in love with "org mode" itself, but, rather with the full
"running org mode with emacs".

at the same time, i have a desire that "the general public" will be able
to "work with" "emacs org mode" *files*; i.e., treat them as somewhat
more than a collection of octets.  *how much* more is tbd; i sort of saw
Karl Voit's proposal of "level 1", ..., as being an attempt to define
ways of extracting (limited) utility from an org mode file.

cheers, Greg

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Greg Minshall]

Juan Manuel (and, Tim, i think),

> On the other hand, we must not forget that Org, as part of Emacs, is
> part of GNU, and this is a mailing list from the GNU project. I think
> everything related to the (possible) extension of GNU Org Mode outside
> of GNU Emacs (even in software incompatible with the ethics and
> philosophy of the GNU project) should be considered offtopic here and
> be discussed in other forums. Otherwise it would only create confusion
> among users.

i hope we don't adopt such an "official policy" regarding discussions on
this list.  i don't think we've had any problems where non-FSF/GNU
topics have somehow swamped our discussions.

cheers, Greg

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

[Greg Minshall]

sigh.

the following is pretty much a lie.  apologies.

> =org-babel-ref-resolve= is convenient to use (as you provide a REF,
> rather than create a [temp] buffer, visit the file, whatever).

the creating a temp buffer, visiting the file, are *not* provided by
=org-babel-ref-resolve=.

cheers (or, cheerless's :), Greg