Re: URLs with brackets not recognised

[Colin Baxter]

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> Hello,
>> 
>> If a URL link in an org file contains a bracket then the link is
>> not fully recognised and may be misdirected. For example,

> This is a known bug [1]. You just need to wait for the patch to be
> merged.

> [1] https://orgmode.org/list/87v99g4p3m.fsf@localhost/


Thank you. I did check the bug list first, but obviously I missed that.

Best wishes,

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

 I do not like abusing prettify-symbols-mode. What if it is not enabled?
>
> If you know of another way of accomplishing text-replacement which
> changes back when the cursor enters the region, please let me know.

cursor-sensor-mode

>>> Ah, it does it anyway at the moment.
>>
>> Hmm. You are right. You are calling compose-region directly. Note, that
>> you do not add 'decompose-region function for automatic region
>> destruction (see help:pretty-symbol-pattern-to-keyword).
>
> Isn't the same effect achieved by the remove-list-of-text-properties call?

It is. Though only while font-lock is active. Now, looking at
prettify-symbols-mode code, it does not seem to be necessary when
font-locking is set correctly.

>> If I understand correctly (I did not really install your patch), if you have
>> composed region, disable font-lock, and try to edit the region, edits
>> will be invisible. Or imagine setting org-inline-src-prettify-results to
>> nil in already fontified buffer.
>
> I just tried "setting org-inline-src-prettify-results to nil in already
> fontified buffer." and the region just decomposed and stayed that way.

Did you also have prettify-symbols-mode disabled?

>> Also, you may find help:font-lock-extra-managed-props useful. That way,
>> you will not have to manually remove composition and other non-standard
>> properties during fontification
>
> Hmmm, from a look I can't tell exactly how these are "managed". Are they
> just removed when a region is processed?

They are removed just before the region is processed and they are
removed when font-lock-mode is disabled. On the other hand, it will not
be possible to set the managed properties directly (try setting font
using a direct M-: command in a buffer with font-lock enabled).

>> P.S. Nitpick: You do not need to run fontification in while loops. Just
>> fontifying next match before limit should be enough. Font-lock will call
>> the function again if needed.
>
> I'm guessing for this to work I'd need to return the final char
> fortified? Or is the moving of point enough?
>
> Maybe related - I've noticed this doesn't seem to work with multiple
> src_ blocks per line, might you have any insight here?

As I understand, the fontificatoin function must behave like
re-search-forward. From font-lock-keywords docstring:

>>> ... MATCHER can be either the regexp to search for, or the function
>>> name to call to make the search (called with one argument, the limit
>>> of the search; it should return non-nil, move point, and set
>>> `match-data' appropriately if it succeeds; like `re-search-forward'
>>> would).

Best,
Ihor

Re: [PATCH] Fontification for inline src blocks

[Tim Cross]

Timothy  writes:

> Thank you for the detailed feedback :)
>
> Ihor Radchenko  writes:
>
>> Timothy  writes:
>>
 I do not like abusing prettify-symbols-mode. What if it is not enabled?
>
> If you know of another way of accomplishing text-replacement which
> changes back when the cursor enters the region, please let me know.
>
>>> Ah, it does it anyway at the moment.
>>
>> Hmm. You are right. You are calling compose-region directly. Note, that
>> you do not add 'decompose-region function for automatic region
>> destruction (see help:pretty-symbol-pattern-to-keyword).
>
> Isn't the same effect achieved by the remove-list-of-text-properties call?
>
>> If I understand correctly (I did not really install your patch), if you have
>> composed region, disable font-lock, and try to edit the region, edits
>> will be invisible. Or imagine setting org-inline-src-prettify-results to
>> nil in already fontified buffer.
>
> I just tried "setting org-inline-src-prettify-results to nil in already
> fontified buffer." and the region just decomposed and stayed that way.
>
>> Also, you may find help:font-lock-extra-managed-props useful. That way,
>> you will not have to manually remove composition and other non-standard
>> properties during fontification
>
> Hmmm, from a look I can't tell exactly how these are "managed". Are they
> just removed when a region is processed?
>
>> why are you even removing 'face? It should be already done by font-lock).
>
> I tried removing such calls, and everything still worked, so this is no
> longer done.
>
 What will happen if user toggles prettify-symbols-mode in Org buffer?
>>>
>>> This seems to be toggled nicely by prettify-symbols-mode too.
>>
>> I would not expect it to. Why would prettify-symbols-mode interfere with
>> Org mode native fontification if it is not strictly necessary?
>
> Well, I guess this is a by-product of using prettify-symbols-start/end,
> see my note at the start of this email about not being aware of anything else.
>
>> P.S. Nitpick: You do not need to run fontification in while loops. Just
>> fontifying next match before limit should be enough. Font-lock will call
>> the function again if needed.
>
> I'm guessing for this to work I'd need to return the final char
> fortified? Or is the moving of point enough?
>
> Maybe related - I've noticed this doesn't seem to work with multiple
> src_ blocks per line, might you have any insight here?
>
>
This may or may not be something to consider but ...

What is the impact of using this technique for accessibility and users
of assistive technology like text-to-speech or braille displays?

I'm currently not in the position to test this patch, but once I get
some environments for testing sorted out, I should be able to try it
out.

>From an accessibility perspective, behaviour which changes what is
'displayed' based on cursor position is often confusing for things like
text-to-speech. In the past, I have run into issues with prettify
symbols because it results in either less meaningful content (e.g.
unicode numbers rather than defined character names) or additional
spoken text which makes it difficult to understand. Things like
overlays, tooltips or features which make display different from
underlying character content can often be problematic with assistive
technology. 



-- 
Tim Cross

Re: URLs with brackets not recognised

[Tim Cross]

Rudolf Adamkovič  writes:

> Maxim Nikulin  writes:
>
>> I do not think it is a bug. Plain text links detection is a kind of
>> heuristics. It will be always possible to win competition with regexp. 
>> Consider it as a limitation requiring some hints from an intelligent
>> user.
>
> I disagree. URLs are well-specified. Per RFC 3986, the characters
> allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
> implement proper URL detection, not asking its users "to give it some
> hints" and using "a kind of heuristics". A string either is a valid URL
> per the relevant RFCs or it is not.
>

Limitations with plain text links are documented in the manual, with an
explanation of why you need to use the org link insertion commands to
created a valid link which escapes the problematic characters.

As this is defined and documented behaviour, I don't see how it can be
considered a bug. You might consider it a frustrating or even
unnecessary limitation, but not a bug.

I'm sure a patch which improves org handling of plain urls would be
considered. However, previous attempts at such enhancements have either
resulted in significant performance impact or unexpected and unwanted
side effects. In short, this is a non-trivial problem to solve. As the
need for such use cases in plain text links is a small use case and as
you can have those links using org link syntax, it would be very hard to
justify a patch which may have adverse performance impact for all users. 

This change could be considered a feature enhancement, but it is not a
bug.

-- 
Tim Cross

Re: updates.orgmode.org giving 502 Bad Gateway Error

[Ihor Radchenko]

Tim Cross  writes:

> FYI the updates.orgmode.org page is giving a 502 Bad Gateway error when
> I try to access it.

Confirmed

Seeing this from yesterday.

Re: URLs with brackets not recognised

[Ihor Radchenko]

Colin Baxter  writes:

> Hello,
>
> If a URL link in an org file contains a bracket then the link is not
> fully recognised and may be misdirected. For example,

This is a known bug [1]. You just need to wait for the patch to be
merged.

[1] https://orgmode.org/list/87v99g4p3m.fsf@localhost/

Re: URLs with brackets not recognised

[Tom Gillespie]

A quick fix is to percent encode the troublesome characters, but the
underlying issue is in org-link-any-re which is defined in
org-link-make-regexps which is what org uses to find the next link.
Some improvements might be possible for some of the edge cases there,
but a complete solution for bare urls is not possible due to conflicts
with native org syntax.

Org doesn't handle these cases well because in some cases org's own
syntax takes priority over url syntax at the moment adding bare url
syntax as part of org syntax is something that could be considered.
However, I would suggest against that because it will taint any org
parser in the future by forcing it to implement full url parsing at
arbitrary positions in paragraphs, which adds a lot of complexity. I
also suggest against it because org already has clear ways to
demarcate links using <> and [[]] which are guaranteed to behave
correctly even in cases where org syntax will always take priority.
For example with
https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_[[Savannah,_Georgia]].

> It might be worthwhile to issue an warning each time a url is written in
> an org file without enclosing brackets < > or [[ ]].

Unfortunately warning on links without < > or [[ ]] will generate
countless annoying false positives for anyone who doesn't hit this
edge case. Maybe a separate function could be added to org lint that
would not run all the time?

Re: URLs with brackets not recognised

[Rudolf Adamkovič]

Maxim Nikulin  writes:

> I do not think it is a bug. Plain text links detection is a kind of
> heuristics. It will be always possible to win competition with regexp. 
> Consider it as a limitation requiring some hints from an intelligent
> user.

I disagree. URLs are well-specified. Per RFC 3986, the characters
allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should
implement proper URL detection, not asking its users "to give it some
hints" and using "a kind of heuristics". A string either is a valid URL
per the relevant RFCs or it is not.

-- Rudy

Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use

[Maxim Nikulin]

On 11/05/2021 01:36, Utkarsh Singh wrote:

What do we mean by interactive preview?  Does this mean that we should
present a user with a list of possible delimiters using minibuffer?


I mean something like the dialog that LibreOffice shows on opening of a 
csv file. There are various options and table preview that allows to 
check if options are selected correctly before dropping to usual 
spreadsheet interface. I have no idea what is the best way to implement 
something like this in emacs. Likely it is out of scope of the discussed 
patch. I do not know what is your use cases. My intention was to show 
that CSV import could be quite cumbersome.


Some users believe that CSV is a reliable portable format and expect 
support of most features from Excel. Actually there are plenty of 
dialects and no way to determine which one was used (e.g. no header that 
defines field or string separator).



For ex (please review my usage of alist):

#+begin_src elisp
(defvar my-separator-alist '(("comma" . ",")
 ("tab" . "\t")
 ("semicolon" . ";")
 ("colon" . ":")
 ("space" . " ")))

(defun my/table-import (file separator)
   (interactive (list (read-file-name "Import CSV file: " nil nil t)
 (cdr (assoc (completing-read "Separator: " 
my-separator-alist)
 my-separator-alist
   (org-table-import file separator))
#+end_src


With such function it is necessary to open file at first to see what 
separator is used inside.


My comments were related to the "guess" part of your patch. Comma is 
tried first. Consider the following file


A;1,2;3,4;5,6
B;7,8;9,1;11,12
C;13,14;15,16;17,18

Decimal separator is ",". Field separator is ";" but there are plenty of 
"," in each row.


LANG=fr_FR.UTF-8 python3 -c "import locale as l; l.setlocale(l.LC_ALL, 
''); print(l.format_string('%.2f', 123456.789))"

123456,79

Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is 
that order in which separator candidates are tried should depend on 
active locale.


I do not insist that interactive preview or smarter approach to guess 
separator have to be implemented. Feel free to disregard my comments. I 
am just not sure whether you are aware of limitations for noticeable 
part of users.

Re: Manual on web site is not the latest version

[William Denton]

On 28 April 2021, Bastien wrote:


Do you still see differences between the doc/org-manual.org and the
one published on https://orgmode.org/manual/ ?

If so, please point at one or two differences.  Thanks!


Here's a late follow-up.  Thanks for checking.

On the web at https://orgmode.org/manual/Languages.html#Languages

"Code blocks in the following languages are supported."

"Additional documentation for some languages is at 
https://orgmode.org/worg/org-contrib/babel/languages.html.;

In org-manual.org, both sentence are different:

$ grep -A2 "Code blocks" doc/org-manual.org
Code blocks in dozens of languages are supported.  See Worg for
[[https://orgmode.org/worg/org-contrib/babel/languages/index.html][language 
specific documentation]].



Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.

Re: URLs with brackets not recognised

[Colin Baxter]

It might be worthwhile to issue an warning each time a url is written in
an org file without enclosing brackets < > or [[ ]].

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Thank you for the detailed feedback :)

Ihor Radchenko  writes:

> Timothy  writes:
>
>>> I do not like abusing prettify-symbols-mode. What if it is not enabled?

If you know of another way of accomplishing text-replacement which
changes back when the cursor enters the region, please let me know.

>> Ah, it does it anyway at the moment.
>
> Hmm. You are right. You are calling compose-region directly. Note, that
> you do not add 'decompose-region function for automatic region
> destruction (see help:pretty-symbol-pattern-to-keyword).

Isn't the same effect achieved by the remove-list-of-text-properties call?

> If I understand correctly (I did not really install your patch), if you have
> composed region, disable font-lock, and try to edit the region, edits
> will be invisible. Or imagine setting org-inline-src-prettify-results to
> nil in already fontified buffer.

I just tried "setting org-inline-src-prettify-results to nil in already
fontified buffer." and the region just decomposed and stayed that way.

> Also, you may find help:font-lock-extra-managed-props useful. That way,
> you will not have to manually remove composition and other non-standard
> properties during fontification

Hmmm, from a look I can't tell exactly how these are "managed". Are they
just removed when a region is processed?

> why are you even removing 'face? It should be already done by font-lock).

I tried removing such calls, and everything still worked, so this is no
longer done.

>>> What will happen if user toggles prettify-symbols-mode in Org buffer?
>>
>> This seems to be toggled nicely by prettify-symbols-mode too.
>
> I would not expect it to. Why would prettify-symbols-mode interfere with
> Org mode native fontification if it is not strictly necessary?

Well, I guess this is a by-product of using prettify-symbols-start/end,
see my note at the start of this email about not being aware of anything else.

> P.S. Nitpick: You do not need to run fontification in while loops. Just
> fontifying next match before limit should be enough. Font-lock will call
> the function again if needed.

I'm guessing for this to work I'd need to return the final char
fortified? Or is the moving of point enough?

Maybe related - I've noticed this doesn't seem to work with multiple
src_ blocks per line, might you have any insight here?

Thanks,

Timothy

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

>> I do not like abusing prettify-symbols-mode. What if it is not enabled?
>
> Ah, it does it anyway at the moment.

Hmm. You are right. You are calling compose-region directly. Note, that
you do not add 'decompose-region function for automatic region
destruction (see help:pretty-symbol-pattern-to-keyword). If I
understand correctly (I did not really install your patch), if you have
composed region, disable font-lock, and try to edit the region, edits
will be invisible. Or imagine setting org-inline-src-prettify-results to
nil in already fontified buffer.

Also, you may find help:font-lock-extra-managed-props useful. That way,
you will not have to manually remove composition and other non-standard
properties during fontification (why are you even removing 'face? It
should be already done by font-lock).

>> What will happen if user toggles prettify-symbols-mode in Org buffer?
>
> This seems to be toggled nicely by prettify-symbols-mode too.

I would not expect it to. Why would prettify-symbols-mode interfere with
Org mode native fontification if it is not strictly necessary?

P.S. Nitpick: You do not need to run fontification in while loops. Just
fontifying next match before limit should be enough. Font-lock will call
the function again if needed.

Best,
Ihor

Re: The fate of ditaa.jar (9.4.5.)

[Russell Adams]

On Wed, May 12, 2021 at 11:41:48AM +0200, Dr. Arne Babenhauserheide wrote:
> I have Java, but not ditaa, because Java is packaged in my distribution
> and ditaa is not. My build pipelines use ditaa as shipped with
> org-mode.

My opinion is that Org has integration for many external tools, but
doesn't ship them. I don't think Org should be shipping anything that
isn't Org's own code due to maintainer overhead, potential
legal/license issues, and inconsistency across tools. We don't ship
Latex distributions or gnuplot either.

> So unbundling ditaa breaks my documents when updating org-mode. The same
> for everyone else who used a standard ditaa-setup with org-mode.

I think it's a reasonable request to make of an end user that if you
want to use Org's integration with the tool, you ensure the tool is
installed first. If your Linux distribution doesn't provide a package
for ditaa, file a bug report or a feature request with
them. Alternatively you can install it yourself as it's just one .jar
file.

Perhaps Org should show a better error message if ditaa isn't found.

> Ask the other way round: What is the benefit of removing ditaa from org?
> If you want to force most current org-ditaa users to unbreak their setup
> after update, there should be a significant tangible benefit.

Org's codebase is always undergoing change and right now there's a
significant cleanup effort going on to separate contrib out of core. I
expect removing ditaa was part of that. I defer here to the wisdom of
the maintainers that there is benefit to reorganizing the code base,
even if it's just to simplify their job as maintainers.

I respect that it's causing you some personal inconvenience, however
it's not a major breakage. It should be simple to resolve by
installing locally.


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Refiling All 'Terminal TODO State' Entries to a Particular Heading

[Ihor Radchenko]

Tim Visher  writes:
>
> I found that my timvisher-org-refile-done-entries had a bug where it could
> skip entries if the org buffer had consecutive DONE/CANCELLED entries. I
> believe this is because of this quote from the manual:
>
> After evaluation, Org moves point to the end of the line that was just
> processed. Search continues from that point forward. This may not always
> work as expected under some conditions, such as if the current sub-tree was
> removed by a previous archiving operation. In such rare circumstances, Org
> skips the next entry entirely when it should not. To stop Org from such
> skips, make FUNC set the variable ‘org-map-continue-from’ to a specific
> buffer position.

I think the easiest would be using markers. You can collect the list of
headline markers in org-map-entries without modifying buffer. Then, you
mapc over the list of markers and refile the corresponding headings. You
will not need to worry about point moving due to changes in buffer as
markers will not be affected by buffer changes.

Hope it helps.

Best,
Ihor

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Thanks for your response.

Ihor Radchenko  writes:

> I do not like abusing prettify-symbols-mode. What if it is not enabled?

Ah, it does it anyway at the moment.

> What will happen if user toggles prettify-symbols-mode in Org buffer?

This seems to be toggled nicely by prettify-symbols-mode too.

> Maybe better use something like org-entities?

I'm not sure if that would work, perhaps someone else knows otherwise.

--
Timothy

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

> If anyone else is interested in this, it would be great to get your
> thoughts.

I do not like abusing prettify-symbols-mode. What if it is not enabled?
What will happen if user toggles prettify-symbols-mode in Org buffer?
Maybe better use something like org-entities?

Best,
Ihor

Re: Bug: org-plot gives Invalid function error

[Ihor Radchenko]

Timothy  writes:
> If you could test it and let me know that would be greatly appreciated
> :) It seems to work with the manual example for me.
>
> Until I hear otherwise, I'm marking this bug as fixed.

I guess the initial report was using example from the manual:

#+PLOT: title:"Citas" ind:1 deps:(3) type:2d with:histograms set:"yrange [0:]"
| Sede  | Max cites | H-index |
|---+---+-|
| Chile |257.72 |   21.39 |
| Leeds |165.77 |   19.68 |
| Sao Paolo | 71.00 |   11.50 |
| Stockholm |134.19 |   14.33 |
| Morelia   |257.56 |   17.67 |

The example works for me on master.

Best,
Ihor

RE: ob-sql is not finding psql when using direnv+guix

[Cook, Malcolm]

> > >I am using Guix with direnv.
> > 
> > What is your shell?
> > 
> 
> My shell is bash, originally I was using zsh and I thought that was the 
> problem, so I switched to bash and still not working.
> 
> > How/When do you "hook direnv into your shell" (https://direnv.net/)?
> > 
> 
> In the .profile file, at login.
> 
> > > In an specific folder I am installing and using psql and postgresql using 
> > > direnv+guix as follows:
> > >use guix --manifest=cdpp-manifest.scm
> > >
> > >export PGUSER=food_user
> > >export PGPASSWORD=some_password
> > >export PGDATABASE=food
> > >
> > >layout postgres
> > 
> > When are you doing this?
> > 
> > a) in the "specific folder"'s .envrc file?
> > b) in an org-mode shell block that you execute prior to the sql block?
> > c) ??
> 
> Option (a)
> 
> 
> > You seem to be following [Per\-project 
> > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) 
> > but with guix instead of nix. Nice.
> > 
> 
> Yep, great post. direnv + guix change the way I develop software, do data 
> science and write lectures and papers.
> 
> > If you enter the directory and then call emacs, earthing should just 
> > work, no changes neede.
> > 
> 
> It works for almost everything (sql-buffers, python buffers, etc), except for 
> org-babel sql blocks.
> 
> I am using EXWM, so emacs is always on.
> 
> 
> > If you want to tell emacs to adopt the environment established by a 
> > .direnv, you probably want [direnv integration for 
> > emacs\.](https://github.com/wbolster/emacs-direnv)
> > 
> 
> emacs-direnv was my first choice, but then I changed to envrc 
> (https://github.com/purcell/envrc) . In both I got the error.
> 

I see.  Envrc looks superior.  Good to know.

You've covered all my bases.  Shooting in the dark,  I would confirm/check the 
following:

How do you know that envrc is working otherwise?

When you switch to a direnv controlled buffer do you get any informative 
diagnostics in *Messages*?

Do you get any more if you first `(setq envrc-debug t)`?

Is this buffer in the same directory as the .direnvrc file?

Presumably TRAMP is not in the mix in any way.

Variable sql-postgres-program is unchanged from default value of psql

What is result of

m-x shell-command
which psql

and does it change as expected/required depending on the current active 
.direnvrc?

What happens if you eval (getenv 'psql) while in buffer governed by direnv, or 
alternatively

m-x getenv
psql

If you `m-x shell`, does normal direnv work as expected in the created shell?

> > I've got to try this!
> > 
> > Cheers
> > 
> 
> Please tell me how that works for you

Gotta get guix rolling again.  Hope to do this RSN.

Cheers,

~Malcolm

> 
> Thanks
> 
> - A
> 
> 
> > >
> > >
> > >Where cdpp-manifest.scm contains the following:
> > >
> > >(specifications->manifest
> > >'("python"
> > >   "python-pandas"
> > >   "python-numpy"
> > >   "python-flask"
> > >   "python-graphene"
> > >   "postgresql"
> > >   "jupyter"))
> > >
> > >I am able to use sql-mode and run queries against the database, in order 
> > >to achieve that I am using the following .dir-locals.el
> > >
> > >;;; Directory Local Variables
> > >;;; For more information see (info "(emacs) Directory Variables")
> > >
> > >
> > >((nil .
> > >  ((projectile-project-test-cmd . "pytest --color=no --failed-first 
> > >--maxfail=5")))
> > >(python-mode .
> > >  ((python-shell-buffer-name . "Python [CDPP-Inspecciones]")))
> > >
> > >(org-mode . (
> > >  (indent-tabs-mode . nil)
> > >  (org-src-preserve-indentation . t)
> > >  (org-footnote-auto-adjust . t)
> > >  (org-footnote-auto-label . t)
> > >  (ispell-local-dictionary . "spanish")
> > >  (org-export-allow-bind-keywords . t)
> > >  (org-footnote-define-inline . nil)
> > >  (org-footnote-section . "Footnotes")))
> > >
> > >(sql-mode . ((sql-connection-alist . ((mydb
> > >    (sql-product 'postgres)
> > >    (sql-database "mydb")
> > >    (sql-user "db_user")
> > >    (sql-server (expand-file-name 
> > >".direnv/postgres"))
> > >    (sql-port 5432)
> > >    )
> > >  )
> > >
> > >But If I try to use an sql org-babel block
> > >
> > >#+begin_src sql
> > >select 1;
> > >#+end_src
> > >
> > >(I am setting the connection variables in a PROPERTY)
> > >
> > >I get the error: `psql is not found`
> > >
> > >
> > >I was reading about the variable sql-postgres-program, so if I set the 
> > >following in dir-locals.el
> > >
> > >(sql-postgres-program . 
> > >"/gnu/store/f2v92bkx2vfzmkl14qxj3hlmby4dy9x0-profile/bin/psql")
> > >
> > >It works (note that psql ONLY lives inside the profile defined by 
> > >direnv+guix), 

Re: Refiling All 'Terminal TODO State' Entries to a Particular Heading

[Tim Visher]

Hi Everyone,

I found that my timvisher-org-refile-done-entries had a bug where it could
skip entries if the org buffer had consecutive DONE/CANCELLED entries. I
believe this is because of this quote from the manual:

After evaluation, Org moves point to the end of the line that was just
processed. Search continues from that point forward. This may not always
work as expected under some conditions, such as if the current sub-tree was
removed by a previous archiving operation. In such rare circumstances, Org
skips the next entry entirely when it should not. To stop Org from such
skips, make FUNC set the variable ‘org-map-continue-from’ to a specific
buffer position.

I've been doing some experimentation around how to fix this:
Attempt 1

This feels like the simplest and most naive approach:

(defun timvisher-org-refile-done-entry-position
()
  (save-excursion
(goto-char (point-min))
(- (re-search-forward "^\\* Done") 6)))

(defun timvisher-org-refile-done-entry
()
  (org-refile nil
  (current-buffer)
  (list "* Done"
(buffer-file-name)
nil
(timvisher-org-refile-done-entry-position

(defun timvisher-org-refile-done-entries
()
  (interactive)
  (while (< 0 (length (org-map-entries #'timvisher-org-refile-done-entry
   "LEVEL=2/+DONE|+CANCELLED"
   nil
   'archive)

Here we're literally just doing the org-map-entries operation forever until
the operation finds nothing to operate on.

I worry about infinite loops and all that here though. It also just seems,
well, a little brute force.
Attempt 2

(defun timvisher-org-refile-done-entry
(point)
  (let ((done-entry-position (timvisher-org-refile-done-entry-position)))
(when (< done-entry-position point)
  (error (concat "Refile target at %d is located after the Done "
 "entry at %d. Move the Done entry to the bottom "
 "of the file.")
 point
 done-entry-position))
(goto-char point)
(org-refile nil
(current-buffer)
(list "* Done"
  (buffer-file-name)
  nil
  (timvisher-org-refile-done-entry-position)

(defun timvisher-org-refile-done-entries
()
  (interactive)
  (seq-map #'timvisher-org-refile-done-entry
   (reverse (org-map-entries #'point
 "LEVEL=2/+DONE|+CANCELLED"
 nil
 'archive

Here we're recognizing that if we could process the entries in reverse then
we'd never have to worry about an entry moving from underneath us as we
refile.

This also seems silly:

   1. I'm sure there's a function already that just returns me the matching
   entries for a given match search. Using the mapping API for seems incorrect.
   2. It requires that the Done entry be below all possible targets which
   I'd rather not require. My Done entry is typically above my deferred
   entries and I want to be able to mark deferred entries as cancelled or done
   and have this work properly.

Overall I actually like this attempt less than the first one.
Attempt 3

I'm convinced that there must be something I can do with the
org-map-continue-from var but I'm having a lot of trouble grokking how to
use it properly.

My initial attempt looks like this:

(defun timvisher-org-refile-done-entry
()
  (let ((entry-begin-point (point)))
(org-refile nil
(current-buffer)
(list "* Done"
  (buffer-file-name)
  nil
  (timvisher-org-refile-done-entry-position)))
(setq org-map-continue-from entry-begin-point)))

(defun timvisher-org-refile-done-entries
()
  (interactive)
  (org-map-entries #'timvisher-org-refile-done-entry
   "LEVEL=2/+DONE|+CANCELLED"
   nil
   'archive))

The idea being that if I do in fact refile an entry I'd actually like the
'search to continue' from where it just was. This 'works' in that it
successfully refiles all the entries even if they're consecutive but it
also manages to get into an infinite loop because, AFAICT, it ignores the
'archive skipping somehow. I've spent some time in the debugger and I can't
figure out yet why it does that.

Any tips on how I might use this variable to achieve my goals?

Thanks in advance!

--

In Christ,

Timmy V.

https://blog.twonegatives.com
http://five.sentenc.es

Re: URLs with brackets not recognised

[Colin Baxter]

> Maxim Nikulin  writes:

> On 12/05/2021 17:38, Nick Savage wrote:
>> I can confirm this as a bug.

>> On 5/12/21 3:32 AM, Colin Baxter wrote:
>>> 
https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia)

> I do not think it is a bug. Plain text links detection is a kind
> of heuristics. It will be always possible to win competition with
> regexp. Consider it as a limitation requiring some hints from an
> intelligent user.

> Do the following links have the same problem?

> -
> 

> -
> 
[[https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia)]]

> Support of parenthesis exists, but it is not perfect. Punctuation
> often should be outside of URL.

Point taken.

On the other hand, there has been a series of posts on emacs-devel asking
how emacs could be made more user-friendly. Perhaps therefore not
requiring a user to consider how to enter a URL might be useful.

Best wishes,

Re: Highlighting and Background Colour for Source Code

[Christopher Dimech]

Did some more thinking on this and trying to set up outline-heading-alist
for texinfo, so I can get headlines similar to org mode.

Have seen people trying to do this lately but there is some problem with it 
that I
cannot understand right now.

(defvar gilgamesh-texinfo-hdlevels
'( ("@chapter" . 2)
("@section" . 3)
("@subsection" . 4)
("@subsubsection" . 5)
;; --
("@unnumbered" . 2)
("@unnumberedsec" . 3)
("@unnumberedsubsec" . 4)
("@unnumberedsubsubsec" . 5)
;; --
("@appendix" . 2)
("@appendixsec" . 3)
("@appendixsubsec" . 4)
("@appendixsubsubsec" . 5)
;; --
("majorheading" 2)
;; --
("chapheading" 2)
("heading" 3)
("subheading" 4)
("subsubheading" 5)
;; --
("@uchap" . 2)
("@usec" . 3)
("@usubsec" . 4)
("@usubsubsec" . 5) ))

(setq-local outline-heading-alist
;; We should merge `outline-heading-alist' and
;; `texinfo-section-list'. But in the mean time, let's
;; just generate one from the other.
(mapcar (lambda (x) (cons (concat "@" (car x)) (cadr x)))
gilgamesh-texinfo-hdlevels))

;;(defun gilgamesh-faddeev-texinfo ()
;; "todo"
;; (add-hook 'texinfo-mode-hook #'gilgamesh-texinfo-hdlevels) )


> Sent: Thursday, May 13, 2021 at 12:11 AM
> From: "Christopher Dimech" 
> To: "Ihor Radchenko" 
> Cc: "Tim Cross" , emacs-orgmode@gnu.org
> Subject: Re: Highlighting and Background Colour for Source Code
>
> Have been looking at texinfo-mode a bit to see how to set 
> outline-heading-alist.
> But not been very successful.  Could need some help.
>
> > Sent: Thursday, May 13, 2021 at 12:08 AM
> > From: "Ihor Radchenko" 
> > To: "Christopher Dimech" 
> > Cc: "Tim Cross" , emacs-orgmode@gnu.org
> > Subject: Re: Highlighting and Background Colour for Source Code
> >
> > Christopher Dimech  writes:
> > > Suppose I have an elisp file and I change to org-mode by hitting "M-x 
> > > org-mode".
> > > The code does not get highlighted because it is not embedded within 
> > > org-babel
> > > construct.
> > >
> > > If I have a programming language file with some org-mode heading commands 
> > > in it,
> > > and change to org-mode, it would be neat to have language highlighting 
> > > available.
> >
> > Hmm. What about polymode [1]?
> >
> > [1] https://github.com/polymode/polymode
> >
> >
>
>

Re: Highlighting and Background Colour for Source Code

[Christopher Dimech]

Have been looking at texinfo-mode a bit to see how to set outline-heading-alist.
But not been very successful.  Could need some help.

> Sent: Thursday, May 13, 2021 at 12:08 AM
> From: "Ihor Radchenko" 
> To: "Christopher Dimech" 
> Cc: "Tim Cross" , emacs-orgmode@gnu.org
> Subject: Re: Highlighting and Background Colour for Source Code
>
> Christopher Dimech  writes:
> > Suppose I have an elisp file and I change to org-mode by hitting "M-x 
> > org-mode".
> > The code does not get highlighted because it is not embedded within 
> > org-babel
> > construct.
> >
> > If I have a programming language file with some org-mode heading commands 
> > in it,
> > and change to org-mode, it would be neat to have language highlighting 
> > available.
>
> Hmm. What about polymode [1]?
>
> [1] https://github.com/polymode/polymode
>
>

Re: Highlighting and Background Colour for Source Code

[Ihor Radchenko]

Christopher Dimech  writes:
> Suppose I have an elisp file and I change to org-mode by hitting "M-x 
> org-mode".
> The code does not get highlighted because it is not embedded within org-babel
> construct.
>
> If I have a programming language file with some org-mode heading commands in 
> it,
> and change to org-mode, it would be neat to have language highlighting 
> available.

Hmm. What about polymode [1]?

[1] https://github.com/polymode/polymode

Re: URLs with brackets not recognised

[Maxim Nikulin]

On 12/05/2021 17:38, Nick Savage wrote:

I can confirm this as a bug.


> On 5/12/21 3:32 AM, Colin Baxter wrote:
https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia) 


I do not think it is a bug. Plain text links detection is a kind of 
heuristics. It will be always possible to win competition with regexp. 
Consider it as a limitation requiring some hints from an intelligent user.


Do the following links have the same problem?

- 

- 
[[https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia)]]


Support of parenthesis exists, but it is not perfect. Punctuation often 
should be outside of URL.

Re: [PATCH] Possibility of using alternative separators in macros

[Maxim Nikulin]

On 03/05/2021 04:08, Christian Moe wrote:


I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget.


Maybe it is not convenient, but if unescaped comma is a real pain, you 
could detect it and report an error


# single line may be wrapped by mailer
#+MACRO: extraerror (eval (if (not $2) (concat "*" $1 "*") (error 
(format "%s: unescaped comma %S" (line-number-at-pos) $2


{{{extraerror(valid)}}}
{{{extraerror(valid\, with escaped comma)}}}
{{{extraerror(missed, comma)}}}

Org gurus might suggest a recipe how to convert error into warning, that 
is easily noticeable but still not fatal, to get all problems after 
single export attempt. Preferably it should act similar to compiler 
errors allowing to jump between problem points.


Org 9.3 requires a bit different macro
#MACRO: extraerror (eval (if (equal "" $2) (concat "*" $1 "*") (error 
(format "%s: unescaped comma %S" (line-number-at-pos) $2



Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above.


I think, this is an idea of the best approach. Unsure concerning precise 
form. Maybe e.g. "$_" could expand into all arguments greater than 
maximum referenced number. No promise of forward compatibility of the 
following hack since it relies on undocumented implementation details.


#+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat 
#'identity _ ",")))


{{{allargshack(one, two, three)}}}

I do not know if Eric can swap order of arguments of his credits macro. 
Extracting namely last argument requires a bit more lisp code.

Re: [PATCH] Fontification for inline src blocks

[Timothy]

If anyone else is interested in this, it would be great to get your
thoughts.

I'd also appreciate it if a core maintainer might be able to find the
time to review the patch and let me know if it looks good.

Thanks,

Timothy.

--

> Tom Gillespie  writes:
>
>> 1. I think there needs to be a function to toggle
>> org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
>> quite confused by the prettified results.
>
> Added org-toggle-inline-results-display.
>
>> 3. I'm not sure about the default choice for prettified delimiters. I
>> see there is already a way to customize the delimiters by providing a
>> cons. I think a default value of '("" . "") might be a better choice
>> since ⟨ and ⟩ being hardcoded seems like it introduces completely
>> alien characters. Going with empty strings also seems consistent with
>> the behavior for hyperlinks.
>
> Changed to your suggestion.
>
> Awaiting others' thoughts on 2. and 5.

Re: URLs with brackets not recognised

[Nick Savage]

I can confirm this as a bug.

On 5/12/21 3:32 AM, Colin Baxter wrote:

Hello,

If a URL link in an org file contains a bracket then the link is not
fully recognised and may be misdirected. For example,

1. emacs -Q 
2. C-x C-f test.org 
3. Insert the URL

https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia)

4. Click on the link.
5. Link is not directed correctly.


Best wishes,

Colin.

Re: The fate of ditaa.jar (9.4.5.)

[Dr. Arne Babenhauserheide]

Arthur Miller  writes:

> I don't think that would be the case. Java is considered unsafe software
> so I wouldn't rely on older versions being pre-installed and avialable 
> everywhere.

Java is not considered unsafe software — not any more than any
interpreted language. What’s unsafe are Java applets, but those are not
what ditaa uses.

>> I would bundle the old version to keep old documents working (I do not
>> want org-mode to be volatile software[1] that breaks existing documents
>> with an update), but notify the user that a new version exists.
>
> Since you already have Java and ditaa installed on your computer, your
> older documents won't get broken. 

I have Java, but not ditaa, because Java is packaged in my distribution
and ditaa is not. My build pipelines use ditaa as shipped with org-mode.

Different from plantuml, there is no ditaa-runner to install as
application.

So unbundling ditaa breaks my documents when updating org-mode. The same
for everyone else who used a standard ditaa-setup with org-mode.

> By the way, how difficult is to download one file from the internet
> (ditaa.jar) if you are an user?

That’s not the point. The point is that every single user with a ditaa
block has to do it.

Ask the other way round: What is the benefit of removing ditaa from org?
If you want to force most current org-ditaa users to unbreak their setup
after update, there should be a significant tangible benefit.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> Christopher Dimech  writes:
>>
>>> If org-mode wants to support ditaa, it is a requirement to inform the user 
>>> how to
>>> get the software and install it.  Moving into into a separate repository 
>>> without
>>> appropriately telling the user introduces the problem that users will miss 
>>> out
>>> on free software that they would otherwise have used.  Using org should not 
>>> be made 
>>> more difficult than it already is. 
>>>   
>> Another problem I didn't mention in previous replay, is that user can
>> have wrong (outdated) version of Java installed on his/her machine which
>> might not be compatible with ditaa version org mode ships, which may
>> introduce further questions and problems. IMO I think it is better to
>> leave out 3rd party applications and let users install those on their
>> own. 
>
> The old version should just keep working. It requires a Java older than
> Java 8, and Java 8 is available everywhere.
I don't think that would be the case. Java is considered unsafe software
so I wouldn't rely on older versions being pre-installed and avialable 
everywhere.

> I would bundle the old version to keep old documents working (I do not
> want org-mode to be volatile software[1] that breaks existing documents
> with an update), but notify the user that a new version exists.

Since you already have Java and ditaa installed on your computer, your
older documents won't get broken. 

By the way, how difficult is to download one file from the internet
(ditaa.jar) if you are an user?

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

>   I find it harder to write good
> documentation than good code!

Yes indeed, takes so much more time than to just write the code :).

URLs with brackets not recognised

[Colin Baxter]

Hello,

If a URL link in an org file contains a bracket then the link is not
fully recognised and may be misdirected. For example,

1. emacs -Q 
2. C-x C-f test.org 
3. Insert the URL

https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia)

4. Click on the link.
5. Link is not directed correctly.


Best wishes,

Colin.

updates.orgmode.org giving 502 Bad Gateway Error

[Tim Cross]

FYI the updates.orgmode.org page is giving a 502 Bad Gateway error when
I try to access it.

-- 
Tim Cross

Re: [bug?] changed behaviour of column view

[Eric S Fraga]

Hi Nicholas,

On Tuesday, 11 May 2021 at 20:32, Nicholas Savage wrote:
> 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. 

Ummm how annoying!

> Could you send me the output of your confirmation, maybe from M-x
> org-submit-bug-report? 

I'd rather not.  Too much personal information in my settings.  I will
say that my configuration has not changed since March other than one
change: the path to org-contrib due to the removal of that aspect of org
from the main repository.

> By chance, would the file you're activating column view on be part of
> org-agenda? 

No, this file is not in org-agenda-files.

I'll play around and see if I can track this down.  It's not mission
critical!

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd