Re: org-fontify-done-headline t by default?
TRS-80 writes: > The change was so jarring, and in total contravention of my (otherwise) > nice looking Nord theme. Something like that might have put me off from > Orgmode /completely/ if I did not know how to quickly fix it. > > For all of above reasons (and probably some others, too!), I do not > think this should be the default! I don't have a strong opinion about org-fontify-done-headline being t by default (though I disable it), but I agree that the current definition of org-headline-done is jarring with most of the themes out there. Maybe it would make sense to make it inherit from one of Emacs's core faces (e.g. shadow): that would pretty much guarantee that themes would cover it, so it would stand out less.
org-fontify-done-headline t by default?
Hello *, I finally got around to upgrading Emacs (and Orgmode) the last couple days. Therefore apologies if this has been discussed previously. A brief search of the list did not turn up any results. Anyway, imagine my shock when many of my headlines suddenly turned LightSalmon! Now, this only took me few minutes of digging to figure out. However I am pretty handy with Emacs and Elisp by now. What about some poor newbie that barely knows their way around an init file? The change was so jarring, and in total contravention of my (otherwise) nice looking Nord theme. Something like that might have put me off from Orgmode /completely/ if I did not know how to quickly fix it. For all of above reasons (and probably some others, too!), I do not think this should be the default! Please discuss. Cheers, TRS-80
Re: org-refile and ivy
Gustavo Barros writes: > On Fri, 22 Jan 2021 at 15:49, Eric S Fraga wrote: > >> Dear all org mode list readers, >> >> I have been trying to get to grips with org-refile. For some reason, >> the completion mechanism (I use ivy generally but I have no idea what >> org-refile actually tries to do/use) only shows me the current file name >> if I have org-refile-targets set to nil. It doesn't show any top level >> headlines to choose from which is what I would expect from the >> documentation. Hitting RET to select the completion target given (file >> name only) refiles to the end of the file which is not what I want. >> >> This is with org updated fairly recently but not quite up to >> date. However, I've had this problem for a long time and don't use >> org-refile as a result. >> >> Any suggestions welcome. > > I use org-refile with ivy, so I might share. If I recall correctly, the > only thing that does not play well between the two is > `org-outline-path-complete-in-steps`. My basic setup is the following: > > #+begin_src emacs-lisp > (setq org-refile-targets > '((org-agenda-files :maxlevel . 6) > ;; 'nil' means consider headings of the current buffer > (nil :maxlevel . 6))) > (setq org-refile-use-outline-path 'file) > (setq org-outline-path-complete-in-steps nil) > #+end_src > > That should get you started. I personally like org-refile for its > quickness, so I do some extra work to filter out candidates of this list > and keeping only the frequent targets (with > `org-refile-target-verify-function'). And if something atypical arises, > I just go with kill-yank. > > Note however, on the relation of org-refile and ivy: > https://orgmode.org/list/87tuvrj7ww@gmail.com/ > I am using spacemacs, currently with helm, but have used it with ivy as well and I have the following setup for my org-refile, which I find works well for my purposes. org-refile-allow-creating-parent-nodes 'confirm org-refile-targets (quote ((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))) org-refile-use-outline-path t which allows me to type some of the 'path' name (e.g. outline heading or org file name) and it shows me appropriate candidates. I don't know if there is some spacemacs helm/ivy setup which plays a part here - it just works, so I've not looked any further. org version reports 9.4.4 -- Tim Cross
Re: How can I keep Org-id links from breaking when moving files?
On 2021-01-21 08:14, aroz...@gmail.com wrote: there's no way to programmatically make sure that Org can find those IDs again (since there's no way to simply add a folder, rather than a list of files, to =org-id-locations= or =org-id-files=? Being that this is Emacs, you can do almost anything you want, with a little Elisp practice. ;) For example, you could write some custom move command which would automatically add the new folder to some variable or file with a list of folders to add to places for org-id to look in from now on. However perhaps we should take a step back and ask ourselves if this is a good approach? And IMHO, starting to scatter files here and there throughout the filesystem is not a good idea. Even if you implement above mentioned custom Elisp, it adds (IMO, needless) complexity. Therefore I would think long and hard if that is actually really necessary, before starting to go down that path. Just my $0.02. Cheers, TRS-80
Re: org-refile and ivy
Eric S Fraga writes: > I have been trying to get to grips with org-refile. For some reason, > the completion mechanism (I use ivy generally but I have no idea what > org-refile actually tries to do/use) only shows me the current file name > if I have org-refile-targets set to nil. It doesn't show any top level > headlines to choose from which is what I would expect from the > documentation. Hitting RET to select the completion target given (file > name only) refiles to the end of the file which is not what I want. I use the built-in completion framework. And if the org-refile-targets is nil, it shows me the top level headings from the same file in the *Completions* buffer when I press TAB. So, in your case, it looks like an Ivy issue. > This is with org updated fairly recently but not quite up to > date. However, I've had this problem for a long time and don't use > org-refile as a result. My org-version is 9.4.4
Re: org-refile and ivy
Hi Eric, On Fri, 22 Jan 2021 at 15:49, Eric S Fraga wrote: > Dear all org mode list readers, > > I have been trying to get to grips with org-refile. For some reason, > the completion mechanism (I use ivy generally but I have no idea what > org-refile actually tries to do/use) only shows me the current file name > if I have org-refile-targets set to nil. It doesn't show any top level > headlines to choose from which is what I would expect from the > documentation. Hitting RET to select the completion target given (file > name only) refiles to the end of the file which is not what I want. > > This is with org updated fairly recently but not quite up to > date. However, I've had this problem for a long time and don't use > org-refile as a result. > > Any suggestions welcome. I use org-refile with ivy, so I might share. If I recall correctly, the only thing that does not play well between the two is `org-outline-path-complete-in-steps`. My basic setup is the following: #+begin_src emacs-lisp (setq org-refile-targets '((org-agenda-files :maxlevel . 6) ;; 'nil' means consider headings of the current buffer (nil :maxlevel . 6))) (setq org-refile-use-outline-path 'file) (setq org-outline-path-complete-in-steps nil) #+end_src That should get you started. I personally like org-refile for its quickness, so I do some extra work to filter out candidates of this list and keeping only the frequent targets (with `org-refile-target-verify-function'). And if something atypical arises, I just go with kill-yank. Note however, on the relation of org-refile and ivy: https://orgmode.org/list/87tuvrj7ww@gmail.com/ HTH, Gustavo.
org-refile and ivy
Dear all org mode list readers, I have been trying to get to grips with org-refile. For some reason, the completion mechanism (I use ivy generally but I have no idea what org-refile actually tries to do/use) only shows me the current file name if I have org-refile-targets set to nil. It doesn't show any top level headlines to choose from which is what I would expect from the documentation. Hitting RET to select the completion target given (file name only) refiles to the end of the file which is not what I want. This is with org updated fairly recently but not quite up to date. However, I've had this problem for a long time and don't use org-refile as a result. Any suggestions welcome. Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-179-g5b5c42
Re: Dealing with wide labels in description environment
Hi Juan,
Juan Manuel Macías writes:
> Hello,
>
> "Loris Bennett" writes:
>
>> I have tried tweaking options such as labelindent and labelwidth in a
>> somewhat haphazard manner with, say,
>>
>> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>>
>> but most of my attempts seem to have the main effect of just shifting
>> the whole list to the right without right-justifying the labels.
>
> The question is more on the side of LaTeX, and the enumitem package
> (which you must have loaded for those options. See:
> https://www.ctan.org/pkg/enumitem). For the effect you are looking for
> you can try this (for horizontal lengths, it is better to use 'em' than
> 'ex):
Yes, of course - using Org for a decade so or has helped me avoid and thus
forget about certain LaTeX details.
> #+LATEX_HEADER: \usepackage{enumitem}
>
> #+attr_latex: :options
> [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
> - short label :: this looks fine
> - very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer
> adipiscing
> elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin
> quam nisl,
> tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque
> penatibus et magnis
> dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
> dolor. Nullam
> tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam
> vestibulum
> accumsan nisl.
Thank, that's what I needed - 'leftmargin' seems to be the main thing
that was missing.
Gruß
Loris
--
This signature is currently under construction.
Re: Dealing with wide labels in description environment
Hello,
"Loris Bennett" writes:
> I have tried tweaking options such as labelindent and labelwidth in a
> somewhat haphazard manner with, say,
>
> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>
> but most of my attempts seem to have the main effect of just shifting
> the whole list to the right without right-justifying the labels.
The question is more on the side of LaTeX, and the enumitem package
(which you must have loaded for those options. See:
https://www.ctan.org/pkg/enumitem). For the effect you are looking for
you can try this (for horizontal lengths, it is better to use 'em' than
'ex):
#+LATEX_HEADER: \usepackage{enumitem}
#+attr_latex: :options
[labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
- short label :: this looks fine
- very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer
adipiscing
elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam
nisl,
tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus
et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam
tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam
vestibulum
accumsan nisl.
Regards,
Juan Manuel
Dealing with wide labels in description environment
Hi, I am exporting to PDF via LaTeX and have the following - short label :: this looks fine - very annoying overly long label :: this doesn't on export, the long label protrudes into the definitions column. I have tried tweaking options such as labelindent and labelwidth in a somewhat haphazard manner with, say, #+attr_latex: :options [labelindent=0pt, labelwidth=10ex] but most of my attempts seem to have the main effect of just shifting the whole list to the right without right-justifying the labels. Does anyone know how to do this properly? Cheers, Loris -- This signature is currently under construction.
