[O] Multiple Indices
I’m using Org mode to document some software. When I see Texinfo used for this, I see that you can have a subject index and a variable index. How do I achieve the same thing in Org mode? Can someone point to examples of this?
[O] bug#34684: 26.1; Strange characters when inserting date
> From: Robert Pluim > Cc: "Wong\, Philip" , 34...@debbugs.gnu.org > Date: Thu, 28 Feb 2019 20:11:45 +0100 > > Eli Zaretskii writes: > > >> From: "Wong, Philip" > >> Date: Thu, 28 Feb 2019 14:16:25 + > >> > >> When I insert a date by pressing CTRL+C then period then enter I get > >> “<2019-02-28 ¶g¥|>”. > >> > >> I’m not sure what the strange character is (¶g¥|), can someone help? > > > > Please show a complete recipe, starting from "emacs -Q", to reproduce > > the issue. When I type "Ctrl-C ." in "emacs -Q", Emacs says that > > sequence is not bound to any command, so I wonder what is needed to > > "insert a date" in your scenario. > > >From the output, this is 'org-time-stamp', which produces > <2019-02-28 Thu> here. Based on this in the report: > > Important settings: > value of $LANG: ZHH > locale-coding-system: cp1252 > > Iʼm assuming thereʼs an issue with buffer-file-coding-system or > similar. Unlikely: buffer-file-coding-system has no effect whatsoever on the text that is inserted into a buffer, it only has effect when you want to save the buffer or send it to some sub-process. It could be some snafu in Org, though, e.,g. if it doesn't know how to support that value of $LANG. In any case, should be reported to Org developers first.
Re: [O] Lowercase keywords in 9.2?
Great, thanks!
Re: [O] bug#34684: 26.1; Strange characters when inserting date
Robert Pluim writes: > Eli Zaretskii writes: > >>> From: "Wong, Philip" >>> Date: Thu, 28 Feb 2019 14:16:25 + >>> >>> When I insert a date by pressing CTRL+C then period then enter I get >>> “<2019-02-28 ¶g¥|>”. >>> >>> I’m not sure what the strange character is (¶g¥|), can someone help? >> >> Please show a complete recipe, starting from "emacs -Q", to reproduce >> the issue. When I type "Ctrl-C ." in "emacs -Q", Emacs says that >> sequence is not bound to any command, so I wonder what is needed to >> "insert a date" in your scenario. > > From the output, this is 'org-time-stamp', which produces > <2019-02-28 Thu> here. Based on this in the report: > > Important settings: > value of $LANG: ZHH > locale-coding-system: cp1252 > > Iʼm assuming thereʼs an issue with buffer-file-coding-system or > similar. If I do > > LANG=zh_HK src/emacs -Q > (require 'org) > (org-time-stamp) => <2019-02-28 四> That means "four", aka "Thursday" :)
[O] bug#34684: 26.1; Strange characters when inserting date
Eli Zaretskii writes: >> From: "Wong, Philip" >> Date: Thu, 28 Feb 2019 14:16:25 + >> >> When I insert a date by pressing CTRL+C then period then enter I get >> “<2019-02-28 ¶g¥|>”. >> >> I’m not sure what the strange character is (¶g¥|), can someone help? > > Please show a complete recipe, starting from "emacs -Q", to reproduce > the issue. When I type "Ctrl-C ." in "emacs -Q", Emacs says that > sequence is not bound to any command, so I wonder what is needed to > "insert a date" in your scenario. >From the output, this is 'org-time-stamp', which produces <2019-02-28 Thu> here. Based on this in the report: Important settings: value of $LANG: ZHH locale-coding-system: cp1252 Iʼm assuming thereʼs an issue with buffer-file-coding-system or similar. If I do LANG=zh_HK src/emacs -Q (require 'org) (org-time-stamp) => <2019-02-28 四> where that character after the date is CJK IDEOGRAPH-56DB (and now Iʼve exhausted what I know about Asian characters) Robert
Re: [O] Bug: Org ignores column-width specifications in tables
On 28 Feb 2019, at 11:02, Nicolas Goaziou wrote: Hello, "Galen Menzel" writes: I’m seeing that in org 9.2.1 (from org-plus-contrib 20190225) tables are not respecting column-width specifications. For example, if I create the following table | Header 1 | | <10> | | This column should be truncated to 10 characters | When I align it in org 9.1.9, I get the following: | Header 1 | | <10> | | This col=> | Narrowing columns is decoupled from alignment. Use `C-c ` to shrink or expand it. Ah I missed that. Works fine as you describe — thanks! Best, Galen
Re: [O] Lowercase keywords in 9.2?
Hello, Carlos Pita writes: > Today I noticed the export templates inserted by org are still uppercase: > > #+LATEX_CLASS: article > #+LATEX_CLASS_OPTIONS: > #+LATEX_HEADER: > #+LATEX_HEADER_EXTRA: > #+DESCRIPTION: > #+KEYWORDS: > #+SUBTITLE: > #+LATEX_COMPILER: pdflatex > > #+DATE: \today > > Is this intentional, is the lowercase convention intended for blocks > only? I fixed it. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org ignores column-width specifications in tables
Hello, "Galen Menzel" writes: > I’m seeing that in org 9.2.1 (from org-plus-contrib 20190225) tables > are not respecting column-width specifications. For example, if > I create the following table > > | Header 1 | > | <10> | > | This column should be truncated to 10 characters | > > When I align it in org 9.1.9, I get the following: > > | Header 1 | > | <10> | > | This col=> | Narrowing columns is decoupled from alignment. Use `C-c ` to shrink or expand it. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org ignores column-width specifications in tables
Oops, forgot to include verbatim markers. For the following table ``` | Header 1 | | <10> | | This column should be truncated to 10 characters | ``` When I align it in org 9.1.9, the column display is truncated as expected: ``` | Header 1 | | <10> | | This col=> | ``` But when I align it in 9.2.1, the column width is not affected, and I get ``` | Header 1 | | <10> | | This column should be truncated to 10 characters | ``` Thanks, Galen On 28 Feb 2019, at 10:29, Galen Menzel wrote: Hi all, I’m seeing that in org 9.2.1 (from org-plus-contrib 20190225) tables are not respecting column-width specifications. For example, if I create the following table | Header 1 | | <10> | | This column should be truncated to 10 characters | When I align it in org 9.1.9, I get the following: | Header 1 | | <10> | | This col=> | But when I align it in 9.2.1, I get | Header 1 | | <10> | | This column should be truncated to 10 characters | Alignment specifications *do* work as expected. It just appears that column-width specs are being ignored. Is anyone else seeing this issue? Best, Galen
[O] Bug: Org ignores column-width specifications in tables
Hi all, I’m seeing that in org 9.2.1 (from org-plus-contrib 20190225) tables are not respecting column-width specifications. For example, if I create the following table | Header 1 | | <10> | | This column should be truncated to 10 characters | When I align it in org 9.1.9, I get the following: | Header 1 | | <10> | | This col=> | But when I align it in 9.2.1, I get | Header 1 | | <10> | | This column should be truncated to 10 characters | Alignment specifications *do* work as expected. It just appears that column-width specs are being ignored. Is anyone else seeing this issue? Best, Galen
[O] bug#34684: 26.1; Strange characters when inserting date
> From: "Wong, Philip" > Date: Thu, 28 Feb 2019 14:16:25 + > > When I insert a date by pressing CTRL+C then period then enter I get > “<2019-02-28 ¶g¥|>”. > > I’m not sure what the strange character is (¶g¥|), can someone help? Please show a complete recipe, starting from "emacs -Q", to reproduce the issue. When I type "Ctrl-C ." in "emacs -Q", Emacs says that sequence is not bound to any command, so I wonder what is needed to "insert a date" in your scenario. Thanks.
Re: [O] [PATCH] Let org-agenda align multibyte tags properly
Hello, tumashu writes: > org agenda can not align tags which include multibyte char, please see > before.png > > This patch fix the problem, please see after.png I replaced (buffer-substring (match-beginning 1) (match-end 1)) with (match-string 1) and applied your patch. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Let radio target works well with Chinese
Hello, tumashu writes: > 在 2019-02-25 20:31:24，"Nicolas Goaziou" 写道： >>Hello, >> >>"Feng Shu" writes: >> >>> * lisp/org.el (org-update-radio-target-regexp): Let radio target works well >>> with Chinese >> >>Thank you. >> >>> There is no need to force split words with the help >>> of space for Chinese, this change let the below >>> example works well. >>> >>> <<<天空>>> >>> >>> 我爱天空和大地 >>> >> >>Org doesn't support mid-word radio targets. Is there any strong reason >>to make a case for Chinese? What about other languages? >> >> > > > Because Chinese need no space between words :-), for example: > > 我不知道这个事情到底对不对，你觉得对就对，不对就不对。 This is a strong reason, indeed. > I have updated the patch adviced by Eric Abrahamsen: I added a comment and applied the patch. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Lowercase keywords in 9.2?
Today I noticed the export templates inserted by org are still uppercase: #+LATEX_CLASS: article #+LATEX_CLASS_OPTIONS: #+LATEX_HEADER: #+LATEX_HEADER_EXTRA: #+DESCRIPTION: #+KEYWORDS: #+SUBTITLE: #+LATEX_COMPILER: pdflatex #+DATE: \today Is this intentional, is the lowercase convention intended for blocks only? Best regards -- Carlos
Re: [O] [PATCH] Let radio target works well with Chinese
在 2019-02-25 20:31:24，"Nicolas Goaziou" 写道： >Hello, > >"Feng Shu" writes: > >> * lisp/org.el (org-update-radio-target-regexp): Let radio target works well >> with Chinese > >Thank you. > >> There is no need to force split words with the help >> of space for Chinese, this change let the below >> example works well. >> >> <<<天空>>> >> >> 我爱天空和大地 >> > >Org doesn't support mid-word radio targets. Is there any strong reason >to make a case for Chinese? What about other languages? > > Because Chinese need no space between words :-), for example: 我不知道这个事情到底对不对，你觉得对就对，不对就不对。 I have updated the patch adviced by Eric Abrahamsen: >Regards, > >-- >Nicolas Goaziou 0001-Let-radio-target-works-well-with-Chinese.patch Description: Binary data
Re: [O] [RFC] Fixing link encoding once and for all
Hello, Jens Lechtenboerger writes: > I copied that from the address bar of my browser, probably two years > ago. Today, I was surprised by a compilation failure. Link syntax is currently unstable. We fix it on one side and it breaks elsewhere. This thread is an attempt to make the link syntax stable. It will not necessarily solve your example, tho. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Fixing link encoding once and for all
On Wed, 27 Feb 2019 at 10:49, Nicolas Goaziou wrote: > > Hello, > > Neil Jerram writes: > > > I'm not sure how much freedom you have here, but I think it would be > > both clearer - by avoiding confusion with URL-escaping - and easier to > > type, to use an entirely different form of escaping in the Org syntax; > > probably just this: > > > > \[ and \] to include a square bracket in a link > > \\ to include a backslash > > Wouldn't that become problematic with file names in Windows? Do you mean Windows file names in existing Org files? I.e. the back-compatibility concern? If so, yes, I confess I didn't think at all about back-compatibility, with my suggestion above. So perhaps that rules my idea out. If we were starting from scratch, however, - I believe it would technically be fine; i.e. it's a complete and unambiguous encoding - it might be considered awkward for Windows users to have to write c:\\system32\\mydoc.txt instead of c:\system32\mydoc.txt, but I don't know how big a concern that would be. Best wishes, Neil > Regards, > > -- > Nicolas Goaziou
Re: [O] Set checkbox to intermediate in code
Op do 28 feb. 2019 om 08:51 schreef Cecil Westerhof : > I can set a checkbox to intermediate with: > C-u C-u C-c C-x C-b > > But I want to do it with code. How would I do that? > Found it. Quit simple: (org-toggle-checkbox '(16)) -- Cecil Westerhof
