Highlighting and Background Colour for Source Code
Currently currently handles the highlighting of programming languages through "Code Blocks". Could org-mode have the capability of highlighting a whole buffer with a particular language highlight typeface. I have also seen that within code blocks, the background is uses a colour that is different from the background colour of the buffer. Is there a capability that the code block background is set to the buffer background colour.
Re: [bug] archiving creates duplicate entries
i have confirmed that this bug occurs as follows. archiving commands append to a buffer for the archive. they do not save, revert, or kill that buffer. my shell workaround, to allow archiving given completely unusably slow archiving, moved the archive files [so that they would not be slow]. therefore there were no archives on disk. but a full buffer. therefore, archiving appended to existing buffers that did not match what was on disk. then saved. ergo duplicates. suggested fix: kill the archive buffer before appending to it, if it is marked as unmodified. if it is not marked as unmodified, maybe it is ok to append? idk. On 5/9/21, Samuel Wales wrote: > when i do a bulk archive, it will sometimes put 2 copies > entries into the archive file. it is more likely to occur > if i am archiving more tasks. at times, it seems certain > entries do this repeatably, but i am not sure. > > there are times when i think i have reset everything (git is > clean, archives are moved out of teh way) but this still > occurs. i cannot make an mwe but it seemed worth reporting. > where is it getting the duplicates from? idk. it has to be > either the source .org file or the newly created and written > archive file. idk if there are any caches or text > properties or some hidden stuff in the agenda. but i can > tell you that there have been times when i experimented with > not cleaning everything and the duplicates increased. each > run would create a new duplicate of certain entries. > > btw i have been trying to archive tasks to files for a year > now. it is too slow for me. so i hit on the idea of moving > archives out of the way, then archiving a little at a time > to new archive files, then using the shell to append the new > archived entries to the old archive files, then moving the > old archive files back. thus, this isn't an issue of big > archive files. > > wish i could provide more for you or even figure out > debugging but i cannot; just hope it will ring bells. > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [wip-cite-new] New natbib processor
On Sun, May 9, 2021 at 4:25 PM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > To bottom line it, seems the decision comes down to something like
> > these three choices:
> >
> > 1. no change; keep sub-styles as they are ATM
> > 2. change sub-styles to a simple string. So [cite/text/caps+full:...],
> > where sub-style is the string "caps+full"; short cut would be
> > something like [cite:/t/c+f:...]
> > 3. remove sub-styles entirely; just have things like
> > [cite/text+caps-full:...], where the style is "text+caps-full"; or
> > with shortcuts [cite/t+c-f:...]
> >
> > Any of them seem reasonable to me.
> >
> > Maybe 2 is the best balance of flexibility and simplicity?
>
> But there are two 2 ;)
The nice thing about a wiki is one can always edit one's mistakes!
But I did correct the quoted text above, so I meant the first "2".
See below however ...
...
> Sub-styles buy us nicer switching between processors, indeed. But they
> come at a price, too. In particular, we need to re-define inheritance
> between styles defined in `org-cite-export-processor', "cite_export"
> keyword and the citation object. As I wrote earlier in this thread,
> there are multiple ways to deal with it, so a clear design is in order.
>
> Plain styles already exist. Sub-styles requires more work. Does the
> benefit outweigh it? If so, what do you suggest for the inheritance
> problem?
I guess the question is really about the logic in this function?
(defun org-cite-natbib--style-to-command (style)
"Return command name to use according to STYLE string."
(let ((base
(if (org-cite-natbib--has-substyle-p style "caps")
"Cite"
"cite"))
(alt
(and (org-cite-natbib--has-substyle-p style "alt")
"al"))
(main (pcase (org-cite-natbib--main-style style)
((or "text" "t") "t")
((or "author" "a") "author")
((or "year" "y") "year")
(_ "p")))
(star
(and (org-cite-natbib--has-substyle-p style "full")
"*")))
(concat "\\" base alt main star)))
My read of the natbib docs is this should work correctly, except for
the 'year' style, for which 'full' and 'caps' do not apply because
there are no authors output in those styles.
Indeed, if you do something like \Citeyear you will get an error from LaTeX.
So I think you need a conditional that ignores those for that style.
But otherwise, I think this should be fine.
The example you raised in the first post in this thread was the following:
> Also it introduces ambiguities in style inheritance.
> For example, if I add
>
> #+cite_export: natbib plainnat text
So the default style is "text."
> would
>
> [cite//alt/caps:...]
>
> mean
>
> [cite/text/alt/caps:...] (i.e., \Citealt{...})
>
> or really
>
> [cite//alt/caps:] (i.e., \Citealp{...})
>
> ?
First, I am thinking "bare" would be more clear than "alt", at least
if we're shooting for names that are clear outside the content of a
particular output format. WDYT?
On the more important output question, do not those two natbib
commands generate the same final output in the end?
As in, this ambiguity is in natbib itself?
That aside, I think just logically the first makes more sense, because
nowhere does the style or sub-styles specify the "citep" style.
Indeed, that style doesn't exist in the current list. This is what the
code currently produces.
Am I missing something there?
Bruce
Bug: org-duration-to-minutes: Invalid duration format [9.4.5 (release_9.4.5-530-g981f25 @ /home/dortmann/src/git-org-mode/lisp/)]
Hello,
I opened my 'plan.org' file today and the C-c a a failed while creating
the agenda. The information is below.
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 following long-time LOGBOOK entry, which has worked for a long time,
now shows an error saying:
- Rescheduled from "[2020-01-16 Thu 12:30-13:30 ++1w]" on [2020-01-16
Thu 11:03]
Here is the message from *Messages*:
org-duration-to-minutes: Invalid duration format: #("12:30-13:00 ++1w" 0
16 (fontified nil org-category "plan"))
Emacs : GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version
3.22.30, cairo version 1.15.12)
of 2021-05-09
Package: Org mode version 9.4.5 (release_9.4.5-530-g981f25 @
/home/dortmann/src/git-org-mode/lisp/)
Re: Bug: spurious change in list indent cursor motion [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
James Powell writes: > I open a new file, /tmp/demo.org, and I start a new list > by typing "- a". It appears: > > - a > > What I expect: my cursor should now be at column 0. This was the > behavior in 9.3.6 and it makes perfect sense. > > What happens instead: after upgrade to 9.4.4, the cursor rests at > column 2, under the a. > > How do I change the behavior back to the 9.3.6 one? Short answer: disable electric-indent-local-mode, as suggested in ORG-NEWS. This will turn RET into the "dumb newline" key which should never indent, and set C-j as the "smart newline" key which occasionally indents. > Facts about it: > > - When I start emacs with 'emacs -Q -nw' the bug does not manifest > even in 9.4.4. That's surprising; on my setups, with Org 9.4.4, emacs -Q -nw stays at column 2 after hitting RET. > - I tried setting org-adapt-indentation to 't (the default) as it is > an obvious suspect, the bug still manifested. org-adapt-indentation's determines how TAB and the "smart newline" key behave: - t (default): section bodies should be hard-indented, - nil (to become the default for Org 9.5): nothing should be indented, - 'headline-data: drawers (e.g. :LOGBOOK: entries and :PROPERTY: blocks) should be hard-indented, but not regular section text. With all settings, "- a" indents at column 2, below "a". As explained above, depending on electric-indent, the key is either RET or C-j. Note also that "- a" goes back to column 0. (FWIW I think that's a bit unwieldy; going back to column 0 on the /second/ would make more sense to me, as it would correspond to a "paragraph break")
Re: Bug: specifying end time of date as +0:20 [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
> I solved this part on maint branch.
Thank you!
> Sure. Patch welcome.
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab12fa70a..ea8901f28 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6074,6 +6074,11 @@ separator in the latter case, e.g.:
| =11am--1:15pm= | \rArr{} same as above |
| =11am+2:15=| \rArr{} same as above |
+If you do not specify an end time, then you can provide a default
+duration by setting ~org-agenda-default-appointment-duration~ to a
+suitable non-~nil~ value.
+
+
#+cindex: calendar, for selecting date
#+vindex: org-popup-calendar-for-date-prompt
Parallel to the minibuffer prompt, a calendar is popped up[fn:62].
[bug] archiving creates duplicate entries
when i do a bulk archive, it will sometimes put 2 copies entries into the archive file. it is more likely to occur if i am archiving more tasks. at times, it seems certain entries do this repeatably, but i am not sure. there are times when i think i have reset everything (git is clean, archives are moved out of teh way) but this still occurs. i cannot make an mwe but it seemed worth reporting. where is it getting the duplicates from? idk. it has to be either the source .org file or the newly created and written archive file. idk if there are any caches or text properties or some hidden stuff in the agenda. but i can tell you that there have been times when i experimented with not cleaning everything and the duplicates increased. each run would create a new duplicate of certain entries. btw i have been trying to archive tasks to files for a year now. it is too slow for me. so i hit on the idea of moving archives out of the way, then archiving a little at a time to new archive files, then using the shell to append the new archived entries to the old archive files, then moving the old archive files back. thus, this isn't an issue of big archive files. wish i could provide more for you or even figure out debugging but i cannot; just hope it will ring bells.
Bug: spurious change in list indent cursor motion [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
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 open a new file, /tmp/demo.org, and I start a new list
by typing "- a". It appears:
- a
What I expect: my cursor should now be at column 0. This was the
behavior in 9.3.6 and it makes perfect sense.
What happens instead: after upgrade to 9.4.4, the cursor rests at
column 2, under the a.
How do I change the behavior back to the 9.3.6 one?
Facts about it:
- When I start emacs with 'emacs -Q -nw' the bug does not manifest even
in 9.4.4.
- When I paste the 'current state' elisp below into ~/it.el, and start emacs
with emacs -Q -nw, and 'L' in dired to load ~/it.el, the bug does not
manifest.
- I have read the changelog and the manual, with no good result.
- I have an example where the bug does not manifest even in 9.4.4 and
even without running emacs -Q, where the .org file is a little thing
full of lines starting with ':' only (!).
- I tried setting org-adapt-indentation to 't (the default) as it is
an obvious suspect, the bug still manifested.
many thanks,
- James P.
Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2020-07-07
Package: Org mode version 9.4.4 (9.4.4-dist @
/home/powellj/elisp/org-9.4.4/lisp/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-adapt-indentation nil
org-latex-classes '(("achemso" "\\documentclass{achemso}"
("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" .
"\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("report" "\\documentclass[11pt]{report}"
("\\part{%s}" . "\\part*{%s}") ("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("book" "\\documentclass[11pt]{book}"
("\\part{%s}" . "\\part*{%s}") ("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-reverse-note-order t
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-agenda-start-on-weekday nil
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-log-done 'time
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-startup-folded 'content
org-agenda-loop-over-headlines-in-active-region nil
org-link-search-must-match-exact-headline nil
org-file-apps '(("\\.pdf" . "evince %s") (auto-mode . emacs)
(directory . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" . default)
("\\.pdf\\'" . default))
org-agenda-skip-scheduled-if-done t
org-agenda-custom-commands '(("d" todo #("DELEGATED" 0 9 (face
org-warning)) nil)
("c" todo #("DONE|DEFERRED|CANCELLED" 0
23 (face org-warning)) nil)
("w" todo #("WAITING" 0 7 (face
org-warning)) nil) ("W" agenda "" ((org-agenda-ndays 21)))
("A" agenda ""
((org-agenda-skip-function (lambda nil
(org-agenda-skip-entry-if (quote notregexp) "\\=.*\\[#A\\]")))
(org-agenda-ndays 1)
(org-agenda-overriding-header "Today's Priority #A tasks: "))
)
("u" alltodo ""
((org-agenda-skip-function
(lambda nil (org-agenda-skip-entry-if
(quote scheduled) (quote deadline) (quote regexp) "<[^>\n]+>")))
(org-agenda-overriding-header
"Unscheduled TODO entries: "))
)
)
org-latex-format-headline-function
'org-latex-format-headline-default-function
org-default-notes-file
Re: [wip-cite-new] New natbib processor
Hello, "Bruce D'Arcus" writes: > To bottom line it, seems the decision comes down to something like > these three choices: > > 1. no change; keep sub-styles as they are ATM > 2. change sub-styles to a simple string. So [cite/text/caps+full:...], > where sub-style is the string "caps+full"; short cut would be > something like [cite:/t/c+f:...] > 2. remove sub-styles entirely; just have things like > [cite/text+caps-full:...], where the style is "text+caps-full"; or > with shortcuts [cite/t+c-f:...] > > Any of them seem reasonable to me. > > Maybe 2 is the best balance of flexibility and simplicity? But there are two 2 ;) I think that sub-styles as currently implemented, i.e., per processor, are not useful. They could as well be replaced by a list of regular styles (e.g., "text-caps-full"). Completion is not really an issue either. We could require export-oriented citation processors to declare the styles they support through a dedicated keyword in `org-cite-register-processor'. Completions utilities, like the function you wrote, could then read from that list. The question you raise about compatibility between processors is interesting however. Without sub-styles, non-standard styles (roughly anything but default, text, author and year) would, as you noted, fallback to default style upon switching citation processors. E.g., "text-caps-full" would become default. With sub-styles, OTOH, fallback mechanism would be able to grab root style and try using it before dropping the ball to default. E.g., "text/caps-full" could gracefully degrade to "text", and, if not supported, default. Sub-styles buy us nicer switching between processors, indeed. But they come at a price, too. In particular, we need to re-define inheritance between styles defined in `org-cite-export-processor', "cite_export" keyword and the citation object. As I wrote earlier in this thread, there are multiple ways to deal with it, so a clear design is in order. Plain styles already exist. Sub-styles requires more work. Does the benefit outweigh it? If so, what do you suggest for the inheritance problem? Regards, -- Nicolas Goaziou
Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
Hi, Nicolas Goaziou writes: >> I just thought there may be people who like me are interested in >> s for LaTeX in HTML, but not in Markdown. > > Fair enough. Let's push your last patch, then. Going off this, I've taken this as assent and just pushed my patch in its current form as 981f25031. -- Timothy
Re: Bug: specifying end time of date as +0:20 [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hello, Stephen Eglen writes: > I'm trying to understand the syntax (e.g. ‘11am+2:15’) for specifying > the end time of an event, from (info "(org)The date/time prompt") > > It works okay if I do org-deadline with 11am+2:15 > > * test 3 > DEADLINE: <2021-05-09 Sun 11:00-13:15> > > but if I do 11pm+2:15 then it gets confused: > > * test 4 > DEADLINE: <2021-05-09 Sun 23:00-25:15> > > and when I next call the agenda, I get an error: > > org-duration-to-minutes: Invalid duration format: "+1:15" I solved this part on maint branch. > Also, I couldn't see any mention in the documentation of > org-agenda-default-appointment-duration -- is that worth mentioning in > the node, e.g. after ‘11am+2:15’ ⇒ same as above > > "If you do not specify an end time, then you can provide a default > duration by setting org-agenda-default-appointment-duration." Sure. Patch welcome. Regards, -- Nicolas Goaziou
Bug: specifying end time of date as +0:20 [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hi, I'm trying to understand the syntax (e.g. ‘11am+2:15’) for specifying the end time of an event, from (info "(org)The date/time prompt") It works okay if I do org-deadline with 11am+2:15 * test 3 DEADLINE: <2021-05-09 Sun 11:00-13:15> but if I do 11pm+2:15 then it gets confused: * test 4 DEADLINE: <2021-05-09 Sun 23:00-25:15> and when I next call the agenda, I get an error: org-duration-to-minutes: Invalid duration format: "+1:15" Also, I couldn't see any mention in the documentation of org-agenda-default-appointment-duration -- is that worth mentioning in the node, e.g. after ‘11am+2:15’ ⇒ same as above "If you do not specify an end time, then you can provide a default duration by setting org-agenda-default-appointment-duration." Best wishes, Stephen Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.28, cairo version 1.17.4) of 2021-04-28 Package: Org mode version 9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)
Could habits appear in the correspondent hour in org-agenda?
Hi I am tinkering with the agenda to make it look better. I am quite happy with the results, but I would like habits to go in the time of the day when they are programmed to be done. Is it possible? Best regards, Ypo
Re: bug#48199: 28.0.50; Org mode surprisingly usurps Calendar key binding
[I added emacs-orgmode@gnu.org in the Cc:] On Mon, 03 May 2021 18:07:25 +0200 Stephen Berman wrote: > By default `i' is a prefix key in calendar-mode for commands that insert > diary entries. But if you happen to display a buffer that activates > org-mode machinery, then `i' in calendar-mode becomes bound to > org-agenda-diary-entry and typing it can raise a wrong-type-argument > error. This can happen by visiting a file in Org mode. To reproduce: > > 0. emacs -Q > 1. (sanity check:) Type `M-x calendar RET' and then in the Calendar >buffer type `i C-h': the *Help* buffer displays all the commands >invoked by `i' plus one or more keys. > 2. Visit the file `ORG-NEWS' (e.g. by typing `C-h n C-x C-f O TAB RET'). > 3. Type `M-x calendar RET' and then in the Calendar buffer type `i' > => Wrong type argument: commandp, org-agenda-diary-entry > > This can also catch users by surprise, e.g. in Gnus. To reproduce, > replace step 2 above by the following: > > 2a. Type `M-x gnus', answer `y' at the prompt; in the Gnus buffer type > `B RET news.gmane.io RET'. > 2b. In the *Gnus Browse Server* buffer type `C-s humani' to put point on > the gmane.emacs.humanities group; type RET to enter it. > 2c. Type `j <87sg6wulu6.fsf@localhost> RET', which displays an article > containing an org-mode source code block. > 3. As above, resulting in the same error (when done from emacs -Q). > > The Org mode manual (info "(org) Agenda Commands") does describe its use > of the `i' binding in the Calendar, and if Org mode has its own versions > of the commands that use `i' by default in calendar-mode, then > overriding the calendar-mode bindings is no problem for Org Agenda > users, but those bindings should not be overridden just by displaying a > buffer that happens to be in org-mode or happens to contain an Org > source code block. The following patch fixes the problem for me: diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el index 1f4e2e8308..b68e5b58fc 100644 --- a/lisp/org/org-compat.el +++ b/lisp/org/org-compat.el @@ -1151,8 +1151,8 @@ org--setup-calendar-bindings ((guard (not (lookup-key calendar-mode-map "c"))) (local-set-key "c" #'org-calendar-goto-agenda)) (_ nil)) - (unless (and (boundp 'org-agenda-diary-file) - (eq org-agenda-diary-file 'diary-file)) + (when (and (boundp 'org-agenda-diary-file) + (not (eq org-agenda-diary-file 'diary-file))) (local-set-key org-calendar-insert-diary-entry-key #'org-agenda-diary-entry))) I have to admit, though, that I don't understand why the version with `unless' results in the bug, since in the recipes I gave org-agenda-diary-file is unbound and, indeed, when I instrument the unpatched org--setup-calendar-bindings and step through it on calling `calendar', the org-calendar-insert-diary-entry-key local-set-key call is skipped as expected. But "c" does get locally set, so if I type `c' in the Calendar buffer, it displays the Org Agenda, and if I then type `i' in the Calendar buffer, I now get prompted with a choice menu for the type of diary entry, but whichever I choose, the result is the user-error "Don't know which date to use for diary entry", evidently because there is indeed no org-agenda-diary-file with the necessary text properties. So somehow the "i" binding is made even though the code should prevent this (and does under Edebug but not when executed normally). With the above patch, after typing `c' in the Calendar buffer, `i' is still unbound, as it should be, but if I changed the value of org-agenda-diary-file from the default 'diary-file to some file, then `i' works with Org Agenda as documented. Steve Berman
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
Bastien writes: >> It is now, as of commit 0a651b746. > > ... and I broke some tests. Sorry for that. I will fix this next > week, unless someone does it before me. Here are two patches that set org-adapt-indentation to t for the tests which were implicitly relying on that behavior; that lets 'make test' succeed again for me. I'm pretty sure the first one is TRT (since I'm the author of the tests), although Eventually™ we should make a more exhaustive suite based on the table you referenced earlier. The second one makes the remaining tests pass again, but I couldn't tell at a glance whether their expectations still make sense. >From e136f0d3123173d947bf4c1ce06aaf5f12117ef8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= Date: Sun, 9 May 2021 18:05:35 +0200 Subject: [PATCH 1/2] Set org-adapt-indentation explicitly in some tests * testing/lisp/test-org.el (test-org/with-electric-indent, test-org/without-electric-indent): Make sure org-adapt-indentation is consistent with expected results. --- testing/lisp/test-org.el | 42 +++- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 9f0ede1b9..5ac9173ac 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -1404,12 +1404,14 @@ (electric-indent-local-mode 1) (call-interactively 'org-return) (buffer-string - (should - (equal "* heading\n body" - (org-test-with-temp-text "* headingbody" - (electric-indent-local-mode 1) - (call-interactively 'org-return) - (buffer-string + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) +(should + (equal "* heading\n body" + (org-test-with-temp-text "* headingbody" + (electric-indent-local-mode 1) + (call-interactively 'org-return) + (buffer-string) ;; C-j, like `electric-newline-and-maybe-indent', should not indent. (should (equal " Para\ngraph" @@ -1423,12 +1425,14 @@ (electric-indent-local-mode 1) (call-interactively 'org-return-and-maybe-indent) (buffer-string - (should - (equal "* heading\nbody" - (org-test-with-temp-text "* headingbody" - (electric-indent-local-mode 1) - (call-interactively 'org-return-and-maybe-indent) - (buffer-string) + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) +(should + (equal "* heading\nbody" + (org-test-with-temp-text "* headingbody" + (electric-indent-local-mode 1) + (call-interactively 'org-return-and-maybe-indent) + (buffer-string)) (ert-deftest test-org/without-electric-indent () "Test RET and C-j specifications with `electric-indent-mode' off." @@ -1467,12 +1471,14 @@ (electric-indent-local-mode 0) (call-interactively 'org-return-and-maybe-indent) (buffer-string - (should - (equal "* heading\n body" - (org-test-with-temp-text "* headingbody" - (electric-indent-local-mode 0) - (call-interactively 'org-return-and-maybe-indent) - (buffer-string) + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) +(should + (equal "* heading\n body" + (org-test-with-temp-text "* headingbody" + (electric-indent-local-mode 0) + (call-interactively 'org-return-and-maybe-indent) + (buffer-string)) (ert-deftest test-org/meta-return () "Test M-RET (`org-meta-return') specifications." -- 2.31.1 >From 2a485754a7f04d00ef5e5ebed82924d44f768424 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= Date: Sun, 9 May 2021 18:20:11 +0200 Subject: [PATCH 2/2] Set org-adapt-indentation explicitly in some tests * testing/lisp/test-org.el (test-org/indent-line, test-org/indent-region): Make sure org-adapt-indentation is consistent with expected results. --- testing/lisp/test-org.el | 126 --- 1 file changed, 66 insertions(+), 60 deletions(-) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 5ac9173ac..95ffb0a80 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -1007,22 +1007,23 @@ ;; At the first line of an element, indent like previous element's ;; first line, ignoring footnotes definitions and inline tasks, or ;; according to parent. - (should - (= 2 - (org-test-with-temp-text "A\n\n B\n\nC" - (org-indent-line) - (org-get-indentation - (should - (= 1 - (org-test-with-temp-text " A\n\n[fn:1] B\n\n\nC" - (org-indent-line) - (org-get-indentation - (should - (= 1 - (org-test-with-temp-text - " #+BEGIN_CENTER\n Contents\n#+END_CENTER" - (org-indent-line) - (org-get-indentation + (let ((org-adapt-indentation t)) +(should + (= 2 +(org-test-with-temp-text "A\n\n B\n\nC" + (org-indent-line) +
[PATCH 2/2] org-refile.el: Fix test case
* lisp/org-refile.el (org-refile-get-targets): Check `buffer-file-name' return value instead of `buffer-base-buffer'. To pass the related tests, we need to check `buffer-file-name'. TINYCHANGE --- lisp/org-refile.el | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 6f5b8acee..2900be27e 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -310,13 +310,12 @@ converted to a headline before refiling." (setq f (buffer-file-name (buffer-base-buffer f (setq f (and f (expand-file-name f))) (when (eq org-refile-use-outline-path 'file) -(push (list (if f (file-name-nondirectory f) nil) f nil nil) tgs)) +(push (list (and f (file-name-nondirectory f)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'buffer-name) (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'full-file-path) -(push (list (if (buffer-base-buffer) - (file-truename (buffer-file-name (buffer-base-buffer))) - nil) +(push (list (and (buffer-file-name (buffer-base-buffer)) + (file-truename (buffer-file-name (buffer-base-buffer f nil nil) tgs)) (org-with-wide-buffer (goto-char (point-min)) @@ -341,10 +340,9 @@ converted to a headline before refiling." (append (pcase org-refile-use-outline-path (`file (list - (if (buffer-base-buffer) - (file-name-nondirectory -(buffer-file-name (buffer-base-buffer))) - nil))) + (and (buffer-file-name (buffer-base-buffer)) +(file-name-nondirectory + (buffer-file-name (buffer-base-buffer)) (`full-file-path (list (buffer-file-name (buffer-base-buffer -- 2.30.0
[PATCH 2/2] org-refile.el: Fix test case
* lisp/org-refile.el (org-refile-get-targets): Check `buffer-file-name' return value instead of `buffer-base-buffer'. To pass the related tests, we need to check `buffer-file-name'. TINYCHANGE --- lisp/org-refile.el | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 6f5b8acee..2900be27e 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -310,13 +310,12 @@ converted to a headline before refiling." (setq f (buffer-file-name (buffer-base-buffer f (setq f (and f (expand-file-name f))) (when (eq org-refile-use-outline-path 'file) -(push (list (if f (file-name-nondirectory f) nil) f nil nil) tgs)) +(push (list (and f (file-name-nondirectory f)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'buffer-name) (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'full-file-path) -(push (list (if (buffer-base-buffer) - (file-truename (buffer-file-name (buffer-base-buffer))) - nil) +(push (list (and (buffer-file-name (buffer-base-buffer)) + (file-truename (buffer-file-name (buffer-base-buffer f nil nil) tgs)) (org-with-wide-buffer (goto-char (point-min)) @@ -341,10 +340,9 @@ converted to a headline before refiling." (append (pcase org-refile-use-outline-path (`file (list - (if (buffer-base-buffer) - (file-name-nondirectory -(buffer-file-name (buffer-base-buffer))) - nil))) + (and (buffer-file-name (buffer-base-buffer)) +(file-name-nondirectory + (buffer-file-name (buffer-base-buffer)) (`full-file-path (list (buffer-file-name (buffer-base-buffer -- 2.30.0
[PATCH 2/2] org-refile.el: Fix test case
* lisp/org-refile.el (org-refile-get-targets): Check `buffer-file-name' return value instead of `buffer-base-buffer'. To pass the related tests, we need to check `buffer-file-name'. TINYCHANGE --- lisp/org-refile.el | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 6f5b8acee..2900be27e 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -310,13 +310,12 @@ converted to a headline before refiling." (setq f (buffer-file-name (buffer-base-buffer f (setq f (and f (expand-file-name f))) (when (eq org-refile-use-outline-path 'file) -(push (list (if f (file-name-nondirectory f) nil) f nil nil) tgs)) +(push (list (and f (file-name-nondirectory f)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'buffer-name) (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'full-file-path) -(push (list (if (buffer-base-buffer) - (file-truename (buffer-file-name (buffer-base-buffer))) - nil) +(push (list (and (buffer-file-name (buffer-base-buffer)) + (file-truename (buffer-file-name (buffer-base-buffer f nil nil) tgs)) (org-with-wide-buffer (goto-char (point-min)) @@ -341,10 +340,9 @@ converted to a headline before refiling." (append (pcase org-refile-use-outline-path (`file (list - (if (buffer-base-buffer) - (file-name-nondirectory -(buffer-file-name (buffer-base-buffer))) - nil))) + (and (buffer-file-name (buffer-base-buffer)) +(file-name-nondirectory + (buffer-file-name (buffer-base-buffer)) (`full-file-path (list (buffer-file-name (buffer-base-buffer -- 2.30.0
Re: org-refile.el: Fix the case of emtpy buffer name
I am very sorry but related tests failed with my previous patch. I fixed it with this additinal patch. Bests, Takehsi SATO
Re: Bug: org-plot gives Invalid function error
Ihor Radchenko writes: >> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title 'H-index' > > This is not valid gnuplot command to create histograms. One needs to use: > > plot '/tmp/org-plotiPs0To' using 3:tics(1) with histograms title 'H-index' I've had a look at this, and it should be addressed in https://code.orgmode.org/bzg/org-mode/commit/7dd667af. If you could test it and let me know that would be greatly appreciated :) It seems to work with the manual example for me. Until I hear otherwise, I'm marking this bug as fixed. -- Timothy
[PATCH] org-refile.el: Fix the case of emtpy buffer name
* lisp/org-refile.el (org-refile-get-targets): Ensure arg of `file-name-non' and `file-truename' is non-nil. If you set `org-refile-use-outline-path' `file' or `full-file-path', and call `org-refile' in the buffer before visiting file, errors are raised at these point. To fix them, check if they are nil or not. TINYCHANGE --- lisp/org-refile.el | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index 24a1bde51..6f5b8acee 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -310,11 +310,14 @@ converted to a headline before refiling." (setq f (buffer-file-name (buffer-base-buffer f (setq f (and f (expand-file-name f))) (when (eq org-refile-use-outline-path 'file) -(push (list (file-name-nondirectory f) f nil nil) tgs)) +(push (list (if f (file-name-nondirectory f) nil) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'buffer-name) (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'full-file-path) -(push (list (file-truename (buffer-file-name (buffer-base-buffer))) f nil nil) tgs)) +(push (list (if (buffer-base-buffer) + (file-truename (buffer-file-name (buffer-base-buffer))) + nil) + f nil nil) tgs)) (org-with-wide-buffer (goto-char (point-min)) (setq org-outline-path-cache nil) @@ -337,9 +340,11 @@ converted to a headline before refiling." #'identity (append (pcase org-refile-use-outline-path - (`file (list (file-name-nondirectory -(buffer-file-name - (buffer-base-buffer) + (`file (list + (if (buffer-base-buffer) + (file-name-nondirectory +(buffer-file-name (buffer-base-buffer))) + nil))) (`full-file-path (list (buffer-file-name (buffer-base-buffer -- 2.30.0
org-refile.el: Fix the case of emtpy buffer name
Dear Org maintainers, I often use org-mode for note-taking and so on. Sometimes, I would like to refile the headings in the scratch to other org files while I am writing. When I call `org-refile' in the buffer, Emacs throws errors on `org-refile-get-targets' because, typically, these buffers do not have `buffer-name' and I set `org-refile-use-outline-path' `file'. To fix it, I have created my first patch. Regards Takeshi SATO
Re: [PATCH] ox-bb.el: Add BBCode exporter
Hi Christian, Christian Garbs writes: >> Instead, you can host your code where you see fit and advertize it >> by contributing to Worg: > > I should have Worg credentials on one my machines – when I find them, > I'll add it. Thanks in advance! I was not able to find your email address among code.orgmode.org users so perhaps you need a new username. If so please send the username you want privately and I'll add you to Worg. Thanks! -- Bastien
Re: outline-minor-mode and org-mode capabilities for programming languages
> I have same elisp code and using outline-minor-mode. The good thing about it > is that > the language highlighting is preserved. But navigating and moving the code > around is > much more difficult than actually being in org-mode (I can use tab ate move > code with > "M-", M-). The downside is that org-mode removes the highlighting > for the > language. Is there any way out of this. Having flexibility of org-mode with > language > highlighting preserved? I think you like to try Orgstruct or Outshine. Stefan
bug#48149: 27.2; Wrong underline width when the line char has a width of 2
Hi, > Please note that using char-width cannot solve the problem of a > character whose width depends on the font, because char-width is > oblivious to fonts, it only knows about the character's codepoint. I updated my patch proposal as attached to use window-text-pixel-size based on Eli's advice. Could you check it to see if it meets the expectation? It works good in my environment with some fonts of different char widths. Here are some comments: - New internal functions org-ascii--make-string and org-ascii--pixel-width are introduced just to improve code readability of this modification - Line width is decided by org-ascii--make-string, which is a pixel width based make-string - org-ascii--make-string uses org-ascii--pixel-width, which returns actual pixel width of characters and strings by using window-text-pixel-size with frame default font - Line justification is also modified to be a pixel width basis Since this is not a simple modification, I think we might need further improvement, so any feedback is appreciated. Especially, we could do better for table alignment, as that is not very easy because the pixel width of line character and that of space character is not always the same. Anyway, I appreciate it if you can give it a try. I am doing FSF signing process in parallel just in case. --- Shingo Tanaka On Mon, 03 May 2021 01:23:02 +0900, Eli Zaretskii wrote: > > > From: Nicolas Goaziou > > Date: Sun, 02 May 2021 18:08:50 +0200 > > Cc: 48...@debbugs.gnu.org > > > > > In case of 1), it correctly takes account of the case in which the > > > character > > > has a width of 2 in `org-ascii--build-title', by dividing the line width > > > by > > > `(char-width under-char)' (line 700-701), maybe because the character is > > > user > > > configurable and its width in unknown. However, in case of 2) and > > > 3), maybe because the characters is embedded in the code, it looks like > > > only > > > considering the character always has a width of 1. But the reality is > > > character ?─ or ?━ can have a width of 2 in the screen displayed with some > > > fonts (ex. "Noto Sans Mono CJK JP"), and in that case the line width gets > > > doubled of the expected width. > > > > > > Attached one is a potential patch. The basic concepts are: > > > > > > a) Do the same in case of 2) and 3) as in case of 1) > > >(dividing the line width by `(char-width under-char)', > > > assuming `char-width-table' is correctly set) > > > > > > b) Prefer the longer line width if the width is odd, even in case of 1) > > >(adding `(1- (char-width under-char))' to dividend, > > > just because it should be more beautiful ;-) ) > > > > Thank you. This looks good. I cannot apply it on "maint" branch, > > however. Also, a proper commit message would be nice. Could you send an > > updated patch? > > Please note that using char-width cannot solve the problem of a > character whose width depends on the font, because char-width is > oblivious to fonts, it only knows about the character's codepoint. ox-ascii.el.patch Description: Binary data
Re: [wip-cite-new] New natbib processor
On Sun, May 9, 2021 at 4:57 AM Nicolas Goaziou wrote: > > Hello, > > "Bruce D'Arcus" writes: > > > On Fri, May 7, 2021 at 7:37 AM Bruce D'Arcus wrote: > >> Also not sure if additional are needed for the other styles; a "caps" > >> default? > > > > I can't figure this bit out though. > > > > '[cite:/Text@doe]' is obvious and elegant enough, but how do you do > > the same thing for default? > > This is no longer the default style, but a "caps" style, so it would be > > [cite/caps:...] Right. I tried to summarize the current state here: https://github.com/bdarcus/bibtex-actions/wiki/Org-cite#variants To bottom line it, seems the decision comes down to something like these three choices: 1. no change; keep sub-styles as they are ATM 2. change sub-styles to a simple string. So [cite/text/caps+full:...], where sub-style is the string "caps+full"; short cut would be something like [cite:/t/c+f:...] 2. remove sub-styles entirely; just have things like [cite/text+caps-full:...], where the style is "text+caps-full"; or with shortcuts [cite/t+c-f:...] Any of them seem reasonable to me. Maybe 2 is the best balance of flexibility and simplicity? Bruce
Re: [PATCH] ox-bb.el: Add BBCode exporter
Hellp Bastien, On Mon, Apr 26, 2021 at 09:49:13AM +0200, Bastien wrote: > Christian Garbs via "General discussions about Org-mode." > writes: > > > after getting an encouraging reply to my initial proposal[1], I went > > forward and finished the patch to include the BBCode exporter in Org. > > The patch applies to current master and includes a suite of tests. > > thanks for the patch. IMHO, such an exporter does not belongs in > Org's core repository. > > In the past, we suggested to add these contributed packages to the > contrib/ directory, but since this we will extract "contrib/" from > the Git repo soon, I don't suggest doing so. Ah, ok, I did not know that. In the meantime I have published ox-bb as my first MELPA package, both on stable and 'normal' MELPA. > Instead, you can host your code where you see fit and advertize it > by contributing to Worg: I should have Worg credentials on one my machines – when I find them, I'll add it. Thanks for the reply! Best Regards Christian -- Christian.Garbshttps://www.cgarbs.de "...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning."(Matt Welsh)
Re: [wip-cite-new] New natbib processor
Hello, "Bruce D'Arcus" writes: > On Fri, May 7, 2021 at 7:37 AM Bruce D'Arcus wrote: > >> Maybe it's fine to drop them (sub-styles_. > ... > >> Also not sure if additional are needed for the other styles; a "caps" >> default? > > I can't figure this bit out though. > > '[cite:/Text@doe]' is obvious and elegant enough, but how do you do > the same thing for default? This is no longer the default style, but a "caps" style, so it would be [cite/caps:...] > > But with some kind of sub-style, you can do: > > [cite//c:@doe] > > Bruce > Regards, -- Nicolas Goaziou
outline-minor-mode and org-mode capabilities for programming languages
Dear Compeers, I have same elisp code and using outline-minor-mode. The good thing about it is that the language highlighting is preserved. But navigating and moving the code around is much more difficult than actually being in org-mode (I can use tab ate move code with "M-", M-). The downside is that org-mode removes the highlighting for the language. Is there any way out of this. Having flexibility of org-mode with language highlighting preserved? Regards Christopher
ob-sql is not finding psql when using direnv+guix
Hi
I am using Guix with direnv. In an specific folder I am installing and using
psql and postgresql using direnv+guix as follows:
use guix --manifest=cdpp-manifest.scm
export PGUSER=food_user
export PGPASSWORD=some_password
export PGDATABASE=food
layout postgres
Where cdpp-manifest.scm contains the following:
(specifications->manifest
'("python"
"python-pandas"
"python-numpy"
"python-flask"
"python-graphene"
"postgresql"
"jupyter"))
I am able to use sql-mode and run queries against the database, in order to
achieve that I am using the following .dir-locals.el
;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")
((nil .
((projectile-project-test-cmd . "pytest --color=no --failed-first
--maxfail=5")))
(python-mode .
((python-shell-buffer-name . "Python [CDPP-Inspecciones]")))
(org-mode . (
(indent-tabs-mode . nil)
(org-src-preserve-indentation . t)
(org-footnote-auto-adjust . t)
(org-footnote-auto-label . t)
(ispell-local-dictionary . "spanish")
(org-export-allow-bind-keywords . t)
(org-footnote-define-inline . nil)
(org-footnote-section . "Footnotes")))
(sql-mode . ((sql-connection-alist . ((mydb
(sql-product 'postgres)
(sql-database "mydb")
(sql-user "db_user")
(sql-server (expand-file-name
".direnv/postgres"))
(sql-port 5432)
)
)
But If I try to use an sql org-babel block
#+begin_src sql
select 1;
#+end_src
(I am setting the connection variables in a PROPERTY)
I get the error: `psql is not found`
I was reading about the variable sql-postgres-program, so if I set the
following in dir-locals.el
(sql-postgres-program .
"/gnu/store/f2v92bkx2vfzmkl14qxj3hlmby4dy9x0-profile/bin/psql")
It works (note that psql ONLY lives inside the profile defined by direnv+guix),
but I don't like the idea of hardcode the path.
Is there a better way?
Ideally I will expect that the org block will read it from the environment, but
is not working.
Thanks in advance
bug#47088: org-w3m: handle w3m-image link information
I'm closing this report as the patch has been applied upstream. -- Bastien
