Re: org-assert-version considered harmful

2022-12-02 Thread Tom Gillespie
Sorry to be so late chiming in here. I've only now encountered this
due to the 9.6 release. In short, org-assert-version is an absolute
disaster for me.

At the very least org-assert-version should be non-fatal by default.

Without going into too much detail, an orgstrap shebang block is
forced to use the system installed version of org because it is
intended to work in the absence of an init.el file, or before an
init.el file can ever be loaded.

This means that if a newer version of org is installed then no code
can ever run again after that package is visible on the load path
because loading the newer version of org will immediately cause an
error when something (e.g. ob-python) tries to require org-macs,
terminating the execution of the orgstrap block prematurely. There is
no simple workaround, and there is no guaranteed workaround aside from
going to great lengths to only ever use the builtin version of org.

I'm not going to write anything else at the moment because I've just
spent the last 3+ hours trying to deal with this and am in an
extremely uncharitable mood.

Tom



Re: Feedback on Org syntax document

2022-12-02 Thread Tom Gillespie
Hi Ihor,
   Thank you for resurfacing this. I'll keep an eye out for the other
threads. I've been preoccupied with trying to wrap up my PhD work so
have been (and will continue to be for a bit longer) focused on other
things. I'll be back to focus on many of these questions some time in
the late winter/early spring if I had to guess. Best!
Tom



Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

2022-12-02 Thread Ihor Radchenko
Ihor Radchenko  writes:

> It looks like there is something wrong with comint-prompt-regexp in R
> buffers. It somehow does not match the prompt.
>
> I will need to look further.

Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=456462741

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: Bug: org-clock-report tag matching seems to be broken [9.1.9 (release_9.1.9-65-g5e4542 @ c:/Users/user/emacs-26.3-x86_64/share/emacs/26.3/lisp/org/)]

2022-12-02 Thread Ihor Radchenko
Nick Dokos  writes:

> You might want to try a patch that I submitted some time ago to fix that:
>
> https://orgmode.org/list/87h7h0w5nz@alphaville.usersys.redhat.com/

For record, the referenced patch has been merged.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1690fbd88

I assume that the issue herein is also fixed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference

2022-12-02 Thread Ihor Radchenko
Ihor Radchenko  writes:

> Thanks for the patch!
> See my comments below.

Feraidoon, have you had a chance to look into my comments?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]

2022-12-02 Thread Ihor Radchenko
Lin Sun  writes:

>> I cannot reproduce.
>> Can you please provide detailed steps starting from emacs -Q?
>
> The bug caused by the function org-table-clean-line​ calls the 
> org-string-width​ inside a string-match​ clause without protection, for the 
> org-string-width​ maybe change the match data then cause the string-match run 
> into wrong result.

`org-string-width' does not touch match data.

Considering that you can only reproduce with Spacemacs, it might be
spacemacs screwing the match data. Not Org.

There is no reason to fix something not caused by Org on Org side.

I suggest you to contact Spacemacs devs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: org-assert-version considered harmful

2022-12-02 Thread Ihor Radchenko
Tom Gillespie  writes:

> Without going into too much detail, an orgstrap shebang block is
> forced to use the system installed version of org because it is
> intended to work in the absence of an init.el file, or before an
> init.el file can ever be loaded.

Once you load built-in Org partially, attempting to load libraries from
newer Org version is a recipe for a disaster (random failures due to
changes in the newer Org).

> This means that if a newer version of org is installed then no code
> can ever run again after that package is visible on the load path
> because loading the newer version of org will immediately cause an
> error when something (e.g. ob-python) tries to require org-macs,
> terminating the execution of the orgstrap block prematurely. There is
> no simple workaround, and there is no guaranteed workaround aside from
> going to great lengths to only ever use the builtin version of org.

If you absolutely need to load older version of Org without affecting
user's choice to use newer version, you may consider unloading Org
first. See `unload-feature'.

Ideally, Emacs itself should provide ways to deal with multiple package
versions.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: Supress title on html export

2022-12-02 Thread Galaxy Being
BTW, this would seem to suggest org-mode has some built-in "master CSS".
Or, how does org-mode know about the class/ID .title? In my case, I use my
own CSS that I put in the header, and yes, it has a .title. Still, how does
bare-bones default html export know about .title?

On Wed, Nov 30, 2022 at 6:43 PM Rudolf Adamkovič  wrote:

> Galaxy Being  writes:
>
> > Yes, leaving it blank suppresses it, but then my browser needs a page
> > title for searching. I'm trying to have and not display a title.
>
> Using CSS, for example:
>
> #+html_head_extra:  .title { display: none; } 
>
> Rudy
> --
> "Genius is 1% inspiration and 99% perspiration."
> -- Thomas Alva Edison, 1932
>
> Rudolf Adamkovič  [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com


Re: Supress title on html export

2022-12-02 Thread Nick Dokos
Galaxy Being  writes:

> BTW, this would seem to suggest org-mode has some built-in "master
> CSS". Or, how does org-mode know about the class/ID .title? In my
> case, I use my own CSS that I put in the header, and yes, it has a
> .title. Still, how does bare-bones default html export know about
> .title?
>

Do

   C-h v org-html-style-default

Also do

   C-h i g(org)RET m CSS

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler




Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]

2022-12-02 Thread Lin Sun
Hi Ihor,

> Considering that you can only reproduce with Spacemacs, it might be
> spacemacs screwing the match data. Not Org.
> There is no reason to fix something not caused by Org on Org side.

Agree with you, I had located the dead loop is cause by the advice function for 
set-window-buffer from evil package, in which the function will screw the match 
data.
I had posted a patch to the evil-package to fix this issue.
https://github.com/emacs-evil/evil/pull/1724/files

Please mark this ticket as closed if you wish. Thank you

Lin


Re: [BUG] Shift-up/down move the cursor to end of timestamp

2022-12-02 Thread Christopher M. Miles

I meet this bug too.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature


How to disable completely org-persist

2022-12-02 Thread Angelo Graziosi
I have already posted this to emacs-devel people (see 
https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00045.html).

After a recent Emacs build from master I find `org-persist` directory in my 
`.emacs.d` folder. It brings no benefit but only garbage in `.emacs.d`. So how 
can I disable the creation of that folder?

Emacs-devel people suggests to disable `org-element-cache-persistent` but

(setq org-element-cache-persistent nil)

does not fix the issue because the directory is recreated each time I quit from 
Emacs.. All this is very annoying.

You should not enable this by default and let people that finds it really 
useful to enable it in its own init.el.

Best wishes,



Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-02 Thread Kyle Meyer
Bastien writes:

> Kyle Meyer  writes:
[...]

>> Every spot that calls org-assert-version is preceded by a line that
>> requires org-macs, so isn't this error likely due to a mixed
>> installation/load-path issue where the wrong/older org-macs is taking
>> precedence?
>
> Yes: I thought `org-assert-version' job was to help catching mixed
> installations, so my reasoning was that, even when an old org-macs
> version has been loaded, autoloading `org-assert-version' would help
> report about mixed installation.

I see.  So your goal isn't to resolve any errors due to mixed
installation but instead to get the more informative error message from
org-assert-version?

I don't think autoloading will help because it will look in the
org-macs file at the front of the load-path, and, in the bad case, that
does not have the org-assert-version definition.

Here's a minimal example:

--8<---cut here---start->8---
#!/bin/sh

set -eu

tdir=$(mktemp -d "${TMPDIR:-/tmp}"/autoload-shadow-test-XXX)
cd "$tdir"

mkdir a
cat<<'EOF' >a/foo.el
(defun foo-do ()
  (message "foo"))

(provide 'foo)
EOF

mkdir b
echo "(provide 'foo)" >b/foo.el

cat<<'EOF' >test.el
(add-to-list 'load-path
 (concat default-directory (file-name-as-directory "a")))
(add-to-list 'load-path
 (concat default-directory (file-name-as-directory "b")))

(autoload 'foo-do "foo")
(foo-do)
EOF

emacs -Q --batch --load=test.el
--8<---cut here---end--->8---

If I run that, I see:

  Debugger entered--Lisp error: (error "Autoloading file 
/tmp/autoload-shadow-test-gmlO35u...")
(foo-do)
load-with-code-conversion("/tmp/autoload-shadow-test-gmlO35u/test.el" 
"/tmp/autoload-shadow-test-gmlO35u/test.el" nil t)
command-line-1(("--load=test.el"))
command-line()
normal-top-level()

And commenting out the add-to-list call for b confirms that it works
without the shadowing.

> That said, do you have any idea how to fix the bug people encounter
> when installing Org from ELPA and being bitten by "invalid-function
> org-assert-version"?

Sorry, I don't.  Given a mixed installation where the org-macs at the
front of load-path does _not_ have org-assert-version, I don't see a way
to catch that.  Not helpful at the moment, but I suppose the situation
improves with time as Org versions that do not have org-assert-version
become less abundant.



Re: How to disable completely org-persist

2022-12-02 Thread tomas
On Sat, Dec 03, 2022 at 01:19:47AM +0100, Angelo Graziosi wrote:
> I have already posted this to emacs-devel people (see 
> https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00045.html).
> 
> After a recent Emacs build from master I find `org-persist` directory in my 
> `.emacs.d` folder. It brings no benefit but only garbage in `.emacs.d`. So 
> how can I disable the creation of that folder?

Now, now... "garbage" seems unnecessarily loaded, But...

> You should not enable this by default and let people that finds it really 
> useful to enable it in its own init.el.

...I won't quibble about the default, but I'd like to have a way
to disable it, too.

Cheers
-- 
t


signature.asc
Description: PGP signature


[BUG] Add option for category to be derived from #+TITLE instead of file name [9.6 ( @ /nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)]

2022-12-02 Thread Payas Relekar


After discovering categories
(https://orgmode.org/manual/Categories.html) I'd like to use them
everywhere because it makes agenda cleaner. But currently, it has only
below options to get this value (in order of precedence, highest to lowest)

- #+CATEGORY property (if present)
- file name

While I can set the property in my capture templates, it will only take
effect on newly created files and will not retroactively apply all the
previously created ones.

As such, I'd like to propose adding variable to allow user to specify
whether #+TITLE property should be preferred over #+CATEGORY. The
default can continue as is, but if the user chooses to perfer title,
order of preference will look like (highest to lowest):

- #+TITLE (if present)
- #+ CATEGORY (if present)
- file name

Will something like this be possible?

Thanks,
Payas

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.16.0)
Package: Org mode version 9.6 ( @ 
/nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)
--



Re: [BUG] Add option for category to be derived from #+TITLE instead of file name [9.6 ( @ /nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)]

2022-12-02 Thread Payas Relekar
Payas Relekar  writes:

> After discovering categories
> (https://orgmode.org/manual/Categories.html) I'd like to use them
> everywhere because it makes agenda cleaner. But currently, it has only
> below options to get this value (in order of precedence, highest to lowest)
>
> - #+CATEGORY property (if present)
> - file name
>
> While I can set the property in my capture templates, it will only take
> effect on newly created files and will not retroactively apply all the
> previously created ones.
>
> As such, I'd like to propose adding variable to allow user to specify
> whether #+TITLE property should be preferred over #+CATEGORY. The
> default can continue as is, but if the user chooses to perfer title,
> order of preference will look like (highest to lowest):
>
> - #+TITLE (if present)
> - #+ CATEGORY (if present)
> - file name

Actually this is a mistake. It should always prefer explicit property
(#+CATEGORY) over implicit (#+TITLE). So the order should look like (if
the user modifies the variable, highest to lowest):

- #+CATEGORY (if present)
- #+TITLE (if present AND if user sets the variable)
- file name

Apologies for confusion.

Thanks,
Payas

--