Re: [O] Footnotes in the manual (hidden option?)
Hello, > > > (a) May I propose the [^1] as an alternative footnotes syntax as a new > > feature? > > I sympathize with your concern, and [^1] may not have been a bad choice > when footnotes were introduced, but that ship has sailed long ago. > > There is enough footnote syntax in Org nowadays. I saw only "fn:" related variations in the docs... > I'd rather keep it that > way. Even if somebody else implements this and provides a patch?... Thank you!
Re: [O] Footnotes in the manual (hidden option?)
On Wed, 2018-05-16 at 14:31 -0400, Kaushal Modi wrote: > Hello, > > On Wed, May 16, 2018 at 2:27 PM ST wrote: > > Hello, > > in the manual > > https://orgmode.org/manual/Footnotes.html#Footnotes > > it says that footnotes[fn:1] > > [fn:1] look like this > > > but actually[1] > > [1] works as well and looks even better. > > So why this option is not documented? > > > I would think that's so because canonically Org mode using [fn:1] > style. It looks like you are manually typing the footnote refs and > definitions. > > > Try using C-c C-x f binding.. you will see that Org inserts the > footnotes in the documented style. > > > I would say that the "fn"-style footnotes remove any kind of > ambiguity.. It's true that [1] alone may very well introduce ambiguity, but why not to take something more lightweight and language/alphabet independent, like [^1]? 1. It's three times shorter (its important if you type manually in GitLab/GitHub without the C-c C-x f binding); 2. If you type in another language - you don't have to switch the keyboard; 3. If your text is in another alphabet - latin "fn" disturbs the eye. 4. It feels a bit heavy as a markup for the lightweight org . (a) May I propose the [^1] as an alternative footnotes syntax as a new feature? (b) How can I define such syntax by my own as a footnote? Thank you!
Re: [O] Feature proposal: Triple square brackets to create a link to a file AND include the file
> > What do you mean by "inlined"? > > Roughly, I mean "located within a paragraph". > > > During an export such a link > > [[[dir/file]]] should be replaced with the content of the "file", and > > the link itself disappear. But in the source .org file it is just > > shorter/cleaner way to write > > > > #+INCLUDE: "dir/file" > > This is different. It is easier to insert text at column 0 than at > a random position in a line. You cannot do the latter in Org. Aaa... I see. Actually I don't need it to be in the middle, only at column 0. > > and be able to click the link to open the file in a separate buffer. > > This is already possible. Starting with which version of Org? I have 8.2.10 and it doesn't seem to work there... > > > Why shouldn't it be possible to achieve just the same by ALSO clicking > > on the URI? If you use .org files as a wiki - this feature is quite > > useful. > > Why do you need something else if there is already a way to do what you > want? I'm not a big fan of extending syntax gratuitously. Well, triple square brackets is shorter and cleaner for wiki purposes... I don't mind it to be able to include files only at column 0, it's totally OK. Regards.
Re: [O] Feature proposal: Triple square brackets to create a link to a file AND include the file
On Thu, 2018-09-27 at 13:58 +0200, Nicolas Goaziou wrote: > Hello, > > ST writes: > > > it would be nice to be able to make URIs to INCLUDEd files clickable. In > > order to make them also lightweight, readable and corresponding to > > current link syntax, I would suggest the following: > > > > [[[dir/file]]] > > [[[dir/file]] :lines "5-10"] > > [[[dir/file][My file]] :lines "5-10"] > > > > as clickable, including links. > > > > What do you think? > > This does not make sense: include files are not meant to be inlined. > Links are. What do you mean by "inlined"? During an export such a link [[[dir/file]]] should be replaced with the content of the "file", and the link itself disappear. But in the source .org file it is just shorter/cleaner way to write #+INCLUDE: "dir/file" and be able to click the link to open the file in a separate buffer. > > > Or maybe there is already something like this, if yes > > - how can I achieve the same? > > Use `C-c '` on a file. Why shouldn't it be possible to achieve just the same by ALSO clicking on the URI? If you use .org files as a wiki - this feature is quite useful. Thank you!
[O] Feature proposal: Triple square brackets to create a link to a file AND include the file
Hello, it would be nice to be able to make URIs to INCLUDEd files clickable. In order to make them also lightweight, readable and corresponding to current link syntax, I would suggest the following: [[[dir/file]]] [[[dir/file]] :lines "5-10"] [[[dir/file][My file]] :lines "5-10"] as clickable, including links. What do you think? Or maybe there is already something like this, if yes - how can I achieve the same? Thank you!
Re: [O] Multi-step ledger org-capture template
Thank you for sharing!
It would be nice to be able to generate a .pdf invoice based on a
predefined template (in .org/.tex/etc formats; maybe utilizing org-mode
exporter) for certain ledger transaction (by default the current one,
highlighted by cursor in ledger-mode).
Did anybody wrote something similar in the past?
On Sun, 2018-08-26 at 23:53 +0200, Stefan Huchler wrote:
> In case somebody wants something similar, I post my solution I came up
> with here:
>
> %(progn
>(defun get-table-content ( start end)
> (let* ((start (or start (buffer-end -1)))
> (end (or end (buffer-end 1)))
> (lines
>(s-split "\n" (buffer-substring-no-properties
> start end
>(remove nil
> (mapcar
> (lambda (line)
> (mapcar
> (lambda (elem)
>(string-trim elem))
> (remove "" (split-string
> line "|"
> lines
>(with-current-buffer (org-capture-get :original-buffer)
> (call-interactively 'copy-region-as-kill))
>(let* (mapping)
> (with-temp-buffer
>"*shop-name-mapping*"
>(erase-buffer)
>(insert-file-contents "capture-templates/products-mapping.org")
>(let* ((start (progn (goto-char (point-min))
> (forward-line 1) (point
>(setq mapping (mapcar (lambda (x) (cons (nth 1 x) (car x)))
>
> (get-table-content start)
> (with-temp-buffer
>"*shop-import-temp*"
>(erase-buffer)
>(yank)
>(org-table-convert-region (buffer-end -1) (buffer-end 1) 2)
>(let* ((data (get-table-content)))
>(erase-buffer)
>(insert
> (concat " " (org-read-date nil nil) " * Shop-name\n"
> (mapconcat
> (lambda (line) (format " %s \t\t%s St {=€%s}"
>(assoc-default (nth 1 line) mapping)
>(nth 0 line) (nth 4 line)))
> data "\n")
> "\n assets:bank:chequing"))
>(ledger-mode)
>(let ((start (progn
> (goto-char (point-min))
> (forward-line 1) (point)))
> (end (progn
> (goto-char (point-max))
> (forward-line -1) (point
> (ledger-post-align-postings start end))
>(buffer-string)
>
> products-mapping would like like that:
>
> #+NAME: food
> | expenses:food:spice:Basilikum | Basilikum bio Sonnentor, 15g |
> | expenses:food:spice:Oregano | Oregano bio Sonnentor, 20g |
>
> Of course it asumes that you have some html or email bill with a table
> selected and you would have to change the (nth x line) depending where
> in the bill the name, amount and price is listed, and maybe change the
> currency.
>
>
>
>
>
>
[O] Please, upvote support for org-mode in GitLab's wiki pages
You can login with Gmail, Facebook, etc. account: https://gitlab.com/gitlab-org/gitlab-ce/issues/38590
Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode
On Sun, 2018-06-17 at 16:10 +0300, Eli Zaretskii wrote:
> > From: ST
> > Cc: Nicolas Goaziou , Emacs-orgmode@gnu.org
> > Date: Sun, 17 Jun 2018 15:29:58 +0300
> >
> > 1. Do you agree that the vast majority of all the documents in human
> > history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are
> > minority that we should not take care of...
> > 2. Do you agree that for pure ltr texts org headings should appear to
> > the left and for pure rtl texts org headings should appear to the right?
> >
> > If you agree with both (1) and (2) - we should put nil as default value,
> > as this will enable (2).
>
> I agree with (1) and (2), but your conclusion doesn't follow from
> that. The value nil means that the base directionality of
> _each_paragraph_ is determined dynamically. It does NOT mean that the
> whole buffer will have the same directionality for all of its
> paragraphs. With nil, some paragraphs could have RTL direction, and
> others LTR. Worse, headings could have one direction and their bodies
> another. A single character at the beginning of a paragraph might
> change that paragraph's base direction. You don't want that with your
> users.
All troubles that you describe here are relevant only for mixed ltr/rtl
texts ("a single character" is an ltr character inside an rtl text,
isn't it?), but we have agreed to exclude those as per (1). Can you give
an example of pure rtl text with the issues mentioned above?
>
> > I'm so eager to change the defaults because we start a project where we
> > have many non_technically_savvy Windows-people who need to edit rtl org
> > files in Emacs (which is a challenge on its own). So we want the
> > experience to be as smooth as possible, but right now rtl users are
> > disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be
> > achieved).
>
> Users of RTL languages should have bidi-paragraph-direction in Org
> buffers set to right-to-left, not to nil. The value of nil will
> sometimes cause the heading to appear at the left while the body
> appears on the right, or vice versa, which is the worst of all worlds.
Again, only for mixed ltr/rtl texts, until you prove (by example)
otherwise.
> I see no reason why non-technically-savvy people couldn't learn that
> they need to set a variable when they start editing text of a known
> directionality.
If you don't have a counter-example, nil is better since that way you
have one default setting for ALL buffers and you can work with BOTH ltr
and rtl texts with the same config without the need to change anything.
Contrary to mixed ltr/rtl texts - working with pure ltr texts is common
also for rtl people.
> That's what MS-Word users do all the time, right?
Yes, but they are used to buttons_check-boxes stuff, not lisp config
files.
Thanks!
Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode
On Sun, 2018-06-17 at 09:12 +0300, Eli Zaretskii wrote: > > From: Nicolas Goaziou > > Cc: Emacs-orgmode@gnu.org > > Date: Fri, 15 Jun 2018 16:05:37 +0200 > > > > ST writes: > > > > > Please leave the Emacs' default value of "bidi-paragraph-direction" > > > which is "nil" in orgmode as well. Right now orgmode seems to force > > > "left-to-right", thus blocking "right-to-left". With "nil" it is > > > dynamic, which means both directions work well out-of-the box. > > > > > > Right now I'm forced to add this to my config: > > > > > > (add-hook 'org-mode-hook > > > (lambda () > > > (setq bidi-paragraph-direction nil))) > > > > > > It took me a lot of time to figure out, which makes the first Org steps > > > for RTL-newbies quite frustrating... > > > > It may not be as obvious as you think. See > > <https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00349.html> > > for details. > > For the record: The change to the current default was my suggestion, > and I still stand by that advice. I think the current default is > correct out of the box for more people than the previous nil value. > And I see no catastrophe in a mode hook that overrides the default for > those who don't like this default. The defaults cannot possibly DTRT > for everyone, only for the majority. That's exactly what I want to achieve - reasonable defaults for the majority. Let's clarify: 1. Do you agree that the vast majority of all the documents in human history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are minority that we should not take care of... 2. Do you agree that for pure ltr texts org headings should appear to the left and for pure rtl texts org headings should appear to the right? If you agree with both (1) and (2) - we should put nil as default value, as this will enable (2). I'm so eager to change the defaults because we start a project where we have many non_technically_savvy Windows-people who need to edit rtl org files in Emacs (which is a challenge on its own). So we want the experience to be as smooth as possible, but right now rtl users are disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be achieved). Thank you!
[O] How to enable truncate-lines in orgmode by default?
Hello, I would like to enable truncate-lines in orgmode by default - how can I do that? Here is what I tried to put in my config, but it doesn't seem to help: (add-hook 'org-mode-hook (lambda () (setq truncate-lines t))) Thank you!
[O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode
Hello, Please leave the Emacs' default value of "bidi-paragraph-direction" which is "nil" in orgmode as well. Right now orgmode seems to force "left-to-right", thus blocking "right-to-left". With "nil" it is dynamic, which means both directions work well out-of-the box. Right now I'm forced to add this to my config: (add-hook 'org-mode-hook (lambda () (setq bidi-paragraph-direction nil))) It took me a lot of time to figure out, which makes the first Org steps for RTL-newbies quite frustrating... Please, let me know if you decide to fix this in the upcoming versions. Thank you!
[O] orgmode.org website
Hello, 1. Where can I find the export configuration/source org files of the orgmode.org website to learn how it works? 2. What tool is used to generate it? Thank you!
[O] Footnotes in the manual (hidden option?)
Hello, in the manual https://orgmode.org/manual/Footnotes.html#Footnotes it says that footnotes[fn:1] [fn:1] look like this but actually[1] [1] works as well and looks even better. So why this option is not documented? Thank you!
Re: [O] Localized org-mode
> Furthermore, in the context of this thread, Org allows drawers with > arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or > :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and > :LOGBOOK: reserved. This means that you can't reliably know if anybody > has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible. > Same thing with todo keywords, tags, etc. 1. What about #+TITLE, #+DATE or #+AUTHOR ? What's problem to translate those? 2. In order to determine reliably what is the language of a particular document we can introduce #+LANGUAGE which would be English by default. Others will write #+SPRACHE: Deutsch and then you can use predefined default mapping of keywords or the local one (overloaded by user) if it exists in his .emacs.d/org-de-vocabulary. 3. I also prefer English in all my UIs and, for sure, in programming languages as you, but here I talk about org not as a programming language but as a _document markup_. Documents that are meant to be _read as raw source_. There it disturbs, especially if it is a not Latin letters based language.
Re: [O] Moving from Jekyll to Orgmode
> > > > Is the difficulty to setup ox-publish the sole disadvantage vis. > > ox-hugo/ox-jekyll/etc.? Is the functionality the same > > more_or_less? > > > > What ox-hugo devs/users have to say on this? > > I enjoy the hugo server. Make a change to the org mode file, > export with ox-hugo, and then look at the web browser to see the > effect of the change. It makes the work much easier, IMHO. > Jekyll also has a built-in web server. It is indeed useful. I didn't check but I thought there must be similar standard command line Linux tool for this, so you could immediately see the results of ox-publish exported website. Is anybody aware of such a tool?
Re: [O] Localized org-mode
On Wed, 2018-05-09 at 13:36 +0200, Diego Zamboni wrote: > I really don't see the point of trying to localize org keywords. To > me, they are like the keywords in any programming language - part of > the language. Would you consider translating C or LISP keywords? I see org, first of all, as an excellent lightweight markup syntax for creating documents and not as a programming language, i.e. it should be readable in raw plain text. Thus it would be more elegant to have native keywords. Just an idea... > > On Wed, May 9, 2018 at 10:19 AM, Nicolas Goaziou > <m...@nicolasgoaziou.fr> wrote: > Hello, > > ST <smn...@gmail.com> writes: > > > So how do you solve this problem now for English > ":PROPERTIES:"? > > Simple. Org does not replace anything arbitrarily. This is > less > error-prone. > > > Anyway if somebody runs into it he could have at least to > options: > > > > 1. write local .emacs.d/.org-de-vocabulary which will > override the > > default one (or parts of it) with a synonym, like: > > PROPERTIES -> ATTRIBUTEN > > or > > PROPERTIES -> ORG_EIGENSCHAFTEN > > and then you can replace blindly before parsing. > > Again, I'm not particularly fond of having conditional syntax > like this. > > > I don't know lisp :( > > You may want to look at `org-display-custom-time'. > > Basically, you search for the regexp "^[ \t]*:\\(PROPERTIES\ > \):", and > use `put-text-property' to change the text between > (match-beginning 1) > and (match-end 1), e.g., > > (defun my-properties-translate () > (org-with-point-at 1 > (while (re-search-forward "^[ \t]*:\\(PROPERTIES\\):" > nil t) > (put-text-property (match-beginning 1) (match-end 1) > 'display "ATTRIBUTEN" > > You need to add this function to, e.g. `org-mode-hook'. Of > course this > is really basic and can be improved. > > Regards, >
Re: [O] Localized org-mode
On Tue, 2018-05-08 at 20:21 +0200, Nicolas Goaziou wrote: > ST <smn...@gmail.com> writes: > > > Why? Run "detranslator" before you start parsing. I.e. based on your > > 1-to-1 vocabulary "detranslator" will substitute all :EIGENSCHAFTEN: and > > all other org syntax back to English :PROPERTIES: etc.. Then apply > > parser as usual. > > You cannot blindly replace all ":EIGENSCHAFTEN:" with ":PROPERTIES:" > because some of them could be real ":EIGENSCHAFTEN:", which is valid > syntax. IOW, you need to parse the buffer to know what ":EIGENSCHAFTEN:" > ought to be replaced, so you're running in circles. So how do you solve this problem now for English ":PROPERTIES:"? Anyway if somebody runs into it he could have at least to options: 1. write local .emacs.d/.org-de-vocabulary which will override the default one (or parts of it) with a synonym, like: PROPERTIES -> ATTRIBUTEN or PROPERTIES -> ORG_EIGENSCHAFTEN and then you can replace blindly before parsing. 2. just go back to using English org-vocabulary as it is done now. > > Writing is only a half of the problem. Imagine Cyrillic or Chinese text > > mixed with Latin letters. Org is not html (that hides its syntax once > > rendered) and it is supposed to be smoothly readable in raw plain texta > > form. Even worth - imagine right-to-left texts like Hebrew or Persian > > mixed up with left-to-right Latin letters. It's not aesthetical. > > If that's an aesthetic issue, we could fix it on the aesthetic side. > > For example, you can localize timestamps with `org-display-custom-times' > and `org-time-stamp-custom-formats'. It could be possible to do > something similar, i.e., to use overlays, e.g., on top of properties > drawers. Of course, this wouldn't change the underlying appearance, but > the solution is much less invasive than what you suggest. > > Do you want to propose a patch? I don't know lisp :(
Re: [O] Moving from Jekyll to Orgmode
On Tue, 2018-05-08 at 00:21 +0200, Rasmus wrote: > ST <smn...@gmail.com> writes: > > >> > 2. how can one create "prettified" links, i.e. /features/ instead > >> > of /features.html ? Basically during the website generation for the file > > > >> > features.org a directory `features` needs to be created and the html > >> > file placed into `features/index.html` ... Is there a tutorial on how to > >> > do that? > >> > >> You make a wrapper around org-html-publish-to-html that creates folders > >> and from filename and save file as index in the folder. The wrapper > >> function is then used as the :publishing-function in > >> org-publish-project-alist. > >> > >> Something like this (untested). > >> > >> (lambda (plist filename pub-dir) > >> (let ((dir (make-directory (file-name-as-directory (file-name-base > >> filename)) > >> pub-dir))) > >> (org-latex-publish-to-html plist filename dir) > >> (rename-file (concat dir (file-name-base filename) ".html") > >> (concat dir "index.html" > >> > >> > >> You could also move around your source files before publishing via the > >> :preparation-function. > > > > Thank you very much! Unfortunately I don't know lisp, so I have to learn > > it first to understand your solution... but now I have something to > > start with. I wish org html export will become a real static site > > generator, like jekyll, hugo, etc.. > > I *think* that is what ox-publish is, but indeed, it’s a bit hairy to set > up. Is the difficulty to setup ox-publish the sole disadvantage vis. ox-hugo/ox-jekyll/etc.? Is the functionality the same more_or_less? What ox-hugo devs/users have to say on this?
Re: [O] Localized org-mode
> > is there something like localized/internationalized org? I.e. all > > keywords, like :PROPERTIES: are translated to another language, > > like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign > > language. It is of a special importance for languages with non-latin > > letters, where the mix of different languages might be > > visually/esthetically disturbing and require switching of keyboard > > layouts while writing. Technically it should be a simple 1-to-1 > > substitution based on an org_keyword_vocabulary for a specific > > language. > > :PROPERTIES: is part of the Org syntax. Having it translated would make > it more difficult for the parser to operate, and possibly break > compatibility between documents written in different languages. Why? Run "detranslator" before you start parsing. I.e. based on your 1-to-1 vocabulary "detranslator" will substitute all :EIGENSCHAFTEN: and all other org syntax back to English :PROPERTIES: etc.. Then apply parser as usual. > > IMO, having PROPERTIES, and a few other keywords, is a minor annoyance. > For example, you never need to actually write "PROPERTIES" since `C-c > C-x p' (`org-set-property') creates it for you. Also, `C-c C-e #' > (`org-export-insert-default-template') inserts many keywords for you. Writing is only a half of the problem. Imagine Cyrillic or Chinese text mixed with Latin letters. Org is not html (that hides its syntax once rendered) and it is supposed to be smoothly readable in raw plain text form. Even worth - imagine right-to-left texts like Hebrew or Persian mixed up with left-to-right Latin letters. It's not aesthetical. Thank you!
[O] Localized org-mode
Hello, is there something like localized/internationalized org? I.e. all keywords, like :PROPERTIES: are translated to another language, like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign language. It is of a special importance for languages with non-latin letters, where the mix of different languages might be visually/esthetically disturbing and require switching of keyboard layouts while writing. Technically it should be a simple 1-to-1 substitution based on an org_keyword_vocabulary for a specific language. Thank you!
Re: [O] Moving from Jekyll to Orgmode
> > 2. how can one create "prettified" links, i.e. /features/ instead > > of /features.html ? Basically during the website generation for the file > > features.org a directory `features` needs to be created and the html > > file placed into `features/index.html` ... Is there a tutorial on how to > > do that? > > You make a wrapper around org-html-publish-to-html that creates folders > and from filename and save file as index in the folder. The wrapper > function is then used as the :publishing-function in > org-publish-project-alist. > > Something like this (untested). > > (lambda (plist filename pub-dir) > (let ((dir (make-directory (file-name-as-directory (file-name-base > filename)) > pub-dir))) > (org-latex-publish-to-html plist filename dir) > (rename-file (concat dir (file-name-base filename) ".html") > (concat dir "index.html" > > > You could also move around your source files before publishing via the > :preparation-function. Thank you very much! Unfortunately I don't know lisp, so I have to learn it first to understand your solution... but now I have something to start with. I wish org html export will become a real static site generator, like jekyll, hugo, etc..
Re: [O] Moving from Jekyll to Orgmode
On Sun, 2018-04-29 at 11:45 -0500, Grant Rettke wrote: > On Sat, Apr 28, 2018 at 4:05 PM, ST <smn...@gmail.com> wrote: > > 3. is there a free modern "corporate" style theme for org-mode? > > Twitter Bootstrap https://github.com/marsmining/ox-twbs and This looks nice... 1. Does it mean that any Bootstrap theme can be used with this? see here: https://themes.getbootstrap.com/ 2. Does it support the latest Bootstrap 4.1? Thank you!
Re: [O] Moving from Jekyll to Orgmode
On Sun, 2018-04-29 at 11:07 +0200, Bastien wrote: > Hi ST, > > ST <smn...@gmail.com> writes: > > > Could you, please, share your website publishing workflow (considering > > the 3 issues I've mentioned)? > > if people take the time to share this on the list, would you be kind > enough to take the time to enhance Worg documentation with a readable > synthesis of all answers? English is not my mother tongue, but I'll give it a try... Thank you!
Re: [O] Moving from Jekyll to Orgmode
Hi Scott, thank you, and all other responders, for the shared information. The reason I want to leave Jekyll is because I don't want to depend on a tool that relies on language (Ruby)/environment that I don't know/use (in this respect Hugo is the same for me). I prefer something more simplistic, even though if I'll have to invest some time for it to work initially. Those 3 features I've mentioned are almost all I need, more or less. Could you, please, share your website publishing workflow (considering the 3 issues I've mentioned)? Thank you! On Sat, 2018-04-28 at 18:13 -0400, Scott Randby wrote: > On 04/28/2018 05:40 PM, Diego Zamboni wrote: > > > > Org-mode is not really a website-publishing tool like Jekyll, although it > > can be part of the chain. Org-mode at its core is a markup language, > > although with considerable tooling support from org-mode and related tools > > in Emacs. > > > > I think Org is a good website publishing tool in many ways. I've been using > it for making and publishing my website since 2010. Sure, it has some > limitations, but I think it can be made to work nicely for a lot of types of > sites. But I do agree that the Org/Hugo combination is really good. > > Scott Randby >
[O] Moving from Jekyll to Orgmode
Hello, I would like to rewrite my website using Orgmode (till now I used Jekyll). It would be nice if you could help me with following questions: 1. could somebody, please, point me to a tutorial on how to create a multilingual site? Like the orgmode.org with EN:FR:JA. Ideally it would be if one would have page-aware language switch, i.e. if one is on the page orgmode.org/fr/features.html and clicks JA he will be redirected to orgmode.org/ja/features.html (and not .../ja/index.html as it is now)... 2. how can one create "prettified" links, i.e. /features/ instead of /features.html ? Basically during the website generation for the file features.org a directory `features` needs to be created and the html file placed into `features/index.html` ... Is there a tutorial on how to do that? 3. is there a free modern "corporate" style theme for org-mode? Thank you!
Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces
Thank you! Unfortunately my (lack of) elisp knowledge doesn't allow me to implement this feature myself. I'll wait until somebody finds it useful enough... On Fri, 2018-03-16 at 22:57 +0100, Nicolas Goaziou wrote: > Hello, > > ST <smn...@gmail.com> writes: > > > to those engineers, who are responsible for adding new features: does this > > case > > of enabling linkwords with spaces (see below) qualifies as a new feature > > request? > > I have no objection, but it needs to be tested carefully. > > > If yes - where should I file it? > > It is already filed here, on the ML. However, I suggest to give it a go, > as it may be faster that waiting for someone to implement it. > > Regards, >
Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces
Hello,
to those engineers, who are responsible for adding new features: does this case
of enabling linkwords with spaces (see below) qualifies as a new feature
request? If yes - where should I file it?
Thank you!
>
> > Why should this not be parse-able? Cut #+LINK: from the beginning, URL
> > (last token) from the end, and the rest will be "link word", even with
> > (several) spaces in between...
>
> Can we be sure so-called URL part will never contain a space? You put
> a constraint either on the linkword or on the "URL" part.
1. If I were to choose on which part to put a constraint - I'll do so
with the "URL" part as it appears only once and in the best case as meta
data in comments, while "link word" can appear tens or hundreds of times
in the text itself, which needs to look nice.
2. Spaces in URLs a rare, while all docs that have more than one word in
their title look nicer with spaces. I found only 3 cases here:
https://orgmode.org/manual/External-links.html
3. Anyway the problem of spaces in the URLs is not a new one - you have
the same in bash. Solution - just put URL part in "URL", as you usually
do on command line. And as you already do defining
org-link-abbrev-alist:
("url-to-ja" . "http://translate.google.fr/translate?sl=en=ja=%h;)
so for the cases where there must be spaces in the URL do:
#+LINK: My Book "path/to/My Book.org"
but by default in normal case just use:
#+LINK: My Book path/to/My_Book.org
What is your opinion? Can this qualify as feature request?
Thanks!
Re: [O] Structured links to headings with endless depth
On Wed, 2018-03-14 at 19:32 +0100, Nicolas Goaziou wrote: > ST <smn...@gmail.com> writes: > > > Why [[file.org::#1:2:1]] is nicer than [file.org::1:2:1]]? > > Because you can write something more meaningful than "1:2:1" when using > a CUSTOM_ID. > > >> - it translates nicely to "id" tag in HTML. > > > > You can generate the "id" tag in HTML like this 1-2-1 (if HTML dislikes > > 1:2:1 tag) > > CUSTOM_ID is built-in, without implementing anything. > > > Isn't a good idea to add such a built in link type in the long term? > > IMO, Org has enough internal link types. > > In particular, this one brings little value compared to CUSTOM_ID. It is > fragile wrt re-ordering, refiling, capture... It may be a headache to > export, too, because "1.2.1" may mean something entirely different once > non-exportable trees have been pruned. Sure, numbers were just a short abstract example. This can very well be: fruits:apples:jonagold > > No offence intended, but it really sounds like a false good idea. You definitely have more experience with org (I'm just learning), so you indeed know better :)
Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces
On Wed, 2018-03-14 at 15:02 +0100, Nicolas Goaziou wrote:
> Hello,
>
> ST <smn...@gmail.com> writes:
>
> > Why should this not be parse-able? Cut #+LINK: from the beginning, URL
> > (last token) from the end, and the rest will be "link word", even with
> > (several) spaces in between...
>
> Can we be sure so-called URL part will never contain a space? You put
> a constraint either on the linkword or on the "URL" part.
1. If I were to choose on which part to put a constraint - I'll do so
with the "URL" part as it appears only once and in the best case as meta
data in comments, while "link word" can appear tens or hundreds of times
in the text itself, which needs to look nice.
2. Spaces in URLs a rare, while all docs that have more than one word in
their title look nicer with spaces. I found only 3 cases here:
https://orgmode.org/manual/External-links.html
3. Anyway the problem of spaces in the URLs is not a new one - you have
the same in bash. Solution - just put URL part in "URL", as you usually
do on command line. And as you already do defining
org-link-abbrev-alist:
("url-to-ja" . "http://translate.google.fr/translate?sl=en=ja=%h;)
so for the cases where there must be spaces in the URL do:
#+LINK: My Book "path/to/My Book.org"
but by default in normal case just use:
#+LINK: My Book path/to/My_Book.org
What is your opinion? Can this qualify as feature request?
Thanks!
Re: [O] Structured links to headings with endless depth
On Wed, 2018-03-14 at 14:26 +0100, Nicolas Goaziou wrote: > Hello, > > > I think this kind of linking is useful for many general cases. Christian > > has expressed concerns that such links are easily breakable which is > > true but only for documents that are in draft phase (or those which are > > supposed to be restructured on regular basis - like ToDo lists). However > > documents that has been published, like books or scientific papers, and > > will no longer change - will benefit greatly from such linking option. > > Imagine you have a scientific paper in your archive that you have > > already published and removed write access from it in order not to > > change it accidentally. You do want to reference certain > > chapter:section:subsection from it in your new paper, which you are > > currently writing, but creating a target <> > > in the old paper is no longer an option... > > > > So may I ask as a feature request, to please add, following link type as > > standard to the org-mode: > > > > [[path/to/file.org::chapter:section:subsection:etc:optional target]] > > > > - chapter/section/subsection could be also just numbers > > - optional target target might be <> > > - there is no need to add '*' (like > > [[path/to/file.org::*chapter:section]] to the link, as ':' after '::' > > imply that headings are referred. > > > > Thank you! > > Again, even in the case you are talking about, CUSTOM_ID is better, for > at least two reasons: > - it leads to much simpler links: [[file.org::#my-id]] Why [[file.org::#1:2:1]] is nicer than [file.org::1:2:1]]? > - it translates nicely to "id" tag in HTML. You can generate the "id" tag in HTML like this 1-2-1 (if HTML dislikes 1:2:1 tag) > > I understand this was not so useful in your use case (only headlines, no > contents), but, it is still valid as a general mechanism. Isn't a good idea to add such a built in link type in the long term? Thank you!
Re: [O] Structured links to headings with endless depth
On Wed, 2018-03-14 at 07:15 -0700, John Kitchin wrote: > I don't think this should be in org-mode, it is still too fragile in > many ways. > > > For example, what if you have a colon in your headlines, e.g. "A > chapter about Romans 15:13". That will will mess up the suggested > approach that splits on ":". My bad, I didn't mean to add this specific solution, but rather improve it till it is no longer fragile. I appealed to those who are responsible for adding new feature requests (as described on the website) to consider this idea (and maybe find other more stable ways to implement it). I'm not sure who they are... > > What if you have duplicate headlines in a hierarchy, how would you > specify the nth one? Normally there shouldn't be identical headlines on the same level (on different levels [[My_Book::2:2:2]] is perfectly fine). Should this happen - take first occurrence. > > What if you have some convention to start at level 2 headlines? what > would you do then? > > > What about include files? > > > What if you skip a level for some reason? What should the path look > like then? Then your structure is not well-defined and you should not use such links. Thank you! > > > > On Wed, Mar 14, 2018 at 3:10 AM, ST <smn...@gmail.com> wrote: > John, thank you for this solution! > > I posted this question also here: > > https://emacs.stackexchange.com/q/39384/18760 > > So if you wish, you may add your solution also there. > > Somebody there, posted also a possible solution however the > syntax is > pretty heavy: > > [[org-heading:/path/to/file.org::*1:2:1]] > > There is a workaround using links abbreviations, but still it > is a > workaround... > > I think this kind of linking is useful for many general cases. > Christian > has expressed concerns that such links are easily breakable > which is > true but only for documents that are in draft phase (or those > which are > supposed to be restructured on regular basis - like ToDo > lists). However > documents that has been published, like books or scientific > papers, and > will no longer change - will benefit greatly from such linking > option. > Imagine you have a scientific paper in your archive that you > have > already published and removed write access from it in order > not to > change it accidentally. You do want to reference certain > chapter:section:subsection from it in your new paper, which > you are > currently writing, but creating a target > <> > in the old paper is no longer an option... > > So may I ask as a feature request, to please add, following > link type as > standard to the org-mode: > > [[path/to/file.org::chapter:section:subsection:etc:optional > target]] > > - chapter/section/subsection could be also just numbers > - optional target target might be <> > - there is no need to add '*' (like > [[path/to/file.org::*chapter:section]] to the link, as ':' > after '::' > imply that headings are referred. > > Thank you! > > On Tue, 2018-03-13 at 20:49 -0700, John Kitchin wrote: > > This is a tricky problem to generally solve. I think this > does it > > approximately well enough. It is lightly tested and works by > exactly > > matching headlines at subsequent levels. It will be > problematic if you > > have headlines with : in them, and it assumes there is a > level 1 > > headline to start in. > > > > > > #+BEGIN_SRC emacs-lisp > > (defun xpath-follow (path) > > (let* ((fields (split-string path "::")) > > (fname (car fields)) > > (paths (split-string (cadr fields) ":")) > > (level 0) > > (current-point (point)) > > cp hls n found) > > (org-mark-ring-push) > > (find-file fname) > > (save-restriction > > (while paths > > (setq cp (pop paths)) > > (incf level) > > (setq hls (org-element-map (org-element-parse-buffer) > 'headline > > (lambda (hl) >
Re: [O] Structured links to headings with endless depth
John, thank you for this solution! I posted this question also here: https://emacs.stackexchange.com/q/39384/18760 So if you wish, you may add your solution also there. Somebody there, posted also a possible solution however the syntax is pretty heavy: [[org-heading:/path/to/file.org::*1:2:1]] There is a workaround using links abbreviations, but still it is a workaround... I think this kind of linking is useful for many general cases. Christian has expressed concerns that such links are easily breakable which is true but only for documents that are in draft phase (or those which are supposed to be restructured on regular basis - like ToDo lists). However documents that has been published, like books or scientific papers, and will no longer change - will benefit greatly from such linking option. Imagine you have a scientific paper in your archive that you have already published and removed write access from it in order not to change it accidentally. You do want to reference certain chapter:section:subsection from it in your new paper, which you are currently writing, but creating a target <> in the old paper is no longer an option... So may I ask as a feature request, to please add, following link type as standard to the org-mode: [[path/to/file.org::chapter:section:subsection:etc:optional target]] - chapter/section/subsection could be also just numbers - optional target target might be <> - there is no need to add '*' (like [[path/to/file.org::*chapter:section]] to the link, as ':' after '::' imply that headings are referred. Thank you! On Tue, 2018-03-13 at 20:49 -0700, John Kitchin wrote: > This is a tricky problem to generally solve. I think this does it > approximately well enough. It is lightly tested and works by exactly > matching headlines at subsequent levels. It will be problematic if you > have headlines with : in them, and it assumes there is a level 1 > headline to start in. > > > #+BEGIN_SRC emacs-lisp > (defun xpath-follow (path) > (let* ((fields (split-string path "::")) > (fname (car fields)) > (paths (split-string (cadr fields) ":")) > (level 0) > (current-point (point)) > cp hls n found) > (org-mark-ring-push) > (find-file fname) > (save-restriction > (while paths > (setq cp (pop paths)) > (incf level) > (setq hls (org-element-map (org-element-parse-buffer) 'headline > (lambda (hl) > (when (eq level (org-element-property :level hl)) > hl > (setq n (-find-index (lambda (hl) >(string= cp (org-no-properties > (org-element-property :raw-value hl > hls)) > (if (not n) > (progn > (goto-char current-point) > (user-error "%s not found" cp)) > (goto-char (org-element-property :begin (nth n hls))) > (org-narrow-to-subtree)) > > > (org-link-set-parameters > "xpath" > :follow 'xpath-follow) > #+END_SRC > > > > John > > --- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > > > > On Mon, Mar 12, 2018 at 8:08 AM, ST <smn...@gmail.com> wrote: > Hello, > > Ss Christian has pointed out - introduce a separate CUSTOM_ID > for text > with fixed structure and rather short verses is too heavy. > > I do need to write a custom link type, if this use case is not > of common > interest for the orgmode community. > > Thank you, > > > On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote: > > Hello, > > > > ST <smn...@gmail.com> writes: > > > > > I'm not that experienced in writing in lisp. Is it > difficult to create > > > such custom link type? What is the closest link type that > you would > > > recommend to take as starting point (link on code, if > possible)? > > > > I'm not answering your question, but I suggest to use a > CUSTOM_ID > > instead. This is readily available. > > > > Regards, > > > > > > >
Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces
> >> > after reading "4.6 Link abbreviations" of the manual I have two > >> > questions: > >> > > >> > 1. is it possible to define linkwords with spaces, like this: [[Harry > >> > Potter:Chapter1]], it looks much more nice than > >> > [[Harry_Potter:Chapter1]]? > >> > >> I think so. > > > > If yes, then it's really worth mentioning this fact in the manual (4.6 > > Link abbreviations) because ones get the impression that only - and _ > > are allowed. One of the most strong sides of org is its readability as > > raw text and in this case space makes link more readable. > > My bad. Spaces are not allowed, because > > #+LINK: linkword URL > > would not be parse-able. #+LINK: link word URL Why should this not be parse-able? Cut #+LINK: from the beginning, URL (last token) from the end, and the rest will be "link word", even with (several) spaces in between... Thanks.
Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces
> > after reading "4.6 Link abbreviations" of the manual I have two > > questions: > > > > 1. is it possible to define linkwords with spaces, like this: [[Harry > > Potter:Chapter1]], it looks much more nice than > > [[Harry_Potter:Chapter1]]? > > I think so. If yes, then it's really worth mentioning this fact in the manual (4.6 Link abbreviations) because ones get the impression that only - and _ are allowed. One of the most strong sides of org is its readability as raw text and in this case space makes link more readable. > > > 2. is it possible to define a "links catalog" of abbreviations, like > > > > #+LINK: bugzilla http://10.1.2.9/bugzilla/show_bug.cgi?id= > > #+LINK: googlehttp://www.google.com/search?q=%s > > > > > > and then include them in all possible org files with > > > > #+INCLUDE: "links_catalog.org" > > SETUPFILE would be more appropriate. Also, you can define abbreviations > globally. See `org-link-abbrev-alist'. I wanted to avoid `org-link-abbrev-alist' as it is Emacs specific, while #+INCLUDE: is part of the org-mode standard which should work also on other platforms (theoretically). Thank you!
[O] Link abbreviations: include abbreviation table and linkwords with spaces
Hello, after reading "4.6 Link abbreviations" of the manual I have two questions: 1. is it possible to define linkwords with spaces, like this: [[Harry Potter:Chapter1]], it looks much more nice than [[Harry_Potter:Chapter1]]? 2. is it possible to define a "links catalog" of abbreviations, like #+LINK: bugzilla http://10.1.2.9/bugzilla/show_bug.cgi?id= #+LINK: googlehttp://www.google.com/search?q=%s and then include them in all possible org files with #+INCLUDE: "links_catalog.org" Will the links be clickable? Thank you!
Re: [O] Structured links to headings with endless depth
Hello, Ss Christian has pointed out - introduce a separate CUSTOM_ID for text with fixed structure and rather short verses is too heavy. I do need to write a custom link type, if this use case is not of common interest for the orgmode community. Thank you, On Mon, 2018-03-12 at 15:10 +0100, Nicolas Goaziou wrote: > Hello, > > ST <smn...@gmail.com> writes: > > > I'm not that experienced in writing in lisp. Is it difficult to create > > such custom link type? What is the closest link type that you would > > recommend to take as starting point (link on code, if possible)? > > I'm not answering your question, but I suggest to use a CUSTOM_ID > instead. This is readily available. > > Regards, >
Re: [O] Structured links to headings with endless depth
Thank you for your reply. I'm not that experienced in writing in lisp. Is it difficult to create such custom link type? What is the closest link type that you would recommend to take as starting point (link on code, if possible)? Thank you! On Mon, 2018-03-12 at 14:08 +0100, Christian Moe wrote: > ST writes: > > > Adding an extra <> is not an option, as it will make the text > > less readable, and there is no need in this, as the headings tree > > structure is already there: > > Adding targets, CUSTOM_IDs or IDs are all options. You may not like them. > > > * 1 > > ** 1 > > ** 2 > > *** 1 > > > > Why should I turn it into the following > > > > * 1 > > ** 1 > > ** 2 > > *** 1 > > <<1>> > > With a fixed structure, you wouldn't; you'd use e.g. <<1:2:1>>. > > > and then link with [[file:1]]?!... This both: > > a) adds unnecessary information into the text making it less readable > > Let's not exaggerate the readability cost. And it does add information. > > > b) those who read the org file as simple text without the ability to > > click the link will not know where it goes... while the link > > [[file:1:2:1]] makes it quite clear even without clicking it. > > But so does the link [[1:2:1]] to the target <<1:2:1>>. > > also, c): Adding a target like <<1:2:1>> to a section preserves > information about the location of that section in the source document if > you later cut that part out and insert it somewhere else. This > information is not contained in your headlines. > > > Example use case: scriptures with well known structure, e.g. the Bible. > > Fair enough. > > But typical Org use will quickly break links like that, since Org shines > as an organizer for drafting and easily restructuring text. I don't > think Org needs a link type that would encourage people to make easily > breakable links. > > I acknowledge that a separate target or CUSTOM_ID for every verse in the > Bible seems a bit heavy; if that's what you need, it might be better > solved by a custom link type. > > Yours, > Christian > > > > > On Mon, 2018-03-12 at 10:29 +, Eric S Fraga wrote: > >> On Monday, 12 Mar 2018 at 12:09, ST wrote: > >> > Hi, > >> > > >> > after reading the manual I didn't find a way to construct structured > >> > links referring to headings with endless depth, like: > >> > >> I'm not entirely sure what your use case is but could you use a target, > >> i.e. something like <>, to indicate where you want to link to? > >> Cf. section 4.2 of org manual on internal links. > >>
Re: [O] Structured links to headings with endless depth
PS: It doesn't have to be Bible. Links in form of citations, like [[MyBook:Chapter 1:Section 5:Subsection 3]] Is quite useful in general. Where #+LINK: MyBook path/to/MyBook.org::*%s It is both readable as raw text and clickable. Maybe it will be a good idea to be able to also add a <> at the end of the tree, like: [[MyBook:Chapter 1:Section 5:Subsection 3:target]] * Chapter 1 ... ** Section 5 ... *** Subsection 3 ... <> ... - Adding an extra <> is not an option, as it will make the text less readable, and there is no need in this, as the headings tree structure is already there: * 1 ** 1 ** 2 *** 1 Why should I turn it into the following * 1 ** 1 ** 2 *** 1 <<1>> and then link with [[file:1]]?!... This both: a) adds unnecessary information into the text making it less readable b) those who read the org file as simple text without the ability to click the link will not know where it goes... while the link [[file:1:2:1]] makes it quite clear even without clicking it. Example use case: scriptures with well known structure, e.g. the Bible. On Mon, 2018-03-12 at 10:29 +, Eric S Fraga wrote: > On Monday, 12 Mar 2018 at 12:09, ST wrote: > > Hi, > > > > after reading the manual I didn't find a way to construct structured > > links referring to headings with endless depth, like: > > I'm not entirely sure what your use case is but could you use a target, > i.e. something like <>, to indicate where you want to link to? > Cf. section 4.2 of org manual on internal links. >
Re: [O] Structured links to headings with endless depth
Adding an extra <> is not an option, as it will make the text less readable, and there is no need in this, as the headings tree structure is already there: * 1 ** 1 ** 2 *** 1 Why should I turn it into the following * 1 ** 1 ** 2 *** 1 <<1>> and then link with [[file:1]]?!... This both: a) adds unnecessary information into the text making it less readable b) those who read the org file as simple text without the ability to click the link will not know where it goes... while the link [[file:1:2:1]] makes it quite clear even without clicking it. Example use case: scriptures with well known structure, e.g. the Bible. On Mon, 2018-03-12 at 10:29 +, Eric S Fraga wrote: > On Monday, 12 Mar 2018 at 12:09, ST wrote: > > Hi, > > > > after reading the manual I didn't find a way to construct structured > > links referring to headings with endless depth, like: > > I'm not entirely sure what your use case is but could you use a target, > i.e. something like <>, to indicate where you want to link to? > Cf. section 4.2 of org manual on internal links. >
[O] Structured links to headings with endless depth
Hi, after reading the manual I didn't find a way to construct structured links referring to headings with endless depth, like: having an file.org: * 1 ** 1 ** 2 *** 1 <---link here with the link: [[path/to/file.org::*1:2:1]] Is this possible or should I file it as feature request? PS: It should work also with link abbreviations: #+LINK: file path/to/file.org::*%s [[file:1:2:1]] Thank you!
Re: [O] Parsing org table from Linux command line
Thank you very much! Is py_org_table.py part of a bigger library? Where can I find it? Thank you! On Sun, 2017-12-10 at 18:12 -0800, John Kitchin wrote: > Check out Listing 7 in > http://pubs.acs.org/doi/pdf/10.1021/acscatal.5b00538. > > It is a pretty minimal Python script to get data from a table. You could > then use it to print column 3 to stdout maybe so it could get piped to > mail, or build up some command you can call. > > ST writes: > > > Hello, > > > > I have an org table and its third column are emails. I would like to > > send an email from command line (with the "mail" cli tool) to all those > > addresses. > > > > 1. How do I extract them from the table and pass to CC of "mail"? > > > > 2. Is the same possible somehow if I have several tables with different > > #+TBLNAMEs: in the same file? > > > > Thank you in advance! > >
[O] Parsing org table from Linux command line
Hello, I have an org table and its third column are emails. I would like to send an email from command line (with the "mail" cli tool) to all those addresses. 1. How do I extract them from the table and pass to CC of "mail"? 2. Is the same possible somehow if I have several tables with different #+TBLNAMEs: in the same file? Thank you in advance!
[O] Beamer mode: specify globally #+ATTR_LATEX:
Hello, I have many images in my presentation. I would like all of them to have the following: #+ATTR_LATEX: :width 0.5\hsize Is there a way to specify this globally (like in the header of the file), so I don't need to write this before each image? Thank you very much!
[O] C-c "." and Converting To Other Calendars
Hi, 1. I try to paste a timestamp in org mode using C-c "." However once I get into Calender I would like to convert to other calender, like here: Converting To Other Calendars https://www.gnu.org/software/emacs/manual/html_node/emacs/To-Other-Calendar.html however pressing "p f" doesn't convert the date to the French calendar (or any other). Is there a way to get this feature working for org? 2. Another question: if I have entries/anniversaries in my diary in other calendar (e.g. French/Chinese/etc.) - how do I display them in my org agenda? Thank you!
Re: [O] Nested ordered (numbered) lists
Thank you for the tip! But shouldn't it be part of org export? And it looks like org itself doesn't support it, so if I press M- while in: 1. item1 1.1. item1.1. I get to the top level "2. " and not into the nested level "1.2. ". Why? Should we file a feature request? Thank you! On Sun, 2016-06-26 at 15:58 +0100, Eric S Fraga wrote: > On Saturday, 25 Jun 2016 at 19:34, ST wrote: > > Hi, > > > > is there a way to produce nested ordered (numbered) lists and get it > > exported (to pdf/html) properly? Like: > > > > 1. item_1 > > 2. item_2 > >2.1. subitem_2_1 > > 2.1.1. subsubitem_2_1_1 > >2.2. subitem_2_2 > > 3. item_3 > > For pdf export, you can use LaTeX settings, as described in > > https://vantr.wordpress.com/2011/12/16/multi-level-enumerated-list-in-latex/ > > For HTML, I have no idea. Sorry. >
[O] Nested ordered (numbered) lists
Hi, is there a way to produce nested ordered (numbered) lists and get it exported (to pdf/html) properly? Like: 1. item_1 2. item_2 2.1. subitem_2_1 2.1.1. subsubitem_2_1_1 2.2. subitem_2_2 3. item_3 Thank you!
Re: [O] Agenda view of BBDB entries with Hebrew dates for anniversaries
1. Get into BBDB mode 2. add new record with the field: anniversary: HSivan 17, 5776 birthday (that is the way you specify a Hebrew date in diary by pressing "i h d" or Diary -> Insert Hebrew -> One time) 3. Get into Org mode 4. Generate Agenda view: C-c a a Thank you! On Thu, 2016-06-23 at 22:19 +0200, Nicolas Goaziou wrote: > Hello, > > ST <smn...@gmail.com> writes: > > > Here is what BBDB developers have to say about my issue... maybe it will > > help... > > Could you show an ECM demonstrating the issue? Thank you. > > Regards, >
Re: [O] Agenda view of BBDB entries with Hebrew dates for anniversaries
Here is what BBDB developers have to say about my issue... maybe it will help... On Thu, 2016-06-23 at 21:22 +0200, Roland Winkler wrote: > On Thu Jun 23 2016 ST wrote: > > I managed to add anniversaries/birthdays to BBDB and display them in > > org-agenda. Now I need to move to the next step and provide those dates > > as Hebrew dates. In diary mode the dates seem to look like HSivan 17, > > 5776 . However if I put it to BBDB like anniversary: HSivan 17, 5776 > > birthday - I get error while trying to generate agenda view: bad-sexp at > > line 5 /path/to/agenda.org (org-bbdb-anniversaries). Any ideas on how to > > get it working? > > You might want to ask this question on a list for org mode. > bbdb-anniv.el has been designed to work with the Emacs calendar. As > described in this file > > In particular, `calendar-date-style' is obeyed via `diary-date-forms'. > > Yet I do not know anything about how org mode might interact with > BBDB anniversaries. > > You mention that you get an error from org-bbdb-anniversaries. This > function is part of org mode, not of BBDB. I do not know what it is > doing / what it is supposed to do. > > (Do your Hebrew dates interact properly with the Emacs calendar?) > > Roland
[O] Agenda view of BBDB entries with Hebrew dates for anniversaries
Hi, I managed to add anniversaries/birthdays to BBDB and display them in org-agenda. Now I need to move to the next step and provide those dates as Hebrew dates. In diary mode the dates seem to look like HSivan 17, 5776 . However if I put it to BBDB like anniversary: HSivan 17, 5776 birthday - I get error while trying to generate agenda view: bad-sexp at line 5 /path/to/agenda.org (org-bbdb-anniversaries). Any ideas on how to get it working? Thank you! ST
Re: [O] Properties in agenda view
Dear Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: On Tuesday, 4 Nov 2014 at 11:24, Toby St Clere Smithe wrote: Hi all, How might I adjust the agenda view so that as well as displaying the dates and names of entries, some property / properties of my choosing are displayed? For instance, I have entries with a LOCATION property, and would like to see that in the agenda view. You can use a column view (C-c C-x C-c) from within the agenda view. You can customise what is presented in this column view by (setq org-agenda-overriding-columns-format %5TODO %TIMESTAMP %40ITEM %LOCATION %TAGS) for instance. Not quite what you wanted, mind you... Don't worry, this is also helpful. Thanks! Toby
[O] Properties in agenda view
Hi all, How might I adjust the agenda view so that as well as displaying the dates and names of entries, some property / properties of my choosing are displayed? For instance, I have entries with a LOCATION property, and would like to see that in the agenda view. Cheers, Toby -- Toby St Clere Smithe http://tsmithe.net
Re: [O] Properties in agenda view
Dear Dominic, Dominic Surano sk8ing...@gmail.com writes: This can be done with custom agenda commands using tables. Something like this should work: (setq org-agenda-custom-commands '((1 . Custom sorted tables) (1t agenda Tasks agenda table (active only) ((org-agenda-skip-function '(org-agenda-skip-entry-if 'nottodo '(TODO WAITING CANCELLED DELEGATED DONE))) (org-agenda-overriding-columns-format %75ITEM %20DEADLINE %100Location) (org-agenda-view-columns-initially t This works with tasks that have the following format: * TODO Go Grocery Shopping DEADLINE: 2014-11-04 Tue :PROPERTIES: :Location: Trader Joe's :END: The above example is for sorted agenda. This can also be accomplished for unsorted task lists. Thanks very much -- I'll have a play with that. Regards, Toby -- Toby St Clere Smithe http://tsmithe.net
[Orgmode] Having time inside a scheduled item
Hello! Whenever I schdedule an item (C-c C-s), I don't know how to have the hour of the scheduled item to appear/to be considered. I know that with timestamps, using C-u C-c ./! will add the hour in the timestamp, but C-u C-c C-s doesn't seem to work. Is it possible to schedule at a precise hour, if so how? Thank you! ^_^Y David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Having time inside a scheduled item
Manish wrote: C-c C-s drops you in a prompt, enter wed 10:10 RET (sans quotes) and it is scheduled for that precise hour. No? *sigh* your right! hehe I was trying to enter 10h00, but i guess it has to be 10:00! hehe Thank you! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Colored highlights?
Hi all! I would like to know if it is possible to highlight some text region with a certain color. I know that the *bold*, _underligned_ and /italic/ works fine, and I was wondering if it would be possible to colorize some other parts to have a better contrast. Thank you! ^_^Y David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Usage of #+STYLE:
Carsten Dominik wrote: When I do this, the line is included. I need a minimal example to find out more. Ok I've attached a minimal org file which uses both the #+TITLE: form (which works fine) and the #+STYLE: form (wich doesn't). I've also attach the generated html file. Thank you! ^_^ Title: Plan du mémoire de maîtrise Plan du mémoire de maîtrise Table of Contents 1 This is a test! 1.1 blublu 1.2 blabla 1 This is a test! 1.1 blublu 1.2 blabla Author: d...@david-laptop Date: 2009/02/02 09:08:29 AM HTML generated by org-mode 6.05b in emacs 22 #+TITLE: Plan du mémoire de maîtrise #+STYLE: link rel=stylesheet type=text/css href=style.css / * This is a test! ** blublu ** blabla signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Usage of #+STYLE:
Sebastian Rose wrote: Hi David, Exactly that file works fine here. Hm - anything else must cause this. I don't think your org-mode version older than the feature? I don't think so. I'm using the most recent version available in gentoo's portage: d...@david-laptop ~ $ eix org-mode [I] app-emacs/org-mode Available versions: 6.05b ~6.16c ~6.20c Installed versions: 6.05b(08:51:52 AM 09/01/09) Homepage:http://www.orgmode.org/ Description: An Emacs mode for notes and project planning Is this version too old? Thanks! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Usage of #+STYLE:
Hello! I tried to add the follwing line to one of my org file: #+STYLE: link rel=stylesheet type=text/css href=style.css / but, when I export it to html, there is no link .../ line in the resulting html... Is there something that I am doing wrong? Thank you! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] elisp code location?
Hi all! I am new to the org-mode, but its been very helpfull so far :). I was wondering though, where should I put the elisp code that is sometime required? For example, when creating a project I have to set the org-publish-project-alist variable, but where that setq should be? I've put it in my ~/.emacs, but I am sure that there must be a better alternative :). Can it be somehow put directly in the org file? Thank you! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] elisp code location?
Manish wrote: Some of the publishing options can be kept in the org file itself but some others would need to defined as part of org-publish-project-alist itself only. Is there a reason why you do not wish to keep the settings in .emacs file? No reason, I was just trying to understand how to publishing system works. I couldn't make it work so far. I now have setup my project alist in my .emacs file (and reloaded my .emacs) and when I try to publish my project, nothing happens... Here is what I added to my .emacs: (setq org-publish-project-alist '((plan :base-directory /home/dave/projet/maitrise/memoire :publishing-directory /home/dave/projet/maitrise/memoire/html :section-numbers nil :table-of-contents t :publishing-function org-publish-org-to-html))) A strange thing I noticed is that when I use M-x and type org-publish then press tab, I only get: Possible completions are: org-publishorg-publish-all org-publish-current-file org-publish-current-project org-publish-initialize-files-alist org-publish-project and thus org-publish-org-to-html doesn't seem to be there... I installed org-mode throuhg gentoo emerge and am at the version 6.05b, is this version too old to use publishing? Thank you very much for your help! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] elisp code location?
Matthew Lundin wrote: Hi David, David St-Hilaire sthil...@iro.umontreal.ca writes: No reason, I was just trying to understand how to publishing system works. I couldn't make it work so far. I now have setup my project alist in my .emacs file (and reloaded my .emacs) and when I try to publish my project, nothing happens... When precisely does nothing happen? After you call org-publish? Yes exactly. I use the binding C-c C-e P (or X then plan ret) and nothing happens :( But nothing happens, I meant that no html file are produced in the specified directory (/home/dave/projet/maitrise/memoire/html). Here is what I added to my .emacs: (setq org-publish-project-alist '((plan :base-directory /home/dave/projet/maitrise/memoire :publishing-directory /home/dave/projet/maitrise/memoire/html :section-numbers nil :table-of-contents t :publishing-function org-publish-org-to-html))) A strange thing I noticed is that when I use M-x and type org-publish then press tab, I only get: Possible completions are: org-publishorg-publish-all org-publish-current-file org-publish-current-project org-publish-initialize-files-alist org-publish-project You've set org-publish-to-html in your org-publish-project-alist, so that means that it will be the publishing function for the project plan. So when you call org-publish with one of the functions above, it should publish the project plan to html in the publishing-directory you've specified. You might want to add the line :base-extension org to your publishing alist, though I'm not sure whether that's absolutely necessary. I tried to add it, but it doesn't change anything :( Am I following the standard procedure for doing this? Thank you very much for your help! David signature.asc Description: OpenPGP digital signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
