Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

On 23/04/2024 18:47, Ihor Radchenko wrote: Max Nikulin writes: There should be a way to align tags for a specific heading even when `org-auto-align-tags' is nil. I can convert org-align-tags into a command. I would prefer to have C-u C-c C-q (`org-set-tags-command') applied just

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

Max Nikulin writes: > There should be a way to align tags for a specific heading even when > `org-auto-align-tags' is nil. > >> - (org-align-tags) >> + (when org-auto-align-tags (org-align-tags)) I can convert org-align-tags into a command. > Instead of re

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

Ihor Radchenko writes: > Upon further examination, I found that ^:{} does accept _only_ curly > braces: > ... > So, round braces can be seen as another variant of DWIM behavior. > > I conclude that there is no reason to change the existing syntax. > > I will need to update

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

On 19/04/2024 22:00, emm.charpent...@free.fr wrote: Embedding /home/charpent/WinFiles/Temporaire/Org/file:ltximg/EssaiSnippetsLaTeX_2923a1941c0e63eab69544afa1be2ec0d95a01c4.png as Images/0001.png... See Ihor Radchenko. Re: strange export problem with a file: link. Sat, 20 Apr 2024 12:25:56

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

- Mail original - > De: "Ihor Radchenko" > À: "Emmanuel Charpentier" > Cc: emacs-orgmode@gnu.org > Envoyé: Vendredi 19 Avril 2024 13:56:52 > Objet: Re: [BUG] LaTeX preview should use a subdirectory in /tmp > > Emmanuel Charpentier writes: >

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

Emmanuel Charpentier writes: >> What if you do M-x trace-function org-compile-file-commands > > No such function : I just have org-compile-file , which I traced. May you try the development branch of Org mode (main)? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

Le mercredi 17 avril 2024 à 22:41 +0200, Emmanuel Charpentier a écrit : [ Snip... ] A couple more data points : * The problem I described happens when I run `emacs` on files belonging in a Windows tree, symlinked to the Linux tree. Running `emacs` on files outside this symlinked tree works

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

On 17/04/2024 17:21, Ihor Radchenko wrote: Or maybe should we keep the status quo with ~org-auto-align-tags~ sometimes respected and sometimes not? I am rather neutral in respect to this change. I like that tags are aligned (so I am not going to set `org-auto-align-tags' to nil

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

Samuel Wales writes: > for some reason 9.6.22 says org-auto-align-tags is set to t by default. Hmm... That's a good reason. And I need to get some sleep. The default is really t. The change is still breaking though, but only for people who customized ~org-auto-align-tags~. -- Ihor Radchenko

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

for some reason 9.6.22 says org-auto-align-tags is set to t by default. [btw, i use proportional fonts, so org-tags-column is 0.] -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

Le mercredi 17 avril 2024 à 20:18 +, Ihor Radchenko a écrit : > Emmanuel Charpentier writes: [ Snip... ] > What if you do M-x trace-function org-compile-file-commands No such function : I just have org-compile-file , which I traced. > > and run the preview. > Then,

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

%O %F")) > > Nope, same problem : the *Org Preview LaTeX Output* buffer says : > > ../../../../../tmp/orgtexSyy18r.dvi: No such file or directory > This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson > > If I understand it correctly, the %F placeholder should be an &

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

same problem : the *Org Preview LaTeX Output* buffer says : ../../../../../tmp/orgtexSyy18r.dvi: No such file or directory This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson If I understand it correctly, the %F placeholder should be an *absolute* filename. It is not... Couldn't the output d

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

Emmanuel Charpentier writes: > I have a case where the current way of forcing the temporary directory > to me `/tmp` is wrong. Running emacs on Ubuntu **under WSL2**,, > exporting latex snippets to ODT *as images* fails : the `.dvi` files > are correctly compiled and placed in `/tmp{, but the

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

William Denton writes: > On Wednesday, April 17th, 2024 at 06:21, Ihor Radchenko > wrote: > >> I'd like to ask you, Org mode users, whether we should flip the default >> value of ~org-auto-align-tags~ to t or leave it as nil > > I use proportional fonts for regular

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

On 25/03/2024 19:49, Max Nikulin wrote: > > (defun org-ensure-tmp-dir (dir-symbol prefix) > >   (let ((dir (symbol-value dir-symbol))) > >     ;; Temporary directory has not been cleaned. > >     (or (and dir (file-directory-p dir) dir) > > >`if' sh

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

On 25/03/2024 19:49, Max Nikulin wrote: > > (defun org-ensure-tmp-dir (dir-symbol prefix) > >   (let ((dir (symbol-value dir-symbol))) > >     ;; Temporary directory has not been cleaned. > >     (or (and dir (file-directory-p dir) dir) > > >`if' sh

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

On Wednesday, April 17th, 2024 at 06:21, Ihor Radchenko wrote: > I'd like to ask you, Org mode users, whether we should flip the default > value of ~org-auto-align-tags~ to t or leave it as nil I use proportional fonts for regular text (with the mixed-pitch package). In this sit

Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere

Hello Ihor, Ihor Radchenko [2024-04-17 10:21 +]: > I'd like to ask you, Org mode users, whether we should flip the default > value of ~org-auto-align-tags~ to t or leave it as nil. I am voting for applying the change you propose and setting the default value of ~org-auto-align-tags

[POLL] Should we enable or disable automatic tag alignment by default everywhere

respect this option. However, because ~org-auto-align-tags~ is disabled by default, this will cause breaking change - there are many more commands in Org mode that re-align tags unconditionally compared to the commands that do take it into account. I'd like to ask you, Org mode users, whether we sho

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

Max Nikulin writes: > I think the following should be taken into account: behavior of popular > calendar applications, specifications they implement, libraries that > likely used to create such applications. ### what happens in google calendar if you repeat task monthly at 31st day

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

the following should be taken into account: behavior of popular calendar applications, specifications they implement, libraries that likely used to create such applications. Should it be configurable per user, per file, or even per rule (timestamp with repeater)? I am not familiar with RFC5545 iCalendar

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: >> I improved the patch a bit, with minor changes to the commit message and >> adding more to the docstring and type spec of the defcustom. I also >> changed the custom group (:group 'checkbox does not exist). > > Great. Thank you. It looks much better. > > But I

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Ihor Radchenko writes: > Thanks! > I improved the patch a bit, with minor changes to the commit message and > adding more to the docstring and type spec of the defcustom. I also > changed the custom group (:group 'checkbox does not exist). Great. Thank you. It looks much better. But I think

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)

jman writes: > I don't particularly have a skin in the game but I ask a question: what would > be the impact of this breaking change for users with existing Orgmode > documents? Mostly that people familiar with the current behaviour might be surprised. I am personally slightly in favour of

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)

> Generally, I did see several requests to change the strategy when > calculating next month/year. However, that would be a breaking change. > I'd only go for it if people are strongly in favor of the change. > So, changing this to a poll. I don't particularly have a skin in the game but I ask

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)

On Fri, Apr 05, 2024 at 06:34:29PM +, Ihor Radchenko wrote: > > In my opinion it should become "2025-02-28 Fri" instead. > > Keeping "end of a month" being end of a month is indeed an alternative > approach in such a situation. Both are possible; w

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: >> Do not forget to add :package-version. > > Thank you for bringing it to my attention. > > Patch in attachment. Thanks! I improved the patch a bit, with minor changes to the commit message and adding more to the docstring and type spec of the defcustom. I also

[POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)

2024-05-31 Fri ++1m> will become SCHEDULED: <2024-07-01 Mon ++1m> since 2024-06-31 does not exist. > In my opinion it should become "2025-02-28 Fri" instead. Keeping "end of a month" being end of a month is indeed an alternative approach in such a situation. Both ar

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Ihor Radchenko writes: > Do not forget to add :package-version. Thank you for bringing it to my attention. Patch in attachment. >From eb71166693065534be9effdc28aea54bb24e64d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C5=82awomir=20Grochowski?= Date: Sat, 16 Mar 2024 13:29:53 +0100 Subject:

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: > After thinking about I have found a better name: > ... > What do you think? Looks reasonable. > (defcustom org-columns-checkbox-allowed-values '("[ ]" "[X]") > "Allowed values for column with SUMMARY-TYPE that use checkbox." > :group 'checkbox > :type

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Ihor Radchenko writes: > It is not very clear when this feature is useful. May you provide a > small example as a part of the news entry and also > `org-columns-checkbox-states' docstring? Yes. You are right. Thank you. After thinking about I have found a better name: (defcustom

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: > After careful consideration, I believe it is most prudent to only > introduce a defcustom variable. This will allow for modification while > simultaneously preserving the current behavior. > ... > What do you think? > Patch in attachment. This patch will be an

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

After careful consideration, I believe it is most prudent to only introduce a defcustom variable. This will allow for modification while simultaneously preserving the current behavior. Currently we can change the value of "org-columns-checkbox" with the following keybindings: (1)C-c C-c

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

On 25/03/2024 19:49, Max Nikulin wrote: (defun org-ensure-tmp-dir (dir-symbol prefix)   (let ((dir (symbol-value dir-symbol)))     ;; Temporary directory has not been cleaned.     (or (and dir (file-directory-p dir) dir) `if' should be used instead of `or' here. (setf (symbol-value

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

On 25/03/2024 18:40, Ihor Radchenko wrote: Max Nikulin writes: This feature should not write temporary files to /tmp directly See the attached tentative patch. Thanks for prompt reaction. +++ b/lisp/org.el @@ -16361,7 +16361,7 @@ (defun org-create-formula-image org-format

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

Max Nikulin writes: > This feature should not write temporary files to /tmp directly, some > subdirectory should be created for this purpose. The idea is to mitigate > consequences if a user opens a file from a compromised or a malicious > source and gets /tmp flooded with a cr

[BUG] LaTeX preview should use a subdirectory in /tmp

This is a follow-up to recent changes related to LaTeX preview. This feature should not write temporary files to /tmp directly, some subdirectory should be created for this purpose. The idea is to mitigate consequences if a user opens a file from a compromised or a malicious source and gets

Re: [BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

Nick Dokos writes: >> The default value is nil. > > You are right... Canceled. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at

Re: [BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

Ihor Radchenko writes: > Nick Dokos writes: > >> If you load `ox-html`, the default value of >> `org-html-head-include-scripts` is nil, despite the defcustom: >> >> (defcustom org-html-head-include-scripts t ... > > Are you sure? What I am seeing in lisp/ox-html.el is > > (defcustom

Re: [BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

Nick Dokos writes: > If you load `ox-html`, the default value of > `org-html-head-include-scripts` is nil, despite the defcustom: > > (defcustom org-html-head-include-scripts t ... Are you sure? What I am seeing in lisp/ox-html.el is (defcustom org-html-head-include-scripts nil "Non-nil

[BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

If you load `ox-html`, the default value of `org-html-head-include-scripts` is nil, despite the defcustom: (defcustom org-html-head-include-scripts t ... The reason is that `org-expot-define-backend`, which is called

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: >> Except that we should not allow removing checkboxes and instead >> force empty checkbox with single prefix argument. > > And why do you want to avoid this? > When using 'org-column' I sometimes remove an empty checkbox. > So I

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

ix argument, set it > to ‘[-]’, which is considered to be an intermediate state. > Thank you for advice. I'm surprised I didn't think of it myself. It's a good idea to ensure consistency between 'org-checkbox' and 'org-columns-checkbox'. > Except that we should not allow removing

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

Ihor Radchenko writes: > "Fraga, Eric" writes: > >> On Saturday, 17 Feb 2024 at 14:06, Ihor Radchenko wrote: >>> Inconsistent with LaTeX syntax, Org mode not only allows >>> x^{superscript}, but also x^(superscript) with round braces used for >>> grouping. >> >> Inconsistent with LaTeX is not a

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: > Thank you for asking. > Yes, I would be interested. > I will prepare a patch. May I know if you had a chance to work on this? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at

Re: [BUG] we should obsolete org-fontify-whole-heading-line [9.7 (9.7-??-b127d72 @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

StrawberryTea writes: > We should make org-fontify-whole-heading-line default to t and obsolete > it. That variable was added before the introduction of the :extend > keyword for text properties. Now that we have :extend, we can make the > whole heading line face extend to the end o

[BUG] we should obsolete org-fontify-whole-heading-line [9.7 (9.7-??-b127d72 @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

Hello Org-Mode developers, We should make org-fontify-whole-heading-line default to t and obsolete it. That variable was added before the introduction of the :extend keyword for text properties. Now that we have :extend, we can make the whole heading line face extend to the end of the window

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

"Fraga, Eric" writes: > On Saturday, 17 Feb 2024 at 14:06, Ihor Radchenko wrote: >> Inconsistent with LaTeX syntax, Org mode not only allows >> x^{superscript}, but also x^(superscript) with round braces used for >> grouping. > > Inconsistent with LaTeX is not a sufficient reason for removing

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

On Saturday, 17 Feb 2024 at 14:06, Ihor Radchenko wrote: > Inconsistent with LaTeX syntax, Org mode not only allows > x^{superscript}, but also x^(superscript) with round braces used for > grouping. Inconsistent with LaTeX is not a sufficient reason for removing this, in my opinion. Org has

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

> On Feb 17, 2024, at 5:33 AM, Ihor Radchenko wrote: > > WDYT? +1 I use the curly braces since I often use underscores for other reasons. There would be no impact to me and this is the first I ever heard that parentheses would work.

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

+1 Tom > On Feb 17, 2024, at 9:38 AM, William Denton wrote: > > On Saturday, February 17th, 2024 at 07:07, Ihor Radchenko > wrote: > >> I tentatively propose to remove the x^(2-i) example from the docstring >> and mark the ^(...) syntax deprecated. >> >> WDYT? > > I think it's very

Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

On Saturday, February 17th, 2024 at 07:07, Ihor Radchenko wrote: > I tentatively propose to remove the x^(2-i) example from the docstring > and mark the ^(...) syntax deprecated. > > WDYT? I think it's very sensible. It's surprising ^(...) works like this, and if anyone was using it

[DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax? (was: Subscript with parenthesis)

Ihor Radchenko writes: > "Tom Alexander" writes: > >> Some additional things I'm noticing: >> >> - when using parenthesis, :use-brackets-p is nil, so they're not equivalent >> to curly braces. > > `org-element-subscript-parser' uses `org-match-substring-regexp', which > indeed allows

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

jos...@ushin.org writes: >> I did not make any changes to Org mode. And I will not, unless we need >> >> to pass this extra information to :follow functions. > > Thank you! I think we can close this issue. Can I close the issue myself? Sure. Handled. -- Ihor Radchenko // yantar92, Org mode

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

February 1, 2024 at 4:23 AM, "Ihor Radchenko" wrote: > > jos...@ushin.org writes: > > > > > > > > > > > What we can do then is pass an extra argument to :follow function - > > > > > the > > > > > > > > link object. That way, :follow function can get all the information > > > it > > >

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

jos...@ushin.org writes: >> > > What we can do then is pass an extra argument to :follow function - the >> > > link object. That way, :follow function can get all the information it >> > > needs. >> > > >> > >> > I like this idea! Would this change break existing :follow functions >> >

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

January 17, 2024 at 5:15 AM, "Ihor Radchenko" wrote: > > Joseph Turner writes: > > > > > > > > > May you please provide an example with an Org file containing file links > > > > > > and how you envision to transform them? Will they be transformed > > > > > > depending on the directory

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Thank you for asking. Yes, I would be interested. I will prepare a patch. Regards, Sławomir Grochowski On Tue, Jan 16, 2024 at 4:47 PM Ihor Radchenko wrote: > Ihor Radchenko writes: > > >> What do you think? > > > > I think that your use-case is not necessarily common enough to change > > the

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Joseph Turner writes: >> May you please provide an example with an Org file containing file links >> and how you envision to transform them? Will they be transformed >> depending on the directory the Org file is located in? > > I don't want to transform the file links. The idea is that an Org

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Ihor Radchenko writes: > Joseph Turner writes: > I'd like for users to be able to take an existing directory of Org mode documents and copy them all into a hyperdrive. I think the least surprising behavior is for the links between those files to continue working. Perhaps

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Ihor Radchenko writes: >> What do you think? > > I think that your use-case is not necessarily common enough to change > the defaults. But we can introduce a defcustom here. Patches welcome! Sławomir, would you be interested to submit a patch here? -- Ihor Radchenko // yantar92, Org mode

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Joseph Turner writes: >>> I'd like for users to be able to take an existing directory of Org mode >>> documents and copy them all into a hyperdrive. I think the least >>> surprising behavior is for the links between those files to continue >>> working. Perhaps the best option is for

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

t; only for relative links. >> >> Yes, there are many users who rely on [[file:/index.html]] exporting to >> instead of . > > This is not what Org HTML export does. Only relative links are affected > by `org-html-link-use-abs-url': > > Documentation > Should we prepend r

Re: Basic citations: should default citation style have a name and style code?

On Sunday, January 14th, 2024 at 03:26, András Simonyi wrote: > I'm not an active Ivy user (although I was in the past) but now I > tried it out with the basic cite-insert processor and "C-u C-j" seems > to be working as "empty input". Phew, what a morning. I removed Ivy, Swiper and Counsel

Re: Basic citations: should default citation style have a name and style code?

ut. This is so that you don't need to complete the top candidate, you can just hit a few characters and if the candidate you want is at the top, you can just hit RET. A consequence of this is that you cannot use RET to select the empty input. Both Ivy and vertico provide a command for that, though. I don

Re: Basic citations: should default citation style have a name and style code?

Dear All, On Sun, 14 Jan 2024 at 06:39, William Denton wrote: > > While we're talking about citations, I'm stuck on something else. If I run > > "C-c C-x @" to insert a citation into a file, I'm shown a list of > > bibliography entries and I can go up and down and hit RET on any I chose. > >

Re: Basic citations: should default citation style have a name and style code?

On Sunday, January 14th, 2024 at 00:08, William Denton wrote: > While we're talking about citations, I'm stuck on something else. If I run > "C-c C-x @" to insert a citation into a file, I'm shown a list of > bibliography entries and I can go up and down and hit RET on any I chose. > That

Re: Basic citations: should default citation style have a name and style code?

On Saturday, January 13th, 2024 at 14:03, Ihor Radchenko wrote: > I tried to clarify about the default style and #+cite_export keyword in > the manual: > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56f6d8d1a >

Re: Basic citations: should default citation style have a name and style code?

Ihor Radchenko writes: >> "Most scholarly works have citations and a bibliography or reference >> section," wrote a computer scientist [cite:@friends]. > >> As far as I can tell, there's nothing that can be done to the first >> citation object to make it use the "default" style. The >>

Re: Bug report for ox-icalendar: newlines should be CRLF

Jack Kamm writes: > I've pushed this change now: > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f4446ce795c924a1e115e360d3674f6ad89be845 Fixed. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development

Re: Basic citations: should default citation style have a name and style code?

On Thursday, January 11th, 2024 at 13:07, Ihor Radchenko wrote: > Another way is [cite/style-that-surely-does-not-exist:@friends] Useful, thanks. The same thing happens with cite_export: these don't match any real options so they fall through to the defaults. #+cite_export: basic stuff

Re: Basic citations: should default citation style have a name and style code?

William Denton writes: >> You can just use [cite/nil:@friends]. > > Huh! Thanks, I didn't see that at all. Looking again at the definition of > org-cite-basic-export-citation in oc-basic.el, I see the doc string says, > "Export CITATION object. STYLE is the expected citation style, as a pair

Re: Basic citations: should default citation style have a name and style code?

On Thursday, January 11th, 2024 at 07:30, Ihor Radchenko wrote: > > As far as I can tell, there's nothing that can be done to the first > > citation object to make it use the "default" style. The > > document-level setting makes a new default, and because the original > > "default" has no name

Re: Basic citations: should default citation style have a name and style code?

William Denton writes: > "Most scholarly works have citations and a bibliography or reference > section," wrote a computer scientist [cite:@friends]. > As far as I can tell, there's nothing that can be done to the first > citation object to make it use the "default" style. The >

Re: Basic citations: should default citation style have a name and style code?

Hi Bill, On Thursday, 11 Jan 2024 at 05:25, William Denton wrote: > The basic citation processor is a proof of concept and shouldn't be > used for real work, so this is probably never going to result in a > real problem. Proof of concept or not, the fact that it exists means people (e.g. me)

Basic citations: should default citation style have a name and style code?

ct to make it use the "default" style. The document-level setting makes a new default, and because the original "default" has no name or style code, there's no way to get at it. The basic citation processor is a proof of concept and shouldn't be used for real work, so this is pr

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

instead of . This is not what Org HTML export does. Only relative links are affected by `org-html-link-use-abs-url': Documentation Should we prepend relative links with HTML_LINK_HOME? Absolute links always remain absolute. >> Why not make [[hyper:/README.org]] use the "default&

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Ihor Radchenko writes: > Joseph Turner writes: > >>> It would be more reliable to provide a separate link type. >>> We might even extend the special file+application: link type syntax that >>> already allows special behavior for opening file links. >> >> Thank you! Would you explain about

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Joseph Turner writes: >> It would be more reliable to provide a separate link type. >> We might even extend the special file+application: link type syntax that >> already allows special behavior for opening file links. > > Thank you! Would you explain about extending file+application syntax?

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Joseph Turner writes: > - When handling "file" type links, check if `org-current-uri-scheme' > matches one of the keys in `org-link-parameters', and use the > appropriate handler instead of the "file" handler. (see attached patch > for an example usage in `org-link-open') Please ignore the last

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Ihor Radchenko writes: > Joseph Turner writes: [...] > Thanks for reporting! > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d15e52fef Thank you for the quick fix! >> In hyperdrive.el currently, "[[/foobar]]" and "[[file:/foobar]]" have >> different

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

Joseph Turner writes: > I expect the following to return "[[/foobar]]": > > (with-temp-buffer > (delay-mode-hooks (org-mode)) > (insert "[[/foobar]]") > (goto-char (point-min)) > (let ((link (org-element-link-parser))) > (org-element-link-interpreter link nil))) > > Instead, it

Should org-link-parser add type "file" when link has no "file:" prefix?

Hello! I expect the following to return "[[/foobar]]": (with-temp-buffer (delay-mode-hooks (org-mode)) (insert "[[/foobar]]") (goto-char (point-min)) (let ((link (org-element-link-parser))) (org-element-link-interpreter link nil))) Instead, it returns "[[file:/foobar]]". In

Re: [QUESTION] Should KEYWORD values in org-export-options-alist be lowercase?

Niall Dooley writes: > Should the KEYWORD values in `org-export-options-alist' that are > uppercase be lowercase to reflect what users see say when using a > template and/or for consistency? > > Similarly, for the KEYWORD values in :options-alist in > `org-export-define-ba

[QUESTION] Should KEYWORD values in org-export-options-alist be lowercase?

Should the KEYWORD values in `org-export-options-alist' that are uppercase be lowercase to reflect what users see say when using a template and/or for consistency? Similarly, for the KEYWORD values in :options-alist in `org-export-define-backend' for example in ox-latex.el? For example the TITLE

Re: [BUG] Should we remove the obsolete org-contrib/org-track.el?

Bastien Guerry writes: > Indeed, done! Fixed.

Re: [BUG] Should we remove the obsolete org-contrib/org-track.el?

Ihor Radchenko writes: > Shall we remove the obsolete org-track.el? > It is an obsolete library, marked obsolete 11 years ago, inside > minimally maintained repository. I suspect that it is now safe to remove > it :) Indeed, done! -- Bastien Guerry

[BUG] Should we remove the obsolete org-contrib/org-track.el?

Shall we remove the obsolete org-track.el? It is an obsolete library, marked obsolete 11 years ago, inside minimally maintained repository. I suspect that it is now safe to remove it :) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at .

[SOLVED] (was: certain files should not be folded)

>>> "FE" == Fraga, Eric writes: > I'll let others chime in because I definitely get the file with > everything opened. Maybe tell us what version of org and emacs you are > using and also what happens if you start emacs with -Q to not include > your customizations? I am an idiot. I debugged my

Re: certain files should not be folded

>>> "FE" == Fraga, Eric writes: > I'll let others chime in because I definitely get the file with > everything opened. Maybe tell us what version of org and emacs you are > using and also what happens if you start emacs with -Q to not include > your customizations? Right I assume I have to

Re: certain files should not be folded

I'll let others chime in because I definitely get the file with everything opened. Maybe tell us what version of org and emacs you are using and also what happens if you start emacs with -Q to not include your customizations? -- : Eric S Fraga, with org release_9.6.7-661-g34ee6f in Emacs

Re: certain files should not be folded

>>> "FE" == Fraga, Eric writes: > On Friday, 24 Nov 2023 at 18:47, Uwe Brauer wrote: >> Since I am not sure what are precisely these VISIBILITY properties, > By VISIBILITY properties, I meant literally that: any properties > labelled as VISIBILITY. But obviously you don't have any! >> here

Re: certain files should not be folded

On Friday, 24 Nov 2023 at 18:47, Uwe Brauer wrote: > Since I am not sure what are precisely these VISIBILITY properties, By VISIBILITY properties, I meant literally that: any properties labelled as VISIBILITY. But obviously you don't have any! > here is one example file which works just fine

Re: certain files should not be folded

>>> "FE" == Fraga, Eric writes: > The default is to show everything. Do you have an VISIBILITY properties > in the file? Since I am not sure what are precisely these VISIBILITY properties, here is one example file --8<---cut here---start->8--- #+STARTUP:

Re: certain files should not be folded

The default is to show everything. Do you have an VISIBILITY properties in the file? -- : Eric S Fraga, with org release_9.6.6-418-g294a4d in Emacs 30.0.50

certain files should not be folded

Hi I tried to follow https://orgmode.org/manual/Initial-visibility.html and put, for example, #+STARTUP: nofold or #+STARTUP: showall or #+STARTUP: showeverything But it did not work I close and open the file, but all headers are folded, what do miss here. Thanks Uwe Brauer -- I

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: > But why is it allowed in '(org-toggle-checkbox TOGGLE-PRESENCE)'. > To set a normal checkbox to 'partial state'? > Description from function: 'With a double prefix argument, set the checkbox > to "[-]".' > > Probably it should not be

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Yes. You are right. After thinking about it I think the same. But why is it allowed in '(org-toggle-checkbox TOGGLE-PRESENCE)'. To set a normal checkbox to 'partial state'? Description from function: 'With a double prefix argument, set the checkbox to "[-]".' Probably it should not

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

Sławomir Grochowski writes: > I was wondering how many states a checkbox has. > Based on https://orgmode.org/manual/Checkboxes.html I conclude that there > are 3 states: > 1. [ ] - not done > 2. [ - ] - an intermediate state > 3. [X] - done > > So I think all 3 st

  1   2   3   4   5   6   7   8   9   10   >