Re: [O] Will there be an updated Org Mode in Emacs 25?
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
[O] Tuning the layout of published html
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
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
Re: [O] Tuning the layout of published html
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
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
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 --> © 2012–2015 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 */ border-left: 1px dotte
Re: [O] Tuning the layout of published html
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] Will there be an updated Org Mode in Emacs 25?
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
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] Tuning the layout of published html
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] Will there be an updated Org Mode in Emacs 25?
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
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] Tuning the layout of published html
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
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
[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)
> 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.
[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)
> 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? Why not? To avoid the cr
Re: [O] Tuning the layout of published html
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)
> 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
[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)
> 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.
Re: [O] how to update and add info to babel documentation?
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: 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 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
[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)
> 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).
Re: [O] Tuning the layout of published html
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 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
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
Re: [O] Tuning the layout of published html
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...
[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)
> 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] Will there be an updated Org Mode in Emacs 25?
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
Re: [O] how to update and add info to babel documentation?
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 writes: > Here it is: Go! Done, thanks! -- Bastien
[O] Release 8.3.5
Hi all, Org 8.3.5, a minor release, is out. Thanks again to Nicolas and all the contributors! Enjoy, -- Bastien
[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)
> 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] convert rmarkdown (rmd) files to orgmode?
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