Re: [O] [RFC] The "c" Org macro

[Kaushal Modi]

On Sun, May 21, 2017 at 9:38 AM Nicolas Goaziou 
wrote:

> Here is the last update, with tests and an ORG-NEWS entry. Noteworthy
> change: the "c" macro is now the "n" macro.
>
> If there are no objection nor additional suggestions, I will push it to
> master in a couple of days.
>

Thanks. I tried it out and it works great, except for one issue I came
across.

If the n macro is at the BOL, followed by a period, the counter value
resets to 1 even when that macro is specifying the counter value.

Here is the full MWE:

#+TITLE: ={{{n}}}= macro

* This works
Some text /plus/ counter on the same line, no trailing period.

Foo {{{n(a, 7463)}}}
* This works
Counter at BOL, no trailing period.

Foo
{{{n(a, 7463)}}}
* This works
Some text /plus/ counter on the same line, *with* trailing period.

Foo {{{n(a, 7463)}}}.
* This *does not* work
Counter at BOL, *with* trailing period.

Foo
{{{n(a, 7463)}}}.
** How I discovered this scenario
I ended up with this scenario because of this example I was playing
with:
#+BEGIN_SRC org
# -*- fill-column: 70; eval: (auto-fill-mode 1) -*-
The counter starts by default at the value of {{{n}}}. This will be
the next value {{{n}}}, and this will be next {{{n}}}... Now this will
back to the reset value: {{{n(, reset)}}}.

If I wish, I can set that counter value to anything I want, like 7463:
{{{n(, 7463)}}}.

Here is how I can keep multiple counters counting independent of each
other. Each column is running an independent counter. The counter in
first column is initialized to 123, the one in second column to 456,
and the one in third column to 789.. and then they keep on incrementing
the count by 1 in their respective columns:

| n1   | n2   | n3   |
|--+--+--|
| {{{n(n1, 123)}}} | {{{n(n2, 456)}}} | {{{n(n3, 789)}}} |
| {{{n(n1)}}}  | {{{n(n2)}}}  | {{{n(n3)}}}  |
| {{{n(n1)}}}  | {{{n(n2)}}}  | {{{n(n3)}}}  |
| {{{n(n1)}}}  | {{{n(n2)}}}  | {{{n(n3)}}}  |
| {{{n(n1)}}}  | {{{n(n2)}}}  | {{{n(n3)}}}  |
#+END_SRC

-- 

Kaushal Modi

Re: [O] [PATCH 1/2] Add tests for org-refile-get-targets

[Nicolas Goaziou]

Hello,

Sebastian Reuße  writes:

> Sure. Have a look at the follow-up patch and let me know what you
> think.

Thank you!

> It didn’t feel right copy-pasting the tests wholesale, so I made a
> helper-macro. I checked the ert output by forcing a failure and the
> failure explanation looks as expected. Does this work for you?

Honestly, I still find it difficult to follow and debug when one the
tests is failing. Also, we can't use `alist-get' since we are still
supporting Emacs 24.3.

Taking inspiration from your patch, I wrote a test for
`refile-get-targets' in f335c3517de06eb74a3c3727843f276147795a84. It has
more code duplication than yours. OTOH, it doesn't require any
hard-coded file. Hopefully, it will be simpler to debug when a problem
arises in the function.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: "PROPERTIES" drawer [9.0.5 (9.0.5-elpa @ /home/ymak/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

Евгений Макей  writes:

> Only after updating to version 9.0.5
> When i'm trying to set property in file with headings with
> PROPERTIES drawers '(not (org-before-first-heading-p))' every times
> creates new drawer, even if drawer has properties end correct ':END:'
> block.

I'm not sure to understand. Could you show an ECM demonstrating the
issue?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Link descriptions in org-element parser

[Nicolas Goaziou]

Hello,

Erik Sjöstrand  writes:

> When having an link where the link's description also look like a link,
> the description will be treated like a link by org-element. As an
> example:
>
> [[info:emacs#Directory%20Variables][info:Directory Variables]]
>
> If the above was an org-file, org-element-parse-buffer would find two
> links in the buffer, but the above is really just one link even though
> its description look like a link. A consequence of this is that the
> org-element-contents of the link above would be another link, which can
> cause bugs.

IIRC, this was fixed a while ago. You may want to update Org.

Regards,

-- 
Nicolas Goaziou

[O] Bug: Link descriptions in org-element parser

[Erik Sjöstrand]

When having an link where the link's description also look like a link,
the description will be treated like a link by org-element. As an
example:

[[info:emacs#Directory%20Variables][info:Directory Variables]]

If the above was an org-file, org-element-parse-buffer would find two
links in the buffer, but the above is really just one link even though
its description look like a link. A consequence of this is that the
org-element-contents of the link above would be another link, which can
cause bugs.

I'm using org-mode 9.0.5 on Emacs 25.2.1.

Re: [O] returning propertized strings

[John Kitchin]

I figured out the properties are getting lost in org-babel-format-result,
in the beginning with (setq result (org-no-properties result)).

I can see a reason this is desirable is that the properties would not be
persistent on saving/closing. On the other hand, it could be really useful
in some scenarios where temporary properties would be useful.

Are there other reasons having properties on strings in the output are not
desirable?

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Sun, May 21, 2017 at 9:04 AM, John Kitchin 
wrote:

>
>
> On Sat, May 20, 2017 at 9:46 PM, Charles C. Berry 
> wrote:
>
>> On Sat, 20 May 2017, John Kitchin wrote:
>>
>> If I run this block I get test as a result, but all its properties have
>>> been stripped.
>>>
>>> #+BEGIN_SRC emacs-lisp :results drawer
>>> (propertize "test" 'font-lock-face '(:foreground "red") 'help-echo
>>> "tooltip")
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> :RESULTS:
>>> test
>>> :END:
>>>
>>> Does anyone know where this happens and if it can be avoided?
>>>
>>
>> Where?
>>
>> Not sure, but late enough that `:results pp' will print them or `:post
>> ...' will receive them in `*this*'.
>>
>> #+BEGIN_SRC emacs-lisp :results drawer pp
>> (propertize "test" 'font-lock-face '(:foreground "red") 'help-echo
>> "tooltip")
>> #+END_SRC
>>
>> #+RESULTS:
>> : #("test" 0 4
>> :   (help-echo "tooltip" font-lock-face
>> :(:foreground "red")))
>>
>
> I get this too, but  I really want test to actually be red, and have a
> tooltip in the results, and neither of these two methods seem to achieve
> that.
>
>
>>
>> also `*this*' will contain the propertized version if you use the :post
>> header arg.
>>
>> HTH,
>>
>> Chuck
>>
>>
>

[O] Bug: "PROPERTIES" drawer [9.0.5 (9.0.5-elpa @ /home/ymak/.emacs.d/elpa/org-20170210/)]

[Евгений Макей]

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

http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Only after updating to version 9.0.5
When i'm trying to set property in file with headings with
PROPERTIES drawers '(not (org-before-first-heading-p))' every times
creates new drawer, even if drawer has properties end correct ':END:' 
block.


Emacs : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
of 2016-03-19 on trouble, modified by Debian
Package: Org mode version 9.0.5 (9.0.5-elpa @ 
/home/ymak/.emacs.d/elpa/org-=

20170210/)

current state:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-a=
rg-expand)
org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-co=
mmand-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-clock-into-drawer 3
org-confirm-shell-link-function 'yes-or-no-p
org-default-notes-file "~/org/=D0=B2=D1=85=D0=BE=D0=B4=D1=8F=D1=89=D0=B8=
=D0=B5.org"
org-todo-keyword-faces '(("=D0=94=D0=95=D0=9B=D0=90=D0=A2=D0=AC" :foregrou=
nd "red" :weight bold)
("=D0=94=D0=90=D0=9B=D0=95=D0=95" :foreground "blue" :weight bold)
("=D0=97=D0=90=D0=92=D0=95=D0=A0=D0=A8=D0=95=D0=9D=D0=9E" :foreground =
"forest green" :weight bold)
("=D0=9E=D0=A2=D0=9B=D0=9E=D0=96=D0=95=D0=9D=D0=9E" :foreground "orang=
e" :weight bold)
("=D0=9E=D0=96=D0=98=D0=94=D0=90=D0=9D=D0=98=D0=95" :foreground "yello=
w" :weight bold)
("=D0=A3=D0=94=D0=90=D0=A0=D0=96=D0=90=D0=9D=D0=98=D0=95" :foreground =
"magenta" :weight bold)
("=D0=9E=D0=A2=D0=9C=D0=95=D0=9D=D0=95=D0=9D=D0=9E" :foreground "fores=
t green" :weight bold)
("=D0=97=D0=92=D0=9E=D0=9D=D0=9E=D0=9A" :foreground "forest green" :we=
ight bold)
("=D0=9F=D0=9E=D0=A0=D0=A3=D0=A7=D0=95=D0=9D=D0=9E" :foreground "fores=
t green" :weight bold)
("=D0=92=D0=A1=D0=A2=D0=A0=D0=95=D0=A7=D0=90" :foreground "forest gree=
n" :weight bold))
org-capture-templates '(("=D0=B4" "=D0=B4=D0=B5=D0=BB=D0=B0=D1=82=D1=8C" e=
ntry (file "/media/ymak/A5BD-2E12/org/=D0=B2=D1=85=D0=BE=D0=B4=D1=8F=D1=89=
=D0=B8=D0=B5.org")
"* =D0=94=D0=95=D0=9B=D0=90=D0=A2=D0=AC %?\n%U\n%a\n\n" :clock-in t :c=
lock-resume t)
("=D0=BE" "=D0=BE=D1=82=D0=B2=D0=B5=D1=82=D0=B8=D1=82=D1=8C" entry (fil=
e "/media/ymak/A5BD-2E12/org/=D0=B2=D1=85=D0=BE=D0=B4=D1=8F=D1=89=D0=B8=D0=
=B5.org")
"* =D0=94=D0=90=D0=9B=D0=95=D0=95 =D0=9E=D1=82=D0=B2=D0=B5=D1=82=D0=B8=
=D1=82=D1=8C %:from =D0=BE %:subject\nSCHEDULED: 
%t\n:PROPERTIES:\n:CATEGOR=
Y: =D0=BE=D1=80=D0=B3. 
=D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B\n:END:\n%U\n%a\=

n\n" :clock-in t :clock-resume t :immediate-finish t)
("=D0=B7" "=D0=B7=D0=B0=D0=BC=D0=B5=D1=82=D0=BA=D0=B0" entry (file "/me=
dia/ymak/A5BD-2E12/org/=D0=B2=D1=85=D0=BE=D0=B4=D1=8F=D1=89=D0=B8=D0=B5.org= 


")
"* COMMENT %? \n:PROPERTIES:\n:CATEGORY: =D0=BE=D1=80=D0=B3. =D1=80=D0=
=B0=D0=B1=D0=BE=D1=82=D1=8B\n:END:\n%U\n%a\n\n"
:clock-in t :clock-resume t)
("=D0=BD" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA" entry (file+date=
tree "~/org/=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D1=81=D1=82=D0=B4. =D0=B7=D0=B0=D0=BD=
=D1=8F=D1=82=D0=B8=D1=8F\n:END:\n%U\n\n" :clock-in t
:clock-resume t)
("=D0=B1" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA (=D0=BE=D1=80=D0=
=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D1=8F =D1=80=D0=B0=D0=B1=D0=
=BE=D1=82=D1=8B)" entry
(file+datetree "~/org/=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D0=BE=D1=80=D0=B3. =D1=80=D0=B0=D0=B1=
=D0=BE=D1=82=D1=8B\n:END:\n%U\n\n" :clock-in t
:clock-resume t)
("=D1=8B" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA (=D0=BE=D1=82=D0=
=B4=D1=8B=D1=85)" entry (file+datetree "~/org/=D0=B4=D0=BD=D0=B5=D0=B2=D0=
=BD=D0=B8=D0=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D0=BE=D1=82=D0=B4=D1=8B=D1=85\n:END:\=
n%U\n\n" :clock-in t
:clock-resume t)
("=D1=81" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA (=D1=81=D0=BE=D0=
=BD)" entry (file+datetree "~/org/=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=
=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D1=81=D0=BE=D0=BD\n:END:\n%U\n\n" :cl=
ock-in t
:clock-resume t)
("=D1=85" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA (=D0=BF=D0=B0=D1=
=81=D1=81=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9 =D0=BE=D1=82=D0=B4=D1=8B=D1=85)" 
en=

try (file+datetree "~/org/=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D0=BF=D0=B0=D1=81=D1=81. =D0=BE=D1=82=
=D0=B4=D1=8B=D1=85\n:END:\n%U\n\n" :clock-in t
:clock-resume t)
("=D1=82" "=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA (=D1=82=D1=80=D0=
=B5=D0=BD=D0=B8=D1=80=D0=BE=D0=B2=D0=BA=D0=B0)" entry (file+datetree 
"~/org=

/=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA.org")
"* %?\n:PROPERTIES:\n:CATEGORY: =D1=82=D1=80=D0=B5=D0=BD=D0=B8=D1=80=

Re: [O] [PATCH] org-store-link: Don't roll C-u behavior into C-u C-u behavior

[Kyle Meyer]

Nicolas Goaziou  writes:

> Kyle Meyer  writes:
>
>> If there are no objections within a few days, I'll apply the following
>> patch to maint.
>
> LGTM. Thank you.

Thanks for having a look.  Applied in 0de7ad043.

-- 
Kyle

Re: [O] Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.

[Titus von der Malsburg]

On 2017-05-21 Sun 12:57, Nicolas Goaziou wrote:
> Hello,
>
> Titus von der Malsburg  writes:
>
>> In the example below, when I place the cursor on “Item 2” and then do
>> (org-end-of-item-list), the cursor is correctly placed at the beginning
>> of line 4.  However, when I then say (org-in-item-p), I get something
>> non-nil.  When I move the cursor to the beginning of line 5, I still get
>> non-nil for (org-in-item-p).  The expected result is nil on line 4 and
>> 5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
>> obviously not moved us to the end of the list.  I think
>> (org-end-of-item-list) is doing the right thing but (org-in-item-p)
>> doesn’t.
>
> I don't see any bug. Blank lines after a plain list still belong to the
> plain list, so `org-in-item-p' is correct.
>
> Indeed, `org-end-of-item-list' moves to the end of the last item

No, it does not move us to the end of the item.  That’s precisely the
problem.  org-in-item-p returns non-nil even for positions after the point
to which org-end-of-item-list takes us.

> instead
> of the very end of the list, but I consider it to be a feature, e.g.,
> when you need to exchange two items in the list.
>
> You may want to explain what is bothering you in this results.

The documentation of org-end-of-item-list says:

  Go to the end of the current list or sublist.

However, when I call this function and then move the point one line
further down in the example, org-in-item-p still says I’m in the
list.  It logically follows that org-end-of-item-list did not take me to
the end of the list, contrary to what the documentation says.

It may be convenient that org-end-of-item-list doesn’t take us to the
very end of the list (in my use case it’s not), but that behavior is
clearly neither consistent with the name of the function nor with its
documentation.  According to the documentation, org–end-of-item-list
should take us to the last position where org-in-item-p returns
non-nil.  Since it doesn’t, there is a bug, either in the implementation
or in the documentation.

> Also, I suggest to use `org-element-at-point' instead.

Thanks.  In the meantime, I had found org-list-struct which also solves
my problem.

  Titus

Re: [O] [RFC] The "c" Org macro

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> On Monday,  8 May 2017 at 16:52, Nicolas Goaziou wrote:
>> Here is an updated patch, in which one can write
>>
>>   {{{c(sub,reset)}}}
>>   {{{c(sub, 5)}}}
>>
>> or even, for the default macro
>>
>>  {{{c(,reset)}}}
>>  {{{c(, 99)}}}
>
> Finally found some time to try the patch out.  All of the above work
> very well.

Thank you for the feedback. 

Here is the last update, with tests and an ORG-NEWS entry. Noteworthy
change: the "c" macro is now the "n" macro.

If there are no objection nor additional suggestions, I will push it to
master in a couple of days.

Regards,

-- 
Nicolas Goaziou
>From 980b713f28596c7f6486dc1ccfa82f76de7c963d Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Mon, 8 May 2017 12:38:38 +0200
Subject: [PATCH] org-macro: Implement the "n" macro

* lisp/org-macro.el (org-macro--counter-table): New variable.
(org-macro--counter-initialize):
(org-macro--counter-increment): New functions.
(org-macro-initialize-templates): Use new functions.

* doc/org.texi (Macro replacement): Document new macro.

* testing/lisp/test-org-macro.el (test-org-macro/n):
(test-org-macro/property): New tests.
---
 etc/ORG-NEWS   |   3 ++
 lisp/org-macro.el  |  38 +--
 testing/lisp/test-org-macro.el | 102 +++--
 3 files changed, 127 insertions(+), 16 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3ca5b0553..b6110c412 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -197,6 +197,9 @@ contents, are now supported.
 This new function is meant to be used in back-ends supporting images
 as descriptions of links, a.k.a. image links.  See its docstring for
 details.
+ New macro : ~{{{n}}}~
+This macro creates and increment multiple counters in a document.  See
+manual for details.
  Add global macros through ~org-export-global-macros~
 With this variable, one can define macros available for all documents.
  New keyword ~#+EXPORT_FILE_NAME~
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 71e917b71..f5ddb92e4 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -36,8 +36,11 @@
 
 ;; Along with macros defined through #+MACRO: keyword, default
 ;; templates include the following hard-coded macros:
-;; {{{time(format-string)}}}, {{{property(node-property)}}},
-;; {{{input-file}}} and {{{modification-time(format-string)}}}.
+;;   {{{time(format-string)}}},
+;;   {{{property(node-property)}}},
+;;   {{{input-file}}},
+;;   {{{modification-time(format-string)}}},
+;;   {{{n(counter,reset}}}.
 
 ;; Upon exporting, "ox.el" will also provide {{{author}}}, {{{date}}},
 ;; {{{email}}} and {{{title}}} macros.
@@ -129,7 +132,7 @@ function installs the following ones: \"property\",
 	(let ((old-template (assoc (car cell) templates)))
 	  (if old-template (setcdr old-template (cdr cell))
 		(push cell templates))
-;; Install hard-coded macros.
+;; Install "property", "time" macros.
 (mapc update-templates
 	  (list (cons "property"
 		  "(eval (save-excursion
@@ -143,6 +146,7 @@ function installs the following ones: \"property\",
   l)
 (org-entry-get nil \"$1\" 'selective)))")
 		(cons "time" "(eval (format-time-string \"$1\"))")))
+;; Install "input-file", "modification-time" macros.
 (let ((visited-file (buffer-file-name (buffer-base-buffer
   (when (and visited-file (file-exists-p visited-file))
 	(mapc update-templates
@@ -152,6 +156,10 @@ function installs the following ones: \"property\",
   (prin1-to-string visited-file)
   (prin1-to-string
    (nth 5 (file-attributes visited-file)
+;; Initialize and install "n" macro.
+(org-macro--counter-initialize)
+(funcall update-templates
+	 (cons "n" "(eval (org-macro--counter-increment \"$1\" \"$2\"))"))
 (setq org-macro-templates templates)))
 
 (defun org-macro-expand (macro templates)
@@ -280,6 +288,9 @@ Return a list of arguments, as strings.  This is the opposite of
 s nil t)
"\000"))
 
+
+;;; Helper functions and variables for internal macros
+
 (defun org-macro--vc-modified-time (file)
   (save-window-excursion
 (when (vc-backend file)
@@ -304,6 +315,27 @@ Return a list of arguments, as strings.  This is the opposite of
 	  (kill-buffer buf))
 	date
 
+(defvar org-macro--counter-table nil
+  "Hash table containing counter value per name.")
+
+(defun org-macro--counter-initialize ()
+  "Initialize `org-macro--counter-table'."
+  (setq org-macro--counter-table (make-hash-table :test #'equal)))
+
+(defun org-macro--counter-increment (name  reset)
+  "Increment counter NAME.
+NAME is a string identifying the counter.  If optional argument
+RESET is a non-empty string, reset the counter instead."
+  (if (org-string-nw-p reset)
+  (let ((new-value (if (string-match-p "\\`[ \t]*[0-9]+[ \t]*\\'" reset)
+			   (string-to-number reset)
+			 1)))
+	(puthash name 

Re: [O] returning propertized strings

[John Kitchin]

On Sat, May 20, 2017 at 9:46 PM, Charles C. Berry  wrote:

> On Sat, 20 May 2017, John Kitchin wrote:
>
> If I run this block I get test as a result, but all its properties have
>> been stripped.
>>
>> #+BEGIN_SRC emacs-lisp :results drawer
>> (propertize "test" 'font-lock-face '(:foreground "red") 'help-echo
>> "tooltip")
>> #+END_SRC
>>
>> #+RESULTS:
>> :RESULTS:
>> test
>> :END:
>>
>> Does anyone know where this happens and if it can be avoided?
>>
>
> Where?
>
> Not sure, but late enough that `:results pp' will print them or `:post
> ...' will receive them in `*this*'.
>
> #+BEGIN_SRC emacs-lisp :results drawer pp
> (propertize "test" 'font-lock-face '(:foreground "red") 'help-echo
> "tooltip")
> #+END_SRC
>
> #+RESULTS:
> : #("test" 0 4
> :   (help-echo "tooltip" font-lock-face
> :(:foreground "red")))
>

I get this too, but  I really want test to actually be red, and have a
tooltip in the results, and neither of these two methods seem to achieve
that.


>
> also `*this*' will contain the propertized version if you use the :post
> header arg.
>
> HTH,
>
> Chuck
>
>

Re: [O] Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.

[Nicolas Goaziou]

Hello,

Titus von der Malsburg  writes:

> In the example below, when I place the cursor on “Item 2” and then do
> (org-end-of-item-list), the cursor is correctly placed at the beginning
> of line 4.  However, when I then say (org-in-item-p), I get something
> non-nil.  When I move the cursor to the beginning of line 5, I still get
> non-nil for (org-in-item-p).  The expected result is nil on line 4 and
> 5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
> obviously not moved us to the end of the list.  I think
> (org-end-of-item-list) is doing the right thing but (org-in-item-p)
> doesn’t.

I don't see any bug. Blank lines after a plain list still belong to the
plain list, so `org-in-item-p' is correct.

Indeed, `org-end-of-item-list' moves to the end of the last item instead
of the very end of the list, but I consider it to be a feature, e.g.,
when you need to exchange two items in the list.

You may want to explain what is bothering you in this results. Also,
I suggest to use `org-element-at-point' instead.

Regards,

-- 
Nicolas Goaziou

[O] Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/el

[Titus von der Malsburg]

In the example below, when I place the cursor on “Item 2” and then do
(org-end-of-item-list), the cursor is correctly placed at the beginning
of line 4.  However, when I then say (org-in-item-p), I get something
non-nil.  When I move the cursor to the beginning of line 5, I still get
non-nil for (org-in-item-p).  The expected result is nil on line 4 and
5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
obviously not moved us to the end of the list.  I think
(org-end-of-item-list) is doing the right thing but (org-in-item-p)
doesn’t.

#+BEGIN_EXAMPLE
- Item 1

- Item 2


** Some headline
#+END_EXAMPLE

I’m using a recent development version of Emacs and Org-Mode from
MELPA.  Tested with emacs -q.  Until a couple of weeks ago, this problem
didn’t occur.  I can’t pin down when exactly this happened for the first
time.

Emacs  : GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-05-14
Package: Org-mode version 8.3.3 (release_8.3.3-529-gfed40e @ 
/home/malsburg/usr/share/emacs/site-lisp/org/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
  org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 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-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-show-block-all
append local]
   5]
 #[nil "\300\301\302\303\304$\207"
   [org-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-archive-hook '(org-attach-archive-delete-maybe)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
  org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] [PATCH] org-store-link: Don't roll C-u behavior into C-u C-u behavior

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> If there are no objections within a few days, I'll apply the following
> patch to maint.

LGTM. Thank you.

Regards,

-- 
Nicolas Goaziou