TexInfo export: Using org-manual.org's `kbd' macro problematic for C-{ and C-} keys
As you already know, I am working on creating a info manual for Emacs'
Helm library. I ran in to a new issue today.
TexInfo export: Using org-manual.org's `kbd' problematic for C-{ and C-} keys
It may not be a problem with the macro as much. It is possible that I
am using it wrongly. How do I get the following snippet DTRT?
Here is the org snippet
- {{{kbd(C-{)}}} (~helm-enlarge-window~) ::
#+findex: helm-enlarge-window
#+kindex: C-{
Enlarge helm window.
- {{{kbd(C-})}}} (~helm-narrow-window~) ::
#+findex: helm-narrow-window
#+kindex: C-}
Narrow helm window.
About completion-ignore-case in org-tags-completion-function
In org-tags-completion-function, completion-ignore-case force nil, what about set it to t? tags are case-sensitive, wile this function is used to search tag. (defun org-tags-completion-function (string _predicate &optional flag) "Complete tag STRING. FLAG specifies the type of completion operation to perform. This function is passed as a collection function to `completing-read', which see." (let ((completion-ignore-case nil);tags are case-sensitive (confirm (lambda (x) (stringp (car x (prefix "")) (when (string-match "^\\(.*[-+:&,|]\\)\\([^-+:&,|]*\\)$" string) (setq prefix (match-string 1 string)) (setq string (match-string 2 string))) (pcase flag (`t (all-completions string org-last-tags-completion-table confirm)) (`lambda (assoc string org-last-tags-completion-table)) ;exact match? (`nil (pcase (try-completion string org-last-tags-completion-table confirm) ((and completion (pred stringp)) (concat prefix completion (if (and org-add-colon-after-tag-completion (assoc completion org-last-tags-completion-table)) ":" ""))) (completion completion))) (_ nil
Re: [Patch] to correctly sort the items with emphasis marks in a list
On 14/04/2021 02:08, Juan Manuel Macías wrote: The situation is that with locales configured for Spanish from Spain (en_ES.UTF-8) the list is not ordered correctly, unless those three spaces from org-sort-remove-invisible are removed. But I couldn't say why or if that would be appropriate as a patch... Did not you get a warning like the following one? (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C library. Using the fallback 'C' locale. Regarding the collation rule of forms with emphasis, at least in Spanish these should come after the non-emphasized forms. I don't know if this is a general rule also for other languages (at least it seems more natural that the forms without emphasis are placed before). LANG=es_ES.UTF-8 \ emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \ list.org - a - /a/ - v - /v/ So it works accordingly to your expectation. Emacs 25.2.2, Ubuntu-18.04 container. I have generated es_ES.UTF-8 locale using dpkg-reconfigure locales Depending on linux distribution you run, the locale may be ready to use or not. I tend to think that in minimal environment of virtual machine it was missed. I had an idea to add a test for sorting of items including emphasized ones but test-org-list/sort forces C locale. Maybe it was done to avoid failures due to missed locale.
Re: [Patch] to correctly sort the items with emphasis marks in a list
On 14/04/2021 22:42, Maxim Nikulin wrote: I have generated es_ES.UTF-8 locale using dpkg-reconfigure locales Depending on linux distribution you run, the locale may be ready to use or not. I tend to think that in minimal environment of virtual machine it was missed. I forgot to add a command how to get the list of generated locales locale --all-locales locales-2.27-3ubuntu1.4 package is built from glibc sources.
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hi Maxim, Thanks again. In my case, I keep getting the wrong result. In addition to the test I did in a virtual machine with Fedora, I use Arch Linux in my every day computers, with locales correctly (I hope) configured as es_ES.UTF-8 (there was a typo in my previous mail, sorry: 'en_ES.UTF-8'). In my /etc/locale.conf file I have: LANG=es_ES.UTF-8 LC_ADDRESS=es_ES.UTF-8 LC_IDENTIFICATION=es_ES.UTF-8 LC_MEASUREMENT=es_ES.UTF-8 LC_MONETARY=es_ES.UTF-8 LC_NAME=es_ES.UTF-8 LC_NUMERIC=es_ES.UTF-8 LC_PAPER=es_ES.UTF-8 LC_TELEPHONE=es_ES.UTF-8 LC_TIME=es_ES.UTF-8 And with locale -a, I get a list of enabled locales: C en_US.utf8 es_ES.utf8 POSIX However, I keep getting the wrong result :-( (Arch, Emacs 27.2). Even with LANG=en_EN.UTF-8 \ emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \ list.org Maybe the problem is on Arch's side (?), although it was also reproducible in the test I did with Fedora in virtual machine and Emacs 27. Best regards, Juan Manuel Maxim Nikulin writes: > On 14/04/2021 02:08, Juan Manuel Macías wrote: >> The situation is that with locales configured for Spanish from Spain >> (en_ES.UTF-8) the list is not ordered correctly, unless those three >> spaces from org-sort-remove-invisible are removed. But I couldn't say >> why or if that would be appropriate as a patch... > > Did not you get a warning like the following one? > > (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C > library. > Using the fallback 'C' locale. > >> Regarding the collation rule of forms with emphasis, at least in Spanish >> these should come after the non-emphasized forms. I don't know if this >> is a general rule also for other languages (at least it seems more >> natural that the forms without emphasis are placed before). > > LANG=es_ES.UTF-8 \ > emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \ > list.org > > - a > - /a/ > - v > - /v/ > > So it works accordingly to your expectation. Emacs 25.2.2, > Ubuntu-18.04 container. > > I have generated es_ES.UTF-8 locale using > > dpkg-reconfigure locales > > Depending on linux distribution you run, the locale may be ready to > use or not. I tend to think that in minimal environment of virtual > machine it was missed. > > I had an idea to add a test for sorting of items including emphasized > ones but test-org-list/sort forces C locale. Maybe it was done to > avoid failures due to missed locale. > >
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hello again, Since I have an old Emacs version (24.5.1) on my Raspberry, I've done a few more tests. The situation is the following: 1. On Arch Linux and Emacs 27.2: - The system locales are set to "es_ES.UTF-8". When, inside Emacs, I do M-x getenv RET LANG RET, I get "es_ES.UTF-8". org-sort-list a -> wrong result; - Launching Emacs from terminal with LANG=es_ES.UTF-8 \ etc... org-sort-list a -> wrong result again. 2. On Fedora 32 (virtual machine) and Emacs 27.1 - Everything as in the previous case. 3. On Raspian stretch and Emacs 24.5.1: - The system locales are set to "es_ES.UTF-8" as well. When, inside a normal Emacs session, I do M-x getenv RET lang RET, I get "es_ES.UTF-8". org-sort-list a -> wrong result; - Launching Emacs from terminal with LANG=es_ES.UTF-8 \ etc... In this case the list is ordered correctly, but I observe that similar forms with or without emphasis are not always ordered in the same way. Sometimes the non-emphasized forms are ordered before and sometimes they are ordered after (?). I don't know if I'm missing something... Best regards, Juan Manuel Juan Manuel Macías writes: > Hi Maxim, > > Thanks again. In my case, I keep getting the wrong result. In addition > to the test I did in a virtual machine with Fedora, I use Arch Linux in > my every day computers, with locales correctly (I hope) configured as > es_ES.UTF-8 (there was a typo in my previous mail, sorry: > 'en_ES.UTF-8'). In my /etc/locale.conf file I have: > > LANG=es_ES.UTF-8 > LC_ADDRESS=es_ES.UTF-8 > LC_IDENTIFICATION=es_ES.UTF-8 > LC_MEASUREMENT=es_ES.UTF-8 > LC_MONETARY=es_ES.UTF-8 > LC_NAME=es_ES.UTF-8 > LC_NUMERIC=es_ES.UTF-8 > LC_PAPER=es_ES.UTF-8 > LC_TELEPHONE=es_ES.UTF-8 > LC_TIME=es_ES.UTF-8 > > And with locale -a, I get a list of enabled locales: > > C > en_US.utf8 > es_ES.utf8 > POSIX > > However, I keep getting the wrong result :-( (Arch, Emacs 27.2). > > Even with > > LANG=en_EN.UTF-8 \ > emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \ > list.org > > Maybe the problem is on Arch's side (?), although it was also reproducible > in the test I did with Fedora in virtual machine and Emacs 27. > > Best regards, > > Juan Manuel > > Maxim Nikulin writes: > >> On 14/04/2021 02:08, Juan Manuel Macías wrote: >>> The situation is that with locales configured for Spanish from Spain >>> (en_ES.UTF-8) the list is not ordered correctly, unless those three >>> spaces from org-sort-remove-invisible are removed. But I couldn't say >>> why or if that would be appropriate as a patch... >> >> Did not you get a warning like the following one? >> >> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C >> library. >> Using the fallback 'C' locale. >> >>> Regarding the collation rule of forms with emphasis, at least in Spanish >>> these should come after the non-emphasized forms. I don't know if this >>> is a general rule also for other languages (at least it seems more >>> natural that the forms without emphasis are placed before). >> >> LANG=es_ES.UTF-8 \ >> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \ >> list.org >> >> - a >> - /a/ >> - v >> - /v/ >> >> So it works accordingly to your expectation. Emacs 25.2.2, >> Ubuntu-18.04 container. >> >> I have generated es_ES.UTF-8 locale using >> >> dpkg-reconfigure locales >> >> Depending on linux distribution you run, the locale may be ready to >> use or not. I tend to think that in minimal environment of virtual >> machine it was missed. >> >> I had an idea to add a test for sorting of items including emphasized >> ones but test-org-list/sort forces C locale. Maybe it was done to >> avoid failures due to missed locale. >> >> >
[PATCH] Add 'simple option to org-fast-tag-selection-single-key.
Hello I have added 'simple option to org-fast-tag-selection-single-key, please try and comment :-) (setq org-use-fast-tag-selection t) (setq org-fast-tag-selection-single-key 'simple) ;; better use vertico or selectrum :-) ;; (require 'vertico) ;; (vertico-mode 1) thanks! 0001-Add-simple-option-to-org-fast-tag-selection-single-k.patch Description: Binary data
Remove file to original state after org-capture-kill?
I have an org-capture template that looks like this:
'(("j" "Journal"
entry (file+headline find-file-function "Journal")
"* %?")
(I create separate Org files for each day, which the find-file-function
returns the path for.)
If I call org-capture "j" on a file that doesn't have a "Journal" headline,
it will create one for me (the desired behavior). But if I abort the
org-capture the "Journal" headline will not be deleted. Is there a way to
change this? I.e., I would like, after I call org-capture-kill, for the
file to return to the state it was before I called org-capture.
Thanks,
Alan
