Re: User set org-hide-block-startup value overwritten by defvaralias

Ruiyang Wu writes: > I recently started to get the following warning from emacs when loading org > mode: > Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by > aliasing to ‘org-cycle-hide-block-startup’ > > I have this in my init file: > (setq org-hide-block-startup t) > >

User set org-hide-block-startup value overwritten by defvaralias

Hi there, Thanks for maintaining this great piece of software. I recently started to get the following warning from emacs when loading org mode: Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by aliasing to ‘org-cycle-hide-block-startup’ I have this in my init file:

Re: [BUG] Org may fetch remote content without asking user consent

s safe if file:///ssh:host:org/test.org is > added to `org-safe-remote-resources'. I was considering a case when > there is no matching entry in `org-safe-remote-resources'. The user > opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to > consider /ssh:host:org/inclu

Re: [BUG] Org may fetch remote content without asking user consent

, actually it resides on the same host as the current document. Perhaps user consent is redundant. `org--safe-remote-resource-p' checks the containing Org file as well, in addition to #+included URL. If my reading of the code is correct then it considers /ssh:host:org/include.org as safe

Re: [BUG] Org may fetch remote content without asking user consent

s something similar. >> >> May you please elaborate? > > Consider a file opened as /ssh:host:org/test.org that has > > #+setupfile: /ssh:host:org/include.org > > Formally it is a remote file, actually it resides on the same host as > the current documen

Re: [BUG] Org may fetch remote content without asking user consent

as /ssh:host:org/test.org that has #+setupfile: /ssh:host:org/include.org Formally it is a remote file, actually it resides on the same host as the current document. Perhaps user consent is redundant. On the other hand, the file likely either contains #+setupfile: include.org or the user has

Re: [BUG] Org may fetch remote content without asking user consent

Max Nikulin writes: > On 07/02/2024 23:12, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> #+setupfile: /dav:localhost#8000:/msg-123456.org > [...] >> I think we can enable checking for anything where `file-remote-p' >> returns non-nil. > ... In addition, TRAMP locations should be >

Re: [BUG] Org may fetch remote content without asking user consent

On 07/02/2024 23:12, Ihor Radchenko wrote: Max Nikulin writes: #+setupfile: /dav:localhost#8000:/msg-123456.org [...] I think we can enable checking for anything where `file-remote-p' returns non-nil. It is a bit more tricky. Current file may be remote as well. Browsers have concept of

Re: [BUG] Org may fetch remote content without asking user consent

uffer: > > Tramp: Opening connection for localhost using dav...failed > ... > No dialog whether the file should be downloaded is displayed. > > My expectation is that Org should not connect to remote servers in > default configuration unless it is explicitly approved by the user

[BUG] Org may fetch remote content without asking user consent

ocalhost#8000:/msg-123456.org" No dialog whether the file should be downloaded is displayed. My expectation is that Org should not connect to remote servers in default configuration unless it is explicitly approved by the user. I am unsure what user option may be changed to mitigate the is

Re: [PATCH] lisp/ox-latex.el: make org-latex-prefer-user-labels safe file local

gerard.vermeu...@posteo.net writes: > I think that it is inconsistent that `org-latex-reference-command' > is a safe file local variable while `org-latex-prefer-user-labels' is > not (it makes no sense to set the first at file scope, while the second > is nil at global scope). Furth

[PATCH] lisp/ox-latex.el: make org-latex-prefer-user-labels safe file local

Hi, I think that it is inconsistent that `org-latex-reference-command' is a safe file local variable while `org-latex-prefer-user-labels' is not (it makes no sense to set the first at file scope, while the second is nil at global scope). Furthermore, `org-html-prefer-user-labels' is also a safe

Re: [BUG] M-x org-lint gives spurious warning when file contains a link with percent-encoded url [9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)]

Suhail Singh writes: > Running M-x org-lint on an org file with below contents results in a > spurious "Link escaped with obsolete percent-encoding syntax" warning. > > #+begin_src org > * org-lint url percent-encoding syntax warning > [[https://www.example.com?param=hello%20world][test url]] >

[BUG] M-x org-lint gives spurious warning when file contains a link with percent-encoded url [9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)]

][test url]] #+end_src I would expect the above org file to not yield any warnings. Emacs : GNU Emacs 29.1 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.38, cairo version 1.18.0) Package: Org mode version 9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/) -- Suhail

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

Aaron Madlon-Kay writes: >> This particular change should fit within TINYCHANGE, I think. So, you do >> not need a copyright assignment (unless you have already exhausted the >> 15LOC limit on Emacs patches, which I do not see in git logs). > > Ah, yes, that should be OK then. Please see

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

> On Dec 12, 2023, at 23:15, Ihor Radchenko wrote: > > This particular change should fit within TINYCHANGE, I think. So, you do > not need a copyright assignment (unless you have already exhausted the > 15LOC limit on Emacs patches, which I do not see in git logs). Ah, yes, that should be OK

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

Aaron Madlon-Kay writes: > OK this was also wrong, because seq only matches a finite sequence. I couldn’t > find a way to match an arbitrary-length list with pcase, so here’s my final > attempt: > > ... > This seems to handle all cases correctly, but again of course I leave the > details to the

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

t; existing > function is correct except that the list case should be wrapped in (seq …). OK this was also wrong, because seq only matches a finite sequence. I couldn’t find a way to match an arbitrary-length list with pcase, so here’s my final attempt: (defun org-entities--user-safe-p (v) &q

Re: [BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

defun org-entities--user-safe-p (v) "Non-nil if V is a safe value for `org-entities-user'." (pcase v (`nil t) ((seq `(,(and (pred stringp) (pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'"))) ,(pred stringp) ,(pred booleanp) ,(pred stringp)

[BUG] "Safe" local values for org-entities-user not recognized as such [9.6.11 (release_9.6.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

. Local definitions for `org-entities-user` are not recognized as "safe" even when they are in the correct format. For instance, including the following local variables list in an org-mode file will still result in Emacs prompting you to accept the value

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Ihor Radchenko writes: > I don't think so. We intentionally keep Org mailing list as a single > place for all the discussions, not just Org development. > AFAIU, Bastien is firmly into this policy (CCing him in case if I > misunderstood). You didn't misunderstood: I firmly believe that we

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Ihor Radchenko writes: > David Masterson writes: > >>> Would it help if we change it to >>> >>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg. >>> >>> ? >> >> Perhaps: >> >> Follow the link https://git.sr.ht/~bzg/worg for information (including >> cloning) on the WORG

Re: Suggestion: User-contributed use-cases on orgmode.org ?

David Masterson writes: >> Would it help if we change it to >> >> It is made of numerous .org files from https://git.sr.ht/~bzg/worg. >> >> ? > > Perhaps: > > Follow the link https://git.sr.ht/~bzg/worg for information (including > cloning) on the WORG Git repository at SourceHut

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Ihor Radchenko writes: > David Masterson writes: > >> I see no mention of "~bzg/org" in worg-about. > > Would it help if we change it to > > It is made of numerous .org files from https://git.sr.ht/~bzg/worg. > > ? Perhaps: Follow the link https://git.sr.ht/~bzg/worg for information

Re: Suggestion: User-contributed use-cases on orgmode.org ?

David Masterson writes: >> FYI, WORG is listed in "Repositories" right at https://sr.ht/~bzg/org/ > > I see no mention of "~bzg/org" in worg-about. > ... I think my lack of > experience for many years is showing -- I didn't think to click on the > ~bzg/worg link which would've told me about

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Ihor Radchenko writes: > David Masterson writes: > >> In worg-about, it looks like the repo is ~bzg/worg on src.ht, but "worg" >> doesn't come up in the project search on src.ht (but "org" does). Is >> the repo hidden (I don't have an account on src.ht yet -- perhaps >> sourcehut should be

Re: Suggestion: User-contributed use-cases on orgmode.org ?

David Masterson writes: > In worg-about, it looks like the repo is ~bzg/worg on src.ht, but "worg" > doesn't come up in the project search on src.ht (but "org" does). Is > the repo hidden (I don't have an account on src.ht yet -- perhaps > sourcehut should be explained a bit in worg-about).

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Corwin Brust writes: > On Tue, Nov 14, 2023 at 8:16 PM David Masterson wrote: >> >> Max Nikulin writes: >> >> > On 14/11/2023 15:36, Russell Adams wrote: >> >> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: >> >>> >> >>> Was thinking I'd like to see an archive of tagged

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Russell Adams writes: > On Tue, Nov 14, 2023 at 06:14:43PM -0800, David Masterson wrote: >> Russell Adams writes: >> >> > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: >> >> Just a suggestion (or maybe this is already handled?). >> >> >> >> Was thinking I'd like to see an

Re: Suggestion: User-contributed use-cases on orgmode.org ?

On Tue, Nov 14, 2023 at 06:14:43PM -0800, David Masterson wrote: > Russell Adams writes: > > > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: > >> Just a suggestion (or maybe this is already handled?). > >> > >> Was thinking I'd like to see an archive of tagged use-cases for Org

Re: Suggestion: User-contributed use-cases on orgmode.org ?

On Tue, Nov 14, 2023 at 8:16 PM David Masterson wrote: > > Max Nikulin writes: > > > On 14/11/2023 15:36, Russell Adams wrote: > >> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: > >>> > >>> Was thinking I'd like to see an archive of tagged use-cases for Org that > >>> could be

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Russell Adams writes: > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: >> Just a suggestion (or maybe this is already handled?). >> >> Was thinking I'd like to see an archive of tagged use-cases for Org that >> could be searched via tags or regexp. The use-cases should include

Re: Suggestion: User-contributed use-cases on orgmode.org ?

Max Nikulin writes: > On 14/11/2023 15:36, Russell Adams wrote: >> On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: >>> >>> Was thinking I'd like to see an archive of tagged use-cases for Org that >>> could be searched via tags or regexp. > [...] >> Have you looked at Worg? > >

Re: Suggestion: User-contributed use-cases on orgmode.org ?

On 14/11/2023 15:36, Russell Adams wrote: On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: Was thinking I'd like to see an archive of tagged use-cases for Org that could be searched via tags or regexp. [...] Have you looked at Worg? Specifically there is

Re: Suggestion: User-contributed use-cases on orgmode.org ?

On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: > Just a suggestion (or maybe this is already handled?). > > Was thinking I'd like to see an archive of tagged use-cases for Org that > could be searched via tags or regexp. The use-cases should include a > description of the

Suggestion: User-contributed use-cases on orgmode.org ?

Just a suggestion (or maybe this is already handled?). Was thinking I'd like to see an archive of tagged use-cases for Org that could be searched via tags or regexp. The use-cases should include a description of the problem, a general description of the answer, blocks of elisp (general code) to

Re: [BUG] Parser error: Invalid search bound (wrong side of point) [9.7 (9.7-??-e90a8a69a @ /home/user/.emacs.d/.local/straight/build-29.1/org/)]

hing else is necessary. > - Lorenzo > > > > Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, > cairo version 1.16.0) >  of 2023-08-24 > Package: Org mode version 9.7 (9.

[BUG] Parser error: Invalid search bound (wrong side of point) [9.7 (9.7-??-e90a8a69a @ /home/user/.emacs.d/.local/straight/build-29.1/org/)]

Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)  of 2023-08-24 Package: Org mode version 9.7 (9.7-??-e90a8a69a @ /home/user/.emacs.d/.local/straight/build-29.1/org/) current state: == (setq  org-link-elisp-confirm-function

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

"M. Pger" writes: > I understand better, thanks. Would be a good opportunity for me to (try to) > contribute; this weekend I will check carefully the link you've sent. I'll > keep you posted, your assistance would be more than welcome :) It has been a month since the last message in this

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

Hi, I understand better, thanks. Would be a good opportunity for me to (try to) contribute; this weekend I will check carefully the link you've sent. I'll keep you posted, your assistance would be more than welcome :) Best, MP Sent with Proton Mail secure email. --- Original Message

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

"M. Pger" writes: > Sorry for the possibly silly question, but by '+1', can I understand that you > will implement this feature because you think it is worth it? No, it just means that I think that this feature makes sense to be implemented. Basically, upvote. Whether I am going to implement

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

, but being able to truncate breadcrumbs from both sides would be even nicer^^ Best, MP --- Original Message --- On Tuesday, July 11th, 2023 at 11:30 AM, Ihor Radchenko wrote: > "M. Pger" mp...@protonmail.com writes: > > > Feature request: adjust ~org-agenda-format

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

"M. Pger" writes: > Feature request: adjust ~org-agenda-format-item~ to let the user choose the > first level included in breadcrumbs +1 -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at

Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

Dear All, Including "%b" in the org agenda prefix formats (org-agenda-prefix-format​) allows to display entries' outline paths, which is super useful to get project-oriented agenda views/todo-list. Consider a project 'Foobar Report'. In the agenda view/todo-list, it would look like the

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Subject: [PATCH] test-org-src.el: Work around `current-column' bug in older > emacs > > * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Work > around `current-column' not working in the presence of display strings > in older emacs. Applied, onto main.

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: We should probably reserve the workaround to Emacs 28 and older and eventually remove it when Org drops Emacs 28 support. Ok. I tested using Emacs 28 and 27 and your patch is passing all the tests. Thanks. -- Sébastien Miquel From

Re: [BUG] org-list-struct-apply-struct overrides src block indentation (was: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)])

Sébastien Miquel writes: > Ihor Radchenko writes: >> The cause is the following line in `org-list-struct-apply-struct' >> [[file:~/Git/org-mode/lisp/org-list.el::indent-line-to (+ >> (org-current-text-indentation) delta)))]] >> >> It calls `indent-line-to' that replaces spaces with tabs

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Ihor Radchenko writes: >> Sebastien, it looks like one of the tests is failing on the older Emacs: >> https://builds.sr.ht/~bzg/job/1020247 > > Does this specify anywhere what version of emacs it is using ? Yup. In the full log

Re: [BUG] org-list-struct-apply-struct overrides src block indentation (was: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)])

Ihor Radchenko writes: The cause is the following line in `org-list-struct-apply-struct' [[file:~/Git/org-mode/lisp/org-list.el::indent-line-to (+ (org-current-text-indentation) delta)))]] It calls `indent-line-to' that replaces spaces with tabs according to current value of

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: Sebastien, it looks like one of the tests is failing on the older Emacs: https://builds.sr.ht/~bzg/job/1020247 Does this specify anywhere what version of emacs it is using ? Most likely, because `current-column' did not take into account 'display property until

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: > Applied, onto main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2e2ed4055 Sebastien, it looks like one of the tests is failing on the older Emacs: https://builds.sr.ht/~bzg/job/1020247 Most likely, because `current-column' did not take into

[BUG] org-list-struct-apply-struct overrides src block indentation (was: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)])

Using a similar example, another indentation bug has been revealed: 1. emacs -Q 2. Create an Org file with the following contents: - 1 - 2 - 3 - 4 - 5 #+begin_src yaml a: b: c: d: #+end_src Everything indented using spaces, including "d:" that uses 8

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Ihor Radchenko writes: >> May you now rebase the patch onto the latest main, add a Link: to this >> discussion to the commit message, and apply the attached extra comments? > > Here it is. Thanks for helping with this. Applied, onto main.

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: May you now rebase the patch onto the latest main, add a Link: to this discussion to the commit message, and apply the attached extra comments? Here it is. Thanks for helping with this. -- Sébastien MiquelFrom 7906d7b7fa2d376e95156ab7177494f2cececaff Mon Sep 17

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > From 9d31a71bc0ab7cfd466ecad60037d00c62bdd9f6 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= > Date: Tue, 27 Jun 2023 09:23:01 +0200 > Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for > indentation Thanks! This looks good

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: For the second scenario, no special treatment of current line is needed. For the first scenario, why do we need to do it all the way in `org-src--contents-for-write-back'? Why not directly in `org-indent-line'? Ah, yes, that is much better. -- Sébastien MiquelFrom

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

. > 5. =org-src--contents-for-write-back= sees the current line is empty, > but it should indent it (with org indentation) nonetheless. Ok. I understand better now (I think). We are talking about \t#+begin_src bash \tcd foo \t#+end_src and user pressing Then, the expected result is \

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: What happens is: in the org buffer, the line is not empty, because it has the org indentation (which was possibly just added by org-indent-line), but in the edit buffer, the line is empty, because the common org indentation was removed. In that case, we want to add back

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > On second thought, I don't think moving the LaTeX fragment logic away > from `org-src--contents-for-write-back` makes sense. This part of the > function does the opposite of `org-do-remove-indentation`, and the > latter has a boolean argument `skip-fl`, so it makes

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

. I've taken this part off the patch for now. If source code in the edit buffer contains non-empty blank lines, it is not Org's responsibility to clear them. In fact, it will go against possible user settings! So, I agree that we should not indent empty lines. However, I do not agree that we should

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

e code in the edit buffer contains non-empty blank lines, it is not Org's responsibility to clear them. In fact, it will go against possible user settings! So, I agree that we should not indent empty lines. However, I do not agree that we should not indent non-empty blank lines. --- The code in your

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: But why do we need to avoid indenting empty lines? In the following link, Greg Minshal argues for preserving empty lines: https://list.orgmode.org/725763.1632663...@apollo2.minshall.org/T/ (CCing the mailing list) -- Sébastien Miquel

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > + ;; Trim contents: `org-src--contents-for-write-back' may have > + ;; added indentation at the beginning, which we remove. May you also mention that we remove the indentation to avoid adding spaces to latex fragments in the middle of a paragraph? >>>

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Hi Ihor, Thank you for the feedback. Ihor Radchenko writes: + ;; Apply WRITE-BACK function on edit buffer contents. + (goto-char (point-min)) + (when (functionp write-back) (save-excursion (funcall write-back))) (set-marker marker nil `save-excursion' is no longer

Re: [BUG] org-display-user-inline-images stops processing when a org-link type fails [9.7-pre (release_9.6.6-412-g2f7b35 @ /Users/dmg/.emacs.d/straight/build/org/)]

dmg writes: > I use org-yt (https://github.com/TobiasZawada/org-yt) to create > thumbnails of a youtube video in the orgfile (eg: yt:) > > When there is no Internet, the function responsible for retrieving the > thumbnail fails with an error. Unfortunately, > org-display-user-

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Here are two patches, the first that removes the special case logic > for LaTeX fragments, and the second that implements what you suggest, > and applies on top of the first one. Does that look ok to you ? Thanks! > + ;; Apply WRITE-BACK function on edit buffer

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: This is not a problem. We can just apply appropriate 'display property in `org-src-font-lock-fontify-block', manually replacing the tab with appropriate number of spaces (as in the origin buffer). Ok, that works, thanks. Here are two patches, the first that removes the

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Ihor Radchenko writes: >> May you please provide an example for such breakage? >> From my point of view, alignment is far lesser concern compared to >> indentation breaking code execution/tangling/other functional parts of Org. > > Let's say tab-width is 8 and

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: May you please provide an example for such breakage? From my point of view, alignment is far lesser concern compared to indentation breaking code execution/tangling/other functional parts of Org. Let's say tab-width is 8 and elisp-mode uses tabs for indentation. In

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > On second thought, I don't think that's a good idea. I did not > understand how tab characters worked: they do not have a fixed width, > but align to the next tab column. This means that if we add a couple > of spaces in front of a tab indented piece of code, we can

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: Should we use native buffer's value of =indent-tabs-mode= to set =use-tabs?= ? I think this trivial change should work. It doesn't seem quite that easy. If we want to add 4 columns to a tab indented line (and tab width is 8), we can either call =indent-to= to indent

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Hi Ihor, Ihor Radchenko writes: ...But I guess what you propose amounts to ... You are right. On second thought, I don't think that's a good idea. I did not understand how tab characters worked: they do not have a fixed width, but align to the next tab column. This means that if we add a

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: > Side note: It looks like `org-edit-special' docstring does not mention > all the cases it considers. In particular, latex fragments are not > mentioned. Fixed on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f8b0b2bab -- Ihor Radchenko //

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Ihor Radchenko writes: ...But I guess what you propose amounts to ... You are right. I'll try to write a patch, this week-end. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

t I don't think >>> so. LaTeX fragments, in particular $$…$$ fragments, can have >>> significant (for the user) newlines. >> >> May you provide an example? >> AFAIK, LaTeX usually treats newlines as whitespace, same with " ". > > When I say significant, I d

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

what we do for inline src blocks. See `org-babel--normalize-body'. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user) newlines. May you provide an example? AFAIK, LaTeX usually treat

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

for inline src blocks. See `org-babel--normalize-body'. > > I was not aware of how we treated inline src blocks, but I don't think > so. LaTeX fragments, in particular $$…$$ fragments, can have > significant (for the user) newlines. May you provide an example? AFAIK, LaTeX usually t

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

completely before editing the body here? Just like what we do for inline src blocks. See `org-babel--normalize-body'. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user) newlines. Here are thr

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Sébastien Miquel writes: > Ihor Radchenko writes: >> Confirmed. >> This is caused by `org-src--contents-for-write-back' not adjusting >> blank line indentation in some cases. > > I don't think that's the issue. In fact, applying your diff didn't > seem to solve the issue on my end. You are

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

Hi Ihor, wolf, Ihor Radchenko writes: Confirmed. This is caused by `org-src--contents-for-write-back' not adjusting blank line indentation in some cases. I don't think that's the issue. In fact, applying your diff didn't seem to solve the issue on my end. Generally, if you edit the given

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

wolf writes: > Reproduction steps: > 1. Have org-mode and yaml-mode installed. > 2. C-x C-f /tmp/x.org RET > 3. Type in: > > #+begin_src yaml > a: > b: > c: > d: > #+end_src > > After each line, press RET to go to the next one. RET is bound to org-return. > Notice that when

[BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

but emacs, so no user configuration is involved at all. Reproduction steps: 1. Have org-mode and yaml-mode installed. 2. C-x C-f /tmp/x.org RET 3. Type in: #+begin_src yaml a: b: c: d: #+end_src After each line, press RET to go to the next one. RET is bound to org-return. Notice

Re: #o544 is user rw?

Timothy writes: > Any objections? Fixed, by Timothy, on bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6a96054f0 -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at

Re: #o544 is user rw?

Hi Ruijie, > I’m looking at this `defcustom’, and its docstring looks wrong. It says > that #o544 corresponds to “u=rw,g=r,o=r”, but shouldn’t it be > “u=rx,g=r,o=r”? Something is wrong, unless there is another definition > of permissions that I’m not aware of. You are correct. I have a

#o544 is user rw?

ere---start->8--- (defcustom org-babel-tangle-default-file-mode #o544 "The default mode used for tangled files, as an integer. The default value 356 correspands to the octal #o544, which is read-write permissions for the user, read-only for everyone else." :group

Re: [BUG] I was asked to report this [9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/)]

c.bu...@posteo.jp writes: >> May you also provide the full text of the warning that asked you to >> send >> this bug report? > > Sorry, I'm not able to do that. I just send what was auto-generated for > that email. > I'm also not able to reproduce. > > It is not in the message buffer. It

Re: [BUG] I was asked to report this [9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/)]

Dear Ihor, thanks for reply. Am 29.03.2023 11:31 schrieb Ihor Radchenko: May you also provide the full text of the warning that asked you to send this bug report? Sorry, I'm not able to do that. I just send what was auto-generated for that email. I'm also not able to reproduce. It is not

Re: [BUG] I was asked to report this [9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/)]

> PDUMPER SECCOMP SQLITE3 THREADS XIM ZLIB") running in "tmux" over "ssh". > > Emacs : GNU Emacs 29.0.60 (build 1, aarch64-unknown-linux-gnu) > of 2023-03-28 > Package: Org mode version 9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/) May you also provide the

[BUG] I was asked to report this [9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/)]

ZLIB") running in "tmux" over "ssh". Emacs : GNU Emacs 29.0.60 (build 1, aarch64-unknown-linux-gnu) of 2023-03-28 Package: Org mode version 9.6.2 ( @ /home/user/.emacs.d/elpa/org-9.6.2/) current state: == (setq org-link-elisp-confirm-function 'yes-or-no-p or

Re: [PATCH] org-user-idle-seconds: Add support for logind

Nathaniel Nicandro writes: > From 1cc887d1378839c3322c93ebb5a524499b8d3073 Mon Sep 17 00:00:00 2001 > From: Nathaniel Nicandro > Date: Wed, 22 Mar 2023 14:54:57 -0500 > Subject: [PATCH] lisp/org-clock.el: Add support for logind Thanks! Applied, onto main. I added a changelog entry for

Re: [PATCH] org-user-idle-seconds: Add support for logind

Ihor Radchenko writes: > Nathaniel Nicandro writes: > >> I would like to submit a patch that adds support for logind to >> `org-user-idle-seconds`. This patch has been working for me for a long >> while now and I thought it time for me to submit it. I've contributed

Re: [PATCH] org-user-idle-seconds: Add support for logind

Hi, Ihor Radchenko writes: > Though I do not see any commits associated with Nathaniel Nicandro or > your email in Emacs git repo. > Bastien, may you check FSF records? Nathaniel's records are okay. -- Bastien Guerry

Re: [PATCH] org-user-idle-seconds: Add support for logind

Nathaniel Nicandro writes: > I would like to submit a patch that adds support for logind to > `org-user-idle-seconds`. This patch has been working for me for a long > while now and I thought it time for me to submit it. I've contributed > to Emacs in the past so my paperwork shoul

[PATCH] org-user-idle-seconds: Add support for logind

Hello, I would like to submit a patch that adds support for logind to `org-user-idle-seconds`. This patch has been working for me for a long while now and I thought it time for me to submit it. I've contributed to Emacs in the past so my paperwork should be on file. Let me know if any changes

[SECURITY] Tangling can overwrite arbitrary tangling targets, including important user files (was: [SECURITY] Arbitrary code evaluation security in Org)

Greg Minshall writes: > one additional item (i don't *think* we discussed this before; apologies > if i'm forgetting): tangling. if one is prompted to "merely" tangle ... > > #+begin_src sh :tangle /var/tmp/foo.org.tangled > echo 'hi!' > #+end_src > > > one could imagine more

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/)]

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.

Re: User

Hello Paul, As far as I know emacs 28 ships with org-mode 9.5. So if you have org-mode 9.4 you might have install an older version on top of this. When installing emacs 28 on window with a plain vanilla installation, M-x org-version, should give you 9.5. My best advice would be to try

Re: User

Paul Schlesinger writes: > Have been using org mode for more than 10 years and package manager since > emacs 26. When I moved to emacs > 28, the included org package was 9.4x and a nag message to install org from > the elpa repository appeared everytime > an org file is processed. I run

User

Have been using org mode for more than 10 years and package manager since emacs 26. When I moved to emacs 28, the included org package was 9.4x and a nag message to install org from the elpa repository appeared everytime an org file is processed. I run emacs on windows and list-packages does not

Re: [PATCH] Remove 'org-speed-commands-user' warning

Stefan Kangas writes: > Just a small cleanup in preparation of 9.6, see attached. Thanks! Applied. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f78dfea63 -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org

  1   2   3   4   5   6   7   >