Re: How do you name your code blocks?
hi, Rodrigo, thanks. i understand. we all like "int i;" to be independent in separate functions (as it were). right now, names of source blocks are global to the .org file, and i don't suspect that will (or should) change. i apologize for bringing it up, but the one thing that jumps out at the programmer part of me is that the python blocks in your code don't "know" what main.txt actually contains when they are executed, as there is no dependency on the correct "create-file" source block. possibly, though, if you created some dummy :var (on the python "begin_src" lines) to express this dependency, it would help? or, maybe it doesn't really matter? cheers, Greg
Re: A small bugfix in org-clock-in
Jean-Marie Gaillourdet writes: > I've experienced occasionally errors while executing org-clock-in from > the agenda. The errors seems to be that indent-line-to is called with > a negative argument. Moving from the agenda to the todo headline in > the underlying org file and repeating org-clock-in and org-clock-out > usually lead to a state in which I could successfully run > org-clock-in. > > The following patch fixes the issue for me and I believe it does no > harm. I've used it daily for two month. I'd appreciate if you could > add it to org-mode. I agree the change is safe, though I couldn't figure out how to get into a state where it'd be needed. Anyway, pushed (ee4ffa567), adding TINYCHANGE to the commit message. Thanks.
Re: Turning off all indentation in 9.4.4
TRS-80 writes: > On 2021-02-04 12:45, Kévin Le Gouguec wrote: [...] >> ORG-NEWS provides these hints: >> >>> To get the previous behaviour back, disable ~electric-indent-mode~ >>> explicitly: >>> >>> #+begin_src emacs-lisp >>> (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) >>> #+end_src >>> >>> Alternatively, if you wish to keep =RET= as the "smart-return" key, >>> but dislike Org's default indentation of sections, you may prefer to >>> customize ~org-adapt-indentation~ to either =nil= or ='headline-data=. [...] > Unfortunately, unless I am doing something wrong, none of these options > seem to really restore the previous behavior. I have set > ~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes > to column 0. However, unfortunately, TAB now no longer jumps to the > indentation level of the previous block (for example, so I can insert a > code block or other block structure into a plain list at the correct > level). I think you're talking about the following behavior. * a foo With org-adapt-indentation at nil (or the new headline-data value), foo doesn't get indented. This behavior is not new to 9.4. If you try with 9.3.8 and org-adapt-indentation is set to nil, it also will not indent. Step through org--get-expected-indentation to see how the different values of org-adapt-indentation are handled. So, if I'm reading your preferences correctly, it sounds like you want just the first suggestion in the above snippet, leaving org-adapt-indentation at its default value: (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
Re: org-agenda for a day different than today
Alan Schmitt writes: > I’ve been reading the documentation around org-agenda, and I cannot find > a way to call it to get an agenda for a day different than today. I’ve > found org-agenda-goto-date, but I don’t know how to call it from > emacs-lisp with the target date. > > By the way, I’m surprised by the code of this function, as it is defined > as: > > (defun org-agenda-goto-date (span) > "Jump to DATE in agenda." > … > ) > > and "span" is never mentioned in the function. Am I missing something? That does look wrong. Among other changes, 93fcfe4d3 (org-agenda.el: Fix org-agenda-goto-date' again, 2012-08-30) switched the DATE argument to SPAN, moving the org-read-date call out of the interactive form. >From that commit alone, I don't have a good guess at why and am wondering if the above change was an unfinished thought that came along with the other changes. Here are two threads from around that time that may be related, though I haven't reviewed either of them: https://orgmode.org/list/blu0-smtp912fc379760ee431d3d68ebb...@phx.gbl/T/#u https://orgmode.org/list/blu0-smtp950e9387b34fa390c4fd9cbb...@phx.gbl/T/#u Moving org-read-date back to the interactive form would allow lisp callers to pass in the date, though perhaps it'd bring back some misbehavior discussed in the above threads. diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9b2009fdb..aef642037 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8238,13 +8238,13 @@ (defun org-agenda-manipulate-query (char) (defun org-add-to-string (var string) (set var (concat (symbol-value var) string))) -(defun org-agenda-goto-date (span) +(defun org-agenda-goto-date (date) "Jump to DATE in agenda." - (interactive "P") - (let* ((org-read-date-prefer-future - (eval org-agenda-jump-prefer-future)) -(date (org-read-date)) -(day (time-to-days (org-time-string-to-time date))) + (interactive + (list +(let ((org-read-date-prefer-future org-agenda-jump-prefer-future)) + (org-read-date + (let* ((day (time-to-days (org-time-string-to-time date))) (org-agenda-sticky-orig org-agenda-sticky) (org-agenda-buffer-tmp-name (buffer-name)) (args (get-text-property (min (1- (point-max)) (point)) 'org-last-args))
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
still not what i am saying. nefver mind. thanks. On 2/16/21, Tim Cross wrote: > > Samuel Wales writes: > >> hi tim, >> >> tanks for your replies. >> >> 1. the same problem occurs without any * in the buffer. > > It will occur with any of the markup special characters e.g. *, =, _, +, / > >> >> 2. the emphasis regexps are supposed to be limited to a few lines. > > Are they? What is 'a few'? This also won't work if you use > visual-line-mode and don't use auto-fill (as your paragraphs are then > just one long line). > >> >> 3. they are also supposed to not try to match dissimilar delimiiters. >> > > Not quite sure what you mean here. > >> the problem is that >> >> hi =something >> >> stops all emphasis of all types in the entire rest of hte bguffer even >> if the buyffer contains many lines. this sems unusual to me. >> >> it does not break anything befofre it. >> >> so i think your hypothesis of what i am talking about might possibly >> not match what i am talking about at all. >> > > I'm not disagreeing with what your saying. I think the reason the rest > of the file doesn't get parsed correctly is because the single markup > character has made the syntax inconsistent and broken. > > The problem is I don't think there is a good fix for this which doesn't > introduce other problems. If the regexp which does the matching is > supposed to limit its search to just a specific number of lines, then > perhaps it is broken. However, I'm not sure what 'a few lines' really > means (2?, 5?, 10?). I also know from past experience that trying to > define font-lock matches which work in such a way is complex, error > prone and often results in a considerable performance hit. > > Bottom line, if you want to use the characters reserved for markup > purposes as just plain characters, you have to somehow quote them or > mark them as being 'verbatim' characters. I do think it would be useful > to have something in the manual on this under the markup section. > > -- > Tim Cross > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: How do you name your code blocks?
On 2021-02-15 14:18, Rodrigo Morales wrote:
> 1. Do you use long names?
Usually. Suppose you were doing a bit of genetic programming. You might have a
function that computes the next generation from the current one. You could
write the following snippet that looks suspiciously like pseudocode:
#+HEADER::noweb-ref genetic/functions
#+BEGIN_SRC python
def next_generation(curr):
<>
<>
<>
<>
return new
#+END_SRC
You would then have a block dedicated to each major part of the evolutionary
step.
> 2. If not, how do you name your code blocks to avoid name conflicts?
I have been over the tangling and noweb expansion code quite a bit lately. The
chief benefit of using #+NAME on a code block is ability to call it. For
example, you might have
#+NAME: generate keymap
#+BEGIN_SRC elisp :var t=keymap
...
#+END_SRC
whose sole purpose is to take a table from elsewhere in an Org file and generate
the code that sets up a keymap. To use it, you might say
#+BEGIN_SRC elisp
<>
#+END_SRC
For every other purpose, :noweb-ref works better. In newer versions of org,
it's the sole means of accumulating code under a common name in the WEB/Noweb
tradition. In older versions, duplicate #+NAMEs did result in accumulation, but
the behavior was undefined.
A word on syntax: I find
#+BEGIN_SRC language :noweb-ref "block name"
...
#+END_SRC
less readable than
#+HEADER::noweb-ref block name
#+BEGIN_SRC language
...
#+END_SRC
especially when there are further block-specific header args. Either is more
cumbersome to type than the #+NAME syntax, but that can be dealt with using
something like
(add-to-list 'org-structure-template-alist
'("ss" "#+HEADER::noweb-ref ?\n#+BEGIN_SRC\n\n#+END_SRC"))
Then, to set up a safely-named block,
Re: How do you name your code blocks?
Eric S Fraga writes: > Yes. Fully qualified and detailed. And then rely on completion to jump > to code blocks (using org-babel-goto-named-src-block). Thanks for the answer. I didn't know about =org-babel-goto-named-src-block=. Regarding using fully qualified and detailed names: I feel like it is not a good idea for the use case I have with Org Mode. I have multiple big Org files for each programming languages I've used and while using long names might avoid name conflicts, there would be a time in which a name conflict would occur because it is necessary to avoid using a name which has already been used, so for example if I name a code block with =generate-data-for-plotting=, I can't use that same name again. For this reason, I was thinking in the following workaround: use use the ID of the subtree as the prefix of the name of the code blocks. Thus, name conflicts are less likely to occur (see example below). #+begin_src org ,* DONE How to get the number of lines in a file? :PROPERTIES: :ID: ec1f7066-213c-458e-a0f9-786b722218f4 :END: ,#+NAME: ec1f7066-213c-458e-a0f9-786b722218f4/create-file ,#+begin_src dash :results silent cat << EOF > main.txt first second third EOF ,#+end_src ,* DONE How to print most repeated word in a file? :PROPERTIES: :ID: e0768c19-080f-47db-9dc2-3bd00efdd036 :END: ,#+NAME: e0768c19-080f-47db-9dc2-3bd00efdd036/create-file ,#+begin_src dash :results silent cat << EOF > main.txt fizz fizz fizz buzz buzz buzz buzz foo bar bar EOF ,#+end_src #+end_src As we can see above, both =dash= code blocks are given the name =create-file= because both of them create a file but the ID of the heading is used a the prefix in order to avoid a name conflict. Let me know your thoughts on this workaround :) -- Rodrigo Morales. IRC: rdrg109 (freenode)
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > hi tim, > > tanks for your replies. > > 1. the same problem occurs without any * in the buffer. It will occur with any of the markup special characters e.g. *, =, _, +, / > > 2. the emphasis regexps are supposed to be limited to a few lines. Are they? What is 'a few'? This also won't work if you use visual-line-mode and don't use auto-fill (as your paragraphs are then just one long line). > > 3. they are also supposed to not try to match dissimilar delimiiters. > Not quite sure what you mean here. > the problem is that > > hi =something > > stops all emphasis of all types in the entire rest of hte bguffer even > if the buyffer contains many lines. this sems unusual to me. > > it does not break anything befofre it. > > so i think your hypothesis of what i am talking about might possibly > not match what i am talking about at all. > I'm not disagreeing with what your saying. I think the reason the rest of the file doesn't get parsed correctly is because the single markup character has made the syntax inconsistent and broken. The problem is I don't think there is a good fix for this which doesn't introduce other problems. If the regexp which does the matching is supposed to limit its search to just a specific number of lines, then perhaps it is broken. However, I'm not sure what 'a few lines' really means (2?, 5?, 10?). I also know from past experience that trying to define font-lock matches which work in such a way is complex, error prone and often results in a considerable performance hit. Bottom line, if you want to use the characters reserved for markup purposes as just plain characters, you have to somehow quote them or mark them as being 'verbatim' characters. I do think it would be useful to have something in the manual on this under the markup section. -- Tim Cross
Re: How do you name your code blocks?
Greg Minshall writes:
> i guess part of the answer depends on why you are naming your code
> blocks.
I was asking because in my notes in Org Mode, I am used to create
subheadings for each question I have. Here's an example:
Let's say that in my notes on Python, I have the following content
#+begin_src org
,* DONE How to get the number of lines in a file?
- State "DONE" from [2021-02-16 Tue 20:02]
,#+NAME: create-file
,#+begin_src dash :results silent
cat << EOF > main.txt
first
second
third
EOF
,#+end_src
,#+begin_src python
print(len(open('main.txt').readlines()))o3
,#+end_src
,#+RESULTS:
,#+begin_example
3
,#+end_example
,* DONE How to print most repeated word in a file?
- State "DONE" from [2021-02-16 Tue 20:02]
,#+NAME: create-file
,#+begin_src dash :results silent
cat << EOF > main.txt
fizz fizz fizz
buzz buzz buzz buzz
foo
bar bar
EOF
,#+end_src
,#+begin_src python
import re
from collections import Counter
with open('main.txt') as f:
passage = f.read()
words = re.findall(r'\w+', passage)
word_counts = Counter(words)
print(word_counts.most_common(1))
,#+end_src
,#+RESULTS:
,#+begin_example
[('buzz', 4)]
,#+end_example
#+end_src
As you can see above, there are two code blocks which creates two text
files so that a Python script can then process it. Both of them create
a text file, that's why I have used =create-file= as the name of those
code block. I could have used very long names but I don't find
comfortable myself doing that since it adds extra effort to think in a
name for such simple code blocks (see below an example of the approach
of using long names).
#+begin_src org
,* DONE How to get the number of lines in a file?
,#+NAME: create-file-for-counting-lines
,#+begin_src dash :results silent
cat << EOF > main.txt
first
second
third
EOF
,#+end_src
,* DONE How to print most repeated word in a file?
,#+NAME: create-file-for-finding-most-repeated-word
,#+begin_src dash :results silent
cat << EOF > main.txt
fizz fizz fizz
buzz buzz buzz buzz
foo
bar bar
EOF
,#+end_src
#+end_src
--
Rodrigo Morales.
IRC: rdrg109 (freenode)
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
to understant, perahsp try to look at the op and remove the line that says *hi*? On 2/16/21, Samuel Wales wrote: > hi tim, > > tanks for your replies. > > 1. the same problem occurs without any * in the buffer. > > 2. the emphasis regexps are supposed to be limited to a few lines. > > 3. they are also supposed to not try to match dissimilar delimiiters. > > the problem is that > > hi =something > > stops all emphasis of all types in the entire rest of hte bguffer even > if the buyffer contains many lines. this sems unusual to me. > > it does not break anything befofre it. > > so i think your hypothesis of what i am talking about might possibly > not match what i am talking about at all. > > i am limited in coputer ue and will have to stop. > > tahnks for your replies. > > > On 2/16/21, Tim Cross wrote: >> >> Samuel Wales writes: >> >>> to answer your question: i expected it to just skip the non-emphasis. >>> not emphasizing the rest of the buffer seemed quite unusual. >>> >> >> I guess the problem is the same - how does org know when it is just a * >> and when it is the beginning of some emphasis text? We could make it >> that such markup only works on words, allowing the code to only consider >> two * as emphasis if there are no spaces, otherwise treat as just a *, >> but that would be inconvenient when you want to emphasis a phrase or a >> couple of words. We could change the regexp to only consider it an >> emphasis block if both markers are on the same line, but again, >> potentially inconvenient and it would fail for those who use visual-line >> mode where there paragraphs are just 1 long line. >> >> In short, can understand what your saying, but not sure there is a >> viable fix which doesn't have a heap of other consequences. Basically, >> if you want to use the 'markup' characters as normal characters, you >> need to either escape them or put them inside a verbatim directive. >> >> -- >> Tim Cross >> > > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
hi tim, tanks for your replies. 1. the same problem occurs without any * in the buffer. 2. the emphasis regexps are supposed to be limited to a few lines. 3. they are also supposed to not try to match dissimilar delimiiters. the problem is that hi =something stops all emphasis of all types in the entire rest of hte bguffer even if the buyffer contains many lines. this sems unusual to me. it does not break anything befofre it. so i think your hypothesis of what i am talking about might possibly not match what i am talking about at all. i am limited in coputer ue and will have to stop. tahnks for your replies. On 2/16/21, Tim Cross wrote: > > Samuel Wales writes: > >> to answer your question: i expected it to just skip the non-emphasis. >> not emphasizing the rest of the buffer seemed quite unusual. >> > > I guess the problem is the same - how does org know when it is just a * > and when it is the beginning of some emphasis text? We could make it > that such markup only works on words, allowing the code to only consider > two * as emphasis if there are no spaces, otherwise treat as just a *, > but that would be inconvenient when you want to emphasis a phrase or a > couple of words. We could change the regexp to only consider it an > emphasis block if both markers are on the same line, but again, > potentially inconvenient and it would fail for those who use visual-line > mode where there paragraphs are just 1 long line. > > In short, can understand what your saying, but not sure there is a > viable fix which doesn't have a heap of other consequences. Basically, > if you want to use the 'markup' characters as normal characters, you > need to either escape them or put them inside a verbatim directive. > > -- > Tim Cross > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > to answer your question: i expected it to just skip the non-emphasis. > not emphasizing the rest of the buffer seemed quite unusual. > I guess the problem is the same - how does org know when it is just a * and when it is the beginning of some emphasis text? We could make it that such markup only works on words, allowing the code to only consider two * as emphasis if there are no spaces, otherwise treat as just a *, but that would be inconvenient when you want to emphasis a phrase or a couple of words. We could change the regexp to only consider it an emphasis block if both markers are on the same line, but again, potentially inconvenient and it would fail for those who use visual-line mode where there paragraphs are just 1 long line. In short, can understand what your saying, but not sure there is a viable fix which doesn't have a heap of other consequences. Basically, if you want to use the 'markup' characters as normal characters, you need to either escape them or put them inside a verbatim directive. -- Tim Cross
org-agenda-list should respect org-agenda-max-entries
While going through the source code, I've noticed that org-agenda-list scans all the files in org-agenda-files and processes all Org items those files contain. However, it seems when org-agenda-max-entries or org-agenda-max-todos are not nil, it still processes every entry, and only after building the agenda it reduces the number of items in the list. It's okay, but if you have lots of files and tons of entries, it seems to be waste of time and resources. Just wanted to bring someone's attention to that. Thank you!
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > hi tim, > > it isn't malformed, so definitely not looking to be told it's > malformed. it is just text that is not emphasis. > > if you think the function works as expected by skipping the rest of > the buffer, then never mind. > > i was, in that case, just emphasizing that the code floating around > that is used to fontify the agenda is going to break. so nm. > OK, that makes more sense. I guess you need to escape the * e.g. \* to turn off its 'special' meaning or put it between = to make it a 'verbatim' value. To be honest, I've never run into this issue, but I tend to not use '*' in my text unless it is for emphasis. -- Tim Cross
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
to answer your question: i expected it to just skip the non-emphasis. not emphasizing the rest of the buffer seemed quite unusual. On 2/16/21, Samuel Wales wrote: > hi tim, > > it isn't malformed, so definitely not looking to be told it's > malformed. it is just text that is not emphasis. > > if you think the function works as expected by skipping the rest of > the buffer, then never mind. > > i was, in that case, just emphasizing that the code floating around > that is used to fontify the agenda is going to break. so nm. > > > On 2/16/21, Tim Cross wrote: >> >> Samuel Wales writes: >> >>> in fundamental mode [to eliminate any extra stuff]: >>> >>> === >>> hi >>> /hi/ >>> hi =test >>> hi >>> hi >>> hi >>> /hi/ >>> hi >>> *hi* >>> hi >>> hi >>> hi >>> === >>> >>> m-: (org-do-emphasis-faces nil) RET >>> >>> everything after =test does not get emphasized. >>> >>> there is code floating around that calls hte function directly instead >>> of via font lock. so even if font lock or org mode forgive this, that >>> code does not seem to. and idk whether it is forgiven or if there are >>> unintended consequences. >>> >>> e.g. to emphasize in agenda. which, not sure why it isn't? >> >> I'm not clear on what you are expecting/wanting here. If you have badly >> formed markup, syntax highlighting and other functions can be expected >> to fail. >> >> Are you expecting something more informative, like an error message >> saying you have an unterminated emphasis marker or similar? If so, while >> it might be possible, I suspect it would come at a high cost from a >> performance perspective, especially in large org files. For example, at >> what point do you decide the closing marker is missing rather than just >> a little further along? At what point do you begin doing the checking - >> after typing the first marker, after the first character, after the >> first space (noting that all this checking comes at a performance cost)? >> >> What does org-lint tell you when you have such malformed markup in your >> document? Would that be sufficient to track down issues when they occur? >> If org-lint is not picking it up or is not providing enough detail to >> help resolve the issue, perhaps tweaking it would be worthwhile. >> >> -- >> Tim Cross >> >> > > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
hi tim, it isn't malformed, so definitely not looking to be told it's malformed. it is just text that is not emphasis. if you think the function works as expected by skipping the rest of the buffer, then never mind. i was, in that case, just emphasizing that the code floating around that is used to fontify the agenda is going to break. so nm. On 2/16/21, Tim Cross wrote: > > Samuel Wales writes: > >> in fundamental mode [to eliminate any extra stuff]: >> >> === >> hi >> /hi/ >> hi =test >> hi >> hi >> hi >> /hi/ >> hi >> *hi* >> hi >> hi >> hi >> === >> >> m-: (org-do-emphasis-faces nil) RET >> >> everything after =test does not get emphasized. >> >> there is code floating around that calls hte function directly instead >> of via font lock. so even if font lock or org mode forgive this, that >> code does not seem to. and idk whether it is forgiven or if there are >> unintended consequences. >> >> e.g. to emphasize in agenda. which, not sure why it isn't? > > I'm not clear on what you are expecting/wanting here. If you have badly > formed markup, syntax highlighting and other functions can be expected > to fail. > > Are you expecting something more informative, like an error message > saying you have an unterminated emphasis marker or similar? If so, while > it might be possible, I suspect it would come at a high cost from a > performance perspective, especially in large org files. For example, at > what point do you decide the closing marker is missing rather than just > a little further along? At what point do you begin doing the checking - > after typing the first marker, after the first character, after the > first space (noting that all this checking comes at a performance cost)? > > What does org-lint tell you when you have such malformed markup in your > document? Would that be sufficient to track down issues when they occur? > If org-lint is not picking it up or is not providing enough detail to > help resolve the issue, perhaps tweaking it would be worthwhile. > > -- > Tim Cross > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Org failing to format a link with verbatim text
> On Feb 16, 2021, at 1:20 PM, Okam wrote: > > I am using the Emacs gccemacs branch with Org version "9.5-dev". > I have noticed that when I try to insert the stored link > > file:doc/loopy-doc.org::*Destructuring with =dash= > > and use the heading as the link description, that Org cannot format this > link correctly in all circumstances, and tries to make the verbatim text > break out from the link. The last para of (info "(org) External Links") says in part: #+begin_quote If spaces must be part of the link (for example in ‘bbdb:R.*Stallman’), or if you need to remove ambiguities about the end of the link, enclose the link in square or angular brackets. #+end_quote To me, this sounds like advice not to drop external links amid normal text. i.e. put them in brackets instead. HTH, Chuck
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > in fundamental mode [to eliminate any extra stuff]: > > === > hi > /hi/ > hi =test > hi > hi > hi > /hi/ > hi > *hi* > hi > hi > hi > === > > m-: (org-do-emphasis-faces nil) RET > > everything after =test does not get emphasized. > > there is code floating around that calls hte function directly instead > of via font lock. so even if font lock or org mode forgive this, that > code does not seem to. and idk whether it is forgiven or if there are > unintended consequences. > > e.g. to emphasize in agenda. which, not sure why it isn't? I'm not clear on what you are expecting/wanting here. If you have badly formed markup, syntax highlighting and other functions can be expected to fail. Are you expecting something more informative, like an error message saying you have an unterminated emphasis marker or similar? If so, while it might be possible, I suspect it would come at a high cost from a performance perspective, especially in large org files. For example, at what point do you decide the closing marker is missing rather than just a little further along? At what point do you begin doing the checking - after typing the first marker, after the first character, after the first space (noting that all this checking comes at a performance cost)? What does org-lint tell you when you have such malformed markup in your document? Would that be sufficient to track down issues when they occur? If org-lint is not picking it up or is not providing enough detail to help resolve the issue, perhaps tweaking it would be worthwhile. -- Tim Cross
[bug] org-do-emphasis-faces breaks with incomplete emphasis
in fundamental mode [to eliminate any extra stuff]: === hi /hi/ hi =test hi hi hi /hi/ hi *hi* hi hi hi === m-: (org-do-emphasis-faces nil) RET everything after =test does not get emphasized. there is code floating around that calls hte function directly instead of via font lock. so even if font lock or org mode forgive this, that code does not seem to. and idk whether it is forgiven or if there are unintended consequences. e.g. to emphasize in agenda. which, not sure why it isn't? -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Org failing to format a link with verbatim text
Hello, I am using the Emacs gccemacs branch with Org version "9.5-dev". I have noticed that when I try to insert the stored link file:doc/loopy-doc.org::*Destructuring with =dash= and use the heading as the link description, that Org cannot format this link correctly in all circumstances, and tries to make the verbatim text break out from the link. I have attached pictures showing this. I can avoid this be separating the sentences with a blank line. Thank you.
Bug: linking to <> requests tags table [9.4.4 ( @ /home/arne/.guix-profile/share/emacs/site-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.
Following the manual at Hyperlinks Node: Internal Links
1. one item
2. <>another item
Here we refer to item [[target]].
And then using C-c C-o on [[target]] I get the prompt in the minibuffer
“Visit tags table (default TAGS)” instead of jumping to <>.
Best wishes,
Arne
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0)
Package: Org mode version 9.4.4 ( @
/home/arne/.guix-profile/share/emacs/site-lisp/)
current state:
==
(setq
org-duration-format '((special . h:mm))
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-skip-additional-timestamps-same-entry t
org-timer-default-timer "\"0:00:30\""
org-after-todo-state-change-hook '(org-checklist
kiwon/org-agenda-redo-in-other-window)
org-columns-default-format "%25ITEM %TODO %3PRIORITY %TAGS %17Effort(Estimated
Effort){:} %CLOCKSUM"
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-global-properties '(("Effort_ALL" . "0:30 1:00 2:00 3:00 6:00 8:00 16:00
40:00"))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer
kiwon/org-agenda-redo-in-other-window)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-time-stamp-custom-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
org-enforce-todo-dependencies t
org-checkbox-hierarchical-statistics nil
org-latex-default-packages-alist '(("AUTO" "inputenc" t) ("T1" "fontenc" t)
("" "fixltx2e" nil) ("" "graphicx" t)
("" "longtable" nil) ("" "float" nil) (""
"wrapfig" nil) ("" "rotating" nil)
("normalem" "ulem" t) ("" "amsmath" t)
("force,almostfull" "textcomp" t) ("" "marvosym" t)
("" "wasysym" t) ("" "amssymb" t) (""
"hyperref" nil) "\\tolerance=1000")
org-edit-src-content-indentation 0
org-src-tab-acts-natively nil
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-latex-pdf-process '("pdflatex -interaction nonstopmode -shell-escape
-output-directory %o %f" "bibtex $(basename %b)"
"pdflatex -interaction nonstopmode -shell-escape
-output-directory %o %f"
"pdflatex -interaction nonstopmode -shell-escape
-output-directory %o %f")
org-jira-progress-issue-flow '(("Open" . "In Bearbeitung") ("In Bearbeitung" .
"In Review") ("In Review" . "Bearbeitet"))
org-agenda-files
'("~/eigenes/1w6/Hauptdokument/ews30/konvertierung-voodoo.org"
"~/.emacs.d/private/org/emacs-plan.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-clock-report-include-clocking-task t
org-reveal-start-hook '(org-decrypt-entry)
org-modules '(org-bbdb org-bibtex org-crypt org-ctags org-docview org-eww
org-gnus org-habit org-info org-irc org-mhe org-rmail
org-w3m)
org-plantuml-jar-path "~/.guix-profile/share/java/plantuml.jar"
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-mode-hook '(org-tempo-setup
#[0
"\305\306>\203\307\n\310\311#\210\307 \312\313#\210\307
\314\315#\210\306>\203,\307\n\316\317#\210\307\n\320\321#\210\322
>\203>\307 \323\324#\210\307 \325\324#\210\326
>\203P\307\n\327\317#\210\307\n\330\321#\210\331
>\203_\332\311\f\333BC\334#\210\335 >\203k\332\311\336\334#\210\337
>\203w\332\311\340\334#\210\341\342\343\344\311$\210\345\342\311\"\210\342\207"
[org-mouse-context-menu-function
org-mouse-features
org-mouse-map
org-mode-map
org-outline-regexp
org-mouse-context-menu
context-menu
org-defkey
[mouse-3]
nil
[mouse-3]
org-mouse-show-context-menu
[down-mouse-1]
org-mouse-down-mouse
[C-drag-mouse-1]
org-mouse-move-tree
[C-down-mouse-1]
org-mouse-move-tree-start
yank-link
[S-mouse-2]
org-mouse-yank-link
[drag-mouse-3]
move-tree
[drag-mouse-3]
[down-mouse-3]
activate-stars
font-lock-add-keywords
(0
`(face org-link mouse-face highlight keymap
Re: A small bugfix in org-clock-in
Hello, I am sorry, for the mess in my previous mail. I've experienced occasionally errors while executing org-clock-in from the agenda. The errors seems to be that indent-line-to is called with a negative argument. Moving from the agenda to the todo headline in the underlying org file and repeating org-clock-in and org-clock-out usually lead to a state in which I could successfully run org-clock-in. The following patch fixes the issue for me and I believe it does no harm. I've used it daily for two month. I'd appreciate if you could add it to org-mode. Kind regards, Jean-Marie >From 319785492d55d33cdf819aa891c3e7834dafacff Mon Sep 17 00:00:00 2001 From: Jean-Marie Gaillourdet Date: Sun, 13 Dec 2020 12:50:52 +0100 Subject: [PATCH] org-clock: fix runtime error in org-clock-in * org-clock.el (org-clock-in): Under certain configurations of org, Emacs doom, evil-org-mode and my custom settings, org-clock-in aborts with an an error because indent-line-to is called with -2. --- lisp/org-clock.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 6c7a797ff..4256b1a21 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1368,7 +1368,7 @@ the default behavior." (end-of-line 0) (org-in-item-p))) (beginning-of-line 1) - (indent-line-to (- (current-indentation) 2))) + (indent-line-to (max 0 (- (current-indentation) 2 (insert org-clock-string " ") (setq org-clock-effort (org-entry-get (point) org-effort-property)) (setq org-clock-total-time (org-clock-sum-current-item -- 2.29.2 -- Jean-Marie Gaillourdet
Re: [question] lisp code in :results header arg.?
"Berry, Charles" writes:
> I think you might do better to use noweb chunks, viz.
>
> #+name: pre-amble
> #+begin_src latex :exports none
>
> \usepackage{luacode}
> \usepackage{fontspec}
> \directlua
> {
> [...]
> }
> }
> \setmainfont{Linux Libertine O}
> [RawFeature={+ktest}]
> #+end_src
>
> #+begin_src latex :noweb yes :results drawer
> ,#+LaTeX_HEADER: <>
> #+end_src
>
>
> Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex .
> t)) gives what I suspect you want.
wow, it works great! Many thanks. I did not know this use of noweb ...
Best regards,
Juan Manuel
Re: [question] lisp code in :results header arg.?
> On Feb 16, 2021, at 8:30 AM, Juan Manuel Macías
> wrote:
>
> Hi,
>
> I'm exploring some ways to include a complex LaTeX preamble using source
> blocks. Consider this (code at the end of this message), that works fine.
>
> My question is: In order to do it all in a single block, would there be
> any way to pass the output of the first block as an argument to a
> function, and put that function as a header arg (results)...?
[rest deleted]
I think you might do better to use noweb chunks, viz.
#+name: pre-amble
#+begin_src latex :exports none
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
[...]
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src latex :noweb yes :results drawer
,#+LaTeX_HEADER: <>
#+end_src
Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex .
t)) gives what I suspect you want.
Note that using a drawer allows replacement of the result.
HTH,
Chuck
Re: Toggle headline underlining in text export?
Hi Loris, have a look at the variable org-ascii-underline. It defines the characters for underlining headings. If no character is set, the headlines shouldn't be underlined (according to the documentation). Best, Christine
A small bufix in org-clock-in
Hello, I've experienced occasionally errors while executing org-clock-in from the agenda. Moving from the agenda to the todo headline in the underlying org file and repeating org-clock-in and org-clock-out usually lead to a state in which I could successfully run org-clock-in. The following patch fixes the issue for me and I believe it does no harm. I've used it daily for two month. I'd appreciate if you could add it org-mode. Kind regards, Jean-Marie -- Jean-Marie Gaillourdet From 319785492d55d33cdf819aa891c3e7834dafacff Mon Sep 17 00:00:00 2001 From: Jean-Marie Gaillourdet Subject: [PATCH] org-clock: fix runtime error in org-clock-in * org-clock.el (org-clock-in): Under certain configurations of org, Emacs doom, evil-org-mode and my custom settings, org-clock-in aborts with an an error because indent-line-to is called with -2. --- lisp/org-clock.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 6c7a797ff..4256b1a21 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1368,7 +1368,7 @@ the default behavior." (end-of-line 0) (org-in-item-p))) (beginning-of-line 1) - (indent-line-to (- (current-indentation) 2))) + (indent-line-to (max 0 (- (current-indentation) 2 (insert org-clock-string " ") (setq org-clock-effort (org-entry-get (point) org-effort-property)) (setq org-clock-total-time (org-clock-sum-current-item -- 2.29.2
[question] lisp code in :results header arg.?
Hi,
I'm exploring some ways to include a complex LaTeX preamble using source
blocks. Consider this (code at the end of this message), that works fine.
My question is: In order to do it all in a single block, would there be
any way to pass the output of the first block as an argument to a
function, and put that function as a header arg (results)...?
Best Regards,
Juan Manuel
#+NAME:preamble
#+begin_src latex :results silent :exports results
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
fonts.handlers.otf.addfeature
{
name = "ktest",
type = "kern",
data =
{
["A"] = { ["V"] = -45 },
},
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src emacs-lisp :var x=preamble :results raw :exports results
(let* ((lines (split-string x "\n" nil))
(headers (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n")))
headers)
#+end_src
#+RESULTS:
#+LaTeX_Header: \usepackage{luacode}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \directlua
#+LaTeX_Header: {
#+LaTeX_Header: fonts.handlers.otf.addfeature
#+LaTeX_Header: {
#+LaTeX_Header:name = "ktest",
#+LaTeX_Header:type = "kern",
#+LaTeX_Header:data =
#+LaTeX_Header: {
#+LaTeX_Header: ["A"] = { ["V"] = -45 },
#+LaTeX_Header: },
#+LaTeX_Header: }
#+LaTeX_Header: }
#+LaTeX_Header: \setmainfont{Linux Libertine O}
#+LaTeX_Header: [RawFeature={+ktest}]
Re: Toggle headline underlining in text export?
Hi Vladimir, Vladimir Lomov writes: > Hello, > ** Loris Bennett [2021-02-16 11:00:08 +0100]: > >> Hi, > >> I have an Org file which I export to a text file. A separate program I >> have written then uses this text file as the body of an email which is >> sent to a number of people. > >> The problem I have is that the underlining of the headlines is much >> longer than the headline text itself if a proportional font is used to >> view the email. > > This contradicts a bit to first paragraph. I would assume that you export to > text format to send email message as plain text. I'm not sure what contradiction you are referring to. I am indeed exporting the a text format and in this text format the top-level headlines are underlined with either a '=' if I export to ASCII or some UTF symbol if I export to UTF-8. Whether the underlining is the same length as the headline itself depends on whether the font used to display the text is fixed-width or proportional. >> As most of the recipients will probably not be using a fixed-width font for >> their mail clients, > > And this assumes that they are fine with html messages otherwise they would > use fixed-width font. I'm not sure this is true. Someone might not like HTML mail for security reasons, but still might use a proportional font. In addition, at least a few of the recipients certainly will be using a fixed-width font. >> I would like to be able to toggle the underlining and just rely on the >> numbering of the headlines. > >> I'd didn't find anything which seemed relevant here > >> https://orgmode.org/manual/Export-Settings.html > >> so is this possible? Is there a (better) alternative? > > May be send them a html message? I could do, but I'd rather not :-) Cheers, Loris -- This signature is currently under construction.
org-agenda for a day different than today
Hello, I’ve been reading the documentation around org-agenda, and I cannot find a way to call it to get an agenda for a day different than today. I’ve found org-agenda-goto-date, but I don’t know how to call it from emacs-lisp with the target date. By the way, I’m surprised by the code of this function, as it is defined as: (defun org-agenda-goto-date (span) "Jump to DATE in agenda." … ) and "span" is never mentioned in the function. Am I missing something? Thanks, Alan signature.asc Description: PGP signature
Re: Toggle headline underlining in text export?
Hello, ** Loris Bennett [2021-02-16 11:00:08 +0100]: > Hi, > I have an Org file which I export to a text file. A separate program I > have written then uses this text file as the body of an email which is > sent to a number of people. > The problem I have is that the underlining of the headlines is much > longer than the headline text itself if a proportional font is used to > view the email. This contradicts a bit to first paragraph. I would assume that you export to text format to send email message as plain text. > As most of the recipients will probably not be using a fixed-width font for > their mail clients, And this assumes that they are fine with html messages otherwise they would use fixed-width font. > I would like to be able to toggle the underlining and just rely on the > numbering of the headlines. > I'd didn't find anything which seemed relevant here > https://orgmode.org/manual/Export-Settings.html > so is this possible? Is there a (better) alternative? May be send them a html message? > Cheers, > Loris --- WBR, Vladimir Lomov -- To get something clean, one has to get something dirty. To get something dirty, one does not have to get anything clean. signature.asc Description: PGP signature
Re: Where has the manual on one html page gone?
I like it when I just want to read through the whole document with my screen reader, not having to page through it. I also like being able to search the whole document. And, converting it to EPUB allows me to read it on my phone when I'm away from the computer, if I want to. On Tue, Feb 16, 2021 at 10:37:29AM +0100, Marcin borkowski wrote: On 2021-02-15, at 23:45, Nick Dokos wrote: Christine Köhn writes: Hi, I always used the manual online as one html page but it does not seem to be available since (?) the website revamp. I prefer the manual as one page for many reasons. Is it still available online? I've always used the one-page per section version on the web (although I tend to use Info much more often), primarily because I thought that downloading the whole manual to just look at a section or two or five would be inefficient - in fact, I've wondered why the single-page versions of various manuals (particularly the larger ones: emacs and elisp) are made available. So it is idle curiosity on my part, but what are the the reasons for your preference? Converting to an ebook format to read on an ebook reader is one possible use-case. Best, -- Marcin Borkowski http://mbork.pl -- Devin Prater r.d.t.pra...@gmail.com signature.asc Description: PGP signature
Re: How do you name your code blocks?
On Monday, 15 Feb 2021 at 14:18, Rodrigo Morales wrote: > 1. Do you use long names? Yes. Fully qualified and detailed. And then rely on completion to jump to code blocks (using org-babel-goto-named-src-block). -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f
Toggle headline underlining in text export?
Hi, I have an Org file which I export to a text file. A separate program I have written then uses this text file as the body of an email which is sent to a number of people. The problem I have is that the underlining of the headlines is much longer than the headline text itself if a proportional font is used to view the email. As most of the recipients will probably not be using a fixed-width font for their mail clients, I would like to be able to toggle the underlining and just rely on the numbering of the headlines. I'd didn't find anything which seemed relevant here https://orgmode.org/manual/Export-Settings.html so is this possible? Is there a (better) alternative? Cheers, Loris -- This signature is currently under construction.
Re: Where has the manual on one html page gone?
On 2021-02-15, at 23:45, Nick Dokos wrote: > Christine Köhn writes: > >> Hi, >> >> I always used the manual online as one html page but it does not seem to >> be available since (?) the website revamp. I prefer the manual as one >> page for many reasons. Is it still available online? >> > > I've always used the one-page per section version on the web (although > I tend to use Info much more often), primarily because I thought that > downloading the whole manual to just look at a section or two or five > would be inefficient - in fact, I've wondered why the single-page > versions of various manuals (particularly the larger ones: emacs and > elisp) are made available. So it is idle curiosity on my part, but > what are the the reasons for your preference? Converting to an ebook format to read on an ebook reader is one possible use-case. Best, -- Marcin Borkowski http://mbork.pl
Re: Where has the manual on one html page gone?
I'm not the OP, but I find the one-page manual useful when I'm not sure what I'm looking for or where in the manual it might be, makes it easier to search through the whole document iteratively. --Diego On Mon, Feb 15, 2021 at 11:47 PM Nick Dokos wrote: > Christine Köhn writes: > > > Hi, > > > > I always used the manual online as one html page but it does not seem to > > be available since (?) the website revamp. I prefer the manual as one > > page for many reasons. Is it still available online? > > > > I've always used the one-page per section version on the web (although > I tend to use Info much more often), primarily because I thought that > downloading the whole manual to just look at a section or two or five > would be inefficient - in fact, I've wondered why the single-page > versions of various manuals (particularly the larger ones: emacs and > elisp) are made available. So it is idle curiosity on my part, but > what are the the reasons for your preference? > > -- > Nick > > "There are only two hard problems in computer science: cache > invalidation, naming things, and off-by-one errors." -Martin Fowler > > >
