Re: [O] [RFC] Official Org manual in Org! (Was: Dog food, anyone?)
Hi all, my 2 cents. 1. Now that we know that it is possible to construct a texi document from org automatically, whould it be feasible to get back to the topic of converting the Emacs manual(s) to org? Would it make sense? 2. Re: the style guide: why not ditch em-dashes altogether? Quoting Robert Brighurst: , | The em dash is the nineteenth-century standard, still prescribed by | many editorial style books, but the em dash is too long for use with | the best text faces. Like the oversized space between sentences, it | belongs to the padded and corseted aesthetic of Victorian | typography. Use spaced en dashes – rather than em dashes or hyphens – | to set off phrases. ` In case you think this is not something of utmost importance: I quoted Bringhurst after the article http://www.denizcemonduygu.com/2009/09/where-to-use-en-and-em-dashes-lupton-vs-bringhurst/, where this gem can be found: , | The en dash between your birth and death dates on your headstone will | be representing your whole life. All your joys and sorrows, adventures | and disappointments, tucked in something slightly longer than a hyphen | and shorter than an em dash. So go on ignoring them. The dashes will | have the last word. ` Best, Marcin On 2017-12-17, at 19:58, Kaushal Modi wrote: > Hi Nicholas, > > Thanks for taking up this humongous project. It was a dream of many like me > to eventually read and maintain the Org manual in Org :) > > To be honest, I discarded this email by instinct by just reading the title > "Dog food, anyone?", as I assumed that email to be from my neighborhood > community, with someone giving away their extra dog food (literally).. and > I don't own dogs.. so off the email went.. to my "read bin".. :) > > It wasn't until few minutes back that I realized what this email was and > that it was actually on the Org list.. so changing the title for more > visibility. > > This arduous task shouldn't go unrecognized. > > -- Forwarded message - > From: Nicolas Goaziou > Date: Sun, Dec 17, 2017 at 5:35 AM > Subject: [O] [RFC] Dog food, anyone? > To: Org Mode List > > > Hello, > > The task started by Thomas S. Dye a couple years ago is now complete. > The "manual.org" file in "contrib/" directory is an up-to-date, > sometimes enhanced, version of the Org manual. Org can now eat its own > dog food. > > During the process, I had to re-organize some parts of the manual (e.g., > "Working with source code" section, the concept index...) and improve > the "texinfo" export back-end, which was not up to the task when Thomas > started it. > > Ultimately, this file is going to serve as the source for a new > "org.texi". IOW, it could go into "doc/" and "make info" should export > "manual.org" to "org.texi". First, however, it would be nice to review > it, either as an Org file, or within the Info viewer, with > >(require 'ox-texinfo) > > and > >`C-c C-e i o' from "manual.org". > > Note that Info output is expected to be sometimes different from the > current manual. This is not a 1:1 conversion. > > Feedback welcome! > > > Regards, > > -- > Nicolas Goaziou0x80A93738 -- Marcin Borkowski
Re: [O] advice please: best way to export to DOC(X) with maths
Thanks! I will experiment with this work-flow, but i have one other issue, any advice on working with existing (word) document templates? I have to work within templates, so it would be great if i could manage to conform. On 19 December 2017 at 06:09, wrote: > On 2017-12-15 12:28, Eric S Fraga wrote: > >> On Friday, 15 Dec 2017 at 03:20, ed...@openmail.cc wrote: >> >> [...] >> >> I only know how to do a rough approximation by means of pandoc: >>> >>> #+BEGIN_SRC bash >>>pandoc -f org+smart my-original.org -t docx+smart -o my-output.docx >>> #+END_SRC >>> >> >> What version of pandoc are you using? My Debian (testing) has pandoc >> 1.19.2.4 and it does not seem to recognise the +smart bits... >> >> But, in any case, pandoc (without the smart bits) does seem to do a >> reasonable job and creates proper maths entities. This is good enough >> for me! My once a year pain is relieved. :-) >> >> Thanks, >> eric >> > > I'm sorry for the very late response (deadlines). I will check for the > pandoc version and let you know. One of the distros that I use is a rolling > linux. The other one is the same as yours. I would also like to note that I > got the pandoc snippet from Dr. Kitchin's website: > http://kitchingroup.cheme.cmu.edu/blog/2015/01/29/Export-org > -mode-to-docx-with-citations-via-pandoc/ > > I checked, and I am very satisfied with ~C-c C-e o o~. I set #+OPTIONS: > dvipng. You can't edit the formulas, but I don't care about that. All my > equations look fine and the pictures too. I also have to copy my references > by hand, but that is the least of my issues, and I only do it when the > final version is ready. I also get my source blocks right. > > I think that the only thing which is really missing from Org as related to > exporting is handling pictures inside tables (a way to create subfigures). > There is a partial solution with ox-latex-subfigure [[ > https://github.com/linktohack/ox-latex-subfigure]], but is limited in the > :width parameter. One of these days I will learn LISP and implement it > myself (unless another brave soul goes for it first). Even Beamer columns > can be used to this end, but this would only work for presentations. I > don't know any other way. > > > - > > ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of > the NSA's hands! > $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No > bandwidth quotas! > Commercial and Bulk Mail Options! >
[O] org-gcal error http 400 - 401
Hello, >From yesterday, I am trying to use org-gcal, and I am near to succeed to connect it with my google calendar with org-gcal-fetc, but after receiving the authorization code from Google to connect emacs, I always see the same error message: Wrote /home/joseph/MEGA/org/agenda.org > (New file) > Wrote /home/joseph/MEGA/org/todo.org > Make /home/joseph/MEGA/git/scimax/userorg-gcal/.org-gcal-token [2 times] > Got error: (error http 401) > Got error: (error http 400) > (error http 400) Version of thie emacs: joseph@joseph-MS-7996 ~ $ emacs --version GNU Emacs 27.0.50 I tried with emacs 25 and I had this error: > request: Symbol’s function definition is void: record > The help of users of org-gcal will be very welcome. Best wishes, Jo.
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen writes:
> Eric Abrahamsen writes:
>
>> Rasmus writes:
>>
>>> Eric Abrahamsen writes:
>>>
Eric Abrahamsen writes:
> Rasmus writes:
>
>> Kaushal Modi writes:
>>
>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus wrote:
>>>
The only way it’s "bad" is in the sense it limits the flexibility of
snippets, like ">>> block
I can no longer have "
> I don't see any way around that. Any system that allows string keys of
> arbitrary length is going to run into that problem.
One possible fix, a bit arbitrary: in the default value, provide
as an artificial "stop key" in the sub-menus. So "s" starts the "source
code" sub-menu, and a after that simply inserts "#+begin_src", and
leaves point after that.
>>>
>>> Yeah, I tried to suggest that earlier (unless I didn’t say it), but I
>>> might not have expressed the idea in an understandable manner :)
>>
>> Maybe I missed it!
>>
>>> I think that would be the best approach, but there’s no infrastructure
>>> that I know of that does this ATM (but I haven’t had a lot of time lately,
>>> so my knowledge on this issue is limited!).
>>
>> Can't we do this with tempo? It will have to be "handmade", not
>> automatic, but:
>>
>> '(("s" "Source Code")
>> ("se" "Elisp" "src elisp")
>> ("sp" "Python" "src python")
>> ("TAB" "Empty" "src ")
>> ...etc
>> ("e" "Export Block")
>> ("eh" "HTML" "export html")
>> ("el" "LaTeX" "export latex")
>> ("TAB" "Empty" "export ")
>> ...etc
>> ("v" "Verbatim" "verbatim")
>> ("q" "Quote" "quote")
>> ("E" "Example" "example")
>> ...etc
>> )
>
> Ahem, should have actually tried that first:
>
> (org-mks
> '(("s" "Source Code")
>("se" "Elisp" "src elisp")
>("sp" "Python" "src python")
>("s\t" "Empty" "src ")
>("e" "Export Block")
>("eh" "HTML" "export html")
>("el" "LaTeX" "export latex")
>("s\t" "Empty" "export ")
>("v" "Verbatim" "verbatim")
>("q" "Quote" "quote")
>("E" "Example" "example"))
> "Insert Block" "Block: ")
>
> It's a bit ugly, but it works...
Great find; I didn’t realize we can use tab here!
I’ll try to build the mks list automatically. It will be a bit annoying,
as we’ll have to figure out valid keys for things like "prop".
Rasmus
--
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] TIL about use of eval in user Org macros.. Documentation?
Kaushal Modi writes:
> Hello,
>
> The commit message in this commit is golden:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=3ac619c8ac9934a2a1368f3de8ffad951f900067
>
> Using that info, I came up with a "classified" version of n macro for
> markdown/HTML:
>
> #+MACRO: sec (eval (concat "" (number-to-string
> (org-macro--counter-increment $1 $2)) ""))
>
> Based on that I have two questions:
> 1. Can you please document the use of eval form in Org macro definitions
> in the Org manual(.org)? Its awesome wasn't evident to me until I read
> that commit message.
I guess it isn’t documented in the manual...
I agree, there could be a second example and the mention of using lisp or
at least a mention of the ‘org-export-global-macros’ docstring.
> 2. (Another question on canonical approach) What would be the recommended
> approach for an exporter backend to add new
> macros or override existing macros (like "n" macro to wrap the string with
> HTML class as an example)? Should it update
> org-macro-templates in org-export-before-processing-hook? or something
> similar?
Do you really need to overwrite an old macro? Couldn’t you define a new
macro? org-export-before-processing-hook is definitely the right hook,
cf. ‘org-export-as’.
(defun fooreplace (backend)
(when (eq backend 'mybackend)
(goto-char (point-min))
(while (search-forward-regexp "{{{foo\\((?\\)" nil t)
(replace-match "{{{myfoo\\1"))
(goto-char (point-max))
(insert "\n#+macro: myfoo mybar\n"
Rasmus
--
May contains speling mistake
Re: [O] Git repository error
And works for me as well. Thank you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.4-214-ge8b71b signature.asc Description: PGP signature
Re: [O] [UPDATE] Re: ob-clojure evaluate error when Org-mode buffer has ns clojure code
Finally found a solution. really hard. spend a lot of time on this issue. The discussion is at here: https://github.com/clojure-emacs/clojure-mode/pull/465 Here is my final source code. paste here as a copy. Hope can help someone want same thing. ;; auto start CIDER REPL session in a complete Leiningen project environment for Org-mode Babel by jack-in. (add-to-list 'org-babel-default-header-args:clojure '(:session . "*cider-repl ob-clojure*")) (progn (find-file (expand-file-name "~/.emacs.d/Org-mode/ob-clojure/src/ob_clojure/core.clj")) (cider-jack-in)) (defun ob-clojure-cider-do-not-find-ns () "Fix the issue that `cider-current-ns' try to invoke `clojure-find-ns' to extract ns from buffer." (with-current-buffer "*cider-repl ob-clojure*" (defvar ob-clojure-cider-repl-ns cider-buffer-ns) (setq-local cider-buffer-ns ob-clojuure-cider-repl-ns))) (add-hook 'org-mode-hook #'ob-clojure-cider-do-not-find-ns) [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Tue, Dec 19, 2017 at 5:54 PM, stardiviner wrote: > I got new update on this issue. > > I think it is caused by `(clojure-find-ns)`. > Here is my found: > > I created a simple clojure project for used by all org-babel-clojure src > blocks. > ```elisp > (progn > (find-file (expand-file-name "~/.emacs.d/Org-mode/ob-clojur > e/src/ob_clojure/core.clj")) > (cider-jack-in)) > ``` > > I edebug the `org-babel-execute:clojure` process, > > `org-babel-execute:clojure' has a step: ~(clojure-find-ns)~ . > This is from ~clojure-mode~. It will find current clojure buffer possible > clojure namespace (even in org-mode). When I the following example org-mode > buffer, it will return "namespace-not-found" error in nrepl response dict. > Then src blcok has no error, not results. > > ```org > #+BEGIN_SRC clojure :session > (in-ns 'user-kk) > or > (ns user-kk) > #+END_SRC > > #+BEGIN_SRC clojure :results output > (print "hi") > #+END_SRC > ``` > > Here is a part of function `clojure-find-ns`: > > #+begin_src emacs-lisp > (when (or (re-search-backward clojure-namespace-name-regex nil t) > ;; Or any form at all. > (and (goto-char (point-min)) > (re-search-forward clojure-namespace-name-regex nil > t))) > (match-string-no-properties 4)) > #+end_src > > So I created an PR to disable find namespace in Org-mode buffer: > https://github.com/clojure-emacs/clojure-mode/pull/465 >
Re: [O] [RFC] Dog food, anyone?
Nicolas Goaziou writes: > Hello, > > The task started by Thomas S. Dye a couple years ago is now complete. > The "manual.org" file in "contrib/" directory is an up-to-date, > sometimes enhanced, version of the Org manual. Org can now eat its own > dog food. > > During the process, I had to re-organize some parts of the manual (e.g., > "Working with source code" section, the concept index...) and improve > the "texinfo" export back-end, which was not up to the task when Thomas > started it. Good stuff! My question about this and your experiences with ox-texinfo, is would it be possible to integrate this into a workflow where a manual was converted piece-meal. So, if a texinfo manual was multi-part (like the Emacs manual for instance), it could be converted one file at a time, rather than having to do the whole lot. Phil
Re: [O] [RFC] Dog food, anyone?
Hello, phillip.l...@russet.org.uk (Phillip Lord) writes: > Nicolas Goaziou writes: > >> Hello, >> >> The task started by Thomas S. Dye a couple years ago is now complete. >> The "manual.org" file in "contrib/" directory is an up-to-date, >> sometimes enhanced, version of the Org manual. Org can now eat its own >> dog food. >> >> During the process, I had to re-organize some parts of the manual (e.g., >> "Working with source code" section, the concept index...) and improve >> the "texinfo" export back-end, which was not up to the task when Thomas >> started it. > > > Good stuff! > > My question about this and your experiences with ox-texinfo, is would it > be possible to integrate this into a workflow where a manual was > converted piece-meal. > > So, if a texinfo manual was multi-part (like the Emacs manual for > instance), it could be converted one file at a time, rather than having > to do the whole lot. You can use #+INCLUDE keywords for that. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] [RFC] Official Org manual in Org!
Hello, Marcin Borkowski writes: > 1. Now that we know that it is possible to construct a texi document > from org automatically, whould it be feasible to get back to the topic > of converting the Emacs manual(s) to org? Would it make sense? I doubt Org will become the de facto standard for Emacs documentation. Two co-existing formats imply maintenance burden. In any case, this should probably be discussed on Emacs-devel ML. > 2. Re: the style guide: why not ditch em-dashes altogether? Even though you're preaching to the choir, I think the main argument in favor of em-dashes is that GNU Emacs manual uses them. There should be some typographic consistency between GNU manuals. Regards, -- Nicolas Goaziou
Re: [O] Bug: Tangling python code results in mixed tabs and spaces, incomaptible with python3 [9.1.4 (9.1.4-dist @ /home/ehere/emacs-scripts/org-9.1.4/lisp/)]
Hello, Edmund Christian Herenz writes: > The following python code uses only whitespaces for the different > indentdation levels: > > a_list = ['elem1', > 'elem2', > 'elem3'] > > for elem in a_list: > print(elem) > for char in elem: > print char > > I enter this code into a SRC block with > > #+BEGIN_SRC python :tangle blank_test.py > > #+END_SRC > > by pressing C-' inside the block (which opens the editing buffer > python-mode). Then I press C-' again, after which I tangle the code > to blank_test.py by pressing C-u C-c C-v C-t. The resulting file > blank_test.py will contain a mix of tabs and spaces for the different > intendation levels. (I checked this with whitespace.el). > > Above behaviour is a bug, since Python3 forbids mixing of spaces and > tabs. (Python2 is more relaxed about mixing of tabs and spaces). Thus, > the above code, syntactical correctly entered into an OrgSrc buffer, > will result in code that can not be run in python3 when tangled from > an org-mode file. Have you tried "-i" switch for the block, i.e., #+BEGIN_SRC python -i :tangle blank_test.py Regards, -- Nicolas Goaziou
Re: [O] Canonical way to strip off all markup from an element in Org exporter backend?
Hello, Kaushal Modi writes: > Thank you! That function is educational. I'll play more with that idea. It > will be a lot more verbose than the 3 line solution I have right now.. (let ((no-thrill (lambda (o c _) (or c (org-element-property :value o) (org-export-create-backend :parent 'ascii ;or `hugo', depending on what you mean :transcoders (mapcar (lambda (type) (cons type no-thrill)) '(bold code italic strike-through underline verbatim Five locs. Not bad either. > It can be used wherever just the element content is needed without > formatting properties, like in my case where the element title is needed to > be extracted without any formatting. So far, no major back-end needs this. Also, it is very simple to provide the back-end above. > I haven't yet invested any time into serious development of this "base > class" backend. The idea of this exporter is to give formatting-free output > (like when you select plain text option in an email client).. so at whim, > entities will be translated to the correct unicode chars, footnotes > behavior could be the same as ox-ascii, and latex-snippets can stay in the > raw ascii form. You're basically describing `ox-ascii' with stripped emphasis markers. At this point, I'm not convinced we need this in Org proper. Regards, -- Nicolas Goaziou0x80A93738
[O] Error when using :show-process header argument in clojure
Hi I was trying to use the new :show-process header argument for clojure in Org mode version 9.1.4 (9.1.4-13-g84cb63-elpaplus @ (org-plus-contrib-20171218/) I get the following error: org-babel-insert-result: Wrong type argument: markerp, nil
Re: [O] Git repository error
Works for me too! Thanks, Sam -- Samuel W. Flint 4096R/266596F4 (9477 D23E 389E 40C5 2F10 DE19 68E5 318E 2665 96F4) λs.(s s) λs.(s s)
Re: [O] [RFC] Dog food, anyone?
Nicolas Goaziou writes: >> Good stuff! >> >> My question about this and your experiences with ox-texinfo, is would it >> be possible to integrate this into a workflow where a manual was >> converted piece-meal. >> >> So, if a texinfo manual was multi-part (like the Emacs manual for >> instance), it could be converted one file at a time, rather than having >> to do the whole lot. > > You can use #+INCLUDE keywords for that. I was wondering the other way around. Can org produce .texi that could be part of a larger existing texinfo. So, something that can be @include'd. Phil
Re: [O] [RFC] Dog food, anyone?
phillip.l...@russet.org.uk (Phillip Lord) writes: > I was wondering the other way around. Can org produce .texi that > could be part of a larger existing texinfo. So, something that can be > @include'd. I don't see why it couldn't. Do you have any difficulty in mind?
Re: [O] Git repository error
Works here too. Thanks! -- Nick
Re: [O] [RFC] Dog food, anyone?
Nicolas Goaziou writes: > phillip.l...@russet.org.uk (Phillip Lord) writes: > >> I was wondering the other way around. Can org produce .texi that >> could be part of a larger existing texinfo. So, something that can be >> @include'd. > > I don't see why it couldn't. Do you have any difficulty in mind? Oh, might even be trivial things. I mean, emacs.texi contains a "title" statement, but none of its include files do. Also, cross references, I believe have to be unique within a file and all include files. Phil
Re: [O] Bug: Editing src blocks: user-error: Cannot modify an area being edited in a dedicated buffer [9.1.4 (9.1.4-2-g118753-elpaplus @ /home/paul/.emacs.d/elpa/org-plus-contrib-20171211/)]
Turns out that the issue was caused by trying to disable a flycheck checker using the org edit src hook On Mon, Dec 18, 2017, 6:30 AM Nicolas Goaziou wrote: > Hello, > > Paul Davis writes: > > > Using ~C-c '~ to edit a src block works as expected, but if I make > > changes and use ~C-c '~ again, I get the error ~Cannot modify an area > > being edited in a dedicated buffer~ > > I need more information. Where do you make changes? In the newly created > buffer? Where do you call ~C-c '~? > > For example, I created the following buffer > > #+begin_src emacs-lisp > (+ 1 2) > #+end_src > > moved on the source block, used C-c '. Then, in the new buffer, > I replaced 2 with 3 and pressed C-c ' again, without any error? > > IOW, could you provide a precise recipe demonstrating the issue? > > Thank you. > > Regards, > > -- > Nicolas Goaziou >
[O] [patch] Snippet expansion
Hi,
The first patches adds string keys to snippet expansion. For tempo, this
is straight-forward.
For the interactive prompt there’s an org-mks interface. It limited to at
most two keys (this shouldn’t be much of a limitation TBH). So for
instance if the key is "prop" the interactive prompt will be "p", "pr",
"po" or "pp".
The second patch are various improvements for org-tempo, e.g. to put the
cursor at a better place. org-tempo now also do some checks wrt. new
structure templates.
The third patch is more experimental and tries to be more "clever" when
using the interactive interface, e.g. with newlines. The code is now a
lot more complicated, and I’m not sure it’s any more pleasant or
DWIMish...
Thanks,
Rasmus
--
Vote for Dick Taid in an election near you!
>From 369a79e2190726aed2aa5dbe71fe2e99d9a59b86 Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Thu, 21 Dec 2017 12:55:35 +0100
Subject: [PATCH 2/4] org-structure-template-alist: Use string keys
* lisp/org-tempo.el (org-tempo-keywords-alist):
(org-tempo-setup):
(org-tempo-add-templates): Use string keys
* lisp/org.el (org-structure-template-alist): Use string keys.
(org-insert-structure-template--mks):
(org-insert-structure-template--unique-keys): New functions for block selection.
(org-insert-structure-template): Use new block selection.
fix
---
lisp/org-tempo.el | 13
lisp/org.el | 98 +++
2 files changed, 85 insertions(+), 26 deletions(-)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index 86e7b51eb..92a97c752 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -51,10 +51,10 @@
"Tempo tags for Org mode")
(defcustom org-tempo-keywords-alist
- '((?L . "latex")
-(?H . "html")
-(?A . "ascii")
-(?i . "index"))
+ '(("L" . "latex")
+("H" . "html")
+("A" . "ascii")
+("i" . "index"))
"Keyword completion elements.
Like `org-structure-template-alist' this alist of KEY characters
@@ -76,6 +76,7 @@ For example \" n n
@@ -114,7 +115,7 @@ Goes through `org-structure-template-alist' and
(defun org-tempo-add-keyword (entry)
"Add keyword entry from `org-tempo-keywords-alist'."
- (let* ((key (format "<%c" (car entry)))
+ (let* ((key (format "<%s" (car entry)))
(name (cdr entry)))
(tempo-define-template (format "org-%s" (replace-regexp-in-string " " "-" name))
`(,(format "#+%s: " name) p '>)
diff --git a/lisp/org.el b/lisp/org.el
index e66e6d543..10e7682af 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11876,16 +11876,16 @@ keywords relative to each registered export back-end."
"TITLE:" "TODO:" "TYP_TODO:" "SELECT_TAGS:" "EXCLUDE_TAGS:"))
(defcustom org-structure-template-alist
- '((?a . "export ascii")
-(?c . "center")
-(?C . "comment")
-(?e . "example")
-(?E . "export")
-(?h . "export html")
-(?l . "export latex")
-(?q . "quote")
-(?s . "src")
-(?v . "verse"))
+ '(("a" . "export ascii")
+("c" . "center")
+("C" . "comment")
+("e" . "example")
+("E" . "export")
+("h" . "export html")
+("l" . "export latex")
+("q" . "quote")
+("s" . "src")
+("v" . "verse"))
"Structure completion elements.
This is an alist of characters and values. When
`org-insert-structure-template' is called, an additional key is
@@ -11898,20 +11898,78 @@ corresponding structure is inserted, with \"#+BEGIN_\" and
(string :tag "Template")))
:package-version '(Org . "9.2"))
+(autoload 'org-mks "org-capture" "Select a member of an alist with multiple keys." t)
+
+(defun org-insert-structure-template--mks ()
+ "Present `org-structure-template-alist' with `org-mks'.
+
+- Menus are added if keys require more than one stroke.
+- Tabs are added to single key entires when needing more than one stroke.
+- Keys longer than two characters are reduced to two characters."
+ (let* (case-fold-search
+ (keys (mapcar 'car org-structure-template-alist))
+ (start-letters (delete-dups (mapcar (lambda (key) (substring key 0 1)) keys)))
+ (mks (mapcar (lambda (letter)
+(list letter
+ (cl-remove-if-not
+ (apply-partially 'string-match-p (concat "^" letter))
+ org-structure-template-alist :key 'car)))
+ start-letters)))
+(org-mks
+ (apply 'append
+(mapcar (lambda (sublist)
+ (if (eq 1 (length (cadr sublist)))
+ (mapcar (lambda (elm)
+(list (substring (car elm) 0 1)
+ (cdr elm) ""))
+ (cadr sublist))
+(let* ((topkey (car sublist))
+ (elms (cadr sublist))
+ (keys (mapcar 'car elms))
+ (longp (> (length elms) 3)))
+ (append
+
[O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you. --- Begin Message --- Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. org-clock-in in org-clock.el calculates org-clock-total-time via calling (org-clock-sum-current-item (org-clock-get-sum-start)). However, org-clock-get-sum-start returns the time in UTC, which is not considered by org-clock-sum-current-time. My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence org-clock-total-time is gives total time starting from 8am today (which is midnight in UTC) instead of midnight in UTC+8. Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit) of 2017-12-06 Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/) -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature --- End Message ---
Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
On Thu, Dec 21, 2017 at 5:55 PM, Ihor Radchenko wrote: > > org-clock-in in org-clock.el calculates org-clock-total-time via calling > (org-clock-sum-current-item (org-clock-get-sum-start)). > However, org-clock-get-sum-start returns the time in UTC, which is not > considered by org-clock-sum-current-time. > > My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence > org-clock-total-time is gives total time starting from 8am today (which > is midnight in UTC) instead of midnight in UTC+8. This sounds like a continuation of Org mode’s timezone issues. The original thread (which is long-winded): http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg0.html http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg00027.html The second bug, also timezone issues: http://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00039.html
[O] make org-fill-paragraph stop fill list headlines.
Hi, given this: >> some text. - a list node. some context. << after filling, it will be: >> some text. - a list node. some context. << possible to stop the joining of the list headline (=a list node.=) and the content (=some context=)? Adding an empty line like: >> some text. - a list node. some context. << will definitely do, but it make the text rather scattered. -- Best, Shiyao
