[O] Bug: org-list-demote-modify-bullet doesn't work with alpha characters to unordered list [9.1.14 (9.1.14-1-g4931fc-elpaplus @ /Users/bigtyme/Programs/scimax/elpa/org-plus-contrib-20180917/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
The first two work below but going from alphabetical to unordered list
(second two)
doesn't work. Is there a reason or way to fix this?
(setq org-list-demote-modify-bullet
'(("1." . "+") ("A." . "a.") ("a." . "+") ("A)" . "+")))
Emacs : GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.6.0, NS
appkit-1404.47 Version 10.11.6 (Build 15G20015))
of 2018-06-03
Package: Org mode version 9.1.14 (9.1.14-1-g4931fc-elpaplus @
/Users/bigtyme/Programs/scimax/elpa/org-plus-contrib-20180917/)
[O] Exporting sitemap from folder structure
Hello all, Given the following folder structure of my "notebooks" folder: post1_name |__ index.org post2_name |__ index.org etc. I would like to create an index of the following form: *no* title for index Date -- [[Title][example.com/post1_name/]] Date -- [[Title][example.com/post2_name/]] etc. I have set the following options in exporting the "notebooks" part of my website through =org-publish-project-alist=: > :sitemap-file-entry-format "%t" > :publishing-function org-html-publish-to-html > :auto-sitemap t > :sitemap-filename "index.org" > :makeindex t > :sitemap-sort-files anti-chronologically > :recursive t But this results in a tree structure (as expected) of the form Sitemap for project website-notebooks (as title) - Index - post1_name + Title of post in org file post1_name - post2_name + Title of post in org file post2_name I am not really sure how to go about this I would really appreciate assistance in achieving this behaviour as I am not very well versed in elisp. Thank you for you time, GB
[O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. I recently installed Org 9.2.1 and encountered a few bugs / issues with the new implementaion of Org tables: 1. columns do not correctly align when using a combined alignment and width cookie 2. shrinking to a specified column width indicates continuation / truncation where none exists 3. editing a cell narrower than its specified column width unnecessarily expands the entire column. Several "Invalid function: org-table-with-shrunk-field" errors also show up in *Messages* during these operations. (it's a macro) Recipes: Emacs -Q (org-version) -> "9.2.1" 1. Create a new table: | one | | two is a longer cell | Add a right alignment override and realign with C-c C-c: | | | one | | two is a longer cell | Specify a column width: | | | one | | two is a longer cell | and shrink to size with C-c TAB: |…| | one …| | two is a longer cell…| The column is no longer right aligned. 2. In the last table above, continuation / truncation / shrunk cell characters (…) display even though the column is the full specified width (40 char in this case) and no cell text is truncated. I expect continuation to only show when text is actually truncated. In the example above, something like this (mockup): | | | one | | two is a longer cell | And in the case of a narrower column, where a cell contains truncated / hidden text, something like this (mockup): || | one | | two is a longer…| 3. Create a new table and shrink to a specified column width with C-u C-c TAB: | <15> …| | one…| | two is a longer…| Move point to the second cell and delete the "e" in "one": | <15> | | on | | two is a longer cell | The entire column expands, even though this action is not necessary to perform the edit (annoying if the column contains other cells with text longer than the window width). Emacs : GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.2.0, Carbon Version 158 AppKit 1671.2) of 2019-02-08 Package: Org mode version 9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)
Re: [O] Bug: org-todo calls unbound org-clock-out-if-current
Hello, Alex Branham writes: > On the tip of the maint branch > (8fc22d464d2bc4a3397516854375b177835d10bb) any call to functions like > 'org-todo' results in an error 'void-function org-clock-out-if-current'. > > Here's a sample backtrace: > > Debugger entered--Lisp error: (void-function org-clock-out-if-current) Oops. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
Michaël Cadilhac writes: > Will do. This in particular requires to swap fontifying the drawers > and the keywords (since :END: and :PROPERTIES: are keywords): [...] > Agreed? Sure. Please do what is necessary ;)
[O] Bug: org-todo calls unbound org-clock-out-if-current
Hello - On the tip of the maint branch (8fc22d464d2bc4a3397516854375b177835d10bb) any call to functions like 'org-todo' results in an error 'void-function org-clock-out-if-current'. Here's a sample backtrace: Debugger entered--Lisp error: (void-function org-clock-out-if-current) (org-clock-out-if-current) (org-todo "DONE") (funcall-interactively org-todo "DONE") (call-interactively org-todo) (org-agenda-todo "DONE") (my/org-agenda-mark-done nil) (funcall-interactively my/org-agenda-mark-done nil) (call-interactively my/org-agenda-mark-done nil nil) (command-execute my/org-agenda-mark-done)
Re: [O] Source blocks confused by Org syntax
That is considered the proper way to do it as far as I know. 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 Thu, Feb 14, 2019 at 3:55 PM Galen Menzel wrote: > Ah, thanks — using C-c ' is a functional work around for most of my needs. > > Still, is there no way to create a proper verbatim text block in org? > > Galen > > On 14 Feb 2019, at 12:37, John Kitchin wrote: > > you can escape those by putting a , in front of them. You may have to type > C-q , to get it put in if you see strange messages about user-error: > Priority must be between ‘A’ and ‘C’. > > In fact org-mode will do that for you if you are in special edit mode when > you exit it. You may not be able to use C-c ' to get into this mode though > with the * in the block until you put , in front of them. > > 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 Thu, Feb 14, 2019 at 3:15 PM Galen Menzel > wrote: > >> Hi all, >> >> I’m finding that org source blocks are getting confused if their text >> contains org syntax. For example, in the text below, org considers all the >> lines beginning with asterisks in the text below to be org headers, and >> will fold them accordingly: >> >> #+BEGIN_SRC text >> This source block folds just fine >> #+END_SRC >> >> #+BEGIN_SRC text >> This source block doesn't fold properly because it contains an org headline >> * See? >> #+END_SRC >> >> #+BEGIN_SRC emacs-lisp >> (surely this problem doesnt apply in emacs-lisp mode) >> * Does it? >> ** Sadly it does >> #+END_SRC >> >> #+BEGIN_QUOTE >> The problem also pertains to quotes >> * as you can see >> #+END_QUOTE >> >> #+BEGIN_EXAMPLE >> And examples are no exception >> * As you can see again >> #+END_EXAMPLE >> >> Since all these “headlines” occur inside source, quote, or example >> blocks, they shouldn’t be considered org headlines. In addition, the blocks >> that contain lines beginning with asterisks won’t fold properly. >> >> I’m seeing this behavior in both 9.2.1 and 9.1.9. Are others seeing this? >> Please let me know if I can provide any further information! >> >> Best, >> >> Galen >> >
Re: [O] Source blocks confused by Org syntax
Ah, thanks — using C-c ' is a functional work around for most of my needs. Still, is there no way to create a proper verbatim text block in org? Galen On 14 Feb 2019, at 12:37, John Kitchin wrote: you can escape those by putting a , in front of them. You may have to type C-q , to get it put in if you see strange messages about user-error: Priority must be between ‘A’ and ‘C’. In fact org-mode will do that for you if you are in special edit mode when you exit it. You may not be able to use C-c ' to get into this mode though with the * in the block until you put , in front of them. 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 Thu, Feb 14, 2019 at 3:15 PM Galen Menzel wrote: Hi all, I’m finding that org source blocks are getting confused if their text contains org syntax. For example, in the text below, org considers all the lines beginning with asterisks in the text below to be org headers, and will fold them accordingly: #+BEGIN_SRC text This source block folds just fine #+END_SRC #+BEGIN_SRC text This source block doesn't fold properly because it contains an org headline * See? #+END_SRC #+BEGIN_SRC emacs-lisp (surely this problem doesnt apply in emacs-lisp mode) * Does it? ** Sadly it does #+END_SRC #+BEGIN_QUOTE The problem also pertains to quotes * as you can see #+END_QUOTE #+BEGIN_EXAMPLE And examples are no exception * As you can see again #+END_EXAMPLE Since all these “headlines” occur inside source, quote, or example blocks, they shouldn’t be considered org headlines. In addition, the blocks that contain lines beginning with asterisks won’t fold properly. I’m seeing this behavior in both 9.2.1 and 9.1.9. Are others seeing this? Please let me know if I can provide any further information! Best, Galen
Re: [O] Source blocks confused by Org syntax
you can escape those by putting a , in front of them. You may have to type C-q , to get it put in if you see strange messages about user-error: Priority must be between ‘A’ and ‘C’. In fact org-mode will do that for you if you are in special edit mode when you exit it. You may not be able to use C-c ' to get into this mode though with the * in the block until you put , in front of them. 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 Thu, Feb 14, 2019 at 3:15 PM Galen Menzel wrote: > Hi all, > > I’m finding that org source blocks are getting confused if their text > contains org syntax. For example, in the text below, org considers all the > lines beginning with asterisks in the text below to be org headers, and > will fold them accordingly: > > #+BEGIN_SRC text > This source block folds just fine > #+END_SRC > > #+BEGIN_SRC text > This source block doesn't fold properly because it contains an org headline > * See? > #+END_SRC > > #+BEGIN_SRC emacs-lisp > (surely this problem doesnt apply in emacs-lisp mode) > * Does it? > ** Sadly it does > #+END_SRC > > #+BEGIN_QUOTE > The problem also pertains to quotes > * as you can see > #+END_QUOTE > > #+BEGIN_EXAMPLE > And examples are no exception > * As you can see again > #+END_EXAMPLE > > Since all these “headlines” occur inside source, quote, or example blocks, > they shouldn’t be considered org headlines. In addition, the blocks that > contain lines beginning with asterisks won’t fold properly. > > I’m seeing this behavior in both 9.2.1 and 9.1.9. Are others seeing this? > Please let me know if I can provide any further information! > > Best, > > Galen >
[O] Source blocks confused by Org syntax
Hi all, I’m finding that org source blocks are getting confused if their text contains org syntax. For example, in the text below, org considers all the lines beginning with asterisks in the text below to be org headers, and will fold them accordingly: ``` #+BEGIN_SRC text This source block folds just fine #+END_SRC #+BEGIN_SRC text This source block doesn't fold properly because it contains an org headline * See? #+END_SRC #+BEGIN_SRC emacs-lisp (surely this problem doesnt apply in emacs-lisp mode) * Does it? ** Sadly it does #+END_SRC #+BEGIN_QUOTE The problem also pertains to quotes * as you can see #+END_QUOTE #+BEGIN_EXAMPLE And examples are no exception * As you can see again #+END_EXAMPLE ``` Since all these “headlines” occur inside source, quote, or example blocks, they shouldn’t be considered org headlines. In addition, the blocks that contain lines beginning with asterisks won’t fold properly. I’m seeing this behavior in both 9.2.1 and 9.1.9. Are others seeing this? Please let me know if I can provide any further information! Best, Galen
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
On Thu, 14 Feb 2019 at 16:11, Nicolas Goaziou wrote:
> Would you want to provide a patch including the replacement of
> `org-special-keyword' with `org-drawer'?
Will do. This in particular requires to swap fontifying the drawers
and the keywords (since :END: and :PROPERTIES: are keywords):
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6255,12 +6255,12 @@ needs to be inserted at a specific position in
the font-lock sequence.")
'("^[ \t]*| *\\([#*]\\) *|" (1 'org-formula t))
'("^[ \t]*|\\( *\\([$!_^/]\\) *|.*\\)|" (1 'org-formula t))
'("| *\\(<[lrc]?[0-9]*>\\)" (1 'org-formula t))
-;; Drawers
-'(org-fontify-drawers)
;; Properties
(list org-property-re
'(1 'org-special-keyword t)
'(3 'org-property-value t))
+;; Drawers
+'(org-fontify-drawers)
;; Link related fontification.
'(org-activate-links)
(when (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
Agreed?
Cheers;
M.
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
Hello, Michaël Cadilhac writes: > I agree; following your advice, I took the simpler path of customizing > org-special-keyword. By changing its height, I got a small glitch; > consider: > https://michael.cadilhac.name/public/org-props-small-1.png > The lines with ":PROPERTIES:" did not change height; this is simply > due to the line-feed having the default face. With: > > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -5934,7 +5934,7 @@ by a #." >"Fontify drawers." >(when (re-search-forward org-drawer-regexp limit t) > (add-text-properties > - (match-beginning 0) (match-end 0) > + (match-beginning 0) (+ 1 (match-end 0)) I suggest replacing (match-beginning 0) and (match-end 0) by, respectively (line-beginning-position) and (line-beginning-position 2) (+ 1 (match-end 0)) could be greater than (point-max), (line-beginning-position 2) cannot. > '(font-lock-fontified t face org-special-keyword)) > (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) > t)) > > I get the desired outcome: > https://michael.cadilhac.name/public/org-props-small-2.png > > (this is also where org-special-keyword should be replaced with org-drawer.) > > Any thoughts? Would you want to provide a patch including the replacement of `org-special-keyword' with `org-drawer'? Thank you! Regards, -- Nicolas Goaziou
Re: [O] Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]
Hello, Leo Vivier writes: > The bug only happens in narrowed org-mode buffers when the tree at > point (or targeted by the resolving) is a single line not followed by a > blank line. [...] > MWE: > > [START] > * Tree 1 > * Tree 2 > -[END]- > > - Narrow to ‘Tree 1’l > - Clock in. > > Observations: > - No clock drawer visible in the narrowed buffer. > - Feedback in the minibuffer that the clock was started. > - Widening the buffer confirms the presence of the buffer where it > should be. This looks correct, indeed. > Whilst the observations would lead one to think that everything ‘Just > Works™’, it causes a slew of problems. Two examples: > - After clocking in, adding a new heading ‘Subtree’ bellow ‘Tree 1’ > would make the drawer belong to ‘Subtree’ instead of ‘Tree 1’ This is to be expected. The same would happen in a widened buffer, if you insert a new headline (M-RET) at the end of the one being clocked. The difference here is that you cannot see the running clock, but this is to be expected when you narrow the document to a single line which is not meaningful syntactically. Try narrowing the buffer to a single character: all weird things may happen. I suggest to narrow only to meaningful parts of a document, e.g., a paragraph, a subtree… > - `org-clock-out-when-done` isn’t respected since the drawer is not > visible This is a bug. I fixed it. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Hello, Carlos Pita writes: > I think your refactor improves the original code a lot and makes clear > that toggling is just a special case. > > I've been testing the changes with a pretty complex beamer document > and found no fault. Great! Thank you for the feedback and the suggested implementation! Regards, -- Nicolas Goaziou
Re: [O] Completely hide the :PROPERTIES: drawer in org-mode.
Hi there; Again, thanks for your help Nicolas—that's much appreciated. On Wed, 13 Feb 2019 at 15:55, Nicolas Goaziou wrote: > The face you use for drawers is, well obnoxious, to say the least. No > wonder you find them cluttering your display. I agree; following your advice, I took the simpler path of customizing org-special-keyword. By changing its height, I got a small glitch; consider: https://michael.cadilhac.name/public/org-props-small-1.png The lines with ":PROPERTIES:" did not change height; this is simply due to the line-feed having the default face. With: --- a/lisp/org.el +++ b/lisp/org.el @@ -5934,7 +5934,7 @@ by a #." "Fontify drawers." (when (re-search-forward org-drawer-regexp limit t) (add-text-properties - (match-beginning 0) (match-end 0) + (match-beginning 0) (+ 1 (match-end 0)) '(font-lock-fontified t face org-special-keyword)) (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) t)) I get the desired outcome: https://michael.cadilhac.name/public/org-props-small-2.png (this is also where org-special-keyword should be replaced with org-drawer.) Any thoughts? Thanks! Michaël
Re: [O] SOLUTION - Re: How to colorize text in square brackets?
I have been using
https://github.com/jkitchin/scimax/blob/master/scimax-editmarks.org
for something like this. It allows me to put comments with a little
markup that are colored as you describe. There is also support to show a
listing of all those comments, so that you don't overlook them by
accident. Of course, you can always use occur on the regexp you are
fontifying to find those too.
Sharon Kimble writes:
> Sharon Kimble writes:
>
>> How can I colorize text within square brackets please, like [fu] ?
>>
>> I need them colorized as they will hold reminders for myself at that
>> position whilst I'm writing.
>>
>
> When I posted this question I knew that the answer would probably lie
> somewhere within font-lock-add-keywords, but I was unable to find it until I
> started googling for 'font-lock-keyword-face' which I was already using. This
> search then lead me to these two pages [1] and [2].
>
> And that lead to this code which achieves what I was trying to accomplish,
> the text within the square boxes to be coloured totally different from its
> surrounding text, meaning that now I can write my book and leave myself
> reminders of various questions, which when I've found the answers can then be
> deleted.
>
> --8<---cut here---start->8---
> #+BEGIN_SRC emacs-lisp
> (font-lock-add-keywords 'org-mode
> '(("\\[\\(.*\\)\\]"
> 1 font-lock-type-face prepend)))
> #+END_SRC
> --8<---cut here---end--->8---
>
> Thanks
> Sharon.
>
> [1] -
> https://stackoverflow.com/questions/7401787/emacs-mode-how-to-specify-that-thing-in-square-brackets-should-be-colored
> [2] -
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Faces-for-Font-Lock.html
--
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] org-clock: Custom shortcuts for C-u C-c C-x C-i
Hi Leo; On Wed, 13 Feb 2019 at 17:46, Leo Gaspard wrote: > Michaël Cadilhac writes: > > This is not possible out of the box; can you say a bit more about how > > you expect to indicate which tasks are to be always present? > > I would be thinking of something like defining a list of key -> link to > a task (that may be generated with org-id's task ID, [[*foobar]] links > or whatever) in my `init.el`. Alright, can you give this patch a spin and see if that's what you want? Cheers; M. diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 343264f7e..1f0870e62 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -164,6 +164,13 @@ which case all digits and capital letters are used up by the :group 'org-clock :type 'integer) +(defcustom org-clock-default-tasks nil + "List of pairs (KEY . ID) ..." + :group 'org-clock + :type '(repeat (cons :tag "Key and ID" + (character :tag "Access char") + (string:tag "Task ID" + (defcustom org-clock-goto-may-find-recent-task t "Non-nil means `org-clock-goto' can go to recent task if no active clock." :group 'org-clock @@ -622,6 +629,15 @@ there is no recent clock to choose from." (+ i (- ?A 10))) m)) (if (fboundp 'int-to-char) (setf (car s) (int-to-char (car s (push s sel-list))) + (let (has-elt m) + (dolist (charid org-clock-default-tasks) + (setq m (org-id-find (cdr charid) 'marker)) + (when m + (unless has-elt + (setq has-elt t) + (insert (org-add-props "Default Tasks\n" nil 'face 'bold))) + (setq s (org-clock-insert-selection-line (car charid) m)) + (push s sel-list (run-hooks 'org-clock-before-select-task-hook) (goto-char (point-min)) ;; Set min-height relatively to circumvent a possible but in
[O] SOLUTION - Re: How to colorize text in square brackets?
Sharon Kimble writes:
> How can I colorize text within square brackets please, like [fu] ?
>
> I need them colorized as they will hold reminders for myself at that position
> whilst I'm writing.
>
When I posted this question I knew that the answer would probably lie somewhere
within font-lock-add-keywords, but I was unable to find it until I started
googling for 'font-lock-keyword-face' which I was already using. This search
then lead me to these two pages [1] and [2].
And that lead to this code which achieves what I was trying to accomplish, the
text within the square boxes to be coloured totally different from its
surrounding text, meaning that now I can write my book and leave myself
reminders of various questions, which when I've found the answers can then be
deleted.
--8<---cut here---start->8---
#+BEGIN_SRC emacs-lisp
(font-lock-add-keywords 'org-mode
'(("\\[\\(.*\\)\\]"
1 font-lock-type-face prepend)))
#+END_SRC
--8<---cut here---end--->8---
Thanks
Sharon.
[1] -
https://stackoverflow.com/questions/7401787/emacs-mode-how-to-specify-that-thing-in-square-brackets-should-be-colored
[2] -
https://www.gnu.org/software/emacs/manual/html_node/elisp/Faces-for-Font-Lock.html
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 9.5, fluxbox 1.3.7, emacs 26.1.91, org 9.2.1
signature.asc
Description: PGP signature
