Re: [PATCH] org-manual.org: Remove languages list and update worg link

[ian martins]

Attached is an updated patch that renumbers footnotes since a few footnotes
were removed with the table.

On Wed, Nov 4, 2020 at 8:39 AM ian martins  wrote:

> The language list in the manual is missing many languages.  Rather
> than trying to keep the list up to date in two places that link to
> each other, this removes the list from the manual which is updated
> less frequently.
>
> The languages page was moved in Worg to make it the index page in the
> languages directory.  This updates the link in the manual to point to
> its new location.
>
From 539afdb50e146f6eaf55d67ae5dd240d8dba6ab3 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Wed, 4 Nov 2020 08:32:12 -0500
Subject: [PATCH] org-manual.org: Remove language list and fix Worg link

* doc/org-manual.org: Remove the language list and fix the Worg link
since the languages page has moved.  Renumber footnotes.

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.  There were a few footnotes in the table, so this
also renumbers the remaining footnotes.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
---
 doc/org-manual.org | 103 +
 1 file changed, 38 insertions(+), 65 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ef2dad9ef..49b31e08d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17925,35 +17925,8 @@ code block header arguments:
 #+cindex: source code, languages
 #+cindex: code block, languages
 
-Code blocks in the following languages are supported.
-
-#+attr_texinfo: :columns 0.25 0.25 0.25 0.20
-| Language   | Identifier| Language   | Identifier   |
-|+---++--|
-| Asymptote  | =asymptote=   | Lisp   | =lisp=   |
-| Awk| =awk= | Lua| =lua=|
-| C  | =C=   | MATLAB | =matlab= |
-| C++| =C++=[fn:142] | Mscgen | =mscgen= |
-| Clojure| =clojure= | Objective Caml | =ocaml=  |
-| CSS| =css= | Octave | =octave= |
-| D  | =D=[fn:143]   | Org mode   | =org=|
-| ditaa  | =ditaa=   | Oz | =oz= |
-| Emacs Calc | =calc=| Perl   | =perl=   |
-| Emacs Lisp | =emacs-lisp=  | Plantuml   | =plantuml=   |
-| Eshell | =eshell=  | Processing.js  | =processing= |
-| Fortran| =fortran= | Python | =python= |
-| Gnuplot| =gnuplot= | R  | =R=  |
-| GNU Screen | =screen=  | Ruby   | =ruby=   |
-| Graphviz   | =dot= | Sass   | =sass=   |
-| Haskell| =haskell= | Scheme | =scheme= |
-| Java   | =java=| Sed| =sed=|
-| Javascript | =js=  | shell  | =sh= |
-| LaTeX  | =latex=   | SQL| =sql=|
-| Ledger | =ledger=  | SQLite | =sqlite= |
-| Lilypond   | =lilypond=| Vala   | =vala=   |
-
-Additional documentation for some languages is at
-https://orgmode.org/worg/org-contrib/babel/languages.html.
+Code blocks in dozens of languages are supported.  See Worg for
+[[https://orgmode.org/worg/org-contrib/babel/languages/index.html][language specific documentation]].
 
 #+vindex: org-babel-load-languages
 By default, only Emacs Lisp is enabled for evaluation.  To enable or
@@ -18067,7 +18040,7 @@ for Python and Emacs Lisp languages.
 
 #+cindex: @samp{noweb-ref}, header argument
 Source code blocks can include references to other source code blocks,
-using a noweb[fn:144] style syntax:
+using a noweb[fn:142] style syntax:
 
 : <>
 
@@ -18578,7 +18551,7 @@ Org Tempo expands snippets to structures defined in
 ~org-structure-template-alist~ and ~org-tempo-keywords-alist~.  For
 example, {{{kbd(< s TAB)}}} creates a code block.  Enable it by
 customizing ~org-modules~ or add =(require 'org-tempo)= to your Emacs
-init file[fn:145].
+init file[fn:143].
 
 #+attr_texinfo: :columns 0.1 0.9
 | {{{kbd(a)}}} | =#+BEGIN_EXPORT ascii= ... =#+END_EXPORT= |
@@ -18658,7 +18631,7 @@ in the desired amount with hard spaces and hiding leading stars.
 To display the buffer in the indented view, activate Org Indent minor
 mode, using {{{kbd(M-x org-indent-mode)}}}.  Text lines that are not
 headlines are prefixed with virtual spaces to vertically align with
-the headline text[fn:146].
+the headline text[fn:144].
 
 #+vindex: org-indent-indentation-per-level
 To make more horizontal space, the headlines are shifted by two
@@ -18686,9 +18659,9 @@ use =STARTUP= keyword as follows:
 
 It is possible to use hard spaces to achieve the indentation instead,
 if the bare ASCII 

Miscellaneous fix, make `org-goto-first-child' behave intuitively before first heading

[Gustav Wikström]

Hi again,

While fixing other issues in the code I found thing worth improving. Thought to 
just briefly mention it here as well, for full transparency. 
`org-goto-first-child' now understand what a child is when before first 
heading. This is inline with how other outline functions behave.

Since this change, and the other changes I've made, are relatively small I 
haven't taken them through any review process on the list. To save us all of 
some bureaucracy.
 
--- Commit dad436c60
Make `org-goto-first-child' behave intuitively before first heading

* lisp/org.el (org-goto-first-child): Make it understand outline
level 0 as well.  The function now behaves intuitively also before
first heading.

Regards
Gustav

Re: Default fold state of property drawers?

[Gustav Wikström]

Hi Kyle,

And thanks for a second pair of eyes on this!

I've pushed a patch to the repo that should fix it.

--- commit 8d7a9b4ce
Hide drawers before first headline properly when cycling visibility

* lisp/org.el (org--hide-drawers): New internal function consolidating
  logic from two places currently.

  (org-cycle-hide-drawers): Hide drawers before first headline at
  appropriate times.  Refactor to use new internal function
  `org--hide-drawers'.

  (org-hide-drawer-all): Refactor to use new internal function
  `org--hide-drawers'.

Kind regards
Gustav


From: Kyle Meyer 
Sent: Sunday, November 1, 2020 19:21
To: Gustav Wikström
Cc: emacs-orgmode@gnu.org
Subject: Re: Default fold state of property drawers?

Gustav Wikström writes:

> But maybe my issue rather lies in how the visibility toggling with
> S-TAB functions. The file property drawer is open in OVERVIEW and
> CONTENT but hidden in SHOW ALL. My intuition says that the
> file-property drawer should be closed for all toggle-states. Thoughts?

I agree.  While I've never used file-level property drawers, my
expectation would be for them to behave in the same way a heading's
would.

FWIW when you introduced file-level property drawers in 1bdff9f73 (Org
document property-drawers, 2019-05-26), it looks like cycling wasn't
considered and S-TAB would just ignore these drawers, preserving their
current state.

The cycling behavior you described above appears to come with 1aa095ccf
(Fix drawer invisibility, 2020-06-06).  I think that was in response to
.  While I
haven't taken a close look, my guess is that the effect on file-level
property drawers was unintended, and that improvements here would be
welcomed.

Re: [PATCH] New "project" option for org-link-file-path-type

[Jack Kamm]

Hi Kyle,

> As a projectile user, I'm tempted to suggest that, instead of the adding
> the `project' value, org-insert-link could learn to call
> org-link-file-path-type if it is a function and, if that returns
> non-nil, do the prefix check.  Then projectile users could set it to
> projectile-project-root.  It seems project.el doesn't have a similar
> function that could be called without any arguments, but I guess we
> could add a simple ol- wrapper.  I'm not sure that's a good idea,
> though.

I like the idea of letting org-link-file-path-type be a function.

However, it struck me that it might be too limiting to just have the
function return the project root. There's a lot more potential for
customization here -- for example, a user might want to combine the
noabbrev option with the adaptive option. If we could instead pass a
function that takes the filename as an argument and returns the path to
insert, that would allow for greater flexibility.

Other benefits are that the implementation is much simpler, and
subjectively I think it's more intuitive to explain the meaning of this
option (as opposed to an option where the user passes a function that
returns the project root).

The downside of this is that the user has to do a bit more work and
write some elisp to take advantage of the option.

I've attached an updated patch in this direction. What do you think? I
think the simplicity and flexibility outweighs the downside, but I'm not
sure.

> The :package-version keyword should be added to signal the change in
> value.

Thanks for the tip, I've added this.

> Functionally I think your current patch would only support Emacs's
> unreleased master, unless the user installed a new project.el via ELPA.
> More on that below.

Good catch. I didn't realize I was using project.el from ELPA but it
turns out I was.

>From d156a9cfcdbfb9be72df3976e2355f48cf10 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Wed, 28 Oct 2020 17:29:04 -0700
Subject: [PATCH] ol.el: New option to set org-link-file-path-type to a
 function

* lisp/ol.el (org-link-file-path-type): Add new option.
(org-insert-link): Handle function option for org-link-file-path-type.
---
 etc/ORG-NEWS | 19 +++
 lisp/ol.el   | 12 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7f935bf52..891a680ae 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,25 @@ omit a file description was to omit the header argument entirely,
 which made it difficult/impossible to provide a default value for
 =file-desc=.
 
+*** New option to set ~org-link-file-path-type~ to a function
+
+If ~org-link-file-path-type~ can now be set to a function that takes
+the full filename as an argument and returns the path to link to.
+
+For example, if you use ~project.el~, you can set this function to use
+relative links within a project as follows:
+
+#+begin_src emacs-lisp
+(setq (org-link-file-path-type
+   (lambda (path)
+ (let* ((proj (project-current))
+(root (if proj (project-root proj) default-directory)))
+   (if (string-prefix-p (expand-file-name root) path)
+   (progn
+ (file-relative-name path))
+ (abbreviate-file-name path))
+#+end_src
+
 ** New features
 *** =ob-python= improvements to =:return= header argument 
 
diff --git a/lisp/ol.el b/lisp/ol.el
index 951bb74e7..262a6c5ae 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -212,13 +212,18 @@ (defcustom org-link-file-path-type 'adaptive
 absolute  Absolute path, if possible with ~ for home directory.
 noabbrev  Absolute path, no abbreviation of home directory.
 adaptive  Use relative path for files in the current directory and sub-
-  directories of it.  For other files, use an absolute path."
+  directories of it.  For other files, use an absolute path.
+
+Alternatively, users may supply a custom function that takes the
+full filename as an argument and returns the path."
   :group 'org-link
   :type '(choice
 	  (const relative)
 	  (const absolute)
 	  (const noabbrev)
-	  (const adaptive))
+	  (const adaptive)
+	  (function))
+  :package-version '(Org . "9.5")
   :safe #'symbolp)
 
 (defcustom org-link-abbrev-alist nil
@@ -1876,6 +1881,9 @@ (defun org-insert-link ( complete-file link-location description)
 	(setq path (expand-file-name path)))
 	   ((eq org-link-file-path-type 'relative)
 	(setq path (file-relative-name path)))
+	   ((functionp org-link-file-path-type)
+	(setq path (funcall org-link-file-path-type
+(expand-file-name path
 	   (t
 	(save-match-data
 	  (if (string-match (concat "^" (regexp-quote
-- 
2.29.2

Speedup of org-id-update-id-locations

[Gustav Wikström]

Hi, A patch is applied to master (commit 19d2f79a0) in order to speed up the 
rebuilding of ID locations.

Performance testing on my own setup shows a huge reduction in time to rebuild 
the cache. It goes from 168 seconds to 3 seconds. This performance increase is 
not to be expected for all operating systems. But for Windows (where Emacs has 
notorious problems working with the filesystem) this certainly helps!

The rest of this mail is the content of the commit message. 

Kind regards
Gustav

--- Commit 19d2f79a0 ---
Speedup of org-id-update-id-locations

Since this is about performance, a benchmark before this change, on a
set of 519 files with total size of 1500 kb gives the following result:

  519 files scanned, 504 files contains IDs, and 911 IDs found.
  (168.243948 38 2.0539493)

After the change the following result:

  519 files scanned, 504 files contains IDs, and 911 IDs found.
  (3.034806 3 0.164457622)

Benchmark done on a a Windows machine with no files previously loaded
into Emacs.

* lisp/org-id.el (org-id-update-id-locations): This function has
gotten a bit of back and forth changes in terms of performance.  One
year ago in 9865e6bd8 and then six months ago in 37a5020bb.
Unfortunately the latest speedup actually was a speed-down.  Speed is
not good again.

[PATCH] repeat cookies should be in the same order as the repeats

[Dieter Faulbaum]

---
 doc/org-manual.org | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ef2dad9ef..e78690993 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -5741,6 +5741,7 @@ expressions to process these values before inserting them 
into a table
 or a dynamic block.
 
 * Dates and Times
+
 :PROPERTIES:
 :DESCRIPTION: Making items useful for planning.
 :END:
@@ -6281,7 +6282,7 @@ organize such tasks using a so-called repeater in a 
=DEADLINE=,
 the =+1m= is a repeater; the intended interpretation is that the task
 has a deadline on =<2005-10-01>= and repeats itself every (one) month
 starting from that time.  You can use yearly, monthly, weekly, daily
-and hourly repeat cookies by using the =y=, =w=, =m=, =d= and =h=
+and hourly repeat cookies by using the =y=, =m=, =w=, =d= and =h=
 letters.  If you need both a repeater and a special warning period in
 a deadline entry, the repeater should come first and the warning
 period last
-- 
2.28.0

[PATCH] org-manual.org: Remove languages list and update worg link

[ian martins]

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
From a02c13a1fcf2b3d023bb5ef464245d600f4eaf30 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Wed, 4 Nov 2020 08:32:12 -0500
Subject: [PATCH] org-manual.org: Remove language list and fix Worg link

* doc/org-manual.org: Remove the language list and fix the Worg link
since the page has moved.

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
---
 doc/org-manual.org | 31 ++-
 1 file changed, 2 insertions(+), 29 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ef2dad9ef..2a6ef6f16 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17925,35 +17925,8 @@ code block header arguments:
 #+cindex: source code, languages
 #+cindex: code block, languages
 
-Code blocks in the following languages are supported.
-
-#+attr_texinfo: :columns 0.25 0.25 0.25 0.20
-| Language   | Identifier| Language   | Identifier   |
-|+---++--|
-| Asymptote  | =asymptote=   | Lisp   | =lisp=   |
-| Awk| =awk= | Lua| =lua=|
-| C  | =C=   | MATLAB | =matlab= |
-| C++| =C++=[fn:142] | Mscgen | =mscgen= |
-| Clojure| =clojure= | Objective Caml | =ocaml=  |
-| CSS| =css= | Octave | =octave= |
-| D  | =D=[fn:143]   | Org mode   | =org=|
-| ditaa  | =ditaa=   | Oz | =oz= |
-| Emacs Calc | =calc=| Perl   | =perl=   |
-| Emacs Lisp | =emacs-lisp=  | Plantuml   | =plantuml=   |
-| Eshell | =eshell=  | Processing.js  | =processing= |
-| Fortran| =fortran= | Python | =python= |
-| Gnuplot| =gnuplot= | R  | =R=  |
-| GNU Screen | =screen=  | Ruby   | =ruby=   |
-| Graphviz   | =dot= | Sass   | =sass=   |
-| Haskell| =haskell= | Scheme | =scheme= |
-| Java   | =java=| Sed| =sed=|
-| Javascript | =js=  | shell  | =sh= |
-| LaTeX  | =latex=   | SQL| =sql=|
-| Ledger | =ledger=  | SQLite | =sqlite= |
-| Lilypond   | =lilypond=| Vala   | =vala=   |
-
-Additional documentation for some languages is at
-https://orgmode.org/worg/org-contrib/babel/languages.html.
+Code blocks in dozens of languages are supported.  Language specific
+documentation can be found on [[https://orgmode.org/worg/org-contrib/babel/languages/index.html][Worg]].
 
 #+vindex: org-babel-load-languages
 By default, only Emacs Lisp is enabled for evaluation.  To enable or
-- 
2.25.1

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Palak,

Palak Mathur  writes:

> Paperwork with FSF is now complete.

Thanks!  I've added you as a maintainer for ob-groovy.el.

Let me know (privately) what username you want for your account
on https://code.orgmode.org.

Best,

-- 
 Bastien

Re: Tables: missing multi-col/row syntax

[TEC]

I think we may be able get something promising by merging your
(Christian + Tom) ideas and David's. What if we have have a
#+TBLCELLMERGE key which acts as you describe, and /just using the
current table syntax/ have something like this (using the example 
from

my first email)

| a | b  | c |
|---++---|
| hi|| a |
| two x || . |
| three || b |
|  c | - | . |
#+TBLCELLMERGE: @2$1..@4$2

This is /currently/ a valid Org table, which /currently/ 
autoformats to:

| a | b | c |
|---+---+---|
| hi|   | a |
| two x |   | . |
| three |   | b |
| c | - | . |

So with an autoformatting change + an overlay, perhaps we can do 
this

nicely without any syntax changes .

Thoughts?

Christian Moe  writes:

+1 for enabling table-cell merges in export. I imagine this 
would be a
tricky job for developers, but it would relieve me as a user of 
much

repeated fiddling with exported drafts.

+1 for doing it without adding clutter to the table syntax, but
specifying merges on a separate line like formulas, like Tom's

  #+TBLCELLMERGE: @2..3$1

(amended here to use the established '..' rather than hyphen for 
range)


Though if we do add such a line, we might also think of a more 
general
solution that could over time be extended with additional 
formatting

options, e.g. something like

  #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color 
  red)


But obviously that could open a can of worms, aka potentially 
endless
feature requests requiring different implementations for each 
backend.


Yours,
Christian



Tom Gillespie writes:

Any support for something like this would need to retain 
backward
compatibility as well to avoid older versions reformatting the 
tables
due to e.g. the presence of a double pipe. I also think that 
extending
the table syntax in ways that makes it more complex than it 
already
is, will be a non-starter. Thus, an alternate but more likely 
approach
would be to allow specification of what cells to merge outside 
the
table as is done for formulas. It is not elegant, but it would 
be a
layer on top of existing syntax, and it would allow the 
fundamental

structure of the table to remain the same -- rows of cells. For
example #+TBLCELLMERGE: @2-3$1 or something like that. 
Thoughts?

Tom

On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:


Hi all,

This is a pretty major 'feature request', but I think also an
important
one.

When developing large tables, it can often be /necessary/ to 
start

using
multi-column/row cells for clarity, and sensible exporting
results.

As far as I am aware, in Org does not currently have any
multi-col/row
syntax. The only viable method seems to be re-implementing the
table
using export blocks in every backend you may want to export to 
(in

my
case, usually TeX + HTML). This is clumsy, difficult to work 
with,

and
could be avoided should org gain support for multi-col/row 
syntax.


I appreciate that this would constitute a major change both 
the

Org's
syntax and the codebase, but I believe such a change is 
warranted

by the
advantages it would provide.

Both how this can be implemented while minimising/eliminating 
the

chance
of breaking well-formed current table elements, and what 
syntax

may be
both acceptable and seem sensible to use.

I would anticipate such a feature working by designating two
characters
to indicate "add row" and "add column". For example "|" and 
"-".

These
characters would take affect when /immediately following/ (no
space) a
cell separator ("|"), and designate the dimensions of the top
right cell.

Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |

Would be interpreted just as any current table is.

However,

| hello | there | you  |
|---+---+--|
|| two column   | cell |

Contains a 2x1 cell.

| a little | test |
|--+--|
|- hello   | hi   |
| two row  | you  |

Contains a 1x2 cell. In a more complex example:

| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |

Contains a 2x3 cell.

This is just the first syntax that comes to mind, but 
hopefully

the
general form of this idea seems viable.

All the best,

Timothy.

Re: Tables: missing multi-col/row syntax

[Christian Moe]

+1 for enabling table-cell merges in export. I imagine this would be a
tricky job for developers, but it would relieve me as a user of much
repeated fiddling with exported drafts.

+1 for doing it without adding clutter to the table syntax, but
specifying merges on a separate line like formulas, like Tom's

  #+TBLCELLMERGE: @2..3$1

(amended here to use the established '..' rather than hyphen for range)

Though if we do add such a line, we might also think of a more general
solution that could over time be extended with additional formatting
options, e.g. something like

  #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color red)

But obviously that could open a can of worms, aka potentially endless
feature requests requiring different implementations for each backend.

Yours,
Christian



Tom Gillespie writes:

> Any support for something like this would need to retain backward
> compatibility as well to avoid older versions reformatting the tables
> due to e.g. the presence of a double pipe. I also think that extending
> the table syntax in ways that makes it more complex than it already
> is, will be a non-starter. Thus, an alternate but more likely approach
> would be to allow specification of what cells to merge outside the
> table as is done for formulas. It is not elegant, but it would be a
> layer on top of existing syntax, and it would allow the fundamental
> structure of the table to remain the same -- rows of cells. For
> example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
> Tom
>
> On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:
>>
>> Hi all,
>>
>> This is a pretty major 'feature request', but I think also an
>> important
>> one.
>>
>> When developing large tables, it can often be /necessary/ to start
>> using
>> multi-column/row cells for clarity, and sensible exporting
>> results.
>>
>> As far as I am aware, in Org does not currently have any
>> multi-col/row
>> syntax. The only viable method seems to be re-implementing the
>> table
>> using export blocks in every backend you may want to export to (in
>> my
>> case, usually TeX + HTML). This is clumsy, difficult to work with,
>> and
>> could be avoided should org gain support for multi-col/row syntax.
>>
>> I appreciate that this would constitute a major change both the
>> Org's
>> syntax and the codebase, but I believe such a change is warranted
>> by the
>> advantages it would provide.
>>
>> Both how this can be implemented while minimising/eliminating the
>> chance
>> of breaking well-formed current table elements, and what syntax
>> may be
>> both acceptable and seem sensible to use.
>>
>> I would anticipate such a feature working by designating two
>> characters
>> to indicate "add row" and "add column". For example "|" and "-".
>> These
>> characters would take affect when /immediately following/ (no
>> space) a
>> cell separator ("|"), and designate the dimensions of the top
>> right cell.
>>
>> Example:
>> | a | b | c |
>> |---+---+---|
>> | a | - | | |
>> | - | b | . |
>> | . | | | c |
>>
>> Would be interpreted just as any current table is.
>>
>> However,
>>
>> | hello | there | you  |
>> |---+---+--|
>> || two column   | cell |
>>
>> Contains a 2x1 cell.
>>
>> | a little | test |
>> |--+--|
>> |- hello   | hi   |
>> | two row  | you  |
>>
>> Contains a 1x2 cell. In a more complex example:
>>
>> | a | b | c |
>> |---+---+---|
>> ||-- hi | a |
>> | two x | . |
>> | three | b |
>> | c | - | . |
>>
>> Contains a 2x3 cell.
>>
>> This is just the first syntax that comes to mind, but hopefully
>> the
>> general form of this idea seems viable.
>>
>> All the best,
>>
>> Timothy.
>>