Re: [O] Importing from Oddmuse?
Dnia 2013-10-30, o godz. 18:44:53 Peter Davis p...@pfdstudio.com napisał(a): On Thu, Oct 31, 2013 at 02:38:48AM +0530, Jambunathan K wrote: Peter Davis p...@pfdstudio.com writes: I've used Oddmuse for years to maintain my own personal Wiki, but now I'm looking to move to Org mode. I am in the process of adding Org-mode markup support to the Oddmuse That would be great. I'd love to use the same markup everywhere. +1 Thanks, -pd One can also look at the churnings happening here: http://repo.or.cz/w/orgmuse.git -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [RFC] [PATCH] [parser] org-element.el: Handle block parameters
Hello, Aaron Ecay aarone...@gmail.com writes: 2013ko urriak 30an, Nicolas Goaziou-ek idatzi zuen: IIRC, I already suggested a solution with Babel for this problem. There's no need to complicate core Org syntax for such a specific case. And I already said why I disagree that your proposal is a solution. Special blocks are “Containers targeted at export back-ends” (according to the manual). Is it appropriate for such containers to have metadata attached? As I explain below, I think so. Whether you approve or disapprove of the use to which someone puts that metadata in a specific instance is a different question, as long as we agree that the metadata is potentially useful for some things. Metadata relative to export back-ends is stuffed into #+attr_backend keywords. There's no reason to clobber Org syntax with back-ends metadata. Actually, there are two points to consider: 1. Providing something like :author implies that all back-ends in core and contrib and the manual have to be updated accordingly. Yes, that is desirable eventually. I guess whoever implements :author for quotes (maybe it will be me) will need to think about all these things. (Though I’m not sure that all backends have to be updated in one fell swoop. The old behavior is still fine as a fall-back until all backends catch up to the new standard. All backends will not magically catch-up if nobody does the job. Creating new syntax has a cost, which is higher than simply adding a few lines in org-element.el. 2. parameters is too vague to be useful. It needs to be parsed further, which means that we must define explicitly use cases and keywords. Thus, I don't think adding parameters to every block is a good move if we don't know beforehand how they will be used. Though, it is possible to extend the syntax to well-defined specific cases. :author may be one of them, there are certainly others. I have the opposite view. The parser should provide a set of convenient tools to elisp code, which are useful for extending org’s functionality at the elisp level. An “if you build it they will come” approach. I'm trying to unify and simplify Org syntax. The simpler the better. That doesn't mean that the syntax cannot be extended, but I'd like to see a concrete good reason for it. Let's do it as it might be used later just doesn't cut it. Moreover, your proposal, IMO, is not well-enough defined. You merely add a free-form string and call it parameters. Parameters for what? Which syntax: a plist, switches? Why cannot some parameters fit into other affiliated keywords (e.g. HEADER)? What happens if the line is too long: is there another location for them? What happens if they compete with other affiliated keywords, i.e. what if I write #+begin_quote :caption Something So, again, it is important to know what they do so we can deduce what location is the more appropriate for them. For example, attributes should be short enough to fit on a single line. Switches are good candidates, a plist is not (see switches in example blocks, for example), unless we limit allowed keywords in it. Regards, -- Nicolas Goaziou
Re: [O] RLT (hebrew) tables and org-odt-export-to-odt problems
Jambunathan == Jambunathan K Jambunathan writes: In LibreOffice, Right click on the table-Table-Text Direction-Right-to-Left. I attach three files. r2ltableOO.odt has been generated by OO, and displays the text as intended. r2ltableorg.org is the org file and displays the text as intended. However not all of the text was written in logical order by GNU emacs, but copied from some other sources. r2ltableorg.odt is the result of the converter, which is not the same as OO produces. So maybe some direction marker is needed in the L2R text? r2ltableorg.odt Description: application/vnd.oasis.opendocument.text שלום דוד Hello David | שלום | דוד | | David |hello | r2ltableOO.odt Description: application/vnd.oasis.opendocument.text smime.p7s Description: S/MIME cryptographic signature
Re: [O] [RFC] Slight change to asynchronous export
Hello, Rick Frankel r...@rickster.com writes: On 2013-10-30 06:00, Nicolas Goaziou wrote: Helo, For reference, here is the suggested patch. Is there any strong point against it? looks great to me. Applied. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] hide inline-tasks in 'children visibility state
Hello, co...@online.de (Jonas Hörsch) writes: one more patch, which takes care of re-hiding inline-tasks properly. finally it is possible to work with longer inline tasks without them getting always in the way. Thank you for the patch. Here are a few comments. Subject: [PATCH] org-inlinetask: hide inline tasks in 'children visibility state Nitpick: you need a capital letter after colons. * lisp/org.el (org-cycle-hide-inline-tasks): re-hide inline tasks when switching to 'children visibility state. Ditto. + Re-hide inline tasks when switching to 'contents or 'children +visibility state. + (cond ((eq state 'contents) I suggest to use `case' here, but it's really a matter of style. + (when (and (boundp 'org-inlinetask-min-level) + org-inlinetask-min-level) (and (boundp 'var) var) = (org-bound-and-true-p var) +(hide-sublevels (1- org-inlinetask-min-level + (while (and (outline-next-heading) + (org-inlinetask-at-task-p)) I think it is more efficient to directly look for inlinetasks since you can use `org-inlinetask-outline-regexp'. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Longtable continuation strings customizable
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I have this, based on the example above:
#+name: tsd-continuation-strings
#+begin_src emacs-lisp
(defun my-personal-table-continuation-strings (row backend info)
(when (org-export-derived-backend-p 'latex)
(replace-regexp-in-string
multicolumn{[0-9]+}{l}{\\(.*\\)} \\ldots\\ continued from previous
page
row nil nil 1)
(replace-regexp-in-string
multicolumn{[0-9]+}{r}{\\(.*\\)} continued on next page \\ldots
row nil nil 1)))
(add-to-list 'org-export-filter-table-row-functions
'my-personal-table-continuation-strings)
#+end_src
I also tried 'org-export-filter-table-functions without success. I
always get the default continuation strings. I've looked around for an
error message, but there doesn't appear to be one, at least that I can
find. The asynchronous export runs through to completion.
The first `replace-regexp-in-string' has to be applied to the return
value of the second one. IOW they have to be nested.
Also, you need to double again backslashes in replacement string, or use
a non-nil LITERAL argument in `replace-regexp-in-string'.
Eventually, I made a typo in my suggestion: the second line should be:
(org-export-derived-backend-p backend 'latex)
In a nutshell:
(defun my-personal-table-continuation-strings (row backend info)
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string
multicolumn{[0-9]+}{l}{\\(.*\\)} \\ldots\\ continued from previous
page
(replace-regexp-in-string
multicolumn{[0-9]+}{r}{\\(.*\\)} continued on next page \\ldots
row nil t 1) nil t 1)))
Regards,
--
Nicolas Goaziou
Re: [O] make new links show as figures?
r...@rickster.com writes: On 2013-10-26 08:10, John Kitchin wrote: Other than having to repeat yourself, wouldn't the [[custom:file.ext][file:file.png]] syntax allow for most/all of the use cases mentioned? rick Yes, I think [[custom:file.ext][file:file.png]] would cover all those cases. So it turns out that this is a REALLY simple patch (two characters): --- a/lisp/org.el +++ b/lisp/org.el @@ -18853,7 +18853,7 @@ BEG and END default to the buffer boundaries. (widen) (setq beg (or beg (point-min)) end (or end (point-max))) (goto-char beg) - (let ((re (concat \\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? + (let ((re (concat \\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? (substring (org-image-file-name-regexp) 0 -2) \\)\\] (if include-linked \\]))) (case-fold-search t) This seems to work in all cases I can think of (see test file below). Let me know if this works for you and i will apply to master when i get home and have git push access. I tried it on some files with images as links, and it works great. Thanks a lot! Alan
[O] check if properties drawer exists before creating or manipulating?
(still trying to set properties automatically when a minor-mode is set, see first message in thread) Is there a simple way to check if the properties drawer exists before creating one? I'm trying to add a hook to org-insert-heading-hook that will create a property drawer if one doesn't exist; I don't want to create a bunch of independent properties drawers. Thanks! Matt
[O] check if properties drawer exists before creating or manipulating?
Is there a simple way to check if the properties drawer exists before creating one? I'm trying to add a hook to org-insert-heading-hook that will create a property drawer if one doesn't exist (see my earlier email, in which I ask,
Re: [O] linebreak after tag of headline in ox-latex.el
Sorry for the delayed answer. Yes, you are right, sort of. In my set-up, the todo ended up as a paragraph environment. I have changed my export class in order to export the todo as a subsection or subsubsection. This gives the correct result. My error is of course in line with the latex paragraph environment being a one-line. However, I used the same .cls file before the update and if I revert back to the earlier version the error is not produced. /rasmus On 10/19/2013 09:08 AM, Nicolas Goaziou wrote: Hello, Rasmus Rempling 400...@gmail.com writes: I export frequently minutes with todos with latex to pdf. I always include planning information, e.g.: * NEXT Check this :Rasmus: DEADLINE: 2013-10-15 tis SCHEDULED: 2013-10-15 tis + some comments After upgrading to (Org-mode version 8.2.1, GNU Emacs 23.4.1 ) the deadline and schedule is not linebreaked after the tag. This gives a unwanted output with all task information on the same line. I cannot reproduce this. Do you use some special class sectionning format? Regards,
Re: [O] check if properties drawer exists before creating or manipulating?
Dnia 2013-10-31, o godz. 10:18:01 Matt Price mopto...@gmail.com napisał(a): Is there a simple way to check if the properties drawer exists before creating one? I'm trying to add a hook to org-insert-heading-hook that will create a property drawer if one doesn't exist (see my earlier email, in which I ask, What about narrowing to the current entry and then searching for the regex in the variable org-property-drawer-re (which see)? Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] check if properties drawer exists before creating or manipulating?
Matt Price mopto...@gmail.com writes: (still trying to set properties automatically when a minor-mode is set, see first message in thread) Is there a simple way to check if the properties drawer exists before creating one? I'm trying to add a hook to org-insert-heading-hook that will create a property drawer if one doesn't exist; I don't want to create a bunch of independent properties drawers. Why can't you set properties directly with org-set-property? It'll create the drawer if it does not exist and reuse the existing drawer if it does. Nick
Re: [O] make new links show as figures?
On 2013-10-31 06:04, Alan Schmitt wrote: r...@rickster.com writes: So it turns out that this is a REALLY simple patch (two characters): +++ b/lisp/org.el @@ -18853,7 +18853,7 @@ BEG and END default to the buffer boundaries. (widen) (setq beg (or beg (point-min)) end (or end (point-max))) (goto-char beg) - (let ((re (concat \\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? + (let ((re (concat \\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? (substring (org-image-file-name-regexp) 0 -2) \\)\\] (if include-linked \\]))) (case-fold-search t) This seems to work in all cases I can think of (see test file below). Let me know if this works for you and i will apply to master when i get home and have git push access. I tried it on some files with images as links, and it works great. Thanks a lot! So, I've done some testing of the export functions (html and latex only) and found the following behaviors with this patch: - HTML - image in description only displayed if the protocol (file:) is included. - LaTeX - same, required file: protocol in description - additionally, pdflatex \includgraphics barfs on any path w/ a =./= path prefix -- this is true for the current implmenation as well. Changing the regexp for in-buffer image expansion to mimic the export behavior is difficult at best. I think the inconsistency is acceptable, and I will documentment the behavior in the `org-display-inline-images' docstring. The latex breakage on paths beginning with =./= should perhaps be addressed in the latex exporter, but this is orthogonal to the current issue. If there is no objection, I will push a fix tonight or tomorrow. rick
Re: [O] make new links show as figures?
So it turns out that this is a REALLY simple patch (two characters): +++ b/lisp/org.el @@ -18853,7 +18853,7 @@ BEG and END default to the buffer boundaries. (widen) (setq beg (or beg (point-min)) end (or end (point-max))) (goto-char beg) - (let ((re (concat \\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? + (let ((re (concat \\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? (substring (org-image-file-name-regexp) 0 -2) \\)\\] (if include-linked \\]))) (case-fold-search t) This seems to work in all cases I can think of (see test file below). Let me know if this works for you and i will apply to master when i get home and have git push access. I tried it on some files with images as links, and it works great. Thanks a lot! [Cook, Malcolm] Hi - I'm trying to follow this thread but having a challenge. Can you please summarize/repeat the original intended effect of this change ~Malcolm So, I've done some testing of the export functions (html and latex only) and found the following behaviors with this patch: - HTML - image in description only displayed if the protocol (file:) is included. - LaTeX - same, required file: protocol in description - additionally, pdflatex \includgraphics barfs on any path w/ a =./= path prefix -- this is true for the current implmenation as well. Changing the regexp for in-buffer image expansion to mimic the export behavior is difficult at best. I think the inconsistency is acceptable, and I will documentment the behavior in the `org-display-inline-images' docstring. The latex breakage on paths beginning with =./= should perhaps be addressed in the latex exporter, but this is orthogonal to the current issue. If there is no objection, I will push a fix tonight or tomorrow. rick
[O] Bug? org-set-tags never uses ido
Greetings, I want to use ido everywhere and wanted to know why this doesn't seem to work for setting org-mode tags (it never has for me). Using edebug to step through the call to org-icompleting-read which org-set-tags does I can see that it never gets to using ido since the last condition below is false: org.el:10147-10150 (package repository version 20131028): (if (and org-completion-use-ido (fboundp 'ido-completing-read) (boundp 'ido-mode) ido-mode (listp (second args))) This is not strange, since org-icompleting-read is called like this in org-set-tags: org.el:14519-14521 (org-icompleting-read Tags: 'org-tags-completion-function nil nil current 'org-tags-history)) ido apparently needs a list of possible completions, not a single symbol. I don't understand much more of this really. Is it a bug? Have I misunderstood something? Greetings, Anders Johansson
Re: [O] Arbitrary lisp functions in column-attributes
Hello all,
Since the formatting on my earlier post was bad, I'm re-posting this
with a bit more information:
I would really appreciate it if it were possible to specify an
arbitrary lisp function to process node-properties when creating a
column view. Currently it is possible to have something like:
* Top node for columns view
:PROPERTIES:
:COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
:END:
But I'd like to be able to do something like:
:COLUMNS: %ITEM{fn:process_item}(My Column Heading Name) %TAGS
%PRIORITY %TODO
which would pass the ITEM property's value as a single argument to the
process_item function. The returned value/string of the function
would be what appears in the column view.
Of course one should also be able to use a lambda expression in place
of the function name.
Does this sound like something worth working on? I would certainly
have various uses for such functionality, so I imagine it would be
useful to others as well.
I understand that there is the org-collector module, but this isn't
quite sufficient. Although it permits arbitrary lisp expressions, it
doesn't allow one to customize what's printed for the column-headers,
like a normal columnview block would allow.
Regards,
Mark
Re: [O] make new links show as figures?
On 2013-10-31 12:20, Cook, Malcolm wrote: So it turns out that this is a REALLY simple patch (two characters): +++ b/lisp/org.el @@ -18853,7 +18853,7 @@ BEG and END default to the buffer boundaries. (widen) (setq beg (or beg (point-min)) end (or end (point-max))) (goto-char beg) - (let ((re (concat \\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? + (let ((re (concat \\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+? (substring (org-image-file-name-regexp) 0 -2) \\)\\] (if include-linked \\]))) (case-fold-search t) This seems to work in all cases I can think of (see test file below). Let me know if this works for you and i will apply to master when i get home and have git push access. I tried it on some files with images as links, and it works great. Thanks a lot! [Cook, Malcolm] Hi - I'm trying to follow this thread but having a challenge. Can you please summarize/repeat the original intended effect of this change To make images in link descriptions (e.g, [[file.dot][file.png]] displayed inline rather than showing the text (file.png) So, I've done some testing of the export functions (html and latex only) and found the following behaviors with this patch: - HTML - image in description only displayed if the protocol (file:) is included. - LaTeX - same, required file: protocol in description - additionally, pdflatex \includgraphics barfs on any path w/ a =./= path prefix -- this is true for the current implmenation as well. Changing the regexp for in-buffer image expansion to mimic the export behavior is difficult at best. I think the inconsistency is acceptable, and I will documentment the behavior in the `org-display-inline-images' docstring. The latex breakage on paths beginning with =./= should perhaps be addressed in the latex exporter, but this is orthogonal to the current issue. If there is no objection, I will push a fix tonight or tomorrow. rick
Re: [O] make new links show as figures?
r...@rickster.com writes: So, I've done some testing of the export functions (html and latex only) and found the following behaviors with this patch: - HTML - image in description only displayed if the protocol (file:) is included. - LaTeX - same, required file: protocol in description - additionally, pdflatex \includgraphics barfs on any path w/ a =./= path prefix -- this is true for the current implmenation as well. Changing the regexp for in-buffer image expansion to mimic the export behavior is difficult at best. I think the inconsistency is acceptable, and I will documentment the behavior in the `org-display-inline-images' docstring. Consistency would be nice, but then we might start asking for more, such as following attr_html attributes (width, for instance). It's very useful like this, to check before exporting that the link to the expected image is indeed correct. Thanks, Alan
Re: [O] Arbitrary lisp functions in column-attributes
Hi Mark, This seems like an intriguing idea. I have just one question: how would this interact with editing in column view? Would function-valued property columns be read only? Or do you have something different in mind? -- Aaron Ecay
Re: [O] [RFC] [PATCH] [parser] org-element.el: Handle block parameters
Hi Nicolas, 2013ko urriak 31an, Nicolas Goaziou-ek idatzi zuen: [...] Moreover, your proposal, IMO, is not well-enough defined. You merely add a free-form string and call it parameters. Parameters for what? Which syntax: a plist, switches? I think a plist would work fine, indeed. Why cannot some parameters fit into other affiliated keywords (e.g. HEADER)? Very interesting. I did not realize that #+header: could apply to elements other than babel blocks. (Babel blocks are all that is documented in the manual, for example.) But a quick experiment shows that they can. I think #+header with a plist can accomplish all of what I wanted. So, if this is a reliable component of org syntax, I will focus on documenting it in the manual. If you like, I will also remove the references to block parameters on worg (or you can do it if you’d rather, since I think you originally wrote the syntax document). Thanks, -- Aaron Ecay
Re: [O] [RFC] [PATCH] [parser] org-element.el: Handle block parameters
Hello, Aaron Ecay aarone...@gmail.com writes: Very interesting. I did not realize that #+header: could apply to elements other than babel blocks. (Babel blocks are all that is documented in the manual, for example.) But a quick experiment shows that they can. I think #+header with a plist can accomplish all of what I wanted. HEADER is not parsed as a plist but as a list of strings (one per keyword). Internally, Babel parses it differently (as an alist). So, if this is a reliable component of org syntax, I will focus on documenting it in the manual. What feature do you want to document? At the moment, HEADER keywords are only used on src blocks, by Babel, and this is already documented. If you like, I will also remove the references to block parameters on worg (or you can do it if you’d rather, since I think you originally wrote the syntax document). Please go ahead. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Do not declare drawers to use them
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 21.10.2013, at 12:03, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: I think one objection agains this patch is that, I think, MobileOrg relies on #+DRAWERS lines to be present to define drawers. The patch also contains org-mobile.el modifications. Maybe the MobileOrg maintainers for both Android and iOS can chime in here? Obviously, a double check cannot hurt. Otherwise I don't have a significant objection against this change. I am wondering if it is going to introduce spurious drawers and parsing errors if someone happens to have a string :xxx: on a line by itself in the buffer. This might be unlikely, but I am not really sure. Actually, as far as the parser goes, :xxx: is insufficient to define a drawer. Indeed, the drawer has to be complete, i.e. it has to contain the :END: part. An incomplete drawer does not trigger a parsing error: it is parsed as a mere paragraph. OK, sounds good to me, then. Applied. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Longtable continuation strings customizable
Nicolas Goaziou n.goaz...@gmail.com writes:
In a nutshell:
(defun my-personal-table-continuation-strings (row backend info)
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string
multicolumn{[0-9]+}{l}{\\(.*\\)} \\ldots\\ continued from previous
page
(replace-regexp-in-string
multicolumn{[0-9]+}{r}{\\(.*\\)} continued on next page \\ldots
row nil t 1) nil t 1)))
Thanks again for your patience and help. This works!
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] Org Mode Customization Survey 2013
All As discussed a few days ago on this list, Carsten and the other developers are interested in what and how us users are customizing Org mode. This was first done in 2009, so a re-do of the survey is useful as is for how people are using Org now, as well as a comparison to the past. Carsten provided the function that was used before to collect the raw data and I am working on the data collection and summarization this time around. I have place the function on Github, https://github.com/SkydiveMike/org-customization-survey The raw elisp is at: https://raw.github.com/SkydiveMike/org-customization-survey/master/org-customization-survey.el All you need to do is: 1. Load and eval the function 2. Execute (interactive) org-customization-survey 3. Review the buffer, cleanse for sensitive information if any 4. Email the buffer to mike.mcl...@pobox.com (If your Emacs is configured for email, C-c C-c will send) Mike
Re: [O] Bug? org-set-tags never uses ido
Anders Johansson mejlaande...@gmail.com writes: Greetings, I want to use ido everywhere and wanted to know why this doesn't seem to work for setting org-mode tags (it never has for me). Using edebug to step through the call to org-icompleting-read which org-set-tags does I can see that it never gets to using ido since the last condition below is false: org.el:10147-10150 (package repository version 20131028): (if (and org-completion-use-ido (fboundp 'ido-completing-read) (boundp 'ido-mode) ido-mode (listp (second args))) This is not strange, since org-icompleting-read is called like this in org-set-tags: org.el:14519-14521 (org-icompleting-read Tags: 'org-tags-completion-function nil nil current 'org-tags-history)) Hmm, shouldn't that 'org-tags-completion-function be replaced with org-last-tags-completion-table? A quick test shows that works, and from glancing at the code it seems like org-last-tags-completion-table should hold the proper assortment of tags... E ido apparently needs a list of possible completions, not a single symbol. I don't understand much more of this really. Is it a bug? Have I misunderstood something? Greetings, Anders Johansson
[O] Beamer and org-language source blocks?
Maybe there is something obvious I'm missing, but I'm having considerable
trouble using org-language source code blocks in Beamer export.
The objective is to show a little of the org code that made the
presentation. This means including some headers. I had thought that
declaring the source code block to be in org mode would cause it to ignore
headings inside, but I haven't found the incantation to make it do that.
I've customized org-babel-load-languages to include Org.
** What I mean and what I see
#+begin_src org :exports code
** Overview
*** This talk will cover:
- bla bla
#+end_src
-- And in the output, you can see that it takes ** Overview as a new
frame and treats the #+begin/end_src markers as regular text. Huh?
\begin{frame}[label=sec-2-3]{What I mean and what I see}
\#+begin$_{\text{src}}$ org :exports code
\end{frame}
\begin{frame}[label=sec-2-4]{Overview}
\begin{block}{This talk will cover:}
\begin{itemize}
\item bla bla
\end{itemize}
\#+end$_{\text{src}}$
\end{block}
\end{frame}
I hope there's a way to do this. Or, do I have to use a screenshot from
Emacs? (Screenshot? Of source code?)
hjh
Re: [O] Writing Challenge
I'm really sorry I didn't reply sooner. I was out of town, and then I forgot to follow up. On Oct 27, 2013, at 2:07 AM, Alan Schmitt alan.schm...@polytechnique.org wrote: Hi Ivan, darthand...@gmail.com writes: Very interesting! I have been working on a mode which gives the current word-count, WPM and an estimate of the time it will take to hit today's quota in the modeline. I would be interested in feedback as well as integrating it with your spreadsheet. You can find it at https://bitbucket.org/gvol/nanowrimo.el I've been looking at your mode, and I find it very interesting. Here are a couple typos I've found (for documentation strings): - documentation of nanowrimo-total-goal should be How many words you would like to write in total. - documentation of nanowrimo-today-goal should be How many words you would like to write today. - documentation of nanowrimo-org-table-name should be Name of the table where goals are tracked. Thanks. Those are fixed now. Finally, it would be great if nanowrimo-today-goal could be computed from the quota part of the spreadsheet. That's is a good idea. You can now customize `nanowrimo-today-goal-calculation-function' and `nanowrimo-finish-functions' to update today's goal and progress. Perhaps I should make them default to the correct values since they should be no-ops if you are not in org-mode. But I haven't tested that all. Nor have I tested the case when you use org-mode, but don't have the table inserted (which you can do with `nanowrimo-insert-org-table'). -Ivan
