[POLL] Setting `org-adapt-indentation' to nil by default?

Various discussions convinced me that `org-adapt-indentation' should be nil by default. With `electric-indent-mode' being activated by default in Emacs, the current behavior is that RET after a headline moves the point below the beginning of this headline, not the beginning of the line, which

Re: [Feature Request] More flexibility in org-speed-commands customization

Hi Gustavo, Gustavo Barros writes: > A possible way to mitigate breakage here can be at hand, since we > ended up with a third name (a proper one, btw). You could mark > `org-speed-commands-user' as obsolete but keep it, for the due time as > usual, and append it to `org-speed-commands'

Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]

Gustavo Barros writes: > This way it would be > possible to toggle the markers selectively, as it is done with the > links. I'm not sure this is granted, but one reasonable hypothesis > why `org-link' was used there in the first place is that some degree > of selective toggling of the markers

bug#48149: 27.2; Wrong underline width when the line char has a width of 2

> Date: Sun, 02 May 2021 10:12:43 +0900 > From: Shingo Tanaka > > When exporting org-mode document to plain text (either ascii/unicode/utf-8) > with `org-export-dispatch', Emacs inserts lines under headlines, inline > tasks, table rows and titles of the document, TOC, list of listings, list of >

Re: [POLL] Breaking change: removing `org-speed-commands-user'

* Bastien [2021-05-02 09:08]: > As discussed in https://orgmode.org/list/87v9hzzhrn@gmail.com the > proposal is to allow users to customize *all* speed keys, not just > some of them through `org-speed-commands-user'. > > By merging `org-speed-commands-default' and `org-speed-commands-user' >

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

Hello, Eli Zaretskii writes: >> Date: Sun, 02 May 2021 08:52:13 +0900 >> From: Shingo Tanaka >> >> For example, when the title is "ＡＢＣＤＥＦ" (each character has width of >> 2), expected title would be like: >> >> ━━━ >> ＡＢＣＤＥＦ >>

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

* Bastien [2021-05-02 09:10]: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the beginning of this

Re: [POLL] Breaking change: removing `org-speed-commands-user'

Bastien writes: > As discussed in https://orgmode.org/list/87v9hzzhrn@gmail.com the > proposal is to allow users to customize *all* speed keys, not just > some of them through `org-speed-commands-user'. > > By merging `org-speed-commands-default' and `org-speed-commands-user' > into a

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Bastien writes: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the beginning of this headline, not the

Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

Hi Gustavo, Gustavo Barros writes: > I just tested the fix and, indeed, > `org-insert-heading-respect-content' no longer breaks the structure of > the first heading. However, if I may add a nitpick, the value of > `org-blank-before-new-entry' does not seem to be honored in this case. > For

Re: [PATCH] Bug: fragile org refile cache

Maxim Nikulin writes: > Some additions. org-outline-path-cache is used solely by > org-refile-get-targets (maybe there are some calls in other packages) > but it efficiency is questionable. It was not clear for me earlier that > the cache is reset before each scan through a buffer. So if >

Re: [PATCH] Bug: fragile org refile cache

Tim Cross writes: > I suspect the reason it is not done automatically is that getting that > right for all use cases is very hard to do without adding adverse impact > to performance. A cache which is marked as 'dirty' too often results in > too frequent cache refresh operations, but at the same

[POLL] Breaking change: removing `org-speed-commands-user'

As discussed in https://orgmode.org/list/87v9hzzhrn@gmail.com the proposal is to allow users to customize *all* speed keys, not just some of them through `org-speed-commands-user'. By merging `org-speed-commands-default' and `org-speed-commands-user' into a single `org-speed-commands' option,

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

> Date: Sun, 02 May 2021 08:52:13 +0900 > From: Shingo Tanaka > > For example, when the title is "ＡＢＣＤＥＦ" (each character has width of > 2), expected title would be like: > > ━━━ > ＡＢＣＤＥＦ > ━━━ > >

[PATCH] org-test: Fix wrong-numbre-of-arguments error on master+native-comp

Running make test on master using Emacs master compiled with native-comp support throws error: decode-time((22352 22528) nil nil) time-to-days((22352 22528)) org-time-stamp-to-now("2016-06-03 Fri") org-deadline-close-p("2016-06-03 Fri" 0) apply(org-deadline-close-p ("2016-06-03 Fri" 0))

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

On Sunday, 2 May 2021 at 08:09, Bastien wrote: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. I have this set to nil in any case, in combination with org-indent-mode and visual-line-mode, so would not have any problem with the change. I do think a

Re: Separator "::" -> what is it for in headlines?

Hi! I have updated to: GNU Emacs 27.2 (build 1, i686-w64-mingw32) Org mode version 9.4.5 (9.4.5-29-gc43041-elpa Same issue: * *To **the left of* :: it's bold Note: I coudn't find Org mode version 9.5, just 9.4.5 Best regards, Ypo El 01/05/2021 a las 19:18, Diego Zamboni escribió: Why

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

(resent: some receiving server complained about multiple recipients blah blah so I am testing with just the org mode mailing list as the recipient; apologies for noise if you receive this twice) On Saturday, 1 May 2021 at 12:04, Nicolas Goaziou wrote: > BTW, I would like to amend the proposed

Re: prettify-symbols-mode in org agenda?

Ihor Radchenko writes: > This change is needed, for example, when you change todo-state using > `org-agenda-todo'. Refreshing the agenda line in > org-agenda-highlight-todo involves > > (insert (format org-agenda-todo-keyword-format s)) > > `insert' will destroy the 'composition as 'composition

Re: <> and ?font-lock? fly-check, ...

I don't think there's an easy way to fix this - since src blocks are fontified using the mode for the corresponding language. Particularly in shell script, since << has a meaning in the language ("here" input), I assume this is why the rest of the block gets fontified differently. Best, --Diego

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Bastien writes: > I suggest (setq org-adapt-indentation 'headline-data). With electric-indent-mode turned off, that is. -- Bastien

Re: [PATCH] org-test: Fix wrong-numbre-of-arguments error on master+native-comp

Hi Ihor, applied in maint as commit 0e7153e63, thank you very much! -- Bastien

Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

Hi Eric and all, Thank you for your comments. Eric S Fraga writes: > What is being proposed looks reasonable to me. I don't use =verse= very > often but have used it now and again and I can particular see the need > for numbering and centring, in particular. Indeed, optical centering is the

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

Eli Zaretskii writes: > I'm not sure what kind of example is necessary. How about if you ask > specific questions about the arguments of that function which you > don't understand clearly how to use? Fair enough. However, i don't think my misunderstanding is related to arguments of that

Re: Separator "::" -> what is it for in headlines?

Ypo writes: > Same issue: > * *To **the left of* :: it's bold I can reproduce. The issue appears only in level 1 headlines because of wrong regexp in font-lock-keywords. The attach patch should fix the problem. Best, Ihor >From 791471a5f28723f5d3b34a9345795e0f2902b9b6 Mon Sep 17 00:00:00 2001

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Jean Louis writes: > * Bastien [2021-05-02 09:10]: >> Various discussions convinced me that `org-adapt-indentation' should >> be nil by default. >> >> With `electric-indent-mode' being activated by default in Emacs, the >> current behavior is that RET after a headline moves the point below

bug#48149: 27.2; Wrong underline width when the line char has a width of 2

> From: Rudolf Schlatte > Date: Sun, 02 May 2021 10:36:14 +0200 > > > You reported a similar bug already, and I replied there that TRT in > > these cases is to use window-text-pixel-size, which will automatically > > account for the actual width on display of any characters and any > > fonts

Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

(resent: some receiving server complained about multiple recipients blah blah so I am testing with just the org mode mailing list as the recipient; apologies for noise if you receive this twice) On Saturday, 1 May 2021 at 12:58, Bastien wrote: > I'm copying Eric, a poweruser of the LaTeX

Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

Eric S Fraga writes: > Is the verse package loaded automatically already? I did not see any > change in the patch to that aspect and when I export a simple test, the > package is not loaded. Wouldn't it be nice if there was something in-between loading the kitchen sink and manually adding

Re: prettify-symbols-mode in org agenda?

Ihor Radchenko writes: > See the updated patch. Thanks, it works quite nice now on the agenda line. The only issue I still see, is that when you org-agenda-redo-all, or org-agenda-log-mode (which triggers org-agenda-redo-all), the prettify gets lost again. Maybe org-buffer-substring-fontified

<> and ?font-lock? fly-check, ...

hi, all. using a <> reference in a bash source block, the buffer's font lock colors go south on lines folowing the <> reference. (in my case, all remaining lines in the buffer are colored bright yellow). the major and minor modes are as listed below. is there an obvious thing to do to either

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

> From: Nicolas Goaziou > Cc: shingo@gmail.com, 48...@debbugs.gnu.org > Date: Sun, 02 May 2021 14:18:24 +0200 > > My problem is that I have some string, _which is not displayed anywhere_ > yet. I need to obtain its real width along with the width of a single > character in order to compute

Re: prettify-symbols-mode in org agenda?

William Xu writes: > Now I try to test it extensively. Even with all your changes, I find > when I use org-agenda-todo to change the todo-state inside the agenda > buffer, the new state isn't always prettified. > > Do you see the same behaviour? Oops. Yes, I do see the same behaviour. I only

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

Thank you for the advice. I see that `window-text-pixel-size' returns true displayed width but I think that's TRT for only the other bug I reported (bug#48149). These two bugs looks similar but the root causes are completed different. This bug (bug#48148) is actually caused by the difference of

[PATCH]: org-columns does not respect global-visual-line-mode for long text within headlines

I've done some more research on https://orgmode.org/list/875z02si3g@nicolasgoaziou.fr/, and I believe the issue is that `org-columns' is setting `truncate-lines' as t, while `global-visual-line-mode' is expecting it to be set to nil. The interaction between the two causes the wrapping to

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Jean Louis writes: >> Indentation is quite sensitive: what do you think of setting a new >> default value of nil for `org-adapt-indentation' in Org 9.5? > > Yes, it should be nil just as it was in beginning. I think `org-adapt-indentation' has always been `t' by default. > But there is one

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

> From: Nicolas Goaziou > Cc: Shingo Tanaka , 48...@debbugs.gnu.org > Date: Sun, 02 May 2021 10:23:34 +0200 > > > The accurate method of lining up in these cases is to use > > window-text-pixel-size instead. That function will return the exact > > width of a string as it will displayed, in

Re: [PATCH] org-protocol: Fix missing '+' in js snippet

On 30/04/2021 14:21, Bastien wrote: Maxim Nikulin writes: On 28/04/2021 12:40, Bastien wrote: Would you like to volunteer as the maintainer for org-protocol.el? For now org-protocol.el indicates that Sebastian Rose, the original author, is the maintainer, but I don't think he would mind

Re: stability of toc links

Hello, Timothy writes: > Nicolas Goaziou writes: > >> I pointed out some concerns I have about the robustness of this system >> already. I don't think you answered to any of them. I fear we may be >> communicating past each other in this thread. > > Sorry about that. I'll try to address the

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

> Date: Sun, 02 May 2021 20:33:23 +0900 > From: Shingo Tanaka > Cc: Nicolas Goaziou , > shingo@gmail.com, > 48...@debbugs.gnu.org > > This bug (bug#48148) is actually caused by the difference of the width > detection methods between line 1036 in ox-ascii.el (`length') and >

bug#48149: 27.2; Wrong underline width when the line char has a width of 2

Eli Zaretskii writes: >> Date: Sun, 02 May 2021 10:12:43 +0900 >> From: Shingo Tanaka >> >> When exporting org-mode document to plain text (either ascii/unicode/utf-8) >> with `org-export-dispatch', Emacs inserts lines under headlines, inline >> tasks, table rows and titles of the document,

Re: Notes about citations in Org (part 3)

Nicolas - just a little question on one detail: On Thu, Apr 29, 2021 at 10:06 AM Nicolas Goaziou wrote: > On a citation key, "follow" capability moves point to the > corresponding entry in the current bibliography. Elsewhere on the > citation, it asks the user to follow any of the keys cited

Re: [PATCH] ob-plantuml: Add PlantUML block post-processing.

Hi Bastien, Bastien writes: > Nick Daly writes: > >> +(org-babel-plantuml-post-process out-file) > > Note that I had to remove the line above from your second patch. > > Can you confirm it is not necessary for your second patch to work? Yes, I can confirm that

Re: Notes about citations in Org (part 3)

Hello, "Bruce D'Arcus" writes: > Nicolas - just a little question on one detail: > > On Thu, Apr 29, 2021 at 10:06 AM Nicolas Goaziou > wrote: > >> On a citation key, "follow" capability moves point to the >> corresponding entry in the current bibliography. Elsewhere on the >> citation, it

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

> Detlef Steuer writes: > Am Sun, 02 May 2021 08:09:02 +0200 schrieb Bastien : >> Various discussions convinced me that `org-adapt-indentation' >> should be nil by default. >> >> With `electric-indent-mode' being activated by default in Emacs, >> the current

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

> From: Nicolas Goaziou > Cc: shingo@gmail.com, 48148-d...@debbugs.gnu.org > Date: Sun, 02 May 2021 17:56:04 +0200 > > More than the width of the text, I'm interested in the > ratio between the width of the text and the width of an underline > character (assuming monospace). And that is

Re: <> and ?font-lock? fly-check, ...

Diego and Sébastien, thank you both. in particular, i didn't know about =org-babel-noweb-wrap-start=, and that's probably perfect for this case. cheers, Greg

Re: [Feature request] String escaped noweb expansion

Sébastien Miquel writes: > #+BEGIN_SRC latex :noweb-ref latex-ref > \some \multiline > \unescaped \latex \code > #+END_SRC > > #+BEGIN_SRC emacs-lisp :noweb yes > (setq my-latex-code "<>\n") > #+END_SRC > > I don't think there's any way to achieve such functionality currently. Just quickly,

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Am Sun, 02 May 2021 08:09:02 +0200 schrieb Bastien : > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the

Re: [Feature Request] More flexibility in org-speed-commands customization

Hi Bastien, On Sun, 02 May 2021 at 03:29, Bastien wrote: Indeed, I have some code ready for this in an updated version of the patch. So the change won't be that "breaking" but let's still assess whether it will break many configurations. Looks good to me. Thank you. Gustavo.

Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]

Hi Bastien, On Sun, 02 May 2021 at 03:30, Bastien wrote: Gustavo Barros writes: This way it would be possible to toggle the markers selectively, as it is done with the links. I'm not sure this is granted, but one reasonable hypothesis why `org-link' was used there in the first place is

bug#48149: 27.2; Wrong underline width when the line char has a width of 2

Hello, Shingo Tanaka writes: > When exporting org-mode document to plain text (either ascii/unicode/utf-8) > with `org-export-dispatch', Emacs inserts lines under headlines, inline > tasks, table rows and titles of the document, TOC, list of listings, list of > tables and footnotes. The

Re: [PATCH]: org-columns does not respect global-visual-line-mode for long text within headlines

Hi Nick, Nick Savage writes: > The attached patch ensures the behaviour is correct when > `global-visual-line-mode' is enabled and that there are no behaviour > changes when it has not already been enabled. Applied in maint with commit cb0ef1280. Thanks! -- Bastien

Re: Notes about citations in Org (part 3)

On Sun, May 2, 2021 at 10:51 AM Nicolas Goaziou wrote: > `org-open-at-point' will try to find key "a" in the current > bibliography. Got it. I was thinking maybe it would complete the key. That can be for other developers to add. Would it be possible for you, or someone else on the list, to

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Bastien writes: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the beginning of this headline, not the

Re: <> and ?font-lock? fly-check, ...

Hi Greg, Greg Minshall writes: is there an obvious thing to do to either get whatever syntax checker is running to ignore the <> reference, or some such? From the org side of things, you could customize the variables `org-babel-noweb-wrap-start` and `org-babel-noweb-wrap-end` to something that

bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

Eli Zaretskii writes: >> From: Nicolas Goaziou >> Cc: shingo@gmail.com, 48...@debbugs.gnu.org >> Date: Sun, 02 May 2021 14:18:24 +0200 >> >> My problem is that I have some string, _which is not displayed anywhere_ >> yet. I need to obtain its real width along with the width of a single >>

Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

Hi Bastien, On Sun, 02 May 2021 at 03:54, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I just tested the fix and, indeed, `org-insert-heading-respect-content' no longer breaks the structure of the first heading. However, if I may add a nitpick, the value of

bug#48149: 27.2; Wrong underline width when the line char has a width of 2

> From: Nicolas Goaziou > Date: Sun, 02 May 2021 18:08:50 +0200 > Cc: 48...@debbugs.gnu.org > > > In case of 1), it correctly takes account of the case in which the character > > has a width of 2 in `org-ascii--build-title', by dividing the line width by > > `(char-width under-char)' (line

[Feature request] String escaped noweb expansion

Hi, Would there be some interest in extending the noweb syntax to allow for string escaped expansion ? I've modified my setup so that if the noweb delimiter `<<` is preceded by a quote `"` then the expansion is string escaped (and the prefix isn't duplicated for each line). This allows the

Re: Separator "::" -> what is it for in headlines?

Hi Ihor, Ihor Radchenko writes: > I can reproduce. The issue appears only in level 1 headlines because of > wrong regexp in font-lock-keywords. The attach patch should fix the > problem. Applied in maint, thanks a lot! -- Bastien

Re: [PATCH] ob-plantuml: Add PlantUML block post-processing.

Nick Daly writes: > Yes, I can confirm that `org-babel-plantuml-post-process` is not > necessary for the second patch. That was a line accidentally left over > from the first, larger, patch. Thanks Nick for confirming. -- Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Hi Bastien, Strong +1 here. Users can get the same visual effect without materializing the whitespace into the file. Materializing the whitespace causes many potential issues with source blocks for languages that have significant whitespace, issues with #+begin_src and #+end_src having

Re: <> and ?font-lock? fly-check, ...

Hi Greg, A slightly different suggestion that doesn't break other org processors (which might not allow users to change org-babel-noweb-wrap- values) is to prefix the names of the blocks with & (e.g. <<>>) as I do in multiple places in

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

On 5/1/2021 11:09 PM, Bastien wrote: With `electric-indent-mode' being activated by default in Emacs, the current behavior is that RET after a headline moves the point below the beginning of this headline, not the beginning of the line, which might surprise users. Indentation is quite

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

* Tim Cross [2021-05-02 11:52]: > > Jean Louis writes: > > > * Bastien [2021-05-02 09:10]: > >> Various discussions convinced me that `org-adapt-indentation' should > >> be nil by default. > >> > >> With `electric-indent-mode' being activated by default in Emacs, the > >> current behavior is

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Bastien writes: > Indentation is quite sensitive: what do you think of setting a new > default value of nil for `org-adapt-indentation' in Org 9.5? I think that makes sense. If the controversy over the electric-indent-mode change taught me anything, it's that a lot of people don't expect their

[PATCH]: Add elisp snippet to worg/org-contrib/org-mac.org

Hello, At the recommendation of Tim Cross I've prepared a patch to worg to include the elisp that I recently sent to the list that I've been using to create TODO items based on the currently selected macOS Mail.app message.

Re: [PATCH] Fontification for inline src blocks

Hi Timothy, It seems to work more or less as expected. A few comments below. Best, Tom 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. 2. I'm also not sure that this approach to

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

+1 from me. It is nil in my config, which feels better to me.

Re: wip-cite status question and feedback

While evaluating different aspects of punctuation moving I had another look at the csquotes package. p. 21 f. and p. 27 ff. in the manual (http://mirrors.ctan.org/macros/latex/contrib/csquotes/csquotes.pdf) are quite instructive.[1] This package a structured representation of a quotation,

Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

Re: [Feature request] String escaped noweb expansion

Hi Sebastien, I have encountered issues with this before when trying to noweb code into a string that was code to be sent via ssh. I ended up switching to use typeset -f in bash in most cases now, but that is not possible for other languages. Some languages also have enough different types of

Re: Notes about citations in Org (part 3)

Hello, "Bruce D'Arcus" writes: > I was thinking maybe it would complete the key. That can be for other > developers to add. You missed the "basic" part in "oc-basic.el". ;) You can write a function for creating citations with completion outside of the oc API. > Would it be possible for you,

Re: [PATCH] Fontification for inline src blocks

It would be good to hear if anyone has been able to test this, and if so what your experience has been :) -- Timothy

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

> Will this handle LaTeX macros[1] gracefully and other things intended as raw > LaTeX? > [1] https://pandoc.org/MANUAL.html#latex-macros This only affects LaTeX fragments, and then it's just changing \(\) / \[\] for $ / $$. I don't think this has any effect on your concerns. -- Timothy

About multilingual documents

Hi all, I'm curious to see how other Org users deal with multilingual documents, that is, those documents (for example, philology or linguistics texts) that contain a significant number of online quotes in other languages. Naturally, this makes more sense in the LaTeX backend, since it is

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

* Bastien [2021-05-02 11:59]: > Bastien writes: > > > I suggest (setq org-adapt-indentation 'headline-data). > > With electric-indent-mode turned off, that is. That is it, thank you. That combination comforts my personal habbits. But that need not stop changes in Org mode of course, unless

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

I frequently need to escape commas in macros, which is a bit of a pain and easy to forget. My most frequent use case is a macro that expands in ODT export to a margin comment (like #+begin_annotation does, but without causing a line break). It takes one argument which typically consists of

Re: [Feature request] String escaped noweb expansion

Timothy writes: Just quickly, this works: #+begin_src emacs-lisp :noweb yes (setq my-latex-code "\ <> ") #+end_src I don't understand the purpose of your backslash, is it a typo ? With or without it, this doesn't tangle to working lisp with my example. The point of my proposal is to allow

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Hello, Tom Gillespie writes: > Materializing the whitespace causes many potential issues with source > blocks for languages that have significant whitespace, issues with > #+begin_src and #+end_src having different levels of indentation > (still an issue if you want a block in a plain list),

Re: [Feature request] String escaped noweb expansion

Sébastien Miquel writes: > The point of my proposal is to allow one to write unescaped latex in > the latex src block. (Mostly to avoid doubling every backslash). It is > quite the shame to have to write non latex code in a latex src block. Ahhh, sorry --- I focused on the wrong part of your

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Hi Nicolas, Sorry, I did not mean to imply that such things were not possible currently. I was writing in the context of how to specify the current behavior formally. As you point out they absolutely are possible. More replies in line. Best, Tom > This is inaccurate. > > The following is a

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Tom Gillespie writes: > Yes. My question is about how to deal with cases like > > --8<---cut here---start->8--- > 1. foo > > #+begin_src emacs-lisp > (+ 1 1) > #+end_src > > 2. bar > --8<---cut here---end--->8--- >

Re: Notes about citations in Org (part 3)

On Sun, May 2, 2021 at 3:32 PM Nicolas Goaziou wrote: > Make sure to checkout "wip-cite-new". Once there, you run "make". > > Then, the following mini-init.el file should be enough. Perfect; thank you! So if I want to add to that mini-init file the config so that the basic processor is

Re: stability of toc links

Nicolas Goaziou writes: > Please note that those short answers did not help me much. So I did my > homework and looked at your code. I didn't test it thoroughly, so I may > be missing something. It's a pity to hear that I wasn't able to suitably clarify things in my reply. Thank you for being

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

* Bastien [2021-05-02 11:57]: > Jean Louis writes: > > >> Indentation is quite sensitive: what do you think of setting a new > >> default value of nil for `org-adapt-indentation' in Org 9.5? > > > > Yes, it should be nil just as it was in beginning. > > I think `org-adapt-indentation' has

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

* Bastien [2021-05-02 11:57]: > Jean Louis writes: > > >> Indentation is quite sensitive: what do you think of setting a new > >> default value of nil for `org-adapt-indentation' in Org 9.5? > > > > Yes, it should be nil just as it was in beginning. > > I think `org-adapt-indentation' has

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

Hello Nicolas, In my plea for patch feedback email, Bastien said he'd like to leave this patch to your discretion. As such, it would be fantastic if you might be able to provide your thoughts on this. All the best, Timothy.

Re: How to use `open` to handle `message:*` links on macOS

Hi Alexander, On Thu, Apr 29, 2021 at 7:38 PM Alexander Adolf < alexander.ad...@condition-alpha.com> wrote: > Tim Visher writes: > > > Pairing that with my org-capture TODO Current Mail Template is a dream > come > > true. :) > > [...] > > That's interesting how you pull the information from

Re: [PATCH] Fontification for inline src blocks

Thanks for trying this! Tom Gillespie writes: > Hi Timothy, >It seems to work more or less as expected. A few comments below. Best, > Tom > > 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

Re: [PATCH] Fontification for inline src blocks

> I see. I imagine the expected behaviour of such a function would be to > toggle org-inline-src-prettify-results and redisplay? Yeah, see org-toggle-link-display for inspiration I think. ;;;###autoload (defun org-toggle-link-display () "Toggle the literal or descriptive display of links."

Re: [PATCH] Fontification for inline src blocks

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

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

Hi Steven, "Steven Bagley" writes: > In emacs -Q: > > 1. M-x org-mode > 2. insert the following line in the buffer (created by > org-mac-grab-link) > > - [[https://rgoswami.me/posts/org-note-workflow/][An Orgmode Note > Workflow :: Rohit Goswami Reflections]] > > 3. You can't follow the link

Re: [PATCH]: Add elisp snippet to worg/org-contrib/org-mac.org

Hi Tim, Tim Visher writes: > At the recommendation of Tim Cross I've prepared a patch to worg to > include the elisp that I recently sent to the list that I've been > using to create TODO items based on the currently selected macOS > Mail.app message. > > Let me know if there's anything I can

Re: <> and ?font-lock? fly-check, ...

Tom, that is quite devious, actually. thank you very much! do you know, by the way, what flycheck and/or the shell make the "<<&" construct out to be? cheers, Greg

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

Jean Louis writes: > * Tim Cross [2021-05-02 11:52]: >> >> Jean Louis writes: >> >> > * Bastien [2021-05-02 09:10]: >> >> Various discussions convinced me that `org-adapt-indentation' should >> >> be nil by default. >> >> >> >> With `electric-indent-mode' being activated by default in

Re: wip-cite status question and feedback

On the substance of these rules, my conclusion (and Denis knows this are better than I, so can amend this) is the primary difference between what Chicago calls "American" punctuation rules and "British" is that the former puts trailing punctuation within the closing quote, and the latter does not,

Re: wip-cite status question and feedback

On Sun, May 2, 2021 at 5:59 PM Denis Maier wrote: > I'm thinking whether this could make the system more flexible and > adaptable. We'd still need to discuss details of course (like including sensible defaults, etc.) if this were possible, but Denis and I agree that having a second optional

Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]

Hello Bastien, Many thanks, I was waiting for feedback but it seems that nobody complained. On Sunday, 2 May 2021 at 05:52, Bastien wrote: > Hi Damien and Jeremie, > > Jeremie Juste writes: > >> The following patch will at least harmonize the results towards the >> data.frame. > > I see the

  1   2   >