Re: [O] OK again, was: Re: Bug: git clone https://code.orgmode.org/bzg/org-mode.git fails with fatal: unable to access 'https://code.orgmode.org/bzg/org-mode.git/': server certificate verification fai

[Brent Goodrick]

Thanks Robert.  Everything is working perfectly now!

On Sun, Aug 19, 2018 at 9:51 AM, Robert Klein  wrote:

> Hi Brent,
>
> On Sun, 19 Aug 2018 08:32:27 -0700
> Brent Goodrick  wrote:
>
> >
> > I noted that even browsing to the website at https://orgmode.org
> > required me to add a certificate exception to my browser.
>
> [rest deleted]
>
> thanks a lot for the information.
>
> It seems the certificate for the web site expired.  I managed to renew
> the certificate, so everything should work again as expected.
>
> The automatic renewal of certificates doesn't work at the moment, so we
> might encounter the issue again in a couple of months.
>
> I'll try to find a solution in the meantime.
>
> Best regards
> Robert
>
>
>

[O] Bug: git clone https://code.orgmode.org/bzg/org-mode.git fails with fatal: unable to access 'https://code.orgmode.org/bzg/org-mode.git/': server certificate verification failed. CAfile: /etc/ssl/c

[Brent Goodrick]

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.

This is not a bug with org-mode but seems to be a configuration
problem with the website and/or the underlying git server there:

As of Sun Aug 19 08:27:11 PDT 2018 the clone operation on my Ubuntu
18.04 laptop fails with:

nunyabidness@oryx:/tmp/org-mode.direct$ git clone 
https://code.orgmode.org/bzg/org-mode.git
Cloning into 'org-mode'...
fatal: unable to access 'https://code.orgmode.org/bzg/org-mode.git/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none
nunyabidness@oryx:/tmp/org-mode.direct$

I've updated my hosts CA's via the instructions found at
https://stackoverflow.com/a/35824116/257924 to no avail.

I checked my system time is constantly up to date, so it is not a NTP
issue.

I noted that even browsing to the website at https://orgmode.org
required me to add a certificate exception to my browser.

I originally did a git pull in order to get my local installed copy of
org-mode up to date, and got the same error, so I'm reporting the 'git
clone' command above into a /tmp directory just to be sure it is not
due to something I've fouled up in my normal directory.


Emacs  : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-09-22, modified by Debian
Package: Org mode version 9.1.7 (release_9.1.7-523-g594b2d @ 
/home/nunyabidness/emacs_lisp_imported/org-mode/org-mode/lisp/)

current state:
==
(setq
 org-id-locations-file "/home/nunyabidness/that_org_dir/.org-id-locations"
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 outline-minor-mode-hook '(wikipedia-outline-magic-keys (lambda nil (require 
(quote outline-magic
 org-clock-persist-file "/home/nunyabidness/that_org_dir/org-clock-save.el"
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-id-link-to-org-use-id t
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-clock-idle-time 10
 org-startup-folded nil
 org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default)
 ("\\.x?html?\\'" lambda (file link) (browse-url-of-file 
(expand-file-name file))) ("\\.pdf\\'" . default))
 org-tab-before-tab-emulation-hook '(org-tempo-complete-tag)
 org-export-with-sub-superscripts nil
 org-return-follows-link t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-default-notes-file "/home/nunyabidness/that_org_dir/notes.org"
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-html-head-include-default-style nil
 org-mode-hook '(org-tempo-setup org-clock-load bg-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-refile-targets '((nil :maxlevel . 9) (org-agenda-files :maxlevel . 9))
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ascii-format-drawer-function #[771 "
\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-clock-persist t
 org-refile-use-outline-path 'file
 org-directory "/home/nunyabidness/that_org_dir"
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines 
org-optimize-window-after-visibility-change)
 org-plantuml-jar-path "/home/nunyabidness/plantuml/plantuml.jar"
 org-edit-src-auto-save-idle-delay 5
 org-todo-keywords '((sequence "TODO(t)" "|" "DONE(d)" "SHELVED(s)" 
"DELEGATED(e)"))
 org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el") ("elisp" 
. "el"))
 org-confirm-elisp-link-function 'bg-org-confirm-elisp-link
 org-html-htmlize-output-type 'css
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 outline-mode-hook '((lambda nil (require 

Re: [O] git://orgmode.org/org-mode.git --> g...@code.orgmode.org:bzg/org-mode.git : Now password is required

[Brent Goodrick]

Thanks!

On Thu, Apr 26, 2018 at 4:34 PM, Bastien  wrote:

> Hi Brent,
>
> https cloning is for users who just want to git pull:
> https://code.orgmode.org/bzg/org-mode.git
>
> git:// cloning is for developers with a username on code.orgmode.org:
> git clone git://code.orgmode.org/bzg/org-mode.git
>
> HTH,
>
> --
>  Bastien
>

Re: [O] Bug: Prevent fill-paragraph from breaking inside Org mode links [9.1.9 (release_9.1.9-580-g39837b @ /home/drunkard/emacs_lisp_imported/org-mode/org-mode/lisp/)]

[Brent Goodrick]

Hi Nicolas,

All of that sounds reasonable.  Thanks for the reply.

-Brent



On Sun, Apr 8, 2018, 9:43 AM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:

> Hello,
>
> Brent Goodrick <bgo...@gmail.com> writes:
>
> > First, it may be a separate "bug" that org-return cannot recognize the
> > multi-line Org link.
>
> Fixed. Thank you.
>
> > I don't know one way or the other for that, but instead I am arguing
> > that org mode's fill paragraph function should never break the line
> > right in the middle of the link.
>
> I disagree. Link descriptions can be arbitrarily long and Org should be
> able to fill them. We could improve the fontification, however (e.g.,
> not using link face on blanks at the beginning of a line).
>
> > Instead the whole link should be treated as a word. To illustrate the
> > fix, I have appended my own function to `fill-nobreak-predicate' to
> > prevent the breakages
>
> I think this is the way to go: prevent filling in your own config.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

[O] Bug: Prevent fill-paragraph from breaking inside Org mode links [9.1.9 (release_9.1.9-580-g39837b @ /home/drunkard/emacs_lisp_imported/org-mode/org-mode/lisp/)]

[Brent Goodrick]

This is not a new bug. It has been there for a long time, but I am
only just now getting around to reporting it. I am also proposing a
fix below.

How to reproduce:

Open up a Org mode file and add the following item to it:

 1. Now is the time for all good men and women to 
[[id:269cedb3-9a50-4de9-9696-f8297c18a75a][come to the aid of their KEG PARTY]]

Ensure you have run `org-toggle-link-display' to show the "descriptive
display" of links, not the literal display that might show up in your
email view of the above line (e.g., the
"[id:269cedb3-9a50-4de9-9696-f8297c18a75a]" part will not show up in the
"descriptive" link display mode).

Move point to the "a" in "aid", and type C-x f (set-fill-column) to
set the fill column to 62.

Place point anywhere inside the above line after the "1. " (e.g. at
the "g" in "good").

Type M-x org-fill-paragraph.

The result is

 1. Now is the time for all good men and women to 
[[id:269cedb3-9a50-4de9-9696-f8297c18a75a][come to the
aid of their KEG PARTY]]

Not only is the above result visually jarring (see
https://i.imgur.com/HnY70le.png for an annotated screenshot) when in
"descriptive link" display mode, it also breaks `org-return', as
follows:

Move the point to the "g" in "good" in the line above.  Type M-x
org-next-link to got to that first link, then type M-x org-return. The
result is an insertion of a newline, resulting in:

 1. Now is the time for all good men and women to 
[[id:269cedb3-9a50-4de9-9696-f8297c18a75a][come to the aid of
their KEG PARTY]]

when I expect it to navigate to the heading upon which is associated
with "id:269cedb3-9a50-4de9-9696-f8297c18a75a".

Here is my proposed fix:

First, it may be a separate "bug" that org-return cannot recognize the
multi-line Org link. I don't know one way or the other for that, but
instead I am arguing that org mode's fill paragraph function should
never break the line right in the middle of the link. Instead the
whole link should be treated as a word.  To illustrate the fix, I have
appended my own function to `fill-nobreak-predicate' to prevent the
breakages, but taking hints from `org-setup-filling' which does
similar things for other areas of Org mode buffers:

(defun bg-org-fill-paragraph-with-link-nobreak-p ()
  "Do not allow `fill-paragraph' to break inside the middle of Org mode links."
  (and (assq :link (org-context)) t))

(defun bg-org-fill-paragraph-config ()
  "Configure `fill-paragraph' for Org mode."
  ;; Append a function to fill-nobreak-predicate similarly to how org-mode does
  ;; inside `org-setup-filling':
  (when (boundp 'fill-nobreak-predicate)
(setq-local
 fill-nobreak-predicate
 (org-uniquify
  (append fill-nobreak-predicate
  '(bg-org-fill-paragraph-with-link-nobreak-p))

And then run bg-org-fill-paragraph-config from my `org-mode-hook'
function.

The fix I propose is to change `org-setup-filling' to do the above.

Thanks,
Brent




Emacs  : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-09-22, modified by Debian
Package: Org mode version 9.1.9 (release_9.1.9-580-g39837b @ 
/home/drunkard/emacs_lisp_imported/org-mode/org-mode/lisp/)

current state:
==
(setq
 org-id-locations-file "/home/drunkard/Plans/Home/.org-id-locations"
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 outline-minor-mode-hook '(wikipedia-outline-magic-keys (lambda nil (require 
(quote outline-magic
 org-clock-persist-file "/home/drunkard/Plans/Home/org-clock-save.el"
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-id-link-to-org-use-id t
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-clock-idle-time 10
 org-startup-folded nil
 org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" 
browse-url-of-file (expand-file-name file))
 ("\\.pdf\\'" . default))
 org-tab-before-tab-emulation-hook '(org-tempo-complete-tag)
 org-export-with-sub-superscripts nil
 org-return-follows-link t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-default-notes-file "/home/drunkard/Plans/Home/notes.org"
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 

Re: [O] Removing ding each time I type TAB when not after a structure template with org-tempo enabled

[Brent Goodrick]

Hi Nicolas,

Thanks. This is close, but not completely fixed: When I have the point at
the start of a line in a Org file, and type the TAB key, it does not move
like it should up underneath the prior heading. See annotated screenshot:

https://i.imgur.com/zUH28W0.png

I'll have to re-instate my workaround for now.

Thanks for the help!

Brent


On Sun, Feb 11, 2018 at 3:05 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Brent Goodrick <bgo...@gmail.com> writes:
>
> > In this new version, I discovered that structure templates were not
> > enabled by default, so I enabled them. But to my chagrin, I found that
> > I get a "ding" each time I type the TAB key when on a blank line that
> > is _not_ right after a structure template such as "<e".
> >
> > Below is my hackaround, but can someone take a look into arranging it
> > so that is not the default to ding if tempo-complete-tag cannot find
> > anything to complete, and thus I can remove my hack?
> >
> > Just passing silent to it will actually break TABing over (normal tab
> > meaning) in Org buffers, so the obvious fix won't work.  (ding)
> > returns nil which it must so that the hook works as expected.
>
> Fixed. Thank you.
>
> >   ;; Enable Structure templates that at one point were by default
> enabled in Org
> >   ;; mode, but someone changed that for some reason, so re enable it.
>
> There is another structure template expansion mechanism enable by
> default. You may want to try `C-c C-x C-w'.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Broken links on orgmode.org site that point to Gmane

[Brent Goodrick]

Cool!!

On Feb 11, 2018 5:19 AM, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote:

> Hello,
>
> Brent Goodrick <bgo...@gmail.com> writes:
>
> > At Sat Feb  3 12:27:14 PST 2018, I navigated to
> >
> > https://orgmode.org/community.html
> >
> > then saw "Browse it through Gmane" which has a link to:
> >
> > http://news.gmane.org/gmane.emacs.orgmode
> >
> > Clicking on that link gave a Page Not found error.
>
> Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

[O] Removing ding each time I type TAB when not after a structure template with org-tempo enabled

[Brent Goodrick]

Hi:

I recently upgraded to org from Git. Thus, org-version for me returns:

Org mode version 9.1.6 (release_9.1.6-425-gd89e35 @
/home/brentg/emacs_lisp_imported/org-mode/org-mode/lisp/)

In this new version, I discovered that structure templates were not
enabled by default, so I enabled them. But to my chagrin, I found that
I get a "ding" each time I type the TAB key when on a blank line that
is _not_ right after a structure template such as "

[O] git://orgmode.org/org-mode.git --> g...@code.orgmode.org:bzg/org-mode.git : Now password is required

[Brent Goodrick]

Hi,

Short summary to bypass the TL;DR below: In order for me to do a 'git
pull' into an existing local repo only for 'read-only' mode (not
contributing changes back), I had to change my .git/config from:

[remote "official"]
url = git://orgmode.org/org-mode.git
fetch = +refs/heads/*:refs/remotes/official/*

to

[remote "official"]
url = https://code.orgmode.org/bzg/org-mode.git
fetch = +refs/heads/*:refs/remotes/official/*

Only after doing that could I do a 'git pull' without errors or
password promptings.

Maybe that is the way it is intended to work, but the instructions on
the website imply it should work without any password requirement
using the "git:" method and not the "https:" method.  So I'm reporting
this just in case there is some server issue, versus user error on my
part.


--
TL;DR: detail:

I have local clone of org-mode from long ago that I'm needing to
update again. My .git/config file contains:

[remote "official"]
url = git://orgmode.org/org-mode.git
fetch = +refs/heads/*:refs/remotes/official/*
[branch "master"]
remote = official
merge = refs/heads/master

I tried doing a 'git fetch' today and it gave me:

fatal: unable to connect to orgmode.org:
orgmode.org[0: 45.77.206.30]: errno=Connection refused

So I looked on the main website at https://orgmode.org/ and it showed
that something had changed w.r.t. where to clone from which is:

g...@code.orgmode.org:bzg/org-mode.git

But cloning from that requires a password:

$ git clone g...@code.orgmode.org:bzg/org-mode.git
Cloning into 'org-mode'...
g...@code.orgmode.org's password:

Why is a password now required just to clone the repo? Note that this
is separate from the need to push back into that repo, so my
expectation is to be able to clone and use separate from committing
changes back to the "official" master, all by using the normal "git:"
method that is indicated as preferred on
https://orgmode.org/worg/org-contribute.html (and I realized that is
for contributing, but the main site still has the "git:" form listed
with no indication that a password ritual is needed).


Regards,
Brent

[O] Broken links on orgmode.org site that point to Gmane

[Brent Goodrick]

Hi Org Mode:

At Sat Feb  3 12:27:14 PST 2018, I navigated to

https://orgmode.org/community.html

then saw "Browse it through Gmane" which has a link to:

http://news.gmane.org/gmane.emacs.orgmode

Clicking on that link gave a Page Not found error.

Regards,
bgoodr

Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers

[Brent Goodrick]

On Sat, Apr 29, 2017 at 2:59 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Brent Goodrick <bgo...@gmail.com> writes:
>
>> I do not understand what is meant by "tailored for the source" which
>> is the Org buffer. All of the indentation changes being made here are
>> within the temporary buffer created by with-temp-buffer, which is
>> using fundamental-mode which is not the same as either emacs-lisp-mode
>> or org-mode. That is the wrong mode to be in when running `indent-line-to`
>> function since it is that particular editing mode that the user has
>> control over the `indent-tabs-mode` variable (typically from mode hook
>> functions). So I conclude that the temporary buffer, at that point in
>> execution, has to be in the mode of the language used when indenting.
>
> This is not necessary. `org-src--contents-for-write-back' merely adds up
> indentation to the existing one.

Agreed.

> In particular, it doesn't re-indent
> lines. The indentation being added depends on Org mode (was the block in
> a list? Is it a src block where special indentation rules apply...), not
> on the major mode from the edit buffer.
>
> However, you have a point, as we need to somehow retain the values of
> `indent-tabs-mode' and `tab-width' from Org source buffer, since those
> may differ from the ones used in the temporary buffer.
>
> Also, calling `org-mode' again in the temporary buffer, in addition to
> being slow,

Yes, I wondered about the performance impact. Agreed.

> wouldn't preserve, e.g., local values from the source
> buffer. So I think the best thing to do is to store `indent-tabs-mode'
> and `tab-width' from source buffer and apply them back into the
> temporary buffer.
>
> I committed a change along those lines, along with tests, in the maint
> branch. Does it fix the issues you were encountering?

It works splendidly!

Thanks Nicolas.
--Brent

Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers

[Brent Goodrick]

On Thu, Apr 27, 2017 at 4:04 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> Brent Goodrick <bgo...@gmail.com> writes:
>
> > In the current implementation of org-src--contents-for-write-back, the
> > `with-temp-buffer` uses fundamental-mode.
>
> Correct.
>
> > Later, while inside that temp buffer, spaces are inserted in to indent
> > the entire source block over to where it needs to be (in my original
> > post, notice that I have the source block within a list item so the
> > source block needs to be aligned properly under that list item, no
> > matter to what depth that list item is).
>
> Correct.
>
> > It is in mode hook functions that certain changes to indentation can
> > occur, so that is why I'm switching into that mode.
>
> This is where I don't follow you. At this point, indentation changes are
> tailored for the source, i.e., Org, buffer. Special indentation rules
> from the source block mode do not apply here.

I do not understand what is meant by "tailored for the source" which
is the Org buffer. All of the indentation changes being made here are
within the temporary buffer created by with-temp-buffer, which is
using fundamental-mode which is not the same as either emacs-lisp-mode
or org-mode. That is the wrong mode to be in when running `indent-line-to`
function since it is that particular editing mode that the user has
control over the `indent-tabs-mode` variable (typically from mode hook
functions). So I conclude that the temporary buffer, at that point in
execution, has to be in the mode of the language used when indenting.

> > But that is not enough: In order for the text to be aligned properly
> > inside the org mode buffer after indentation, there cannot be a mix of
> > tabs and spaces, as shown in my original post. IIRC, `indent-to' is
> > called within the `write-back' function, and `indent-to' is affected
> > by the `indent-tabs-mode' value, which by default in emacs lisp mode
> > buffers, is t.
>
> You cannot set `indent-tabs-mode' to nil and discard user's
> configuration. What if I want it to be non-nil in Org buffers?

I agree with that. I now see that what I proposed earlier is a not a
solution for that reason. So I have a further suggested change below.

Also I mistakenly referred to `indent-to` when the function is actually
`indent-line-to`.

> Another option is to delete any leading indentation and indent it again
> according to `indent-tabs-mode' value in source buffer.

By "in source buffer", do you mean that after the text is inserted
into the Org mode buffer, the code then reindents it again, while the
current mode in that buffer is org-mode (i.e., no longer inside the
temporary buffer, which is fundamental-mode)? If that is the
interpretation, then how is Org mode to know about the syntax of emacs
lisp code? I think it won't and it will indent the emacs lisp code
without proper handling of parens. In fact I played with that a bit
and it is also not going to work (yields left justified text since
fundamental mode knows nothing the parens in Emacs lisp).

Here is my somewhat improved fix. I'm still switching into the
original language mode inside the temp buffer.

(defun org-src--contents-for-write-back ()
  "Return buffer contents in a format appropriate for write back.
Assume point is in the corresponding edit buffer."
  (let ((indentation (or org-src--block-indentation 0))
(preserve-indentation org-src--preserve-indentation)
(contents (org-with-wide-buffer (buffer-string)))
(write-back org-src--allow-write-back))
(let ((orig-major-mode major-mode))
  (with-temp-buffer
(insert (org-no-properties contents))
;; CHANGE: Switch into the mode of the language that was being edited so
;; that `indent-tabs-mode` will be respected:
(funcall orig-major-mode)
(goto-char (point-min))
(when (functionp write-back)
  ;; CHANGE: Hack to allow stepping through through this function in
  ;; edebug: I commented out this line:
  ;;
  ;;   (funcall write-back)
  ;;
  ;; and inlined the value of write-back here and reindented for
  ;; readability:
  (when (> org-edit-src-content-indentation 0)
(while (not (eobp))
  (unless (looking-at "[ ]*$")
(indent-line-to (+ (org-get-indentation)
org-edit-src-content-indentation)))
  (forward-line
;; CHANGE: Switch into org-mode so that `indent-tabs-mode` in org mode
;; buffers will also be respected:
(org-mode)
(unless (or preserve-indentation (= indentation 0))
  (let ((ind (make-string indentation ?\s)))
(goto-char (point-min))
(while (not (eobp))
   

Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers

[Brent Goodrick]

On Sat, Apr 22, 2017 at 1:41 AM, Nicolas Goaziou  wrote:
>
> > The bug is in the `org-src--contents-for-write-back' function. It
> > uses a temp buffer. The temp buffer's major-mode is left to be
> > the default, which is fundamental-mode, which knows nothing about
> > how to indent lisp code properly.
>
> And it doesn't need to. This function doesn't care about the code, but
> indents it rigidly according to original source block.  IOW, I don't
> think changing the major mode is required.
>
> > So in the fix below, I run the major-mode function from the original
> > buffer. But even with that fix, the indentation must also use spaces
> > in order to avoid mixing tabs and spaces in the resulting Org buffer.
>
> Why do you think it is a good thing that tabs and spaces shouldn't be
> mixed. For example, imagineh that the source code requires
> `indent-tabs-mode' being non-nil, but Org source buffer indentation is
> space only, i.e., with `indent-tabs-mode' being nil.

Thanks for looking into this!

In the current implementation of org-src--contents-for-write-back, the
`with-temp-buffer` uses fundamental-mode.  Later, while inside that
temp buffer, spaces are inserted in to indent the entire source block
over to where it needs to be (in my original post, notice that I have
the source block within a list item so the source block needs to be
aligned properly under that list item, no matter to what depth that
list item is). It is in mode hook functions that certain changes to
indentation can occur, so that is why I'm switching into that
mode. But that is not enough: In order for the text to be aligned
properly inside the org mode buffer after indentation, there cannot be
a mix of tabs and spaces, as shown in my original post. IIRC,
`indent-to' is called within the `write-back' function, and
`indent-to' is affected by the `indent-tabs-mode' value, which by
default in emacs lisp mode buffers, is t.

You might try my implementation both without the change to
`indent-tabs-mode' to see how improperly indented the resulting source
block looks.

>
> Shouldn't the resulting block be indented with spaces from column 0 to
> block boundaries' indentation, and then follow with space indentation?
>

Yes, if I understand what you are meaning. In fact, I think that is,
in effect, what my replacement function is doing.  Basically the
bottom line is that you can't mix tabs and spaces in the final Org
buffer and have it look correctly indented in that buffer, and the
change to indent-tabs-mode to nil will be buffer local inside that
with-temp-buffer so nothing is affected in any other buffer.

For your reference, below is my replacement function that has
elaborated comments that hopefully clarify things a bit more:

(defun org-src--contents-for-write-back-fix-indentation ()
  "Return buffer contents in a format appropriate for write back.
Assume point is in the corresponding edit buffer."
  (let ((indentation (or org-src--block-indentation 0))
(preserve-indentation org-src--preserve-indentation)
(contents (org-with-wide-buffer (buffer-string)))
(write-back org-src--allow-write-back))
;; --- BEGIN CHANGES FROM ORIGINAL DEFINITION ---
;;
;; Save off the original mode into orig-major-mode:
;;
(let ((orig-major-mode major-mode))
  (with-temp-buffer
;;
;; Insert the contents as was done before:
;;
(insert (org-no-properties contents))
;;
;; First change: Switch to the original mode for indentation by
;; switching its mode to be the original one. This is because that mode
;; handles mode-specific indentation behavior:
;;
(funcall orig-major-mode)
;;
;; Second change: Do not use tabs here. If the mode being switched to
;; has indent-tabs-mode set to t, that is fine for separate buffers, but
;; for when org source blocks are shown in Org buffers, mixing tabs and
;; spaces will mess up the view (see this for emacs lisp code blocks
;; when indent-tabs-mode is set to t) when write-back calls `indent-to'.
;;
;; The alternative is to require everyone to set indent-tabs-mode to nil
;; in their mode hooks for all modes used in Org mode, but that seems
;; slightly heavy-handed.
;;
(setq indent-tabs-mode nil)
;; --- END CHANGES FROM ORIGINAL DEFINITION ---
(goto-char (point-min))
(when (functionp write-back) (funcall write-back))
(unless (or preserve-indentation (= indentation 0))
  (let ((ind (make-string indentation ?\s)))
(goto-char (point-min))
(while (not (eobp))
  (when (looking-at-p "[ \t]*\\S-") (insert ind))
  (forward-line
(buffer-string)

I am curious to see if there is a better fix that what I've coded up above.

Thanks again for your help,
-Brent

[O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers

[Brent Goodrick]

Hi,

I found a bug in org-mode where emacs-lisp code that is in a
already-indented source block in an org-mode buffer is improperly
indented when editing it via C-c '. Take the following contrived
example emacs-lisp source code:

 1. Here is a list item with a emacs-lisp source block:
#+BEGIN_SRC emacs-lisp :results value
  (let ((uuid "c2327c73-6da3-4421-8bda-194783a00e8f"))
(progn
  (let ((xxx 'yyy))
(let ((xxx 'yyy))
  (while t
(message "infinite loop"))
#+END_SRC

After C-c ', indenting it, and C-c ' again, it renders as
follows (tabs converted to spaces for this email, since I have
`indent-tabs-mode' set to t in my emacs-lisp mode, which
is the Emacs default):

 1. Here is a list item with a emacs-lisp source block:
#+BEGIN_SRC emacs-lisp :results value
  (let ((uuid "c2327c73-6da3-4421-8bda-194783a00e8f"))
(progn
  (let ((xxx 'yyy))
(let ((xxx 'yyy))
  (while t
(message "infinite loop"))
#+END_SRC

Notice how the indentation looks bad due to the mixture of tabs
and spaces.

The bug is in the `org-src--contents-for-write-back' function. It
uses a temp buffer. The temp buffer's major-mode is left to be
the default, which is fundamental-mode, which knows nothing about
how to indent lisp code properly. So in the fix below, I run the
major-mode function from the original buffer. But even with that
fix, the indentation must also use spaces in order to avoid
mixing tabs and spaces in the resulting Org buffer.  My fix,
shown below, is to initialize the major-mode, and set
`indent-tabs-mode' to nil, before it runs the `write-back'
code.

See "CHANGE" comments for the changes made:

(defun org-src--contents-for-write-back ()
  "Return buffer contents in a format appropriate for write back.
Assume point is in the corresponding edit buffer."
  (let ((indentation (or org-src--block-indentation 0))
(preserve-indentation org-src--preserve-indentation)
(contents (org-with-wide-buffer (buffer-string)))
(write-back org-src--allow-write-back))
;; CHANGE: Save off the original mode into orig-major-mode:
(let ((orig-major-mode major-mode))
  (with-temp-buffer
(insert (org-no-properties contents))
;; CHANGE: Switch to the original mode to obtain mode-specific
indentation behavior:
(funcall orig-major-mode)
;; CHANGE: Do not mix tabs and spaces during indentation:
(setq indent-tabs-mode nil)
(goto-char (point-min))
(when (functionp write-back) (funcall write-back))
(unless (or preserve-indentation (= indentation 0))
  (let ((ind (make-string indentation ?\s)))
(goto-char (point-min))
(while (not (eobp))
  (when (looking-at-p "[ \t]*\\S-") (insert ind))
  (forward-line
(buffer-string)

If the above change seems correct, can someone apply it to org-mode?

Thanks,
Brent Goodrick