[O] convert rmarkdown (rmd) files to orgmode?

[Xebar Saram]

Hi all

anyone know of a way to convert rmarkdown (rmd) files to orgmode?

im preparing a R course and lots of cool examples in R are in rmd format so
it could be very useful to me

best

Z

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Stefan Monnier]

> Do we care that using save-match-data in every call to replace-match
> might mean a performance hit?

I do but:
- to be honest, it's probably lost in the noise.
- if we copy search_regs.start and search_regs.end with something like
  alloca+memcpy (instead of calling Fmatch_data), the cost should be even more
  lost in the noise.  Especially if you consider that the current code
  already loops through the match-data to adjust it.
- it's the best fix we've found so far.

> If it will, then this will again punish
> most of the users for the benefit of those few who (1) have
> buffer-modification hooks, and (2) those hooks call save-match-data.

I think the combination of 1 and 2 is actually pretty frequent.


Stefan


PS: I can think of one (theoretical) other/better way to fix this
problem: move the match-data adjustment so it's done within
replace_range before running the after-change-functions.  I think
this would be very satisfactory, since it would mean that the Elisp
code would always see the valid match-data (whereas currently the
after-change-functions get passed not-yet-adjusted match-data), so
save-match-data wouldn't mess it up.  But I fear this would require
much larger changes (and might involve a heavier performance cost as
well).

[O] Release 8.3.5

[Bastien Guerry]

Hi all,

Org 8.3.5, a minor release, is out.

Thanks again to Nicolas and all the contributors!

Enjoy,

-- 
 Bastien

Re: [O] Will there be an updated Org Mode in Emacs 25?

[Bastien Guerry]

Nicolas Goaziou  writes:

> Here it is: Go!

Done, thanks!

-- 
 Bastien

Re: [O] how to update and add info to babel documentation?

[dmg]

Thanks Tom,

Here is my patch.


On Tue, Jul 19, 2016 at 10:05 AM, Thomas S. Dye  wrote:

> Aloha dmg,
>
> You can find instructions here:
>
> http://orgmode.org/worg/worg-git.html
>
> Thanks for your help.
>
> All the best,
> Tom
>
> dmg writes:
>
> > hi there,
> >
> > I was trying to find the sources for the babel language documentation.
> > Specifically:
> >
> >
> > http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-sqlite.html
> >
> > Could anybody please tell me which is the best way to submit a patch to
> it?
> >
> > Specifically, I would like to document the use of variables in the mode.
> I had
> > to read its source code to know that you can to prefix the variable name
> with
> > $ for it to work, eg:
> >
> >
> > #+BEGIN_SRC sqlite :db /tmp/rip.db :var x="table"
> > select * from $x;
> > #+END_SRC
> >
> >
> > ​thank you,​
>
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>



-- 
--dmg

---
Daniel M. German
http://turingmachine.org
From 67f1d69ea3de516fd46ce8bc74d0b11f3d06cdc4 Mon Sep 17 00:00:00 2001
From: D German 
Date: Tue, 19 Jul 2016 13:47:14 -0700
Subject: [PATCH] added documentation on how ot pass variables to sqlite

---
 org-contrib/babel/languages/ob-doc-sqlite.org | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/org-contrib/babel/languages/ob-doc-sqlite.org b/org-contrib/babel/languages/ob-doc-sqlite.org
index 6b5be03..04deb57 100644
--- a/org-contrib/babel/languages/ob-doc-sqlite.org
+++ b/org-contrib/babel/languages/ob-doc-sqlite.org
@@ -112,6 +112,18 @@ There are 11 SQLite-specific header arguments.
 =.import=. 
  - nullvalue :: a string to use in place of NULL values.
 
+*** Variables 
+
+It is possible to pass variables to sqlite. Variables can be of type table or scalar. Variables are defined using :var=
+and referred in the code block as $.
+
+ - Table variables :: Table variables are exported as a temporary csv file that
+can then be imported by sqlite. The actual value of the variable is the name of temporary csv file. 
+
+ - Scalar variables :: This is a value that will replace references
+   to variable's name. String variables should be quoted;
+   otherwise they are considered a table variable.
+
 
 ** Sessions
 SQLite sessions are not supported.
@@ -152,4 +164,52 @@ Hello world!
 Note that =db= and =dir= together specify the path to the file
 that holds the SQLite database.
 
+** Using scalar variables
+
+In this example we create a variable with the name of the relation to query and a value to use in a query where clause.
+Note that the replacement excludes the quotes of string variables.
+
+#+BEGIN_EXAMPLE
+,#+BEGIN_SRC sqlite :db /tmp/rip.db :var rel="tname" n=300 :colnames yes
+drop table if exists $rel;
+create table $rel(n int, id int);
+insert into $rel(n,id) values (1,210), (3,800);
+select * from $rel where id > $n;
+,#+END_SRC
+
+,#+RESULTS:
+| 3 | 800 |
+#+END_EXAMPLE
+
+** Using table variables
+
+We can also pass a table to a query. In this case, the contents of the table are exported as a csv file that can then 
+be imported into a relation:
+
+#+BEGIN_EXAMPLE
+,#+NAME: tableexample
+| id |  n |
+|+|
+|  1 |  5 |
+|  2 |  9 |
+|  3 | 10 |
+|  4 |  9 |
+|  5 | 10 |
+
+,#+begin_src sqlite :db /tmp/rip.db :var orgtable=tableexample :colnames yes
+drop table if exists testtable;
+create table testtable(id int, n int);
+.mode csv testtable
+.import $orgtable testtable
+select n, count(*) from testtable group by n;
+,#+end_src
+
+,#+RESULTS:
+|  n | count(*) |
+|+--|
+|  5 |1 |
+|  9 |2 |
+| 10 |2 |
+#+END_EXAMPLE
+
 
-- 
2.7.4

Re: [O] Will there be an updated Org Mode in Emacs 25?

[Nicolas Goaziou]

Hello,

Bastien Guerry  writes:

> I may still have some time to make the release tonight, waiting for
> Nicolas "go".

Here it is: Go!

Thank you!

-- 
Nicolas Goaziou

[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Eli Zaretskii]

> From: Alex Bennée 
> Cc: monn...@iro.umontreal.ca, 23...@debbugs.gnu.org, rpl...@gmail.com, 
> jwieg...@gmail.com, nljlistb...@gmail.com, m...@lunaryorn.com
> Date: Tue, 19 Jul 2016 18:45:44 +0100
> 
>   ;; Save and restore the match data, as recommended in (elisp)Change Hooks
>   (save-match-data
> (when flycheck-mode
>   ;; The buffer was changed, thus clear the idle timer
>   (flycheck-clear-idle-change-timer)
>   (if (string-match-p (rx "\n") (buffer-substring beg end))
>   (flycheck-buffer-automatically 'new-line 'force-deferred)
> (setq flycheck-idle-change-timer
>   (run-at-time flycheck-idle-change-delay nil
>#'flycheck-handle-idle-change))
> 
> However it doesn't look as though it tweaks the buffer until idle timer
> has run. Weird

Tweaking the buffer is not what causes the problem.  It's the call to
save-match-data itself.  It doesn't matter at all what the code inside
save-match-data does.

Re: [O] Tuning the layout of published html

[Eric Abrahamsen]

Robert Klein  writes:

> Hi,
> Jarmo Hurri  wrote:
>
>> I am writing teaching material (for programming) using Org. All the
>> material (text, figures, code, program outputs) are written using Org
>> and Babel-supported languages. Publishing to html works just fine.
>> What I would like to do, however, is to add some layout structure to
>> the produced html.
>> 
>> More specifically, I would like to add, on all pages, a navigation bar
>> on the left-hand side and a title bar with no functionality on the top
>> of each page.
>> 
>> What options do I have to accomplish this? Searches led me to "derived
>> backends," but they sound like an overkill for a task that is this
>> simple. Or?
>
> You can use the preamble and postamble features for this.

[...]

> A lot depends on the CSS.  I'm dumping one here, not a very good one...

FWIW, this seems like a perfect place to use flexboxes, where the actual
location of the elements in the document matters a bit less...

Re: [O] Tuning the layout of published html

[Christian Moe]

Jarmo Hurri writes:

>> and position the different parts as needed with CSS.
>
> This is where I don't know what exactly is going to happen. Org writes
> quite a bit of CSS in each exported HTML file. If I add in, say, a
> vertical navigation bar, how am I going to control its placement with
> respect to everything else that is already in the CSS?

Say you put the navbar at the end of the HTML preamble and give it a
#navbar id (). Org already gives the main content a
#content id. Then this should be all the CSS you need to get started:

#navbar { float: left;
  ...loads more CSS here...
  }
#content { float: left;
   ...and more CSS here...
   }

Yours,
Christian

[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Alex Bennée]

Eli Zaretskii  writes:

>> From: Alex Bennée 
>> Cc: Stefan Monnier , 23...@debbugs.gnu.org, 
>> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com
>> Date: Tue, 19 Jul 2016 18:05:37 +0100
>>
>> > Do we care that using save-match-data in every call to replace-match
>> > might mean a performance hit?  If it will, then this will again punish
>> > most of the users for the benefit of those few who (1) have
>> > buffer-modification hooks, and (2) those hooks call save-match-data.
>>
>> I care unless there is an easy way to identify which buffer modification
>> hooks are responsible so I can take steps as a user to mitigate the
>> problems.
>
> Any hook in before-change-functions or after-change-functions that
> calls save-match-data.
>
> If we care about the performance hit, we need to come up with a
> different solution for this problem (or measure the performance hit
> and convince ourselves it is not a big deal).

Thanks for the hint. So in my case it was flycheck-handle-change which
was triggering the problem:

(defun flycheck-handle-change (beg end _len)
  "Handle a buffer change between BEG and END.

BEG and END mark the beginning and end of the change text.  _LEN
is ignored.

Start a syntax check if a new line has been inserted into the
buffer."
  ;; Save and restore the match data, as recommended in (elisp)Change Hooks
  (save-match-data
(when flycheck-mode
  ;; The buffer was changed, thus clear the idle timer
  (flycheck-clear-idle-change-timer)
  (if (string-match-p (rx "\n") (buffer-substring beg end))
  (flycheck-buffer-automatically 'new-line 'force-deferred)
(setq flycheck-idle-change-timer
  (run-at-time flycheck-idle-change-delay nil
   #'flycheck-handle-idle-change))

However it doesn't look as though it tweaks the buffer until idle timer
has run. Weird

--
Alex Bennée

Re: [O] Tuning the layout of published html

[Scott Randby]

On 07/19/2016 09:59 AM, Robert Klein wrote:

You can use the preamble and postamble features for this.


This solves a problem that has been bugging me for some time. All I need 
to do is use the preamble to solve my problem. Why didn't I think of 
that sooner?


Scott Randby

[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Eli Zaretskii]

> From: Alex Bennée 
> Cc: Stefan Monnier , 23...@debbugs.gnu.org, 
> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 18:05:37 +0100
> 
> > Do we care that using save-match-data in every call to replace-match
> > might mean a performance hit?  If it will, then this will again punish
> > most of the users for the benefit of those few who (1) have
> > buffer-modification hooks, and (2) those hooks call save-match-data.
> 
> I care unless there is an easy way to identify which buffer modification
> hooks are responsible so I can take steps as a user to mitigate the
> problems.

Any hook in before-change-functions or after-change-functions that
calls save-match-data.

If we care about the performance hit, we need to come up with a
different solution for this problem (or measure the performance hit
and convince ourselves it is not a big deal).

[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Alex Bennée]

Eli Zaretskii  writes:

>> From: Stefan Monnier 
>> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
>> jwieg...@gmail.com,  nljlistb...@gmail.com
>> Date: Tue, 19 Jul 2016 12:03:51 -0400
>>
>> I guess the next best thing is:
>> - copy search_regs.start and search_regs.end before calling replace_range.
>> - use that copy when adjusting the match data.
>> Or equivalently, use save-match-data.  IOW go back to your original patch.
>> Duh!
>
> Do we care that using save-match-data in every call to replace-match
> might mean a performance hit?  If it will, then this will again punish
> most of the users for the benefit of those few who (1) have
> buffer-modification hooks, and (2) those hooks call save-match-data.

I care unless there is an easy way to identify which buffer modification
hooks are responsible so I can take steps as a user to mitigate the
problems.

--
Alex Bennée

Re: [O] how to update and add info to babel documentation?

[Thomas S. Dye]

Aloha dmg,

You can find instructions here:

http://orgmode.org/worg/worg-git.html

Thanks for your help.

All the best,
Tom

dmg writes:

> hi there,
>
> I was trying to find the sources for the babel language documentation.
> Specifically:
>
>
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-sqlite.html
>
> Could anybody please tell me which is the best way to submit a patch to it?
>
> Specifically, I would like to document the use of variables in the mode. I had
> to read its source code to know that you can to prefix the variable name with
> $ for it to work, eg:
>
>
> #+BEGIN_SRC sqlite :db /tmp/rip.db :var x="table"
> select * from $x;
> #+END_SRC
>
>
> ​thank you,​


-- 
Thomas S. Dye
http://www.tsdye.com

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 12:03:51 -0400
> 
> I guess the next best thing is:
> - copy search_regs.start and search_regs.end before calling replace_range.
> - use that copy when adjusting the match data.
> Or equivalently, use save-match-data.  IOW go back to your original patch.
> Duh!

Do we care that using save-match-data in every call to replace-match
might mean a performance hit?  If it will, then this will again punish
most of the users for the benefit of those few who (1) have
buffer-modification hooks, and (2) those hooks call save-match-data.

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Stefan Monnier]

> Before call to replace_range in replace-match:
>
>|---|---|--||
>s1 e1   s2e2   EOB
>
> (s1, e1, etc. are the start and end of the corresponding
> sub-expressions.)
>
> After the call to replace_range in replace-match:
>
>|-|---|--||
>s1   e1   s2e2   EOB

Ah, right, now I see my confusion, thank you.

So, the data is within bounds before replace_range but after bounds
afterwards and the subsequent adjustments should fix it, but an
intervening save-match-data will mess it up.

Hmm... indeed, the adjustment isn't working correctly in this case.

I don't think we can safely change the way save-match-data works, so
I guess the next best thing is:
- copy search_regs.start and search_regs.end before calling replace_range.
- use that copy when adjusting the match data.
Or equivalently, use save-match-data.  IOW go back to your original patch.
Duh!


Stefan

Re: [O] Tuning the layout of published html

[Scott Randby]

On 07/19/2016 10:27 AM, Jarmo Hurri wrote:



This is where I don't know what exactly is going to happen. Org writes
quite a bit of CSS in each exported HTML file. If I add in, say, a
vertical navigation bar, how am I going to control its placement with
respect to everything else that is already in the CSS?

I can start my trial and error -period...


If you put the following line in your Org file, then the exported HTML 
will use only your CSS.


#+HTML_HEAD: 

Scott

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 00:48:19 -0400
> 
> > The more general problem is when there's at least one more
> > sub-expression, whose start and/or end are after the new EOB.
> > Those sub-expression's data will be completely bogus after the
> > adjustment,
> 
> If they were after the EOB, they were already bogus to start with.

I think we are mis-communicating.  I mean the following scenario:

Before call to replace_range in replace-match:

   |---|---|--||
   s1 e1   s2e2   EOB

(s1, e1, etc. are the start and end of the corresponding
sub-expressions.)

After the call to replace_range in replace-match:

   |-|---|--||
   s1   e1   s2e2   EOB

IOW, the 1st sub-expression got replaced with a much shorter text,
which made EOB be smaller than the original beginning and end of the
2nd sub-expression.  There's nothing bogus with this, is there?  The
user will expect to get match-data adjusted as shown in the second
diagram, and that's what she will really get -- unless there are
buffer-modification hooks that use save-match-data.  In the latter
case, what the user will get instead is this:

   |-|---|--||
   s1   EOB
e1
s2
e2

and that is even before the adjustment code kicks in and makes
"adjustments" with an incorrect adjustment value, which is computed as

  newpoint = search_regs.start[sub] + SCHARS (newtext);
  [...]
  ptrdiff_t change = newpoint - search_regs.end[sub];

and so will use the new EOB as search_regs.end[sub], instead of the
correct original value of e1 from the first diagram above.

IOW, the call to save-match-data in a buffer-modification hook
_disrupts_ the normal operation of replace-match in this case, by
indirectly sabotaging the adjustment of match data after the
replacement.

Am I missing something?

> And in any case, that's what has been happening for ever and has
> proved safe enough.

So you are saying that if a bug has been happening "for ever", it
doesn't have to be fixed?  (I disagree about "safe enough": the amount
of bug reports in our data base that are not reproducible and about
whose reasons we have no clear idea is non-negligible, so we don't
really know whether this particular issue caused trouble in the past
or not.)

> >> So I think a safe fix is to try and relax the check we added to
> >> replace-match so it doesn't get all worked up when something ≥ EOB gets
> >> changed to something else that's also ≥ EOB.
> > And lose the other sub-expressions in a more general case?  Really?
> 
> I'm not sure what you mean by "losing sub-expressions".

See above: the match data for any sub-expressions beyond the one that
shrunk too much is now bogus.  Thus "losing".

> >> Or maybe instead of signaling an error, we could simply skip the "Adjust
> >> search data for this change".
> > That would still sweep the problem under the carpet, leaving the match
> > data bogus, so I don't like doing that.
> 
> Maybe I'm not 100% satisfied with the behavior either, but I don't think
> it's a significant problem and I don't think it'd cause the crash we saw
> in bug#23869.

We don't only solve bugs that cause crashes, do we?  When I debugged
the crash in bug#23869, I found and tried to solve the root cause of
it, not just the symptom that caused the assertion violation.  I still
think we should strive to solve the root cause.

As for the significance of the problem, I hope you will reconsider
this after reading the above description of the scenario I have in
mind.  (Or tell me where I am wrong.)

> > The crash in bug#23869 was due to this:
> >
> >   newpoint = search_regs.start[sub] + SCHARS (newtext);
> >   [...]
> >   /* Now move point "officially" to the start of the inserted replacement.  
> > */
> >   move_if_not_intangible (newpoint);  <<<
> >
> > because due to clobbering, newpoint became -1.
> 
> Ah, I see.
> 
> Then maybe another fix is to compute newpoint before we call
> replace_range, so it uses search_regs.start[sub] before the
> *-change-functions can mess it up.  IOW:
> 
> @@ -2726,9 +2726,9 @@ since only regular expressions have distinguished 
> subexpressions.  */)
>unsigned  num_regs = search_regs.num_regs;
> 
>/* Replace the old text with the new in the cleanest possible way.  */
> +  newpoint = search_regs.start[sub] + SCHARS (newtext);
>replace_range (search_regs.start[sub], search_regs.end[sub],
>  newtext, 1, 0, 1);
> -  newpoint = search_regs.start[sub] + SCHARS (newtext);
>  
>if (case_action == all_caps)
>  Fupcase_region (make_number (search_regs.start[sub]),
> 
> Would that be sufficient to avoid the crash? 

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: Robert Pluim ,  23...@debbugs.gnu.org,  
> alex.ben...@linaro.org,  jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 20:58:35 -0400
> 
> > I think this change performed by save-match-data is harmless: the old
> > value (62) was not valid any more anyway.
> 
> In this particular case, yes.  But only in this case, because (a)
> there's actually only one sub-expression, and (b) it ends exactly at
> EOB.

Moreover, if the value of 62 was left alone by save-match-data, the
adjustment code in replace-match would have fixed it.  That's what
that code is all about: it fixes the match data due to changes to the
buffer made by replacing the old text by the new.  Any attempts to
"fix" those values under that code's feet are not helpful; quite the
contrary.

> > So I think a safe fix is to try and relax the check we added to
> > replace-match so it doesn't get all worked up when something ≥ EOB gets
> > changed to something else that's also ≥ EOB.
> 
> And lose the other sub-expressions in a more general case?  Really?

What really bothers me is that by just loosening the conditions under
which we signal an error we defeat _valid_ code, which did use
save-match-data, and yet the match data still ends up being
clobbered.  I don't mind making the test more loose so that invalid
programs have a longer rope to hang themselves, but valid programs
should not be failed, IMO.

> > Or maybe instead of signaling an error, we could simply skip the "Adjust
> > search data for this change".

> That would still sweep the problem under the carpet, leaving the match
> data bogus, so I don't like doing that.

> > This said, I don't fully understand what's going on: bug#23869 reported
> > a crash, but AFAICT the match-data here is only used to adjust
> > search_regs which seems like it wouldn't cause a crash, even if the new
> > values are bogus.

> The crash in bug#23869 was due to this:

>   newpoint = search_regs.start[sub] + SCHARS (newtext);
>   [...]
>   /* Now move point "officially" to the start of the inserted replacement.  */
>   move_if_not_intangible (newpoint);  <<<

> because due to clobbering, newpoint became -1.


> > > -   '((save-match-data-internal (match-data)))
> > > +   '((save-match-data-internal (match-data 'integers)))
> > 
> > That looks risky.
> 
> Then how about manually doing the equivalent of save-match-data around
> the call to replace_range, calling match-data with non-nil argument?

Here are some more alternatives for dealing with this issue:

 (1) Make match-data use integers instead of markers by default when a
 call to replace-match is in progress, i.e. when match-data is
 called from some buffer-modification hook triggered by
 replace-match

 (2) Don't signal an error, even if match data seems clobbered, if the
 new value of point is valid and either (a) there's only one
 search register, or (b) the adjustment value is zero (i.e. the
 registers will be left unchanged).

I like (1) better than (2) because (1) will let valid programs avoid
clobbering match data, but maybe it's too risky for emacs-25.  Also,
is it plausible that some buffer-modification hook will edit the
buffer in the save-match-data forms, and expect the match data to be
adjusted, or is this something that a buffer-modification hook should
never do?  If valid programs can do this, then (1) is probably not a
good idea.

Re: [O] Tuning the layout of published html

[Robert Klein]

Hi,
Jarmo Hurri  wrote:

> 
> Robert Klein  writes:
> 
> > You can use the preamble and postamble features for this.
> >
> > You'd have to edit the navigation bar manually, though.
> >
> > Example preamble (file: html/preamble.html):
> > ...
> > Does this help a bit?
> 
> Yes it does, but it is impossible for me to tell which parts of these
> files are really necessary to achieve the desired result. But I will
> start experimenting.


I'll try to put together something more cohesive...

Best regards
Robert

Re: [O] Tuning the layout of published html

[Jarmo Hurri]

Eric S Fraga  writes:

> On Tuesday, 19 Jul 2016 at 13:09, Jarmo Hurri wrote:
>> More specifically, I would like to add, on all pages, a navigation
>> bar on the left-hand side and a title bar with no functionality on
>> the top of each page.
>
> You are probably looking for cascading style sheets (CSS) for the
> HTML.  org's HTML export already tags everything of note so you may
> be able to achieve what you want with careful style choices.

I guess "careful" is the operative word here. Unfortunately I feel like
I am inserting new stuff into ready-to-eat spaghetti. ;-)

> You might like to look at the example web pages at
>
> http://orgmode.org/worg/org-web.html

I took a look at some of those. The unfortunate thing is that most of
them are not accompanied by source code.

All the best,

Jarmo

Re: [O] Tuning the layout of published html

[Jarmo Hurri]

Robert Klein  writes:

> You can use the preamble and postamble features for this.
>
> You'd have to edit the navigation bar manually, though.
>
> Example preamble (file: html/preamble.html):
> ...
> Does this help a bit?

Yes it does, but it is impossible for me to tell which parts of these
files are really necessary to achieve the desired result. But I will
start experimenting.

Thanks!

Jarmo

Re: [O] Will there be an updated Org Mode in Emacs 25?

[Bastien Guerry]

Kyle Meyer  writes:

>> I agree.  Let me know if there is anything special to check before
>> releasing 8.3.5.  If not, I will release it this afternoon.
>
> The backports from the main Emacs repo are up-to-date.

Thanks Kyle!

I may still have some time to make the release tonight, waiting for
Nicolas "go".

-- 
 Bastien

Re: [O] Tuning the layout of published html

[Jarmo Hurri]

Greetings.

> No need for derived backends.
>
> You could just add both the title bar and the navigation bar in the
> HTML preamble to each page,

Can do that.

> and position the different parts as needed with CSS.

This is where I don't know what exactly is going to happen. Org writes
quite a bit of CSS in each exported HTML file. If I add in, say, a
vertical navigation bar, how am I going to control its placement with
respect to everything else that is already in the CSS?

I can start my trial and error -period...

Thanks!

Jarmo

Re: [O] Tuning the layout of published html

[Marcin Borkowski]

On 2016-07-19, at 15:09, Jarmo Hurri  wrote:

> Greetings.
>
> I am writing teaching material (for programming) using Org. All the
> material (text, figures, code, program outputs) are written using Org
> and Babel-supported languages. Publishing to html works just fine. What
> I would like to do, however, is to add some layout structure to the
> produced html.
>
> More specifically, I would like to add, on all pages, a navigation bar
> on the left-hand side and a title bar with no functionality on the top
> of each page.
>
> What options do I have to accomplish this? Searches led me to "derived
> backends," but they sound like an overkill for a task that is this
> simple. Or?

I don't know about other ways, but a derived backend /can/ be really
simple -- you might as well use the "derived backend" feature to modify
just the page template.  You'd probably have to look at the
`org-html-template' function and write your version of it.

> Jarmo

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Will there be an updated Org Mode in Emacs 25?

[Kyle Meyer]

Bastien Guerry  writes:

[...]

>> last stable release in the 8.3.X series.
>
> I agree.  Let me know if there is anything special to check before
> releasing 8.3.5.  If not, I will release it this afternoon.

The backports from the main Emacs repo are up-to-date.

--
Kyle

Re: [O] Tuning the layout of published html

[Scott Randby]

On 07/19/2016 09:09 AM, Jarmo Hurri wrote:


Greetings.

I am writing teaching material (for programming) using Org. All the
material (text, figures, code, program outputs) are written using Org
and Babel-supported languages. Publishing to html works just fine. What
I would like to do, however, is to add some layout structure to the
produced html.

More specifically, I would like to add, on all pages, a navigation bar
on the left-hand side and a title bar with no functionality on the top
of each page.

What options do I have to accomplish this? Searches led me to "derived
backends," but they sound like an overkill for a task that is this
simple. Or?

Jarmo





I don't know if I can answer your questions, but I used to do something 
similar to what you want using Org and CSS. I had a navigation list at 
the top and a fixed table of contents. There are some disadvantages to 
this setup and I no longer use it.


I still have some pages up which use this setup. You can see these pages 
by clicking on the following link:


  http://srandby.org/ictcm-2014/index.html

To get the navigation list, I had the following at the top of the Org 
file before any headlines (two items are not used in the above page):


#+BEGIN_HTML


  
Home
Lessons
Help
  


#+END_HTML

In the CSS file for the page, I had the following code to style the list:

/* Navigation List Styles Begin */
div #nav {
  position: absolute;
  left: 10px;
  top: 5em;
}

#nav ul {
  margin: 3px 10px 10px 5px;
  list-style: none outside none;
  padding: 0px 0px 0px 0px;
}

#nav ul li {
  margin-right: 4px;
  margin-bottom: 5px;
  float: left;
  margin-top: 20px;
}

#nav a {
  color: white;
  background-color: navy;
  padding: 5px;
  text-decoration: none;
  font-weight: bold;
  border: 5px solid blue;
  border-radius: 10px;
}
/* Navigation List Styles End */

It is easy to place the table of contents generated by Org wherever you 
want it using CSS. Here is to CSS code I used to style the table of 
contents. This code is sloppy.


#table-of-contents {
  font-size: small;
  position: fixed;
  right: 1em;
  top: 0.5em;
  background-image: url(./styleimages/toc-back.jpg);
  border-radius: 10px;
  height: 5em;
  max-height: 15%;
  width: 18em;
  overflow: auto;
  z-index: 1;
  border: 5px solid seagreen;
}
#table-of-contents h2 {
  font-size: medium;
  color: springgreen;
  font-style: oblique;
  text-align: center;
  margin-right: 15px;*/
  margin-top: 5px;
  margin-bottom: 5px;
  border-bottom: 0px solid silver;
  padding-top: 0px;
  padding-left: 0px;
  margin-left: 0px;
  margin-right: 0px;
}
#table-of-contents ul {
  color: aqua;
  list-style-type: disc;
  float: none;
  margin-left: 0px;
  margin-bottom: 0px;
}
#table-of-contents li {
  margin-bottom: 0px;
}
#table-of-contents a {
  color: white;
  font-weight: bold;
}
#table-of-contents #text-table-of-contents {
  display: block;
  text-align: left;
  padding-left: 0px;
  padding-right: 0px;
  margin-left: 10px;
  margin-right: 5px;
  margin-bottom: 10px;
}

Re: [O] Tuning the layout of published html

[Robert Klein]

Hi,
Jarmo Hurri  wrote:

> I am writing teaching material (for programming) using Org. All the
> material (text, figures, code, program outputs) are written using Org
> and Babel-supported languages. Publishing to html works just fine.
> What I would like to do, however, is to add some layout structure to
> the produced html.
> 
> More specifically, I would like to add, on all pages, a navigation bar
> on the left-hand side and a title bar with no functionality on the top
> of each page.
> 
> What options do I have to accomplish this? Searches led me to "derived
> backends," but they sound like an overkill for a task that is this
> simple. Or?

You can use the preamble and postamble features for this.

You'd have to edit the navigation bar manually, though.

Example preamble (file: html/preamble.html):
--- snip ---

  Home
  Imprint
  

  

  


 
--- snip ---

Example postamble file:

 

  

   
  

Contents

  main page
  Heading
  imprint
 -->

  
  
  
  

  

   20122015 Robert Klein

 
--- snip ---


Preamble and postamble functiond in .emacs:
--- snip ---
;; pre- and postamble for html export
(defun my-preamble (options)
  (with-temp-buffer
(insert-file-contents "~/projects/myprj/html/preamble.html")
(buffer-string)))

(defun xyzzys-postamble (options)
  (with-temp-buffer
(insert-file-contents "~/projects/myprj/html/postamble.html")
(buffer-string)))
--- snip ---

project-alist excerpt(in .emacs, too):
--- snip ---
(add-to-list 'org-publish-project-alist
 '("myprj-html"
   :base-directory "~/projects/myprj"
   :base-extension "org"
   :publishing-directory "~/public_html/myprj"
   :publishing-function org-html-publish-to-html
   :html-head "" :html-head-include-default-style nil
   :html-head-include-scripts nil
   :html-preamble my-preamble
   :html-postamble my-postamble
--- snip ---


A lot depends on the CSS.  I'm dumping one here, not a very good one...

---snip---
/* 
  a lot of stuff is from Matthew James Taylor's ultimate 2 column
  left menu layout.
  */

body {
margin: 0 auto;
padding: 0; /* 0 5em 0; */
/* padding for the footer is in colmask */
/* border: 0; */
width: 100%;
/* max-width: 40em; */
/* line-height: 1.4; */
/* background: #fff; */
background: #fffaf0; /* floralwhite */ /* whitesmoke; #f5f5f5 */
font-size:100%;
color: #000;
text-align: justify;
/* font-family: "Linux Libertine", Georgia, serif; */
font-family: wfSourceSansPro, serif;
display: block;
}

code {
font-family: wfSourceCodePro, monospace;
font-size: 90%;
}


/* if i use a breadcrumb again */
#breadcrumb {
float:left;
width:100%;
padding:.1em 0 ;
margin:0;
background-color: #eee;
font-size: small;
/* border-bottom: 4px solid #75A838; */
}
#breadcrumb p {
padding:0;
margin:0;
}

#preamble {
clear: both;/* nothing to the left or right of the header */
float: none;/* essentially the same */
width: 100%;
margin: 0;
padding: 0;
background-color: mintcream;
font-size: small;
border-bottom:1px solid gainsboro; /* #7ca6a6; */ /* solid #000; */
/* Fixed header at the top of the screen. */
position: fixed;
top: 0;
left: 0;
z-index: 999;
height: 1.5em;
/* letter-spacing: 0.1em; */
/* background: none repeat scroll 0 0; */
/*border-bottom: 1px dotted #7ca6a6; */
}


#preamble p {
margin:0;
padding: .2em 1em .2em 1em;
/* space above text and below letters g and y. */
}

.alignright { float: right; }
.alignleft { float: left; }

/* Here begins Matthew James Taylor's 2 ultimate 2 column layout.  I
   removed anything left over from the other layouts as well as stuff
   which would allow me to reuse the components (that is, I can use
   only one liquid layer per page) */


/* column container */
/* I use only colmask instead of colmask and leftmenu. Doesn't make
   a difference if I use only this 2-column layout */
.colmask {
position:relative;  /* This fixes the IE7 overflow hidden bug */
clear:both;
float:left;
width:100%; /* width of whole page */
overflow:hidden;/* This chops off any overhanging divs */
/* background color for the fixed (navigation) column.  Note: this
   also requires the color for the main column to be set in
   .colleft, so the main column doesn't get the background of the
   this column. */
background-color: OldLace; /*linen; /* whitesmoke */
padding-top: 1.5em; /* padding for the header/preamble */
padding-bottom: 1.5em; /* padding for the footer */
}

.colleft {
float: left;
width:200%;
position:relative;
left: 2em;
background-color: #fffaf0; /* floralwhite */

Re: [O] Tuning the layout of published html

[Josiah Schwab]

On 19 July 2016 at 13:35 GMT, Eric S Fraga wrote:

> On Tuesday, 19 Jul 2016 at 13:09, Jarmo Hurri wrote:
>> More specifically, I would like to add, on all pages, a navigation bar
>> on the left-hand side and a title bar with no functionality on the top
>> of each page.
>
> You are probably looking for cascading style sheets (CSS) for the
> HTML.  org's HTML export already tags everything of note so you may
> be able to achieve what you want with careful style choices.

I agree with Eric (and now Christian) that is the way to go.

Personally, I have enjoyed using the styles in Fabrice Niessen's
org-html-themes, especially

https://github.com/fniessen/org-html-themes#readtheorg

It already has some similarities to the layout you describe.

Hope that helps,
Josiah

Re: [O] Tuning the layout of published html

[Christian Moe]

Hi,

No need for derived backends.

You could just add both the title bar and the navigation bar in the HTML
preamble to each page, and position the different parts as needed with
CSS.

If you're using Org's publishing function, define a :html-preamble in
org-publish-project-alist. 

Yours,
Christian


Jarmo Hurri writes:

> Greetings.
>
> I am writing teaching material (for programming) using Org. All the
> material (text, figures, code, program outputs) are written using Org
> and Babel-supported languages. Publishing to html works just fine. What
> I would like to do, however, is to add some layout structure to the
> produced html.
>
> More specifically, I would like to add, on all pages, a navigation bar
> on the left-hand side and a title bar with no functionality on the top
> of each page.
>
> What options do I have to accomplish this? Searches led me to "derived
> backends," but they sound like an overkill for a task that is this
> simple. Or?
>
> Jarmo

Re: [O] Tuning the layout of published html

[Eric S Fraga]

On Tuesday, 19 Jul 2016 at 13:09, Jarmo Hurri wrote:
> More specifically, I would like to add, on all pages, a navigation bar
> on the left-hand side and a title bar with no functionality on the top
> of each page.

You are probably looking for cascading style sheets (CSS) for the
HTML.  org's HTML export already tags everything of note so you may
be able to achieve what you want with careful style choices.

You might like to look at the example web pages at

http://orgmode.org/worg/org-web.html

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.94.1, Org release_8.3.4-1049-g481709

[O] Tuning the layout of published html

[Jarmo Hurri]

Greetings.

I am writing teaching material (for programming) using Org. All the
material (text, figures, code, program outputs) are written using Org
and Babel-supported languages. Publishing to html works just fine. What
I would like to do, however, is to add some layout structure to the
produced html.

More specifically, I would like to add, on all pages, a navigation bar
on the left-hand side and a title bar with no functionality on the top
of each page.

What options do I have to accomplish this? Searches led me to "derived
backends," but they sound like an overkill for a task that is this
simple. Or?

Jarmo

Re: [O] Will there be an updated Org Mode in Emacs 25?

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

>> I would suggest that you push the latest maint branch org version to the
>> master branch of emacs now, so that it would be fairly tested by the time
>> the next to next emacs release happens (25.2?).
>
> My secret plan is to have Org 9.0 merged in Emacs master branch just
> after Emacs 25.1 is released.

It sounds like a good plan to me, and you know better now.

> Meanwhile, I think we can release Org 8.3.5 which, hopefully will be the
> last stable release in the 8.3.X series.

I agree.  Let me know if there is anything special to check before
releasing 8.3.5.  If not, I will release it this afternoon.

Thanks,

-- 
 Bastien