Re: [O] [RFC] Dog food, anyone?

[Neil Jerram]

In my $dayjob we're now calling that "drinking our own champagne", which IMO is 
rather nicer than eating our own dog food :-)

Best wishes - Neil


On 9 May 2018 19:11:21 BST, Jon Snader  wrote:
>This is excellent. I love that, as Nicolas says, we're eating our 
>own
>dog food. Perhaps this will put to rest the doubts expressed on
>Emacs-Devel a year or two ago in the thread about replacing 
>TeXinfo as
>to whether Org mode was up to the task.

Re: [O] Link "bracket-types"

[Nicolas Goaziou]

Hello,

Michael Brand  writes:
>
> For the four different Org link "bracket-types" shown below I would
> like to have four different faces to be able to distinguish them at
> first sight. What is the recommended way to do this?

This is not possible. I'm not even sure this is desirable.

Note that 2) is not a "bracket type".

> The four Org link bracket-types by example:
>
> Buffer raw content (or visible-mode):
> : 1) 
> [[https://en.wikipedia.org/wiki/Filter#References][https://en.wikipedia.org/wiki/Filter]]
> : 2) https://en.wikipedia.org/wiki/Filter
> : 3) [[https://en.wikipedia.org/wiki/Filter]]
> : 4) [[https://en.wikipedia.org/wiki/Filter_(higher-order_function)]]
>
> (To try them out copy the above into an Org buffer and remove the colons.)
>
> Currently rendered all with the same face as:
> : 1) https://en.wikipedia.org/wiki/Filter
> : 2) https://en.wikipedia.org/wiki/Filter
> : 3) https://en.wikipedia.org/wiki/Filter
> : 4) https://en.wikipedia.org/wiki/Filter_(higher-order_function)
>
> As you know and can see above 1) to 3) can not be distinguished when
> rendered with the default of org-descriptive-links t.

Just move the mouse over them. A tooltip or the minibuffer will display
what the link is really.

> The brackets for 3) are optional as 2) opens the same URL.

They are strictly equivalent, indeed.

> The brackets for 4) are mandatory because without them
> "_(higher-order_function)" is not fontified and not recognized by
> org-open-at-point as part of the Org link any more.

True. This limitation is a feature. You cannot have parenthesis in plain
links even though they are technically allowed in URL.

However, you could also use angle brackets.



The advantage on angle brackets is that they make it clear there is no
description attached to the link, i.e., the brackets are visible when
fontified). You can also use angle brackets for a more prominent visual
clue.

I'm not sure to understand the problem you want to solve. What is
important is if the displayed part of a link is a description or the URL
itself, i.e., case 1. This is solved by hovering the mouse above the
link. The other cases are equivalent, barring the limitation from case
2.

Regards,

-- 
Nicolas Goaziou

Re: [O] Link "bracket-types"

[Eric S Fraga]

On Thursday, 10 May 2018 at 10:14, Nicolas Goaziou wrote:
> Michael Brand  writes:

[...]

>> As you know and can see above 1) to 3) can not be distinguished when
>> rendered with the default of org-descriptive-links t.
>
> Just move the mouse over them. A tooltip or the minibuffer will display
> what the link is really.

Feature request: would it be possible to have the link echoed in the
minibuffer when point enters or is on a link?  I don't use the mouse at
all and always end up having to C-c l to see what the link is.

thanks,
eric

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b


signature.asc
Description: PGP signature

Re: [O] Link "bracket-types"

[Michael Brand]

Hi Nicolas

Thank you for looking into this.

On Thu, May 10, 2018 at 10:14 AM, Nicolas Goaziou
 wrote:

> Just move the mouse over them. A tooltip or the minibuffer will display
> what the link is really.

During my use case I don't care what URL the link opens. I want to
know if there are brackets and even better when I know whether they
are case 1 or 3/4.

> True. This limitation is a feature. You cannot have parenthesis in plain
> links even though they are technically allowed in URL.
>
> However, you could also use angle brackets.
>
> 
>
> The advantage on angle brackets is that they make it clear there is no
> description attached to the link, i.e., the brackets are visible when
> fontified). You can also use angle brackets for a more prominent visual
> clue.

Good to know, I didn't (or forgot?).

> I'm not sure to understand the problem you want to solve. What is
> important is if the displayed part of a link is a description or the URL
> itself, i.e., case 1. This is solved by hovering the mouse above the
> link. The other cases are equivalent, barring the limitation from case
> 2.

My use case is different, see above, and I don't like to move point or
mouse for my use case. I would like to have a visual indication like
with org-descriptive-links nil which leads to this thought:

Probably better than more faces would be to render case 1 like with
org-descriptive-links t and case 3/4 like with org-descriptive-links
nil. What would be the recommended way to do this? Could that become a
new value beside the current t and nil for org-descriptive-links?

Michael

Re: [O] Link "bracket-types"

[Nicolas Goaziou]

Michael Brand  writes:

> My use case is different, see above, and I don't like to move point or
> mouse for my use case.

I still don't understand what your use case is about. Why do you care
about the presence of square brackets?

It is difficult to think about the pertinence of a solution if the
problem is not well defined.

Re: [O] Link "bracket-types"

[Michael Brand]

Hi Nicolas

On Thu, May 10, 2018 at 2:44 PM, Nicolas Goaziou  wrote:

> I still don't understand what your use case is about. Why do you care
> about the presence of square brackets?

Because I care about the raw file content that I see when using
non-Org tools like mainly git but also diff, grep, less, vi and
whatever.

> It is difficult to think about the pertinence of a solution if the
> problem is not well defined.

I could use org-descriptive-links nil to make the brackets visible.
But I would prefer a compromise like I mentioned in my last post: Case
1 like with org-descriptive-links t and case 3/4 like with
org-descriptive-links nil.

Michael

Re: [O] Link "bracket-types"

[Nicolas Goaziou]

Michael Brand  writes:

> Because I care about the raw file content that I see when using
> non-Org tools like mainly git but also diff, grep, less, vi and
> whatever.

Sorry for being dense, but I still don't get it.

When using non-Org tools, the solution doesn't belong to Org, does it?
I mean, we are talking about fontification in Emacs Org mode. Tweaking
it will not change the output of these other tools.

This is probably obvious to you, but again, this is a genuine question:
how would you use /in Org/ the information about the brackets
surrounding the link? A concrete example would probably help.

Re: [O] Link "bracket-types"

[Michael Brand]

Hi Nicolas

On Thu, May 10, 2018 at 3:33 PM, Nicolas Goaziou  wrote:

> Sorry for being dense, but I still don't get it.

I can not claim to have been clear enough, hope to make it clearer below.

> When using non-Org tools, the solution doesn't belong to Org, does it?
> I mean, we are talking about fontification in Emacs Org mode. Tweaking
> it will not change the output of these other tools.

Agreed.

> This is probably obvious to you, but again, this is a genuine question:
> how would you use /in Org/ the information about the brackets
> surrounding the link? A concrete example would probably help.

Only when I can see the brackets of case 3 in Org rendered as
: [[https://en.wikipedia.org/wiki/Filter]]
I know that I can change it to
: https://en.wikipedia.org/wiki/Filter
for a cleaner view in non-Org tools.

For case 1 I still prefer to see only the link description because I
prefer to hide a too disturbing URL part most of the times. My example
for case 1 is only artificial and my actual descriptions will be such
that it can not be confused with case 2.

I hope the previously described idea of a third value for
org-descriptive-links or something similar makes some sense.

Michael

Re: [O] Link "bracket-types"

[Nicolas Goaziou]

Michael Brand  writes:

> Only when I can see the brackets of case 3 in Org rendered as
> : [[https://en.wikipedia.org/wiki/Filter]]
> I know that I can change it to
> : https://en.wikipedia.org/wiki/Filter
> for a cleaner view in non-Org tools.
>
> For case 1 I still prefer to see only the link description because I
> prefer to hide a too disturbing URL part most of the times. My example
> for case 1 is only artificial and my actual descriptions will be such
> that it can not be confused with case 2.

IIUC, you want fontification to make it obvious there are square
brackets in links, so that you know when they can be removed, for
improved readability outside Org.

If I'm correct, why don't you write a function that normalizes links for
you, so you don't have to bother, e.g., something that turns [[URL]]
into URL unless URL contains parenthesis or spaces?

Re: [O] Link "bracket-types"

[Samuel Wales]

(add-hook 'org-mode-hook 'alpha-eldoc-help-echo-mode)
;; fixme in elisp we want both link eldoc and elisp eldoc
(defun hoka-eldoc-help-echo-at-point ()
  "Eldoc thingy for help-echo text properties."
  (let ((val (get-text-property (point) 'help-echo)))
val))
(defun alpha-eldoc-help-echo-mode ()
  "Enable eldoc mode with e.g. org links to display in minibuffer
when cursor is over them.  Call in the relevant buffer.  M-x
eldoc-mode to turn off."
  (interactive)
  (eval-when-compile (require 'eldoc))
  (setq-local eldoc-documentation-function 'hoka-eldoc-help-echo-at-point)
  (eldoc-mode))


On 5/10/18, Nicolas Goaziou  wrote:
> Michael Brand  writes:
>
>> Only when I can see the brackets of case 3 in Org rendered as
>> : [[https://en.wikipedia.org/wiki/Filter]]
>> I know that I can change it to
>> : https://en.wikipedia.org/wiki/Filter
>> for a cleaner view in non-Org tools.
>>
>> For case 1 I still prefer to see only the link description because I
>> prefer to hide a too disturbing URL part most of the times. My example
>> for case 1 is only artificial and my actual descriptions will be such
>> that it can not be confused with case 2.
>
> IIUC, you want fontification to make it obvious there are square
> brackets in links, so that you know when they can be removed, for
> improved readability outside Org.
>
> If I'm correct, why don't you write a function that normalizes links for
> you, so you don't have to bother, e.g., something that turns [[URL]]
> into URL unless URL contains parenthesis or spaces?
>
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] Link "bracket-types"

[Michael Brand]

Hi Nicolas

On Thu, May 10, 2018 at 6:27 PM, Nicolas Goaziou  wrote:

> IIUC, you want fontification to make it obvious there are square
> brackets in links, so that you know when they can be removed, for
> improved readability outside Org.

Yes, and generally just to see what is going on in Org with a little
bit more details.

In the meantime I tried a changed org-activate-links

#+begin_example
-   (visible-start (or (match-beginning 4) (match-beginning 2)))
+   (visible-start (or (match-beginning 4) start))
-   (visible-end (or (match-end 4) (match-end 2
+   (visible-end (or (match-end 4) end)))
#+end_example

to show the brackets of case 3/4 always which I even prefer over my
earlier proposal of fontification. And org-toggle-link-display can
still be used to toggle case 1.

Somehow I don't like to hide the brackets for case 3/4 where nothing
else is to be hidden.

> If I'm correct, why don't you write a function that normalizes links for
> you, so you don't have to bother, e.g., something that turns [[URL]]
> into URL unless URL contains parenthesis or spaces?

The search criteria is more complex because e. g.
: https://en.wikipedia.org/wiki/Filter_(signal_processing)
does not need brackets.

The changed org-activate-links works better for me than an automatic
normalization as I don't need and want to change all
: [[URL]]
now and prefer something similar to lazy evaluation: Change such links
only when I stumble upon for some other reason because after bracket
removal or replacement with angle brackets I have to interact anyway
with org-fill-paragraph and table realignment etc. because I used
org-descriptive-links nil before.

Michael

[O] Agenda-like/query language project: org-agenda-ng/org-ql

[Adam Porter]

Hi all,

I've made some improvements to my experimental "org-agenda-ng" project
which might be interesting to some of you.  It also works as a kind of
"query language" for Org files, providing a lispy DSL to
match/filter/select entries in Org files.  It's on GitHub at:

https://github.com/alphapapa/org-agenda-ng

Note that the agenda-like view that it creates is largely compatible
with agenda-related code, because it makes strings with the same
text-properties as the canonical Org agenda view (not guaranteed to be
comprehensive, it's a WIP, but it does most that I'm aware of).  For
example, org-super-agenda can group its views the same way it groups
"real" Org agenda views.

Here are some examples:

#+BEGIN_SRC elisp
  ;; Show an agenda-like view of items in all agenda files with TODO and 
SOMEDAY keywords which are
  ;; tagged "computer" or "Emacs" and in the category "main":
  (org-agenda-ng org-agenda-files
(and (todo "TODO" "SOMEDAY")
 (tags "computer" "Emacs")
 (category "main")))

  ;; Show an agenda-like view of all habits:
  (org-agenda-ng org-agenda-files
(habit))

  ;; Show an agenda-like view similar to a "traditional" Org agenda:
  (org-agenda-ng "~/org/main.org"
(or (habit)
(date = today)
(deadline <=)
(scheduled <= today)
(and (todo "DONE" "CANCELLED")
 (closed = today

  ;; Return a list of Org entry elements which are not done, are tagged 
"Emacs", and have
  ;; priority B or higher:
  (org-ql org-agenda-files
(and (not (done))
 (tags "Emacs")
 (priority >= "B"))) ;; => ((headline (:raw-value "org-board" :begin 
1220270 :end 1220403 ...)) ...)

  ;; Find the same entries as before, but return a list of heading positions:
  (org-ql "~/org/main.org"
(and (not (done))
 (tags "Emacs")
 (priority >= "B"))
:action-fn (lambda (element)
 (org-element-property :begin element)))  ;; => (44154 46469 
56008 63965 18 ...)

  ;; Or you can use mapcar around it to get the same result (API is WIP):
  (mapcar (lambda (element)
(org-element-property :begin element))
  (org-ql "~/org/main.org"
(and (not (done))
 (tags "Emacs")
 (priority >= "B"  ;; => (44154 46469 56008 63965 18 
...)
#+END_SRC

There are a few more ideas I have for improvements, but it has been
whittled down to where I'm fairly happy with it.  I will probably adjust
the org-ql :action-fn so that users can directly control what function
is used to return each matching result, instead of always using
org-element-headline-parser as it currently does (which would improve
performance when users don't need all the element properties).  I may
add some more matchers too, like for properties, regexps, etc.

Performance is not quite on par with the traditional agenda code (which
is more optimized, but also more complicated), but it's pretty good, and
good enough to be useful, I think.  And if Emacs ever gains a faster
Elisp implementation, I think it would be fast enough in all cases.

So my question is, would anyone find this generally useful?  Should I
consider polishing it up and releasing it as a package (in which case,
it would probably be called something like org-ql rather than
org-agenda-ng, and the agenda-like views would be ancillary)?

Any questions, ideas, suggestions, and contributions are welcome.

Thanks,
Adam

Re: [O] Link "bracket-types"

[Nicolas Goaziou]

Michael Brand  writes:

> In the meantime I tried a changed org-activate-links
>
> #+begin_example
> -   (visible-start (or (match-beginning 4) (match-beginning 
> 2)))
> +   (visible-start (or (match-beginning 4) start))
> -   (visible-end (or (match-end 4) (match-end 2
> +   (visible-end (or (match-end 4) end)))
> #+end_example

If you mean that fontification should show one pair of brackets instead
of hiding them all, I suggested it already, users found it added too
much cruft.

You may want to check ML archives about it.

> The search criteria is more complex because e. g.
> : https://en.wikipedia.org/wiki/Filter_(signal_processing)
> does not need brackets.

Of course. The search criteria is :

1. no description,
2. not an internal link,
3. path matches exactly `org-plain-link-re'.

I was merely giving you an idea.

> The changed org-activate-links works better for me than an automatic
> normalization as I don't need and want to change all
> : [[URL]]
> now and prefer something similar to lazy evaluation: Change such links
> only when I stumble upon for some other reason because after bracket
> removal or replacement with angle brackets I have to interact anyway
> with org-fill-paragraph and table realignment etc. because I used
> org-descriptive-links nil before.

Your function could take care of filling paragraph and re-aligning
table.

Anyway, about showing brackets in fontification, see above.

Re: [O] How to hide a table column from exporting

[stardiviner]

Hi, Modi, I try to apply you config into Org Radio Tables.

Like this:

,
| #+ BEGIN RECEIVE ORGTBL test-table-comment-column
| | a | b |
| | 1 | 2 |
| #+ END RECEIVE ORGTBL test-table-comment-column
| 
| #+ORGTBL: SEND test-table-comment-column orgtbl-to-orgtbl :splice nil :skip 0
| | / | <#> |  |
| |   | a   |  b  |
| |   | 1   |  2  |
`

But as you can see, the commented column is not deleted at radio table receive 
location.

Can it be adapted to Org Radio Tables?

-- 
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3