Re: resume an interrupted enumerated list or reset the counter

[Uwe Brauer]

> Uwe Brauer  writes:

> You need an indent:

> 1. first

> 2. Second

> 3. Third

>#+begin_src
> A=7
>#+end_src

> 4.

Thanks, but what if the list itself is indented, like:

   1. first
  
   2. Second
  
   3. Third

   4. 
  #+begin_src
   A=7
  #+end_src
   4. < does not work anymore

Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: Ox-pandoc and Org-cite

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 14. Oktober 2021 schrieb Alex Fenton:
> The arrival of citation support in Org is fantastic, but it is a bit
> tricky for ox-pandoc, b/c pandoc itself has csl-based cite processing
> ability. I'd appreciate any pointers on a couple of points:

Maybe it will get easier when pandoc supports org's new citation syntax?
There's a ticket for this open: https://github.com/jgm/pandoc/issues/7329

  -quintus

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

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Max Nikulin]

On 14/10/2021 17:16, Ihor Radchenko wrote:

Marco Wahl writes:


Since org-goto in main is still broken I'll commit the fix for org-goto
which kicks out the use of the macro org-no-popups (but not the macro
itself since it's used elsewhere AFAICS.)

Max, Ihor!  If you see the necessity of refinement please keep going!


I am inclined to think that org-no-popups may still be useful to
suppress pop-up-frames.  However, no so much for pop-up-windows.  Note
that I introduced pop-up-windows let-binding in org-no-popups in place
of overriding display-buffer-alist.  However, I did not fully understand
pop-up-windows does and the current let-binding actually changes
pop-up-windows value to nil (t is the Emacs default). I think we can
simply remove pop-up-windows binding from org-no-popups. Feel free to
commit this change. I am currently working on org-element-cache and do
not spend much time on other patches.


Today I am against dropping of `org-no-popups'. Since Ihor confirmed 
that he had no particular reason to add `pop-up-windows', the minimal 
change (that should be applied to the bugfix branch)


diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 52fc09a06..5f2c29c42 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -209,7 +209,7 @@ because otherwise all these markers will point to 
nowhere."


 (defmacro org-no-popups ( body)
   "Suppress popup windows and evaluate BODY."
-  `(let (pop-up-frames pop-up-windows)
+  `(let (pop-up-frames)
  ,@body))

 ^L

I think, something should be done with `org-no-popups'. Assume a user 
who has (I have no idea concerning the goal though)


  (setq pop-up-frames t)
  (setq display-buffer-base-action
'((display-buffer-reuse-window display-buffer-pop-up-frame)
  (reusable-frames . 0)))

e.g. https://list.orgmode.org/20200503033854.GA28741@singpolyma-beefy

With "emacs -Q" and above settings completion e.g. for "C-h f" does not 
cause creation of a new frame. Org help windows appear in new frames 
though. That is why `org-no-popups' should have more code.


Minimal patch works in the cases like 
https://list.orgmode.org/87h7ij12t8.fsf@localhost and the one raised in 
this thread. I hope it will not break 
https://list.orgmode.org/orgmode/871rdtupey@joshuao.com/T/#u as well.


In the meanwhile I found the following thread on window creation in Org 
and `display-buffer' machinery (accessibility concerns were mentioned 
besides other things):

https://list.orgmode.org/87eevw7jqk@gmail.com/T/#u
Jack Kamm. [RFC PATCH] Changes to pop-up source buffers. 2020-01-18 17:33

Unfortunately info "(elisp) Displaying Buffers" 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Displaying-Buffers.html 
is a reference rather than a guide. I have not realized when 
`pop-up-frames' or its modern equivalent can be convenient. I have not 
tried Eric's setup yet.



BTW I think the name *Org Help* for the UI buffer could be better.


Do you have better ideas? Maybe something like *Org-goto Help*? If we
want to change it, we may want to do it now, before users actually use
*Org Help* name i.e. in display-buffer-alist. display-buffer-alist did
not affect *Org Help* before 399481bad, so we have low odds to break
anybody's config yet.


Are there use cases when "*Org Help*" is not specific enough and more 
than one help window should be shown simultaneously or they should be 
shown in different sides?


P.S. Example of complex window setup unrelated to Org:
info "(elisp) Frame Layouts with Side Windows"
https://www.gnu.org/software/emacs/manual/html_node/elisp/Frame-Layouts-with-Side-Windows.html

Re: resume an interrupted enumerated list or reset the counter

[Ihor Radchenko]

Uwe Brauer  writes:

> Hi 
>
> Sometimes I have the following 
>
> 1. first
>
> 2. Second
>
> 3. Third
> #+begin_src 
> A=7
> #+end_src
>
> 1. 
>
>
> So enumerated list start with a fresh counter, is there a possibility
> either to resume the list or to reset its counter?

You need an indent:

1. first

2. Second

3. Third
   #+begin_src
A=7
   #+end_src
4.

Best,
Ihor

resume an interrupted enumerated list or reset the counter

[Uwe Brauer]

Hi 

Sometimes I have the following 

1. first

2. Second

3. Third
#+begin_src 
A=7
#+end_src

1. 


So enumerated list start with a fresh counter, is there a possibility
either to resume the list or to reset its counter?

Regards

Uwe Brauer 

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Ihor Radchenko]

Marco Wahl  writes:

> Since org-goto in main is still broken I'll commit the fix for org-goto
> which kicks out the use of the macro org-no-popups (but not the macro
> itself since it's used elsewhere AFAICS.)
>
> Max, Ihor!  If you see the necessity of refinement please keep going!  

I am inclined to think that org-no-popups may still be useful to
suppress pop-up-frames.  However, no so much for pop-up-windows.  Note
that I introduced pop-up-windows let-binding in org-no-popups in place
of overriding display-buffer-alist.  However, I did not fully understand
pop-up-windows does and the current let-binding actually changes
pop-up-windows value to nil (t is the Emacs default). I think we can
simply remove pop-up-windows binding from org-no-popups. Feel free to
commit this change. I am currently working on org-element-cache and do
not spend much time on other patches.

> BTW I think the name *Org Help* for the UI buffer could be better.

Do you have better ideas? Maybe something like *Org-goto Help*? If we
want to change it, we may want to do it now, before users actually use
*Org Help* name i.e. in display-buffer-alist. display-buffer-alist did
not affect *Org Help* before 399481bad, so we have low odds to break
anybody's config yet.

Best,
Ihor

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Marco Wahl]

Thanks Eric and Max!

> On Wednesday, 13 Oct 2021 at 19:23, Max Nikulin wrote:
>> Does someone have settings that pins help buffer to particular
>> window/frame of location in a frame (e.g. bottom of "sidebar")?
>
> This is what I use, which is slightly more complex because I have a wide
> landscape monitor and a tall portrait one and want different behaviour
> in each:
>
> #+begin_src emacs-lisp
>   (defun esf/display-buffer-in-side-window (buffer alist)
> (let ((fw (/ 80.0 (frame-width
>   (display-buffer-in-side-window buffer
>  (if (> (frame-width) 120)
>  (list (cons 'window-width fw)
>'(side . left)
>'(slot . 0))
>'((window-height . 0.25)
>  (side . bottom)
>  (slot . 0))
>   (setq display-buffer-alist
> '(("^\\*Async Shell Command*" . (display-buffer-no-window))
>   ("^magit-[a-z]+: " . (esf/display-buffer-in-side-window))
>   ("\\*\\(Backtrace\\|Compile-Log\\|DICT 
> .*\\|grep\\|[Hh]elp.*\\|Messages\\|Occur\\|tex-shell\\|vc-\\(diff\\|change-log\\)\\|Warnings\\|WoMan
>  .*\\)\\*"
>(esf/display-buffer-in-side-window
> #+end_src
>
> This doesn't pin to a specific frame but does make the pop-ups appear in
> the same place always in each respectively frame.  By the way, I use
> exwm so I have one frame per monitor, full screen, generally.

Thanks for the example and the implied teaching!

I experimented with the use of display-buffer-alist and the org-goto UI.
E.g. with the config:

(defun experiment/202110141141 (buffer alist)
  (display-buffer-in-side-window
   buffer
   (list '(window-width . 23)
 '(side . right)
 '(slot . 0

(setq display-buffer-alist
  '(("\\*Org Help\\*" . (experiment/202110141141

AFAICS this has an effect for org-goto.  The user can control the
appearance of the org-goto UI.

BTW I think the name *Org Help* for the UI buffer could be better.

Since org-goto in main is still broken I'll commit the fix for org-goto
which kicks out the use of the macro org-no-popups (but not the macro
itself since it's used elsewhere AFAICS.)

Max, Ihor!  If you see the necessity of refinement please keep going!  


Best regards,
-- 
Marco

Re: New user experience ct'd: exporting citations into LaTeX (9.5)

[Leszek Wroński]

Thank you very much! For some mistaken reason I assumed this would
only point to the location of the bibliography section of the
generated file, but now I understand that it serves a double role,
specifying the .bib file too.

Thanks again!

Best regards,

Leszek.

On Wed, 13 Oct 2021 at 23:35, Bruce D'Arcus  wrote:
>
> Try adding this where you want the bibliography.
>
> #+print_bibliography:
>
> On Wed, Oct 13, 2021 at 5:27 PM Leszek Wroński  wrote:
> >
> > Guys,
> >
> > thank you very much for your responses to my previous query. (I will
> > study the ebib package more closely; as of now it does not seem to
> > work with the file fields in my Mendeley-created .bib file. (Yes, I
> > promise will stop using Mendeley.))
> >
> > I wanted to try the two LaTeX export processors mentioned in the 15.2
> > section of the manual: natbib and biblatex. My .org file has a
> > #+bibliography line specifying my .bib (which is correct, since
> > inserting citations is now working). I put both (use-package
> > oc-natbib) and (use-package oc-biblatex) in my .emacs . (I've used
> > natbib for years when writing .tex documents; I don't know biblatex.)
> >
> > The situation is as follows:
> > -- if I put #+cite_export: natbib at the beginning of my .org file,
> > then C-c C-e l L gives me a LaTeX file which does *not* specify the
> > .bib file; it has \citep{} commands where they should be, but of
> > course bibtex doesn't know what to do with them;
> > -- if I use #+cite_export: biblatex instead, then the resulting .tex
> > file does contain the \addbibresource{} line pointing to my .bib , and
> > \autocite{} commands where citations should be; however, I simply
> > cannot get this to work: Biber works alright, but eventually pdflatex
> > gives me the following error:
> >
> > --
> > ERROR: LaTeX3 Error: Mismatched LaTeX support files detected.
> >
> > --- TeX said ---
> > (LaTeX3)Loading 'l3backend-pdftex.def' aborted!
> > (LaTeX3)
> > (LaTeX3)The L3 programming layer in the LaTeX format
> > (LaTeX3)is dated 2021-01-09, but in your TeX tree the files require
> > (LaTeX3)at least 2021-02-18.
> > ---
> >
> > which I'm unable to get rid of. (This is of course not a question for
> > this group but if anyone had similar problems I'd be grateful for
> > pointers ;-);  fmtutil-sys --all and fmtutil-user --all did nothing to
> > alleviate this)
> >
> > So: I'd really like to keep using natbib and make it somehow insert
> > the information about the .bib file into the .tex when exporting. How
> > do I do that?
> >
> > Thank you again for your help!
> >
> > Best regards,
> >
> > Leszek.
> >

Ox-pandoc and Org-cite

[Alex Fenton]

Hello,

I have recently forked [1] and tidied up ox-pandoc with some fixes for 
incompatibilities that had arisen with newer versions of pandoc. I'm talking to 
MELPA people about getting this distributed.

Briefly, ox-pandoc exports an .org file to a temporary .org (so that e.g. Babel 
code is resolved) and then calls pandoc to export to any of its many supported 
formats. 

The arrival of citation support in Org is fantastic, but it is a bit tricky for 
ox-pandoc, b/c pandoc itself has csl-based cite processing ability. I'd 
appreciate any pointers on a couple of points:

1) how best to handle an file level option (BIBLIOGRAPHY) that is defined in a 
mode and in some (>9.4) versions of org itself? At the moment it's choking on 
incompatible types with 9.5, because ox-pandoc expects a string but gets a 
list. 

2) how best to allow users to pick between org citation export, pandoc citeproc 
or letting biblatex do something? At the moment, there seems no way to prevent 
citation export (passthrough) or a filter mechanism. 

Should I plan to write a org cite export handler that converts to a format that 
pandoc understands (the new Org citation format is not yet fully supported, 
though an issue [2] is filed)? 

Cheers
 alex

[1] https://github.com/a-fent/ox-pandoc
[2] https://github.com/jgm/pandoc/issues/7329

Re: org-table-blank-field key binding removal

[Bastien Guerry]

Hi Eric,

Eric Abrahamsen  writes:

> I also agree it should have had a NEWS entry (something I never
> remember)

I added a note about this on
https://orgmode.org/worg/org-contribute.html 

Thanks,

-- 
 Bastien

Re: org-table-blank-field key binding removal

[Bastien Guerry]

Hi Kyle,

thanks for the heads up!

Kyle Meyer  writes:

> Right, I agree this change should have come with a NEWS entry, though
> 0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
> is from the 9.5 release not 9.4.
>
> However, 9.5 is out, and my understanding is that released NEWS sections
> should not be substantially modified in most cases
> ().  I'll leave it to
> the author of the original change and Bastien to decide if they want to
> make an exception in this case.

I suggest we add a news entry in etc/ORG-NEWS in the bugfix branch for
the change to be advertized for 9.5.x users.

Can anyone do that?

-- 
 Bastien