Re: [O] RFC: changes to the way prefix arguments work for the command org-todo
I have pushed these changes now. Carsten On Tue, Aug 13, 2019 at 10:24 AM Carsten Dominik wrote: > Hi, > > I have been looking at the code for the command org-todo in combination > with the setting of the variable org-use-fast-todo-selection. And I am > frustrated with the complication and special cases, so I would like to > simplify. Much of this complication stems from a time when the fast > selection interface had just been implemented and I was not yet sure if I > and others wanted to use it. I think things can be better. > > But that does changes something with the user interface, so I am trying to > figure out if anyone would be bothered by this change. > > 1. Right now, you can set org-use-fast-todo-selection to `prefix'. With > this setting, fast todo keyword selection is used when you call org-todo > with a prefix argument. I think this is not useful and I would like to > remove that functionality. Is anyone even aware of this effect of C-u and > is using this? > > 2. I want to change org-use-fast-todo-selection to allow these values: >- nilNever use it >- autoUse it, if keys have been defined. This would make it > similar > to the tags selection. I would accept the value `t' to > mean the same, > for backward compatibility >- expert Use it, but do not pop up the window with the selections, > only show them in the prompt (or don't show them at all, am still > considering). This is because I have been bothered by the jumping windows > when I do a selection that I do so many times a day, and where I know the > keys blindly. > > The default setting would be `auto'. I myself would be using `expert'. > > 3. I want to make `C-u C-c C-t' to switch the TODO state and force logging > a time stamp and taking a note. I am already using that functionality (now > harder to access, on `C-u C-u C-u C-c C-t'), I find it very natural and I > think it is often better than configuring automatic note-taking for every > change, at least for my working environment. Automatic note-taking slows > me down too often. > > Any comments? > > Thanks > > - Carsten > > > >
Re: [O] exported contacts problem
Eric Abrahamsen writes: > David Masterson writes: > >> Eric Abrahamsen writes: >> >>> But Org can be an excellent *interface* to those tools, mostly through >>> dynamic blocks. I've started using small sqlite databases to keep track >>> of things, and dynamic blocks as sql composers/views, and it works >>> great. It's very easy to play with the queries, and this is the first >>> time I'm actually starting to feel comfortable with sql. >>> >>> I think in general Org is best used as a compositional tool for data >>> drawn from elsewhere. >> >> What do you think of RDB? It seems to be an old set of Perl scripts >> derived from /rdb (an older set of Unix shell scripts) that can be used >> to do basic relational database commands on textual database tables. If >> it could be translated into an Elisp package, it would fit the Emacs >> model of open source and easily understandable data storage. It can be >> gotten via ftp here: >> >> cdb.netbsd.org/pub/pkgsrc/distfiles/RDB-2.6d.tar.gz > > I've never heard of it! But from your description it kind of sounds like > another attempt to use relational databases without actually using > relational databases :) I guess I think databases are one of those > things you should delegate to an external program. Org is already pretty > good at interfacing with them. The interesting point is that it was originally done as a series of shell scripts (in /rdb) and now is a series of Perl scripts (in RDB) that implement the key features of relational functions using textual tables as a relational database system in the Unix sense. Were I an Elisp expert (which I'm not), each script could probably be translated into Elisp and, rather than pipe from stdin to stdout, it could load the database into an Emacs buffer and then process the result into another buffer. *OR*, since RDB is open source, perhaps an Elisp front-end could be put on it to incorporate it into Org. Just an idea... -- David
Re: [O] Problem with org-mode odt exporter for styling exported src code blocks
On Thursday, 15 Aug 2019 at 12:51, Laurent Geneste wrote: >I try to change the style of src code blocks export with odt >exporter but it does not work as expected. It doesn't work for me either. I struggled with this some time ago and never did figure it out. I did learn a lot about the xml files ODT uses, mind you. ;-) Looking at you two .odt files, the styles.xml files differ *only* in the OrgSrcBlock definition. Is org maybe overriding this somehow/somewhere? Maybe have a look at ox-odt.el and look for the colour "#38393d". -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-401-gfabd6d
[O] Problem with org-mode odt exporter for styling exported src code blocks
Hello all,
I posted the following message in StackOverflow
(https://emacs.stackexchange.com/q/51800/9245):
I try to change the style of src code blocks export with odt
exporter but it does not work as expected.
I first exported my org file to an odt document. Then I changed the
style of *OrgSrcBlock* (red background) and saved my document as a
template file (let's say |mystyle.odt|).
Finally I added |#+ODT_STYLES_FILE: "mystyle.odt"| in the org file
and re-exported but nothing changed in the resulting odt document.
I tried the same procedure for the OrgTile style and it works as
expected (the style is correctly applied in the resulting odt document).
I'm using Org mode version 9.2.4.
I had no clear answer and I wonder if this is a normal behavior of if it
could be a bug in the odt exporter. The behavior is the same with Org
mode version 9.2.5. I attached a set of files (org file, style file,
exported file) to illustrate the problem.
Laurent
* Code
#+name: test
#+begin_src python :results output :exports both
print("First Line")
print("Second Line")
#+end_src
#+RESULTS: test
: First Line
: Second Line
* Config :noexport:
#+options: toc:nil
#+Title: Test ODT exporter
#+ODT_STYLES_FILE: "mystyle.odt"
mystyle.odt
Description: application/vnd.oasis.opendocument.text
codeml.odt
Description: application/vnd.oasis.opendocument.text
Re: [O] Org syntax inside verbatim/literal blocks
> Certainly. Would you want to provide a patch to the manual?
Yes, thank you, patch attached (on top of current maint branch).
I don't know how robust the footnote indexing is, e.g. putting #+cindex
above instead of below [fn] lead to errors during 'make info'; but the
version attached does work (for the texinfo export at least).
--
Štěpán
>From bcd5049620e938c8687f239c10248db3805de721 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=
Date: Thu, 15 Aug 2019 11:57:17 +0200
Subject: [PATCH] org-manual: Index and link to information on literal block
comma escape
* doc/org-manual.org (Escape Character): Mention comma and link to the "Literal
Examples" section.
(Footnotes): Index explanation of comma escape inside literal blocks.
---
doc/org-manual.org | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1418abb50..06d5eb262 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18292,8 +18292,9 @@ init file[fn:146].
You may sometimes want to write text that looks like Org syntax, but
should really read as plain text. Org may use a specific escape
character in some situations, e.g., a backslash in macros (see [[*Macro
-Replacement]]). In the general case, however, we suggest to use the
-zero width space. You can get it with one of the following:
+Replacement]]) or a comma in source code and example blocks (see
+[[*Literal Examples]]). In the general case, however, we suggest to use
+the zero width space. You can get it with one of the following:
: C-x 8 zero width space
: C-x 8 200B
@@ -21354,7 +21355,10 @@ information on evaluating code blocks.
while using line numbers for the links, which might be useful to
explain those in an Org mode example code.
-[fn:117] Upon exit, lines starting with =*=, =,*=, =#+= and =,#+= get
+[fn:117]
+#+cindex: escape character
+#+cindex: comma
+Upon exit, lines starting with =*=, =,*=, =#+= and =,#+= get
a comma prepended, to keep them from being interpreted by Org as
outline nodes or special syntax. These commas are stripped when
editing with {{{kbd(C-c ')}}}, and also before export.
--
2.22.0
Re: [O] Org syntax inside verbatim/literal blocks
Hello,
Štěpán Němec writes:
> I think it would be much more helpful if, instead of a footnote to one
> related special case (`org-edit-special'), this information was indexed
> ("escape character" and "comma" come to mind) and also mentioned in or
> linked to from section 16.3 (Escape Character).
Certainly. Would you want to provide a patch to the manual?
Regards,
--
Nicolas Goaziou
Re: [O] Bug: Language code for Brazilian in org-latex-babel-language-alist and org-latex-polyglossia-language-alist
Hello,
Gustavo Barros writes:
> `org-latex-babel-language-alist' and
> `org-latex-polyglossia-language-alist' have the language code for
> Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and
> our language is Portuguese, and Brazilian Portuguese is a variant.
> That to say that I’ve never seen the language code "bt-br" to refer to
> "brazilian", whereas the usual code is "pt-br" (hyphen or underscore).
> So this looks very much like a typo.
Fixed. Thank you!
Regards,
--
Nicolas Goaziou
Re: [O] Bug: Description of org agenda columns format in manual not correct/misleading
On Wednesday, 14 Aug 2019 at 15:57, Nick Dokos wrote: > "Fraga, Eric" writes: > >> I have this setting in my Emacs initialization: >> >> (setq org-agenda-overriding-columns-format "%5TODO %TIMESTAMP %40ITEM >> %LOCATION %TAGS") >> >> HTH, >> eric > > Shouldn't you be using org-columns-default-format instead? No because it's about setting the columns format for the agenda view alone, not the format for normal org buffers. My error was in using a deprecated variable; the actual variable is org-overriding-columns-format. The OP's post was actually about the documentation (which I misunderstood). -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-401-gfabd6d
