Re: What's up with ob-template.el? It seems heavily outdated

[Nicholas Savage]

Thanks for working on updating the template!

If the worg ob-template.el is broken, I feel like your updates should be 
replacing what is there, even if it isn't perfect yet. I can help you replace 
it if you would like to be contributing your version to improving the 
documentation.

On Wed, May 26, 2021, at 08:07, dalanicolai wrote:
> Ha! Well not too much response here...
> 
> Anyway @Pedro:
> So I do not have too much time to work on an updated template. But I have 
> added a somewhat updated template file to my emacs-lisp repo here 
>  along with some handy tips 
> .
> Then of course you can further just check out examples of other ob-el 
> files. Hope this is useful.

Re: [bug?] changed behaviour of column view

[Nicholas Savage]

Hi Eric,

Thanks for those, that is very helpful. Unfortunately, as you can see in the 
attached screenshot from my system, I can't replicate your issue. Could you 
send me the output of your confirmation, maybe from M-x org-submit-bug-report? 
By chance, would the file you're activating column view on be part of 
org-agenda? Based on your description I doubt it, but just wanted to make sure.

Cheers,
Nick

On Tue, May 11, 2021, at 09:45, Eric S Fraga wrote:
> Hi Nicholas,
> 
> On Tuesday, 11 May 2021 at 09:32, Nicholas Savage wrote:
> > When I activate column view on Headline, it applies the columns on all
> > of the subheadings. Are you not seeing the same thing, or is your use
> > case different? Do you have some sort of minimal file you could
> > provide to show the bug?
> 
> If point is on the first (top-level) headline, I only get the column
> view for that headline and not the subheadings.
> 
> Attached is a small(-ish) file along with a screenshot of what I get.
> 
> The org file consists of the first three papers in a bibliography I have
> (which has hundreds of entries).
> 
> If you are seeing something different, maybe I have some setting that is
> causing problems although I cannot imagine what that would be. Advice
> would be welcome!
> 
> Thank you,
> eric
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd
> 
> Attachments:
> * screendump-20210511144322.png
> * bug.org

Re: [bug?] changed behaviour of column view

[Nicholas Savage]

I believe this would have been some of my commits. That change would not have 
been intended, so I believe this is a bug.

I just tried it out, I have column view applied to something like this:

* Headline
** subheading
** subheading
** subheading
** subheading

When I activate column view on Headline, it applies the columns on all of the 
subheadings. Are you not seeing the same thing, or is your use case different? 
Do you have some sort of minimal file you could provide to show the bug?

On Tue, May 11, 2021, at 09:24, Eric S Fraga wrote:
> Hello all,
> 
> Until recently, I was able to ask for a column view of a headline with
> the column view being applied to each and all of the (visible)
> subheadings.  Now, I can only do either the top heading itself or
> individual subheadings, not all of them.
> 
> I note that there have been changes to org-colview.el in the past week
> or two so maybe something has changed that affects this?  Was the
> previous behaviour wrong in some way?  How do I get that behaviour back?
> 
> Thank you,
> eric
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd
> 
> 

Re: Invalid duration format (9.4.5)

[Nicholas Savage]

Thanks for the report. This was also reported last night too: 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00592.html

I'll probably have a chance to look into this sometime today, but it probably 
won't be until this evening if anyone else has a chance earlier than that.

On Mon, May 10, 2021, at 09:54, Detlef Steuer wrote:
> Am Mon, 10 May 2021 16:45:30 +0300
> schrieb Jarmo Hurri :
> 
> > Greetings.
> > 
> > To get my work done, I had to switch from master branch to stable, but
> > now I started getting "invalid duration format" error when trying to
> > create my daily agenda:
> > 
> > org-duration-to-minutes: Invalid duration format: #("12:45-14:15 +1w"
> > 0 15 (fontified nil org-category "schedule"))
> > 
> > Here is the corresponding row, and the preceding row, from file
> > schedule.org:
> > 
> > <2021-04-15 Thu 09:15-10:45 +1w>
> > <2021-04-19 Mon 12:45-14:15 +1w>
> > 
> > Any hints?
> > 
> > Jarmo
> > 
> > 
> 
> 
> Can confirm!
> 
> Detlef
> 
> 
> -- 
> "Wozu leben wir, wenn nicht dazu, uns gegenseitig das Leben 
>  einfacher zu machen. (George Eliot)" 
> 
> Dr. Detlef Steuer
> Helmut-Schmidt-Universität
> Fakultät WiSo
> Holstenhofweg 85
> 22043 Hamburg
> 
> Tel:  040/6541-2819
> mail: ste...@hsu-hh.de
> 
> 

Re: bug#47088: org-w3m: handle w3m-image link information

[Nicholas Savage]

I have applied it now as commit 5d2ccdae7f in master. Thank you, Boruch!

On Sat, May 8, 2021, at 03:44, Bastien wrote:
> Hi Nick,
> 
> Nick Savage  writes:
> 
> > I haven't opened up the code yet to take a look, but I likely will
> > take a crack at some of these items in the future as low-hanging fruit
> > refactoring project.
> 
> Please feel free to go ahead and enhance ol-w3m.el in Org's repo with
> the patches that Boruch kindly provided---and other enhancements that
> you would find useful.
> 
> Thanks,
> 
> -- 
>  Bastien
> 

Re: babel output seems to drop anything before % (in session)

[Nicholas Savage]

I can confirm this too on the latest master.

I took a quick peek this morning, and my suspicion is that the problem is 
somewhere within org-babel-comint-with-output in lisp/ob-comint.el, but I'm not 
positive at this point.

On Wed, May 5, 2021, at 22:35, John Corless wrote:
> Confirmed
> 
> Daniele,
> 
> I was able to reproduce the behavior you described.  Using the test case...
> 
> #+BEGIN_SRC shell script :results output
> ping -c 1 127.0.0.1
> #+END_SRC
> 
> ... the results output matches what I get in a bash shell.  But if you add 
> the :session to the header args like this...
> 
> #+BEGIN_SRC shell script :results output :session test
> ping -c 1 127.0.0.1
> #+END_SRC
> 
> ... the output line that includes "0% packet loss" gets truncated to after 
> the "%" sign.
> 
> I tested with 9.4.5.
> 
> John
> 
> 
> On Wed, May 5, 2021 at 10:19 AM Daniele Pizzolli  wrote:
>> 
>> Hello,
>> 
>> Try to execute a few times the following and see the output corrupted in
>> the line:
>> 
>> #+BEGIN_EXAMPLE
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> #+END_EXAMPLE
>> 
>> #+PROPERTY: header-args:shell
>> #+PROPERTY: header-args:shell+ :results output verbatim :wrap src text 
>> :session test
>> 
>> #+NAME: ping
>> #+BEGIN_SRC shell
>> ping -c 1 127.0.0.1
>> #+END_SRC
>> 
>> I tried to write a test (now with the :expected-result :failed), that
>> hit the problem both in main and master (applies fine to both).
>> 
>> I was not able to fix it, but hopefully the tests are still useful for
>> somebody more knowledgeable!
>> 
>> Thanks for you suggestion/fix!
>> 
>> Best,
>> Daniele
>> 

Re: org-tables with monetary amounts

[Nicholas Savage]

I don't have anything to answer your questions, but I wanted to chime in that 
this is a feature I'd also like to exist, or find out more about if it already 
does exist.

I'd be definitely willing to help out too code-wise to the extent I can.

Thanks,
Nick

On Tue, Sep 22, 2020, at 10:57, Daniele Nicolodi wrote:
> Hello,
> 
> I often use org-tables to work with monetary amounts. It would be very
> nice to have a couple of functionalities common in this domain:
> 
> - fixed precision arithmetic, namely derive the precision of the results
> from the precision of the arguments (I think that calc can do this),
> 
> - support for parsing numbers followed by currencies,
> 
> - correct alignment for monetary values.
> 
> I had a quick look around, but I haven't found anything that implements
> those things. Has anyone some secret code that they would like to share?
> 
> Thank you!
> 
> Cheers,
> Dan
> 
>

Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Nicholas Savage]

I tried reproducing this, but I am having difficulties. "Baz" and the " - 
State" stayed correctly aligned as I would have expected them, and not as you 
have shown them.

I am on emacs 28.0.50 though so maybe that has made the difference, with org 
compiled from master as of a day or two ago.

Nick

On Mon, Sep 21, 2020, at 15:37, Gustavo Barros wrote:
> Hi All,
> 
> the new release brought the interesting value `headline-data' to the 
> option `org-adapt-indentation'.  However it introduces some issues 
> regarding the indentation of log entries in the `LOGBOOK' drawer, which 
> I describe below.
> 
> An ECM to reproduce the issue is:
> 
> - Start 'emacs -Q'
> 
> - Do an initial setup:
>   #+begin_src emacs-lisp
>   (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
>   ;; This is the latest Org weekly build (Org 9.4)
>   (setq org-adapt-indentation 'headline-data)
>   (setq org-log-into-drawer t)
>   (setq org-todo-keywords '((sequence "TODO(t)" "DONE(d@)")))
>   #+end_src
> 
> - Open file "~/org/test.org", with contents:
>   #+begin_src org
>   ,** Foo
>   #+end_src
> 
> - Change the todo state of "Foo" to "DONE" and add a corresponding note 
>   with "C-c C-t d Baz C-c C-c".
> 
> - After expanding the `LOGBOOK' drawer we find:
>   #+begin_src org
>   ,** DONE Foo
>  :LOGBOOK:
>   - State "DONE"   from  [2020-09-21 Mon 16:19] \\
> Baz
>  :END:
>   #+end_src
> 
>   In which we find that the drawer itself is honoring the setting in 
>   `org-adapt-indentation' whereas the content of the drawer is not.  And 
>   it is expected that it did.
> 
> - After that, move point to the headline and demote it with "" 
>   and examine the buffer again to find:
>   #+begin_src org
>   ,*** DONE Foo
>   :LOGBOOK:
>   - State "DONE"   from  [2020-09-21 Mon 16:19] \\
>   Baz
>   :END:
>   #+end_src
> 
>   We now see the demotion did bring the content of `LOGBOOK' to align 
>   with the headline, but in doing so, broke the plain list structure of 
>   the note, removing the indent of "Baz", which is also not expected.
> 
> 
> Best regards,
> Gustavo.
> 
> 
> 
> 
> Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.20, cairo version 1.16.0)
>  of 2020-08-11
> Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @ 
> /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)
> 
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer 
>  org-src-mode-configure-edit-buffer)
>  org-link-shell-confirm-function 'yes-or-no-p
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook 
>  change-major-mode-hook org-show-all append local] 5]
>#[0 "\300\301\302\303\304$\207"
>  [add-hook change-major-mode-hook 
>  org-babel-show-result-all append local] 5]
>org-babel-result-hide-spec org-babel-hide-all-hashes 
>org-eldoc-load)
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
>  "\n\n(fn ENTRY)"]
>  org-adapt-indentation 'headline-data
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
>  org-babel-header-arg-expand)
>  org-agenda-loop-over-headlines-in-active-region nil
>  org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" 
>  . php) ("C" . c) ("C++" . c++)
> ("asymptote" . asy) ("bash" . sh) ("beamer" 
> . latex) ("calc" . fundamental) ("cpp" . c++)
> ("ditaa" . artist) ("dot" . fundamental) ("elisp" 
> . emacs-lisp) ("ocaml" . tuareg)
> ("screen" . shell-script) ("shell" . sh) ("sqlite" 
> . sql))
>  org-occur-hook '(org-first-headline-recenter)
>  org-log-into-drawer t
>  org-cycle-hook '(org-cycle-hide-archived-subtrees 
>  org-cycle-hide-drawers org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
>  org-todo-keywords '((sequence "TODO(t)" "DONE(d@)"))
>  org-speed-command-hook '(org-speed-command-activate 
>  org-babel-speed-command-activate)
>  org-export-before-parsing-hook '(org-attach-expand-links)
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-link-parameters '(("attachment" :follow org-attach-follow :complete 
>  org-attach-complete-link)
>  ("id" :follow org-id-open) ("eww" :follow 
>  org-eww-open :store org-eww-store-link)
>  ("rmail" :follow org-rmail-open :store 
>  org-rmail-store-link)
>  ("mhe" :follow 

[PATCH] (org-remove-occur-highlights) Implements option to remove highlights between points

[Nicholas Savage]

I realize now that I messed up sending this patch yesterday so it didn't show 
up on updates.orgmode.org. I just wanted to repost it with a correct subject to 
make sure it didn't get lost. My original message follows.

--

I posted earlier about why org-remove-occur-highlights ignored it's options of 
beg and end. I'm fairly sure it was so they could be implemented later. I 
wanted to use this functionality, so I've implemented it. This should not 
change any current behaviour. If beg and end are nil, it will run the same way 
as before. This is called as part of org-sparse-tree, and my changes do not 
affect that. When beg and end are non-nil, it checks which overlays are between 
those two points and deletes them. I've ensured that 'make test' still passes 
and believe I've formatted my changelog entry as required.

If I'm missing something about how this should be working, please let me know.

My copyright paperwork with FSF is currently in progress, but I wanted to put 
this out there to get comments as necessary.

Thanks,
NickFrom 3213a8d50af0a99be43bf1f91c5621a6474548dd Mon Sep 17 00:00:00 2001
From: nick 
Date: Thu, 17 Sep 2020 21:49:43 -0400
Subject: [PATCH] org.el: Implements option to remove highlights between points

* lisp/org.el (org-remove-occur-highlights): Implements BEG and END in
order to allow the option of removing highlights between a range of
points and adjust the shown context.

org-remove-occur-highlights has long had two options, BEG and END,
that were ignored. This change checks first 1) are BEG and END are
nil (as would be expected with the vast majority of current
behaviour)? If yes, there is no change in behaviour. Otherwise, it
removes only the highlights between BEG and END and updates
org-occur-highlights to contain the remaining highlights.
---
 lisp/org.el | 41 -
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 053635c85..f509b8049 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11106,18 +11106,41 @@ match is found."
 (overlay-put ov 'org-type 'org-occur)
 (push ov org-occur-highlights)))
 
-(defun org-remove-occur-highlights ( _beg _end noremove)
+(defun org-remove-occur-highlights ( beg end noremove)
   "Remove the occur highlights from the buffer.
-BEG and END are ignored.  If NOREMOVE is nil, remove this function
-from the `before-change-functions' in the current buffer."
+When BEG and END are set, removes the overlay and hides the items
+between those two points. It does this by going through each overlay
+and comparing whther or not they are within the two points. If BEG and
+END are not set, erases all overlays and sets related variables to
+nil. If NOREMOVE is nil, remove this function from the
+`before-change-functions' in the current buffer."
   (interactive)
   (unless org-inhibit-highlight-removal
-(mapc #'delete-overlay org-occur-highlights)
-(setq org-occur-highlights nil)
-(setq org-occur-parameters nil)
-(unless noremove
-  (remove-hook 'before-change-functions
-		   'org-remove-occur-highlights 'local
+; if only one of BEG and END are set, set both to nil
+(when (or (and beg (not end)) (and (not beg) end))
+  (setq beg nil end nil))
+(cond
+ ((and (not beg) (not end))
+  (mapc #'delete-overlay org-occur-highlights)
+  (setq org-occur-highlights nil)
+  (setq org-occur-parameters nil)
+  (unless noremove
+	(remove-hook 'before-change-functions
+		 'org-remove-occur-highlights 'local)))
+ ((> end beg)
+  (org-overview)
+  (setq temp-overlays '())
+  (dolist (overlay org-occur-highlights)
+	(let ((overlay-point (overlay-start overlay)))
+
+	  (if (and (> overlay-point beg) (< overlay-point end))
+	  (delete-overlay overlay)
+	(progn
+	  (save-excursion
+		(goto-char overlay-point)
+		(org-show-set-visibility 'ancestors)
+		(add-to-list 'temp-overlays overlay))
+  (setq org-occur-highlights temp-overlays)
 
  Priorities
 
-- 
2.20.1

Re: Cycling through TODO workflow joins the next line onto the current one

[Nicholas Savage]

I'm having a hard time reproducing this on the latest master, although it's 
clear from your image that something is going wrong. How are you marking the 
tasks as DONE? When I use C-c C-t to mark them as done, it doesn't add the 
"CLOSED" tag by default under emacs -Q, so I'm wondering if it's something 
about your or the spacemacs configuration that's causing this?

On Sun, Sep 20, 2020, at 02:37, Krishan Kharagjitsing wrote:
> Hello, I found the following weird behaviour. I first reported it to the 
> spacemacs github (https://github.com/syl20bnr/spacemacs/issues/13901) but 
> they confirmed that it is an upstream bug.

> When I set some tasks to DONE and fold the headings with TAB, then when I 
> cycle back from DONE to TODO it joins the next line with the current one.

> 

> org_mode_bug 
> 

> Reproduction guide

>  * Make two TODO headings in org mode
>  * Cycle both TODO items to DONE
>  * Fold the headings (so the dots appear, because the timestamp gets folded 
> with the heading)
>  * Cycle the first DONE heading

> *Observed behaviour:* 
> The next line gets joined on the current one.


> *Expected behaviour:* 
> No joining of lines.

> System Info 

>  * OS: gnu/linux (WSL2, connected via X410 to Windows)
>  * Emacs: 28.0.50 (also tested it on 26.1, same behaviour observed)
>  * Graphic display: t
>  * Distribution: spacemacs
>  * Editing style: vim
>  * Completion: helm
>  * Layers:
> (helm auto-completion emacs-lisp org themes-megapack treemacs)
>  * System configuration features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM 
> DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE 
> HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES 
> THREADS PDUMPER LCMS2

Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Nicholas Savage]

I can reproduce this. I'm on the most recent master with Emacs 28.0.50. Once 
the last line is deleted, org-cycle won't show the "**" line and the minibuffer 
continues to say "FOLDING" instead of cycling through the various states.

On Sat, Sep 19, 2020, at 12:10, B Goodr wrote:
> Hi,
> 
> Still loving Org mode!!  Keep up the good work.
> 
> Here is a bug, though:
> 
> Steps to reproduce:
> 
> Store the following into some .org file (in between the "cut-here" lines):
> 
> ---cut-here---cut-here---cut-here---cut-here---cut-here---cut-here---
> * TODO aaa bbb ccc
> 
> ** TODO aaa bbb ccc
> 
> delete-this-line-to-see-the-problem
> ---cut-here---cut-here---cut-here---cut-here---cut-here---cut-here---
> 
> Move point at first asterisk (beginning of buffer).
> 
> Type TAB key (bound to org-cycle) multiple times and notice it cycles
> the headings through the various levels of exposure.
> 
> Now go to the end of the buffer, and delete the one line there
> containing "delete-this-line-to-see-the-problem", but retain the two
> empty lines at the end.
> 
> Repeat the above steps with the TAB key at the top of the buffer, and
> notice it stops working.
> 
> On the mailing list, I see some recent changes that might or might not
> have broken this. I've not upgraded Org mode in a while:
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00520.html
> 
> Thanks!
> -bgoodr
> 
> 
> 
> Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
>  of 2020-03-26, modified by Debian
> Package: Org mode version 9.4 (9.4-elpaplus @ 
> /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)
> 
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer 
> org-src-mode-configure-edit-buffer)
>  org-link-shell-confirm-function 'yes-or-no-p
>  org-babel-after-execute-hook '(bg-org-babel-after-execute-hook)
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-export-with-sub-superscripts nil
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-refile-targets '((nil :maxlevel . 9) (org-agenda-files :maxlevel . 9))
>  org-html-format-inlinetask-function 
> 'org-html-format-inlinetask-default-function
>  org-odt-format-headline-function 'org-odt-format-headline-default-function
>  org-agenda-files "/home/brentg/Plans/Home/org-agenda-files-list-file.txt"
>  org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
>  org-plantuml-jar-path "/home/brentg/plantuml/plantuml.jar"
>  org-startup-folded nil
>  org-id-link-to-org-use-id t
>  org-mode-hook '(org-tempo-setup org-clock-load bg-org-mode-hook #[0 
> "\301\211 \207" [imenu-create-index-function org-imenu-get-tree] 2]
> #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-show-all 
> append local] 5]
> #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
> org-babel-show-result-all append local] 5] org-babel-result-hide-spec 
> org-babel-hide-all-hashes org-eldoc-load)
>  org-clock-persist t
>  org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-confirm-elisp-link-function 'bg-org-confirm-elisp-link
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3 
> "\n\n(fn ENTRY)"]
>  org-adapt-indentation nil
>  org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-file-apps '((auto-mode . emacs) (directory . emacs) ("\\.mm\\'" . 
> default) ("\\.x?html?\\'" lambda (file link) (browse-url-of-file 
> (expand-file-name file))) ("\\.pdf\\'" . default))
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
> org-babel-header-arg-expand)
>  org-babel-load-languages '((emacs-lisp . t) (python . t) (shell . t) (sqlite 
> . t) (dot . t) (plantuml . t))
>  org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS 
> WIDTH)"]
>  org-agenda-loop-over-headlines-in-active-region nil
>  org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php) 
> ("C" . c) ("C++" . c++) ("asymptote" . asy) ("bash" . sh) ("beamer" . latex) 
> ("calc" . fundamental) ("cpp" . c++) ("ditaa" . artist)
>  ("dot" . fundamental) ("elisp" . emacs-lisp) ("ocaml" . tuareg) 
> ("screen" . shell-script) ("shell" . sh) ("sqlite" . sql))
>  org-occur-hook '(org-first-headline-recenter)
>  org-html-head-include-default-style nil
>  org-html-htmlize-output-type 'css
>  org-export-headline-levels 100
>  org-edit-src-auto-save-idle-delay 5
>  org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
> org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
>  org-todo-keywords '((sequence "TODO(t)" "|" "DONE(d)" "SHELVED(s)" 
> "DELEGATED(e)"))
>  org-speed-command-hook '(org-speed-command-activate 
> org-babel-speed-command-activate)
>  

PATCH: (org-remove-occur-highlights) Implements option to remove highlights between points

[Nicholas Savage]

I posted earlier about why org-remove-occur-highlights ignored it's options of 
beg and end. I'm fairly sure it was so they could be implemented later. I 
wanted to use this functionality, so I've implemented it. This should not 
change any current behaviour. If beg and end are nil, it will run the same way 
as before. This is called as part of org-sparse-tree, and my changes do not 
affect that. When beg and end are non-nil, it checks which overlays are between 
those two points and deletes them. I've ensured that 'make test' still passes 
and believe I've formatted my changelog entry as required.

If I'm missing something about how this should be working, please let me know.

My copyright paperwork with FSF is currently in progress, but I wanted to put 
this out there to get comments as necessary.

Thanks,
NickFrom 3213a8d50af0a99be43bf1f91c5621a6474548dd Mon Sep 17 00:00:00 2001
From: nick 
Date: Thu, 17 Sep 2020 21:49:43 -0400
Subject: [PATCH] org.el: Implements option to remove highlights between points

* lisp/org.el (org-remove-occur-highlights): Implements BEG and END in
order to allow the option of removing highlights between a range of
points and adjust the shown context.

org-remove-occur-highlights has long had two options, BEG and END,
that were ignored. This change checks first 1) are BEG and END are
nil (as would be expected with the vast majority of current
behaviour)? If yes, there is no change in behaviour. Otherwise, it
removes only the highlights between BEG and END and updates
org-occur-highlights to contain the remaining highlights.
---
 lisp/org.el | 41 -
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 053635c85..f509b8049 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11106,18 +11106,41 @@ match is found."
 (overlay-put ov 'org-type 'org-occur)
 (push ov org-occur-highlights)))
 
-(defun org-remove-occur-highlights ( _beg _end noremove)
+(defun org-remove-occur-highlights ( beg end noremove)
   "Remove the occur highlights from the buffer.
-BEG and END are ignored.  If NOREMOVE is nil, remove this function
-from the `before-change-functions' in the current buffer."
+When BEG and END are set, removes the overlay and hides the items
+between those two points. It does this by going through each overlay
+and comparing whther or not they are within the two points. If BEG and
+END are not set, erases all overlays and sets related variables to
+nil. If NOREMOVE is nil, remove this function from the
+`before-change-functions' in the current buffer."
   (interactive)
   (unless org-inhibit-highlight-removal
-(mapc #'delete-overlay org-occur-highlights)
-(setq org-occur-highlights nil)
-(setq org-occur-parameters nil)
-(unless noremove
-  (remove-hook 'before-change-functions
-		   'org-remove-occur-highlights 'local
+; if only one of BEG and END are set, set both to nil
+(when (or (and beg (not end)) (and (not beg) end))
+  (setq beg nil end nil))
+(cond
+ ((and (not beg) (not end))
+  (mapc #'delete-overlay org-occur-highlights)
+  (setq org-occur-highlights nil)
+  (setq org-occur-parameters nil)
+  (unless noremove
+	(remove-hook 'before-change-functions
+		 'org-remove-occur-highlights 'local)))
+ ((> end beg)
+  (org-overview)
+  (setq temp-overlays '())
+  (dolist (overlay org-occur-highlights)
+	(let ((overlay-point (overlay-start overlay)))
+
+	  (if (and (> overlay-point beg) (< overlay-point end))
+	  (delete-overlay overlay)
+	(progn
+	  (save-excursion
+		(goto-char overlay-point)
+		(org-show-set-visibility 'ancestors)
+		(add-to-list 'temp-overlays overlay))
+  (setq org-occur-highlights temp-overlays)
 
  Priorities
 
-- 
2.20.1

org-remove-occur-highlight ignores BEG and END

[Nicholas Savage]

I've been exploring a bit of the code base for Org Mode and I stumbled upon 
something I wanted to ask the wider community about. I've googled already and 
didn't find anything. `org-remove-occur-highlight' in org.el takes two optional 
parameters (alongside a third) BEG and END, but the documentary states that 
they are ignored. I can see in the code as well that they have no purpose. What 
is the reasoning for this? The only thing I can think of that could explain it 
is if the optional parameters are there as placeholders so in the future if 
they are implemented code that uses `org-remove-occur-highlight' doesn't break 
since it is assuming the parameters are nil.

Am I on the right track here?

If so, I'm going to take a crack at implementing BEG and END, since I want that 
functionality for my own personal todo system that might end up with some 
improvements on Org's end.

Re: strange bug after a fresh install

[Nicholas Savage]

Are you using ob-ipython? Your trace makes it seem like that might be loaded 
maybe in your init files. This issue seems to cover the problem you are having, 
since it says that it's modifying `org-mode-hook'.

https://github.com/gregsexton/ob-ipython/issues/161

Maybe since you have a clean install you're missing jupyter while you weren't 
before?

On Wed, Sep 16, 2020, at 16:56, Uwe Brauer wrote:
> Hi
> 
> I freshly installed Ubuntu 20.04 and used the pre compiled Emacs 26, I
> copies also all my init files.
> 
> When I open an org file I obtain an error message I don't understand and
> attach any help is appreciated
> 
> Regards
> 
> Uwe Brauer 
> 
> 
> Attachments:
> * bug

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[Nicholas Savage]

Hi there,

I'm new to the development scene (contributed my first patch to Emacs last week 
or so) and a new developer in general who has been looking to get involved. I 
saw Bastien's post on Hacker News yesterday and thought that if Org Mode is 
looking for contributors it would be a good place for me, since I use Org Mode 
frequently. I have a rudimentary understanding of elisp, but I'm looking to 
improve by actually contributing.

I'm just wondering about some of these ideas, mostly from an administrative 
point of view. I think they're fantastic ideas, such as moving code from Org 
Mode back up to Outline mode. I'm just looking to wrap my head around how this 
is supposed to work (I already understand submitting patches and can read the 
READMEs, so don't worry about that).

If I am looking to do that though, would I be submitting a patch both to Emacs 
and one to Org Mode? At what point are Org Mode commits merged into Emacs? I 
guess my concern is that these changes could be breaking for users of Org Mode 
if they're not also using the most recent master of Emacs as well.

Nick

On Tue, Sep 15, 2020, at 06:05, William Rankin via General discussions about 
Org-mode. wrote:
> Hello,
> 
> At the request of Bastien I'm sending on these ideas regarding the 
> future of Org Mode development. I'm also copying emacs-devel since they 
> might be interested too.
> 
> Org Mode and Emacs would benefit greatly from the codebase being broken 
> apart, not unlike how an antitrust suit breaks apart a big company for 
> the good of society!
> 
> It is my view that many parts of Org code could be implemented as minor 
> modes or independent libraries. This would encourage cleaner, more 
> modular and more easy to understand code. It would provide an 
> exponential benefit for other elisp programs. And by splitting up the 
> codebase you allow contributors more a sense of ownership and emotional 
> investment in the things to which they provide their time/effort.
> 
> A few suggestions...
> 
> * outline
> 
> Org Mode builds on top of outline, but those improvements are isolated 
> to Org, e.g. Org has wonderful outline cycling, but if someone wants 
> outline cycling in another major mode they need to implement this again 
> (likely just duplicating Org's existing code). Ideally all of this could 
> be ported back to outline itself. This would slim down the Org codebase 
> while benefiting all other outline-based major modes.
> 
> * orgtbl-mode
> 
> This is a good attempt at implementing some of Org's functionality as a 
> minor mode. Ideally orgtbl could be ported back to table and enough 
> flexibility added to make it compatible with Markdown Mode tables 
> (currently implemented with its own table stuff).
> 
> * source blocks
> 
> Org's source block functionality could be spun off into its own library. 
> In theory it could work just like outline (where a major mode defines 
> its own heading regexp). A major mode would define its own source block 
> delimiter regexpes.
> 
> Ideally any major mode writing for a plain text markup format would 
> just:
>   (require 'source-blocks)
> then have all the same functionality of Org source blocks. Any 
> improvements would then benefit everyone.
> 
> * org-toggle-time-stamp-overlays / org-toggle-link-display
> 
> This functionality, although small within Org, could be very nice as 
> their own minor modes. Displaying dates/times with custom format is easy 
> enough... URLs a bit harder.
> 
> I went so far as to try this with varying degrees of success:
> https://github.com/rnkn/prettify-date-time-mode
> https://github.com/rnkn/prettify-url-mode
> 
> * org-link
> 
> I see a lot of interest for that Zettelkasten method, with many 
> different implementations. What's stopping Org's cross-linking being 
> implemented as its own global minor mode, independent of .org files?
> 
> * electric-pair-mode
> 
> Org currently uses org-emphasize for its emphasis pairs, but could it 
> just use electric-pair-mode? Would this prompt some improvements to 
> electric-pair-mode? This would benefit everyone.
> 
> 
> I don't mean to suggest that the above ideas are things I'm particularly 
> hanging out for, I'm just trying to sketch an ideas of beneficial ways 
> Org could be broken apart.
> 
> Finally, I'm pretty sure breaking apart Org will mean it will be much 
> easier to maintain -- it will be far easier to find one or two people 
> passionate about maintaining perhaps a source-blocks library than the 
> entirety of Org. If Org's development takes this more modular direction, 
> where libraries are designed to work independently of the rest of the 
> code, then it won't need an elite few people who understand the whole 
> codebase.
> 
> I hope some of these ideas were either valuable or provide valuable 
> discussion.
> 
> -- 
> William Rankin
> https://bydasein.com
> 
> ~ The single best thing you can do for the world is to delete your 
> social media accounts.
> 
>