Re: [O] How to create tables with multi-rows/columns cells?

[jiewuza]

Eric S Fraga  writes:

> On Monday, 11 Sep 2017 at 04:36, jiewuza wrote:
>> It is quite common to have multi-rows/columns cells in talbe. But as far
>> as I know, it seems impossible with the org built-in table editor.
>
> org does not support multi-row/column cells in tables.  

Well, I am thinking whether this proposal would work:
1. `|@` as a separator, meaning the next cell will span multiple columns
2. `|$` as a separator, meaning the next cell will span multiple rows
3. the span will terminate when it meats a regular cell separator `|`
4. the content of the "multi-rows/columns cell"(the big cell) should be
placed in the right-bottom single cell of the big one

For example, these two tables have the same effect.
#+BEGIN_SRC org
   |@   | header |$   |
   | h1 | h2 | h3 |
   |++|
   | a  |@$  |$   |
   | d  |@   | f  |

   +-+-+-+
   | h | |
   +-+-+  h3 |
   |  h1 | h2  | |
   +-+-+-+
   |  a  |   |
   +-+ f |
   |  d  |   |
   +-+---+

#+END_SRC

I do not know if it can be implemented in a clear and simple way based
on the current org-table and ox-* code. Maybe '|@n$m' like separator
(m,n is a number) would be simpler. I do not know. But it is great if
org supports multi-row/column cells in tables.

[O] Strange latex symbol behavior on html export

[Lawrence Bottorff]

Consider this markup:


* MATHEMATICS AUXILIARY

** deriving sines and cosines

#+caption: Right triangle with two $\pi\big/4$ angles.
[[file:images/45-45-triangle.png]]

$\big/$


If I remove the second $\big/$, the first latex, $\pi\big/4$, in the
caption will not properly render on export to html. Include it and both
render just fine. Without the second, the first looks like this:

Figure 1: Right triangle with two \(\pi\big/4\) angles.

Is this a bug?

LB

Re: [O] How to create tables with multi-rows/columns cells?

[jiewuza]

Eric S Fraga  writes:

> On Monday, 11 Sep 2017 at 04:36, jiewuza wrote:
>> It is quite common to have multi-rows/columns cells in talbe. But as far
>> as I know, it seems impossible with the org built-in table editor.
>
> org does not support multi-row/column cells in tables.  When you say:
>
>> It works.
>
> what do you mean?  If I edit your example, org does not recognise it as
> a table (or, at least, not a properly defined one).

I mean when I export the table to html (see below), I get what I want.

#+BEGIN_SRC org
   +-+-+-+
   | h | |
   +-+-+  h3 |
   |  h1 | h2  | |
   +-+-+-+
   |  a  |  b  |  c  |
   +-+-+-+
   |  d  |  e  |  f  |
   +-+-+-+
#+END_SRC

#+BEGIN_SRC html

  

  h


  
  h3
  

  
  

  h1


  h2

  
  

  a


  b


  c

  
  

  d


  e


  f

  

#+END_SRC

But there is no  in the output. That is why I suggest maybe we
can add org support to treat "===" as a separator of thead and tbody.

[O] Git repo for org-odt-export

[Qiang Fang]

Anyone trying to hack ox-odt can definitely get help here:
https://github.com/kjambunathan/org-mode-ox-odt/

James Harkins  writes:

>   On Sat, 09 Sep 2017 05:06:24 -0400 James Harkins  
> wrote 
> I guess next I'm going to try to hack ox-odt.el...

[O] Bug in ox.el

[Qiang Fang]

The original issue is at
https://github.com/kjambunathan/org-mode-ox-odt/issues/25

"org-export-table-cell-alignment uses org-export-data to infer cookies
of some columns. I think, it should use other mechanisms like
org-element-interpret-data (may be)."

The odt exporter is really useful, it replaces latex in most cases for
me. How can I help in getting it into the main org repo?

[O] [bug, fr] cannot doneify repeaters that have clock entries when org-log-repeat is nil

[Samuel Wales]

* x
recent maint

(setq org-log-repeat nil)

doneify this in emacs 24.4.1 -Q.
*** TODO test if presence of clock entry fails to advance repeater
when doneified :goto:
SCHEDULED: <2017-09-07 Thu 12:00 .+1d>
:PROPERTIES:
:LAST_REPEAT: [2017-09-12 Tue 15:27]
:END:
:LOGBOOK:
- State "DONE"   from "NEXTREPEAT" [2017-09-12 Tue 12:05]
- State "DONE"   from "NEXTREPEAT" [2017-09-12 Tue 11:52]
CLOCK: [2017-09-11 Mon 12:34]--[2017-09-11 Mon 12:48] =>  0:14
:END:
*** also feature request 'never


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] How to create tables with multi-rows/columns cells?

[Grant Rettke]

If you set the column width like this

http://orgmode.org/manual/Column-width-and-alignment.html#Column-width-and-alignment

then you can hit C-` to edit the cell and that works nicely.

Sincerely,

Grant Rettke

On Mon, Sep 11, 2017 at 4:47 AM, Eric S Fraga  wrote:

> On Monday, 11 Sep 2017 at 04:36, jiewuza wrote:
> > It is quite common to have multi-rows/columns cells in talbe. But as far
> > as I know, it seems impossible with the org built-in table editor.
>
> org does not support multi-row/column cells in tables.  When you say:
>
> > It works.
>
> what do you mean?  If I edit your example, org does not recognise it as
> a table (or, at least, not a properly defined one).
>
> --
> : Eric S Fraga via Emacs 24.5.1, Org release_9.1-57-gc6e563
>

Re: [O] Dynamically narrow table columns

[Kaushal Modi]

+1 here too!

The only thing to keep in mind is that the shrunk columns can be quickly
edited after C-c TAB instead of doing C-c ` first. Glad to see the column
width cookies working as always :)

On Tue, Sep 12, 2017 at 11:53 AM Eric S Fraga  wrote:

> On Sunday, 10 Sep 2017 at 10:27, Colin Baxter wrote:
> > I very much like the new table-column narrowing.
>
> +1
>
> Yesterday, I finally had the need/opportunity to use the new table
> column narrowing feature.  Works very well.  Thank you Nicolas!
>
> --
> : Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612
>
-- 

Kaushal Modi

Re: [O] Table aligning and editing in 9.2

[Kaushal Modi]

On Fri, Sep 8, 2017 at 3:42 PM Nicolas Goaziou 
wrote:

> William Denton  writes:
> > But now the cell contents are locked until either a) C-C ` opens up an
> > edit buffer (which was useful before for editing a long piece of text
> > that got shrunk, but is a lot of work when you have something short
> > like "Foo" in a <10> column and want to make it "Bar") or, as you
> > point out, b) something is typed in the shrunk column.
>
> Or c), simply expand the columns with C-c TAB, and edit the field to
> your heart's content.
>

I was initially bummed by the same observation that William made too.. that
you now needed to first do C-c ` for editting shrunk cells. So thanks for
that C-c TAB tip. That workflow works for me.
-- 

Kaushal Modi

Re: [O] Dynamically narrow table columns

[Eric S Fraga]

On Sunday, 10 Sep 2017 at 10:27, Colin Baxter wrote:
> I very much like the new table-column narrowing. 

+1

Yesterday, I finally had the need/opportunity to use the new table
column narrowing feature.  Works very well.  Thank you Nicolas!

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612


signature.asc
Description: PGP signature

Re: [O] SCHEDULE duration not honored in iCalender export

[Eric S Fraga]

On Tuesday, 12 Sep 2017 at 09:26, Warren Lynn wrote:
> Hi Eric:
>
> The change of "-" to "--" actually fixed the issue!. Thanks.
>
> It would be nice though if the single "-" also works just like in org
> agenda, and I don't need to worry about missing one hyphen. But I am happy
> now. :-)

Funnily enough, it probably shouldn't work in the agenda.  The
documentation (index range) clearly states that two hyphens are needed.

But glad you got it working!

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612


signature.asc
Description: PGP signature

Re: [O] Using orgtbl-mode with markdown: hfmt1

[Carsten Bormann]

On Sep 12, 2017, at 16:07, Kaushal Modi  wrote:
> 
> On Tue, Sep 12, 2017, 9:56 AM Carsten Bormann  wrote:
> 
> 
> Works perfectly.  But it would be nice not to have to apply this patch each 
> time I update.
> 
> Would it be possible to make hfmt1 configurable?
> (Preferably, using a buffer-local variable so I don’t have to break tables in 
> org-mode proper?)
> 
> I use a different approach to do the same thing using ox-gfm (based on a SO 
> solution). Look for orgtbl-to-gfm function here[1] and also my  notes at the 
> end of that file.
> 
> [1]: 
> https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-markdown.el
> -- 
> Kaushal Modi
> 

I am aware of a number of these workarounds.
The specific one you are proposing does not work for me as the markdown tables 
are in collaboratively edited documents and I can’t get the other authors to do 
any special dance around the tables; orgtbl-mode has to just work.

Besides, a 83-line workaround for what can be done seamlessly by changing one 
line of code?

(Yes, it would be nice to also preserve the column alignments, but we already 
have a solution that gets around that limitation.)

Grüße, Carsten

Re: [O] Using orgtbl-mode with markdown: hfmt1

[Kaushal Modi]

On Tue, Sep 12, 2017, 10:07 AM Kaushal Modi  wrote:

>
> I use a different approach to do the same thing using ox-gfm
>

Correcting myself.. that solution has nothing to do with ox-gfm.

> --

Kaushal Modi

Re: [O] Using orgtbl-mode with markdown: hfmt1

[Kaushal Modi]

On Tue, Sep 12, 2017, 9:56 AM Carsten Bormann  wrote:


Works perfectly.  But it would be nice not to have to apply this patch each
> time I update.


> Would it be possible to make hfmt1 configurable?
> (Preferably, using a buffer-local variable so I don’t have to break tables
> in org-mode proper?)
>

I use a different approach to do the same thing using ox-gfm (based on a SO
solution). Look for orgtbl-to-gfm function here[1] and also my  notes at
the end of that file.

[1]:
https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-markdown.el

> --

Kaushal Modi

[O] Using orgtbl-mode with markdown: hfmt1

[Carsten Bormann]

As is, orgtbl-mode is a great addition to markdown-mode.

There is one snag:

The markdown table syntax isn’t fully standardized.
A number of implementations react unfavorable to the + characters that 
orgtbl-mode uses as a column/row separator in the line separating the header 
from the body of the table; they prefer the | character here as well.

So I apply this little patch in org-table-align each time I install a new 
version of org-mode:

org-table.el
874c158
<  (hfmt1 "-%s-+"))
---
>  (hfmt1 "-%s-|"))   ; HACK: + ➔ |

Works perfectly.  But it would be nice not to have to apply this patch each 
time I update.

Would it be possible to make hfmt1 configurable?
(Preferably, using a buffer-local variable so I don’t have to break tables in 
org-mode proper?)

Grüße, Carsten

Re: [O] SCHEDULE duration not honored in iCalender export

[Warren Lynn]

Hi Eric:

The change of "-" to "--" actually fixed the issue!. Thanks.

It would be nice though if the single "-" also works just like in org
agenda, and I don't need to worry about missing one hyphen. But I am happy
now. :-)

Warren

On Mon, Sep 11, 2017 at 9:59 AM, Eric S Fraga  wrote:

> On Monday, 11 Sep 2017 at 14:29, Warren Lynn wrote:
> > Emacs 24.5.1, Org-mode 9.1, Windows 7
> >
> > If I have task like this:
> > * Spring break
> >SCHEDULED: <2018-03-30 Fri>-<2018-04-06 Fri>
> >
> > I would see "Spring break" listed in the daily agenda for each day
> between
> > the starting and ending date in the "SCHEDULED" line. However, the
> exported
> > ".ics" file only puts one entry for the starting date, which neither
> > correctly reflects the task nor be consistent with the daily org agenda
> > view.
>
> Not sure whether this helps or not but a period is specified using two
> hyphen characters: <...>--<...>
>
> --
> : Eric S Fraga via Emacs 24.5.1, Org release_9.1-57-gc6e563
>

Re: [O] BUG - strange characters showing in agenda after times displayed

[Sharon Kimble]

Matt Lundin  writes:

> Sharon Kimble  writes:
>
>> Matt Lundin  writes:
>>
>>> Sharon Kimble  writes:
>>>
 With the new release of org-mode to 9.1 I am finding with every build of
 a new agenda that this is displaying for items with a time as part of
 them -

   organiser:   8:30΄ьԔלڤ  Scheduled: TODO email org-mode list

 This is new and has only appeared with the new agenda which is generated
 after the release of org-mode 9.1.

 How do I stop it and get rid of it please?
>>>
>>> I cannot replicate this. My guess is that it is related to a particular
>>> configuration setting on your machine. For instance, what is the value
>>> of org-agenda-time-grid? The order of items in this variable changed
>>> with the upgrade to 9.1.
>>
>> ;; Enable display of the time grid so we can see the marker for the current 
>> time
>> (setq org-agenda-time-grid (quote ((daily today remove-match)
>>#("" 0 16 (org-heading t))
>>(0900 1100 1300 1500 1700
>>
>> But time-grid is not enabled in my agenda.
>
> This setting is definitely the problem. I can now reproduce the behavior.
>
> The order of items in org-agenda-time-grid changed recently, which I
> think is the root of the problem. The value for this variable should be
> a list of four (not three) items. Even if time grid is not enabled, the
> 3rd item in the setting is used to generate trailing characters that
> follow the time string in the agenda. This should be a string, not a
> list of numbers.
>
> You can type C-h v org-agenda-time-grid for all the details. Here is the
> default value of org-agenda-time-grid for reference. Note how the order
> differs from your current setting:
>
> ((daily today require-timed)
>  (800 1000 1200 1400 1600 1800 2000)
>  ".." "")
>

Thanks Matt. This code snippet gets my agenda back into its normal
good-looks.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk  
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.1


signature.asc
Description: PGP signature

Re: [O] asymmetry between org-backward-sentence and org-forward-sentence around headings

[Nicolas Goaziou]

Hello,

Mat Vibrys  writes:

>   Org file looks like following:
>
>   * heading
> my line.
>
>   when cursor is at beginning of file, `org-forward-sentence' goes to the
> end of "my line.", which does not seem to be correct (heading is special
> outline). Then calling `org-backward-sentence' behaves correctly, ie it
> goes to the beginning of "my line.".

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou