Extraneous blank lines in when attempting to export org tables

[Rohit Patnaik]

Hello,

I'm currently working on an exporter that will allow org-mode to export to
PMWiki markdown (https://github.com/quanticle/ox-pmwiki/), and I'm running into
a problem when writing the export code to handle tables. When exporting table
rows, I'm getting extraneous blank lines between table rows.

My export code for tables is as follows:

#+begin_src elisp
(defun org-pmwiki-table-cell (table-cell contents info)
  "Transcode a TABLE-CELL from org to pmwiki format. CONTENTS is nil. INFO is a
plist used as a communications channel."
  (let ((cell-alignment (org-export-table-cell-alignment table-cell info)))
(cond ((eq cell-alignment 'left) (format "%s  ||" contents))
  ((eq cell-alignment 'right) (format "  %s||" contents))
  ((eq cell-alignment 'center) (format " %s ||" contents)

(defun org-pmwiki-table-row (table-row contents info)
  "Transcode a TABLE-ROW element from org to pmwiki format. CONTENTS is the
contents of the row. INFO is a plist used as a communications channel."
  (format "||%s" contents))

(defun org-pmwiki-table (table contents info)
  "Transcode a TABLE from org to pmwiki format. TABLE is the table element
itself. CONTENTS is the contents of the table. INFO is a plist holding
contextual information."
  contents)
#+end_src

When I run this code on the following table:
#+begin_src org
| Col 1 | Col 2 |  Col 3 |
||| |
| left aligned cell | centered cell | right aligned cell |
#+end_src

I expect to see the following output:

#+begin_example
||Col 1  || Col 2 ||  Col 3||
||left aligned cell  || centered cell ||  right aligned cell||
#+end_example

However, the actual output generated by the code is:

#+begin_example
||Col 1  || Col 2 ||  Col 3||

||left aligned cell  || centered cell ||  right aligned cell||
#+end_example

The contents of each cell are formatted correctly, but there's an additional
newline between the two rows. How do I prevent this newline from being added?

Thanks,
Rohit Patnaik

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

[Mark Barton]

> On Feb 17, 2024, at 5:33 AM, Ihor Radchenko  wrote:
> 
> WDYT?
+1

I use the curly braces since I often use underscores for other reasons. There 
would be no impact to me and this is the first I ever heard that parentheses 
would work. 

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

[Thomas Dye]

+1

Tom

> On Feb 17, 2024, at 9:38 AM, William Denton  wrote:
> 
> On Saturday, February 17th, 2024 at 07:07, Ihor Radchenko 
>  wrote:
> 
>> I tentatively propose to remove the x^(2-i) example from the docstring
>> and mark the ^(...) syntax deprecated.
>> 
>> WDYT?
> 
> I think it's very sensible.  It's surprising ^(...) works like this, and if 
> anyone was using it (perhaps by accident) it will be easy to change when 
> necessary.
> 
> 
> Bill
> 
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
> 
> 

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

[William Denton]

On Saturday, February 17th, 2024 at 07:07, Ihor Radchenko  
wrote:

> I tentatively propose to remove the x^(2-i) example from the docstring
> and mark the ^(...) syntax deprecated.
> 
> WDYT?

I think it's very sensible.  It's surprising ^(...) works like this, and if 
anyone was using it (perhaps by accident) it will be easy to change when 
necessary.


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: nested blocks in org

[Ihor Radchenko]

[ Adding Org list back to CC; please use Reply All or wide reply to keep
  the discussion public ]

mahmood sheikh  writes:

> consider the following block
> ```
> #+begin_solution
> #+begin_src sql
>   SELECT
> CONCAT(c.first_name, ' ', c.family_name) AS name, c.customer_id,
> ...
> #+end_solution
> ```
> the src block isnt fontified by org because it is inside another block

... which is just a bug in the Org fontification code.
If you try M-: (org-element-at-point) , you will see that Org does
recognize the code block.

So ...

> can you point me in the right direction of getting org mode to recognize
> nested blocks,

Org already recognizes nested blocks using Org element parser. See
https://orgmode.org/worg/dev/org-element-api.html

> ... like code highlighting for src blocks that are within
> another special block?

See https://list.orgmode.org/87ee7c9quk.fsf@localhost/
This is something we are working in.
To get parser-aware fontification locally, you can use a function
MATCHER (as in font-lock-keywords docstring) and invoke
`org-element-at-point' there to check context.

> ... and getting org-element-map to iterate through both
> a parent and its child blocks all the same?

May you elaborate? `org-element-map' iterates through everything,
including nested parent and child blocks. What did you try?

> could modifying `org-block-regexp` to be a recursive regex be of help?

Sorry, but it is hard to see how this is related to `org-element-map'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: #6 [[bbb:OrgMeetup]] on Wed, Feb 14, 19:00 UTC+3

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> Another OrgMeetup will be scheduled on the second Wednesday of
>> February, in two weeks.
>
> Wait, ... the date of your message is "the second Wednesday of February"
> (Feb 14).  Did you mean "the *fourth* Wednesday of February" (Feb 28),
> which is "in two weeks" from Feb 14, or perhaps you meant "the second
> Wednesday of *March*" (Mar 13), which is "in four weeks and one day"
> from Feb 14?

The email you are replying to has been submitted on January 30, two
weeks before Feb 14.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: #6 [[bbb:OrgMeetup]] on Wed, Feb 14, 19:00 UTC+3

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Another OrgMeetup will be scheduled on the second Wednesday of
> February, in two weeks.

Wait, ... the date of your message is "the second Wednesday of February"
(Feb 14).  Did you mean "the *fourth* Wednesday of February" (Feb 28),
which is "in two weeks" from Feb 14, or perhaps you meant "the second
Wednesday of *March*" (Mar 13), which is "in four weeks and one day"
from Feb 14?

Rudy
-- 
"'Obvious' is all too often a synonym for 'wrong'."
--- Jeff Erickson, Algorithms, 2019

Rudolf Adamkovič  [he/him]
Studenohorská 25, 84103 Bratislava, Slovakia, European Union

Re: detangling with babel :var header entries

[Ihor Radchenko]

"Fraga, Eric"  writes:

> Can anybody suggest a workaround that allows me to incorporate a :var
> data field in a src block but still allow to tangling/detangling to work
> as it should?  I cannot think of any way and can obviously live with it
> (I just have to remember to delete the spurious version lines
> periodically...).

I also have no idea. I'm afraid that detangling can only be used in
simple cases as it is implemented now.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: nested blocks in org

[Ihor Radchenko]

mahmood sheikh  writes:

> can you point me in the right direction of getting org mode to recognize
> nested blocks, like code highlighting for src blocks that are within
> another special block?

May you please give an example of what you have in mind?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Change calling convention for when `org-link-file-path-type' is set to custom function (was: Enhancement Proposal for 'org-link-file-path-type' Behavior)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I'd like to suggest a small enhancement to the
>> 'org-link-file-path-type' option. When set to 'function', it currently
>> passes an absolute path to the user's custom function. This limits
>> flexibility as the original path input is not available to the
>> function.
>>
>> For better customization, I propose passing the raw path to the
>> function. Users needing an absolute path could use 'expand-file-name'
>> within their function.
>
> Thanks for the suggestion!
>
> This makes sense - the current approach with passing absolute path is
> indeed limiting the information passed to the custom function.
> ...
> Yet, I am starting a poll to give users who may be affected a chance to
> chime in.

No objections after 1 month.
Done, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=388ba5b5c

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Warning: The error was: (error "Invalid search bound (wrong side of point)") [9.6.15 (release_9.6.15 @ z:/emacs-i686/share/emacs/29.2/lisp/org/)]

[Ihor Radchenko]

Ypo  writes:

> Nope, I don't usually see that error.

Thanks for checking!
I did some non-trivial fixes to org-element-cache code on main that
cannot go onto the stable branch. So, I will assume that this error will
be gone in the next Org mode release.

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Warning: The error was: (error "Invalid search bound (wrong side of point)") [9.6.15 (release_9.6.15 @ z:/emacs-i686/share/emacs/29.2/lisp/org/)]

[Ypo]

Hi, Ihor

Nope, I don't usually see that error.

On 14/02/2024 15:22, Ihor Radchenko wrote:

Ypo  writes:


I got a warning, which asked to be reported. Not sure why it happened, I
think it was when I refreshed calfw calendar:

Thanks for reporting!
Do you see the same warning if you switch to Org development branch?

[DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

[Ihor Radchenko]

Ihor Radchenko  writes:

> "Tom Alexander"  writes:
>
>> Some additional things I'm noticing:
>>
>> - when using parenthesis, :use-brackets-p is nil, so they're not equivalent 
>> to curly braces.
>
> `org-element-subscript-parser' uses `org-match-substring-regexp', which
> indeed allows foo_(...). This is not documented in org-syntax.org and in
> the manual (12.3 Subscripts and Superscripts).

Inconsistent with LaTeX syntax, Org mode not only allows
x^{superscript}, but also x^(superscript) with round braces used for
grouping.

This does not seem to be documented in the manual and is only vaguely
mentioned in the `org-use-sub-superscripts' docstring in a single
example:

 x_{i^2} or   x^(2-i)braces or parenthesis do grouping.

The rest of the docstring only refers to {} or just to genetic "braces".

This situation is awkward, because such subtle inconsistency between Org
and LaTeX syntax can be very surprising.

To demonstrate, try to export the following to pdf:

# ---
Direct latex code =$foo^(bar)$= :: @@latex:$foo^(bar)$@@

Org mode markup =foo^(bar)= :: foo^(bar)
# ---

The first line will only create superscript for "(", while the second
line will make the whole "(bar)" into superscript.

-

I tentatively propose to remove the x^(2-i) example from the docstring
and mark the ^(...) syntax deprecated.

WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Table of contents position in HTML export

[Ihor Radchenko]

Ihor Radchenko  writes:

> Kodi Arfer  writes:
>
>> the table of contents appears before "text before headline", although the 
>> manual says "Org normally inserts the table of contents directly before the 
>> first headline of the file". So shouldn't it be after "text before 
>> headline"? Or is it the manual that's wrong?
>
> Confirmed.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c9fc4c03e
TOC is placed before document contents, not before first headline.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Exporting multiple #+AUTHOR keywords

[Juan Manuel Macías]

ypuntot writes:

> Is it related with AUTHOR property? 
> I am starting to add these properties to every book, and chapter of
> the book, that I study. I hope this doesn't lead to a suboptimal
> workflow. 
>
> Doesn't this work? 
>
> :PROPERTIES: 
> :AUTHOR:   García-Ael, Cristina and Pérez-Garín, Daniel and Recio
> Saboya, Patricia 
> :BTYPE:incollection 
> :BOOKTITLE: Psicología de los Grupos 
> :TITLE:Métodos y Técnicas de Investigación en Psicología de
> los Grupos. 
>
> :PUBLISHER: UNED 
>
> :ADDRESS:  C/ Bravo Murillo, 38; 28015; Madrid 
> :INSTITUTION: UNED 
> :YEAR: 2017 
> :CHAPTER:  2 
> :PAGES:49-83 
> :END: 


What we are dealing with here is the keyword #+AUTHOR or the
EXPORT_AUTHOR property (when exporting a subtree), that is, the author
of the document (see 'Export settings' in the Org Manual), not the
AUTHOR property of org-ref. Your workflow is correct.