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

Re: [O] ANN: org-sticky-header

[Charles C. Berry]

On Wed, 19 Apr 2017, Adam Porter wrote:


This should now be fixed.  Thanks!



I have encountered a bug when trying to export a subtree containing an 
inlinetask just after the headline/metadata and a src block further down.


Here is an ECM:

--8<---cut here---start->8---
* a Headline
*** my task

  Do this well!

*** END

#+NAME: my-model
#+BEGIN_src latex :results latex
  \begin{displaymath}
y = x + z
  \end{displaymath}
#+END_src
--8<---cut here---end--->8---

Put the cursor under the headline (at the end of buffer, say) then type

C-c C-e C-s l L y

and without org-sticky-header mode you get an exported buffer.

With org-sticky-header mode, it just hangs after the 'y' is typed.

Also, if you put point at the beginning of the second line (the start
of the inlinetask) and type

: M-: (narrow-to-region (point) (point-max))

it will narrow if o-s-h mode is off, but hang if it is on.

Adding a newline after the headline `cures' the export problem.
However, if point is at the start of an inlinetask, then emacs will
hang when running the narrow-to-region snippet above regardless of
newlines.

p.s. I am using commit b82b4f210e... (newest at this time)

Chuck

Re: [O] RFC: Extensible Dependencies 'N' Actions

[Ian Dunn]

Gergely Polonkai writes:

> • Some finders have missing documentation (although their names are pretty
> straightforward)

Yup, working on that.

> • Why the “new language”, why can’t it be lisp, or at least more lispish?

Initially, I made it similar to org-depend.el, but as parsing became
complicated, it has effectively morphed into lisp.  The keywords are all
symbols (they've got to be functions, after all), and the argument lists
are lisp lists.

I find this to be a good compromise between ease of coding for me, and
ease of understanding for the users.

> • You gave us a possibility to create naming clashes between targets,
> finders, etc. For example, I might want to file a note when a file of a
> project changes, so I use your file target, and create the file action. How
> will Edna know when to use which?

Right now, Edna will use the finder and ignore the action.  I didn't
want to force users to specify when to change from finders to actions or
conditions, so I just had Edna search for the functions.

Thinking about it, Guile uses the suffixes '!' to denote functions that
destructively change the input (like actions) and '?' to denote
predicates (like conditions).

If Edna looks for these characters at the end of the keyword (starting
character already means something), then that will allow users to name
both a finder and action 'file' (although the action would be 'file!').

And of course, thank you for your support and feedback.

-- 
Ian Dunn

[O] set org-attach-directory location per buffer

[Xebar Saram]

Hi!

i was wondering if one could use perhaps local variables in separate org
files to define the location of the attachment folder per file so that for
each folder the attachment will be stored in a separate directory

thx

Z

[O] function-finding-location?

[Xebar Saram]

today i saw this in the DOCU

(file+function "path/to/file" function-finding-location)
A function to find the right location in the file.

i assume you dont just use "function-finding-location" but rather a
specific function. are there examples for such functions?

best

Z

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

[Nicolas Goaziou]

Hello,

Brent Goodrick  writes:

> 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.

Indeed. Thank you.

> 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, imagine 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.

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

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Canceling a TODO state change does not revert the heading [9.0.5 (9.0.5-elpa @ /home/laurence/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

Laurence Rochfort  writes:

>> I disagree. You may want to cancel the message because this change
>> doesn't require one, but, yet, want the todo state change.
>
> I see, that makes sense.
>
> I notice that supplying an empty message with C-c C-k results in no
> logbook entry at all. Is that intended behaviour too?

It doesn't sound nonsensical. What would you expect instead ?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: export does not ignore #+INCLUDE if archived or tagged :noexport: Package: Org mode version 9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Stefan Kredler  writes:
>
>> when archiving sections or exclude them from export I would expect
>> them being exempt from being evaluated during export.
>> The section archived or marked as ~:no export:~ is still evaluated and there 
>> is an error
>> if the reference in the include file is no longer available. I get the error 
>> message
>> ~"org-export-expand-include-keyword: Cannot include file ~/filename.org"~
>
> IMO this is a feature.  I have used this before, for instance when
> including tables used in source blocks at export time.

I agree an included file could introduce Babel contents which would then
be processed, even though the tree is not exported.

However, COMMENT keyword prevents Babel evaluation, so we could avoid
expanding include keywords in this particular case.

WDYT?

Regards,

-- 
Nicolas Goaziou