[O] CUSTOM_ID property does not support Chinese
Here is the example: #+begin_src org * headline :CUSTOM_ID: 测试 #+end_src I use org-store-link, and org-insert-link keybindings. But it reports error: Position saved to mark ring, go back with ‘M-,’. if: No match for custom ID: %E5%AE%BD%E5%BA%A6%E4%BC%98%E5%85%88%E6%9C%89%E5%88%A9%E4%BA%8E%E5%A4%9A%E4%B8%AA%E7%88%AC%E8%99%AB%E5%8D%8F%E5%90%8C%E6%8A%93%E5%8F%96 Position saved to mark ring, go back with ‘M-,’. if: No match for custom ID: %E5%AE%BD%E5%BA%A6%E4%BC%98%E5%85%88%E6%9C%89%E5%88%A9%E4%BA%8E%E5%A4%9A%E4%B8%AA%E7%88%AC%E8%99%AB%E5%8D%8F%E5%90%8C%E6%8A%93%E5%8F%96 Seems Org Mode can't handle Chinese correctly. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Yet another data point: I followed your suggestion : * desinstalled MELPA's org * cloned https://code.orgmode.org/bzg/org-mode.git * make autoloads * make * emacs -q * M-: (add-to-list 'load-path "/org-mode/lisp") C-c C-e l o still gets me the same result (i. e. a table of contents entitled "Contents" rather than "Table des matières"). I got this result * using the (default) master branch * using the "next" branch : - git branch next origin/next - git checkout next - make autoloads - make In both branches, make says "org-version: 9.1.14 (release_9.1.14-1124- gfb5e3e)" at the end of compilation. I'm stymied... I have but one *visual* clue : whereas the fontlock gives me a gray color for #+title, #+author and #+date (light gray for the tags, dark blue for the title, medium grey for author and date), "#+language: fr" remains in red, even after C-c C-c. (Approximate colors : I'm semi- color-blind). HTH, -- Emmanuel Charpentier Le dimanche 25 novembre 2018 à 23:31 +0100, Nicolas Goaziou a écrit : > Emmanuel Charpentier writes: > > > Thanks for a prompt answer ! A couple questions : > > > > 1) What do you mean by "minimal configuration" ? A stripped > > .emacs/d/init.el ? > > Indeed. > > > 2) How can I get the "development version" ? I'm following MELPA > > already... > > You have to clone the repository and load Org from there, "master" > branch, aka "Org 9.2".
Re: [O] Standard Format for Org Outlines?
Nicolas Goaziou writes: > David Masterson writes: >> Why does org-insert-heading insert a heading with a blank line after it >> inserts the heading while org-insert-heading-respect-context does not? > It may be a bug. Do you have an ECM for it? No. Thought it might be a mistake on my part. How do you file ECMs? >> Am I missing a setting? Or have I (accidently) set a setting without >> realizing it? I seem to recall reading something about this in the Org >> manual(s), but I can't find it now. > See `org-blank-before-new-entry'. Bingo! Its value is ((heading . auto) (plain-list-item . auto)) It apparently only affects org-insert-heading, but not org-insert-heading-respect-content -- I'm not sure why. Is that a bug? -- David
Re: [O] suppress ++ markup in orgmode?
hm. I would have interpreted it as an empty string with a strikethrough, followed by a plus. It makes sense to require 1 or more characters between them though. Why is +-+ not a - with a strikethrough? Because it is a table line? Or + + is not a space with a strikethrough. I guess there are word boundaries required. I thought it was interesting that ++ + and + ++ show no strikethrough, but ++ ++ does. Evidently a strikethrough on + +. An editor, on the other hand, might want to strikeout excess spaces. It isn't a big deal, I just changed the editmark syntax to avoid clashing with org-syntax. Nicolas Goaziou writes: > Hello, > > John Kitchin writes: > >> That doesn't seem right to me. It seems like a bug that it is rendered as >> strikethrough to me, like the regexp that is generated is too greedy. That >> was a good hint though. > > IMO, +++ is clearly a plus sign with strike-through. Why would "+" sign > be excluded from strike-through? > > You can use a zero-width space, like +++. > > Regards, -- 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
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Emmanuel Charpentier writes: > Thanks for a prompt answer ! A couple questions : > > 1) What do you mean by "minimal configuration" ? A stripped > .emacs/d/init.el ? Indeed. > 2) How can I get the "development version" ? I'm following MELPA > already... You have to clone the repository and load Org from there, "master" branch, aka "Org 9.2".
Re: [O] [PATCH] don't always restore previous window configuration?
Hello, Matt Price writes: > Personally I prefer your solution. Would you like me to make a new patch or > would you prefer to do this yourself? Please be my guest. ;) Thank you! Regards, -- Nicolas Goaziou
Re: [O] Standard Format for Org Outlines?
Hello, David Masterson writes: > Why does org-insert-heading insert a heading with a blank line after it > inserts the heading while org-insert-heading-respect-context does not? It may be a bug. Do you have an ECM for it? > Am I missing a setting? Or have I (accidently) set a setting without > realizing it? I seem to recall reading something about this in the Org > manual(s), but I can't find it now. See `org-blank-before-new-entry'. Regards, -- Nicolas Goaziou
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
One more data point : I can reproduce the problem with no init file :
* same org file
* emacs started by "emacs -q"
* M-x (require 'org)
* C-x C-f TstLanguage.org
* C-c C-e l p
==> Same result.
HTH,
--
Emmanuel Charpentier
Le dimanche 25 novembre 2018 à 20:03 +0100, Nicolas Goaziou a écrit :
> Hello,
>
> Emmanuel Charpentier writes:
>
> > As of today, I note that the #+langiage export variable is no
> > longer
> > honored when exporting to LaTeX/PDF. See enclosed files :
> >
> > - #+language:fr should get me a table of contents entitled "Table
> > des
> > matières" ;
> >
> > - #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup
> > call,
> > but nothing even remotely babel-related (i. e. nothing related to
> > the
> > LaTeX package babel, which isn't loaded...)
> >
> > - the PDF file has a table of contents entitled "Contents".
>
> I cannot reproduce your problem. You may try again with a minimal
> configuration, or with development version, which is very stable at
> this
> point.
>
> Regards,
>
Re: [O] Standard Format for Org Outlines?
Nicolas Goaziou writes: > Neil Jerram writes: >> On 23 November 2018 23:23:27 GMT, David Masterson >> wrote: >>>Probably a dumb question, but is there a standard format for Org >>>outlines. I'm particularly wondering about the use of blank lines. I >>>prefer to have blank lines before my headings for readability, but I >>>think a lot of other people work without the blank lines. I recently >>>ran into a case with BeOrg where it, in fact, removed the blank lines >>>when it synced my change back to my original file. That led me to >>>think what is the standard format for an Org outline. Should I >>>expect the tools to adjust to me or should I adjust to them? >> Great question; I've seen and wondered the same thing. In my case it's >> Orgzly that seems to like removing some blank lines - although happily >> it doesn't seem to mind when I add some of them back again. > Blank lines before a headline are not significant in Org syntax. Why does org-insert-heading insert a heading with a blank line after it inserts the heading while org-insert-heading-respect-context does not? Am I missing a setting? Or have I (accidently) set a setting without realizing it? I seem to recall reading something about this in the Org manual(s), but I can't find it now. -- David
Re: [O] [RFC] Link-type for attachments, more attach options
Hi again, > -Original Message- > From: Nicolas Goaziou > Sent: den 20 november 2018 00:52 > To: Gustav Wikström > Cc: Org Mode List > Subject: Re: [RFC] Link-type for attachments, more attach options > > > Yeah - I liked "attached" because I prefer clear keywords. But sure, > > we can keep it shorter. I'd suggest "@" instead in that case. Patch > > updated with that. > > "@" syntax is a reserved syntax for citations in the "wip-cite" branch. > I'd rather not use it here. Also, years ago, "att" link type was used to > link to attachments, hence my proposal. Too bad, "@" was growing on me. @ is currently automatically set as a tag when attaching files to nodes. So it was fitting to use it also in links in my opinion. Is the cite-syntax the same as the regular link-pattern? [[@: ...]] ? Otherwise I'd suggest them to coexist. Or to change the cite-symbol to ... "c" maybe? @ is a pretty standard symbol for attachments. Just have a look at Gmail, Outlook etc. I didn't change this in the attached patch. I'm hoping for second thoughts! :) The future ease of use (i.e. clarity and standardization of symbols in this case) should have precedence over current work in progress... > >> > When working with ATTACH_DIR there are now a couple of new options > >> > available: > >> > - org-attach-dir-inherit-by-default > >> > >> What is the difference between this and > >> `org-attach-allow-inheritance'? > > You didn't answer this question, did you? No, seems I missed it. > Something is fishy here anyways. Why is "ATTACH_DIR_INHERIT" needed at > all? If `org-attach-allow-inheritance', "ATTACH_DIR" should be > inherited. Why depend on another property? Yeah, I don't know why it's configured like that from the start. A bit convoluted. Not sure of what way to go forward though. I can see at least two paths: 1) Rename `org-attach-allow-inheritance' to `org-attach-enable-inheritance' and always make attachments inherited when that is set to "t". Deprecate "ATTACH_DIR_INHERIT". With this I'd also change the precedence-logic between ATTACH_DIR & ID properties and make ID-based attachment inherit as well. The properties ATTACH_DIR and ID should be inherited from the closest node when resolving attachments, with ATTACH_DIR having precedence over ID if both exist for the same node. 2) remove `org-attach-allow-inheritance' and only rely on the "ATTACH_DIR_INHERIT" property of any of the parent nodes to decide if the "ATTACH_DIR" property should be inherited. This would be a smaller change from the user's perspective, where we're basically saying you cannot disable inheritance, but it's only active when a node has the ATTACH_DIR_INHERIT-property. I prefer path (1). That would be a great default. But that change is bigger and should be separated from this patch anyways. To not increase the complexity I've removed the `org-attach-dir-inherit-by-default' customization. > >> > - org-attach-dir-create-if-not-exist > >> > >> What is the use-case for this one? It doesn't seem terribly useful at > >> first glance. > > > > If you try to open attachments on a node where there is no ID or > >> ATTACH_DIR, the default behavior is to add an ID and create a folder > >> based on that ID. I would like Org-mode to not do that. This > >> customization give the user the option to change that. Instead of > >> providing this customization one could just change the default > >> behavior of org-attach, since it's a bit offensive to create folders > >> when I didn't ask for it. But instead of changing the default, > >> I thought this way was more graceful. I wouldn't mind skipping this > >> customization though, if the behavior was changed to what > >> I implemented with org-attach-dir-create-if-not-exist set to nil. > > Considering attaching is about moving, or copying files somewhere, > creating a folder doesn't sound terribly offensive. You don't even have > to know the name of the folder. > > Do you suggest to raise an error if there is no folder available for the > attached documents? If so, wouldn't it be better to ask the user first? Agreed, the parameter can be removed and a "do you want to create a folder?" question could be raised instead, when it's not intuitive for the program to create the folder by itself. > >> > +This list shows the full set of built-in external link types: > >> > +| http | web | > >> > +| https | secure web | > >> > +| doi| DOI for electronic resources| > >> > +| file | file-links | > >> > +| file+sys | file-links forced to open via OS| > >> > +| file+emacs | file-links forced to open via emacs | > >> > +| attached | links to attachments for nodes | > >> > +| docview| doc-view mode | > >> > +| id | Link to heading by id | > >> > +| news | Usenet link | > >> > +| mailto
Re: [O] [PATCH] don't always restore previous window configuration?
On Sun, Nov 25, 2018, 4:02 AM Nicolas Goaziou Hello, > > Matt Price writes: > > > Then I'm sorry for the noise (and also for this aside!). Magit, or git, > or > > some other tool was doing something quite strange and disturbing, and I > am > > now seeing these remotes in my repo: > > dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (fetch) > > dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (push) > > origin https://code.orgmode.org/bzg/org-mode.git (fetch) > > origin https://code.orgmode.org/bzg/org-mode.git (push) > > original/tmp/tmp-orgtest/org-annex-testrgbPft/ (fetch) > > original/tmp/tmp-orgtest/org-annex-testrgbPft/ (push) > > My bad. It seems "test-org-annex.el" messes with "git init". Since > I don't have git-annex command, these tests are usually skipped, so > I hadn't noticed. > > > I'm not sure. Until now only Eric and I had commented on this feature. I > > will say that I will probably never go back to the old behavior, but > maybe > > there are people who prefer it. I believe there are 6 possible options > for > > org-src-window-setup (though only 5 are listed in the defcustom > definition, > > I think that org-src-switch-to-buffer also recognizes 'silently). It may > be > > that some of those options only make sense if the window config is > restored > > after closing the src buffer. > > > > ~org-src--saved-window-config~ is only used in this function, so instead > of > > adding a new variable we could just get rid of an old one :-). > > IMO, the only value for `org-src-window-setup' where it might be > meaningful to preserve windows excursion is `reorganize-frame', since it > can disturb a lot the configuration used before editing the block. > However, the docstring disagrees: "When exiting the edit buffer, return > to one window." > > Therefore, I suggest to simply do not restore previous configuration in > Org 9.3, and document it in incompatible changes. It will leave time to > test it and complain if something is not right. > > WDYT? > Personally I prefer your solution. Would you like me to make a new patch or would you prefer to do this yourself? >
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Thanks for a prompt answer ! A couple questions :
1) What do you mean by "minimal configuration" ? A stripped
.emacs/d/init.el ?
2) How can I get the "development version" ? I'm following MELPA
already...
--
Emmanuel Charpentier
Le dimanche 25 novembre 2018 à 20:03 +0100, Nicolas Goaziou a écrit :
> Hello,
>
> Emmanuel Charpentier writes:
>
> > As of today, I note that the #+langiage export variable is no
> > longer
> > honored when exporting to LaTeX/PDF. See enclosed files :
> >
> > - #+language:fr should get me a table of contents entitled "Table
> > des
> > matières" ;
> >
> > - #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup
> > call,
> > but nothing even remotely babel-related (i. e. nothing related to
> > the
> > LaTeX package babel, which isn't loaded...)
> >
> > - the PDF file has a table of contents entitled "Contents".
>
> I cannot reproduce your problem. You may try again with a minimal
> configuration, or with development version, which is very stable at
> this
> point.
>
> Regards,
>
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Hello,
Emmanuel Charpentier writes:
> As of today, I note that the #+langiage export variable is no longer
> honored when exporting to LaTeX/PDF. See enclosed files :
>
> - #+language:fr should get me a table of contents entitled "Table des
> matières" ;
>
> - #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup call,
> but nothing even remotely babel-related (i. e. nothing related to the
> LaTeX package babel, which isn't loaded...)
>
> - the PDF file has a table of contents entitled "Contents".
I cannot reproduce your problem. You may try again with a minimal
configuration, or with development version, which is very stable at this
point.
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] Add support for Brave to org-mac-link
On November 25, 2018 at 1:08:35 AM, Nicolas Goaziou (m...@nicolasgoaziou.fr(mailto:m...@nicolasgoaziou.fr)) wrote: > Hello, > Applied. > Fixed. Thank you for the quick response! Aaron
[O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
As of today, I note that the #+langiage export variable is no longer
honored when exporting to LaTeX/PDF. See enclosed files :
- #+language:fr should get me a table of contents entitled "Table des
matières" ;
- #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup call,
but nothing even remotely babel-related (i. e. nothing related to the
LaTeX package babel, which isn't loaded...)
- the PDF file has a table of contents entitled "Contents".
HTH,
--
Emmanuel Charpentier
# Vérification d'un loup possible sur #+language...
#+title: Option "Language" ?
#+author: Emmanuel Charpentier
#+date: novembre 2018
#+language: fr
* Pique
Baratin...
* Et pique
Autre baratin
* Et colegram...
Troisième baratin...
# Il y a bien un loup : la table des matières est intitulée
# "Contents"...
TstLanguage.pdf
Description: Adobe PDF document
% Created 2018-11-25 dim. 16:45
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Emmanuel Charpentier}
\date{novembre 2018}
\title{Option "Language" ?}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={Option "Language" ?},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 25.2.2 (Org mode 9.1.14)},
pdflang={Frenchb}}
\begin{document}
\maketitle
\tableofcontents
\section{Pique}
\label{sec:orgc6b6d38}
Baratin\ldots{}
\section{Et pique}
\label{sec:orgf382b87}
Autre baratin
\section{Et colegram\ldots{}}
\label{sec:org30745ef}
Troisième baratin\ldots{}
\end{document}
Re: [O] [Feature Request] Add an dispatcher command (keybinding) for inserting dynamic blocks
Hello, Thierry Banel writes: > Org defines C-c C-x i as org-insert-columns-dblock. Instead, it could call > the org-insert-dblock dispatcher shown here. The original > org-insert-columns-dblock would be one among > other dblock inserters. > > Possible dblocks: > org-insert-columns-dblock > org-clock-report > propview > invoice > org-insert-dblock:aggregate > org-insert-dblock:join > org-insert-dblock:transpose > > Any future dblock inserter would be taken into account by the > dispatcher just by providing an autoloadable > org-insert-dblock:something function. I think we could do something similar to links, i.e., populate a variable (for links, it is `org-link-parameters') with a command (`org-link-set-parameters'), so the dispatcher knows what dynamic blocks can be provided. Otherwise, it sounds like a good idea. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add support for Brave to org-mac-link
Hello, Aaron Jensen writes: > Brave is a chromium-based browser, so the existing Chrome code works > with slight modifications. Applied. > By the way, I’ve signed FSF papers though > https://orgmode.org/worg/org-contribute.html currently has me listed > in the wrong place. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] don't always restore previous window configuration?
Hello, Matt Price writes: > Then I'm sorry for the noise (and also for this aside!). Magit, or git, or > some other tool was doing something quite strange and disturbing, and I am > now seeing these remotes in my repo: > dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (fetch) > dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (push) > origin https://code.orgmode.org/bzg/org-mode.git (fetch) > origin https://code.orgmode.org/bzg/org-mode.git (push) > original/tmp/tmp-orgtest/org-annex-testrgbPft/ (fetch) > original/tmp/tmp-orgtest/org-annex-testrgbPft/ (push) My bad. It seems "test-org-annex.el" messes with "git init". Since I don't have git-annex command, these tests are usually skipped, so I hadn't noticed. > I'm not sure. Until now only Eric and I had commented on this feature. I > will say that I will probably never go back to the old behavior, but maybe > there are people who prefer it. I believe there are 6 possible options for > org-src-window-setup (though only 5 are listed in the defcustom definition, > I think that org-src-switch-to-buffer also recognizes 'silently). It may be > that some of those options only make sense if the window config is restored > after closing the src buffer. > > ~org-src--saved-window-config~ is only used in this function, so instead of > adding a new variable we could just get rid of an old one :-). IMO, the only value for `org-src-window-setup' where it might be meaningful to preserve windows excursion is `reorganize-frame', since it can disturb a lot the configuration used before editing the block. However, the docstring disagrees: "When exiting the edit buffer, return to one window." Therefore, I suggest to simply do not restore previous configuration in Org 9.3, and document it in incompatible changes. It will leave time to test it and complain if something is not right. WDYT? Regards, -- Nicolas Goaziou
