Re: Minimal Gnus setup for test purposes

Jens Schmidt writes: > More notes: Don't know if this is well-suited to ol-gnus hacking, but the gnus-mock package on GNU ELPA might be of interest? I have faint memories of using it once or twice to debug & fix Gnus problems.

Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

Kévin Le Gouguec writes: > Here are the stats for today: And today's session: > org-element-cache-hash-show-statistics: >> 19.32% of cache searches hashed, 11.88% non-hashable. 23.65% of cache searches hashed, 17.88% non-hashable. > emacs-uptime: >> 10 hours, 50 minutes,

Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

Hey Ihor, Ihor Radchenko writes: > If you are ok with sharing the statistics, and you are running Emacs > session for at least few hours (using Org mode, obviously), please reply > sharing the output of > M-x org-element-cache-hash-show-statistics > M-x emacs-uptime Here are the stats for

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

Ihor Radchenko writes: > Kévin Le Gouguec writes: > >> Just to make sure I understand this new setting correctly: by default, >> despite org-cycle-hide-drawer-startup being t, it's ineffectual, because >> org-startup-folded defaults to 'showeverything, right? >

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

Ihor Radchenko writes: > Thanks for the heads-up! > Fixed on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4323a19b1 > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=47bcdce19 Fixes duly noted, thanks  Just to make sure I understand this new

9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

Hey Org, Trying out Emacs 29 and going over ORG-NEWS, this item stands out to me: > *** A new custom setting =org-hide-drawer-startup= to control initial folding > state of drawers A quick grep for org(-cycle)?-hide-drawer-startup turns this up: File: etc/ORG-NEWS 459 27 *** A new custom

Re: Setting org-todo-keywords through directory-local variables

Ihor Radchenko writes: > [sending to Org ML in-reply to the relevant thread] [Thanks!] > Kévin Le Gouguec writes: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003 > 28.1.90; Can local variables be loaded before loading major mode? > >> … reminded me of a patch I

Re: [FR] [Revived] Human readable / customizable link anchors during export

Ihor Radchenko writes: > Kévin Le Gouguec writes: > >>> 3. Instead of trying to find a silver bullet for human-readable anchor >>>generator, we allow users to customize it. The default will be >>>constant "org" yielding "org-Ajjq"-t

Re: [FR] [Revived] Human readable / customizable link anchors during export

Ihor Radchenko writes: > 3. Instead of trying to find a silver bullet for human-readable anchor >generator, we allow users to customize it. The default will be >constant "org" yielding "org-Ajjq"-type anchors, just like we have >now. But we can also provide other generators, like the

Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch

Ihor Radchenko writes: > I think I addressed the raised issues. > Just merged org-fold upstream.  > Kévin Le Gouguec writes: > >> My recipe (based on commit f9dd109bc, Emacs 29.0.50 commit 864c8013fd): >> >> $ git switch feature/org-fold-universal-core-tidy >

Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch

Hey Ihor! Ihor Radchenko writes: > This is the final version of the patch. I am going to merge it this > weekend. If there are any comments, please send them ASAP. I've thrown a couple of LOGBOOK-heavy Org files at your branch; I'm observing something that I can't make sense of. I tried to

New folding backend & outline (was: [PATCH 22/35] ORG-NEWS: Add list of changes)

Ihor Radchenko writes: > + =outline-*= functions may no longer work correctly in Org mode > + > +The new folding backend breaks some of the =outline-*= functions that > +rely on the details of visibility state implementation in > +=outline.el=. The old Org folding backend was compatible

bug#52587: 29.0.50; Wrong block header/footer background in Org

Protesilaos Stavrou writes: > On 2021-12-26, 22:04 +0100, Rudolf Adamkovič wrote: > >>> - Create a file with demo content, such as ~/test-org-block.org >>> - Execute 'emacs -Q' on the command-line. >>> - M-x load-theme RET modus-operandi >>> - C-x C-f test-org-block.org RET > > Gotcha! I can

bug#52399: 28.0.60; easier access to ORG-NEWS

Kyle Meyer writes: >> 3. The entry in NEWS for the Org mode update mentions ORG-NEWS, but it >> doesn't say how to get to it. (Yes, I know how to get to ORG-NEWS from >> NEWS. Do we expect random users to understand the layout of an >> installed Emacs at that level of detail?) > > And I guess

Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]

Ingo Lohmar writes: > It seems the change was introduced in > 565361eb698b0b39c1d823ad1565f5bd88fa2034 and persists. > > Can people actually enter "C-c C-TAB" into their emacs (how?), or has > everybody has just bound another key in their config? Mmm, I can't seem to input C-c C-TAB either.

Re: [PATCH] Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]

Uwe Brauer writes: >>>> "KLG" == Kévin Le Gouguec writes: > >> I've applied your fix on top of 281a0e26b; AFAICT it works as expected. > > I applied the patch on top of e2fa3c4c4046b6, (Me too actually; 281a0e26b is the commit ID I got by applying Ihor

Re: [PATCH] Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]

Ihor Radchenko writes: >The tentative fix is attached, but please > double check because I am not very familiar with the indentation code. I've applied your fix on top of 281a0e26b; AFAICT it works as expected. Thanks for cooking up a test case! 'make check'

Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]

Uwe Brauer writes: > In the attached file Maybe I missed it, but I don't think your report included an attachment? I went with the two example files you showed in the previous discussion; cf. my own attachments. > I do: > > M-: (setq org-adapt-indentation

Re: [BUG in org master?]

Tim Cross writes: > The effect of org-adapt-indentation is somewhat confusing to say the > least. The effect of that setting is also dependent on the setting for > electric-indent-mode. Getting the desired result often depends on having > the right setting for both that variable and

Re: [BUG in org master?]

Uwe Brauer writes: >> In Org 9.5, setting org-adapt-indentation to 'headline-data makes >> :DRAWERS: indented (setting it to t makes everything but headlines >> indented). > > Thanks, but it did not work. I set the variable > org-adapt-indentation to 'headline-data makes > > > But when I opened

Re: how to indent (or refill) properties

Uwe Brauer writes: > But I would like them to be indented like this > > ** DONE G1:H1:G1: > :PROPERTIES: In Org 9.5, setting org-adapt-indentation to 'headline-data makes :DRAWERS: indented (setting it to t makes everything but

bug#51167: 29.0.50; org-indent-line broken

Andreas Röhler writes: > On 13.10.21 09:34, Kévin Le Gouguec wrote: >> >> "Modern" did not factor in; the goal was to have RET and C-j behave >> consistently in all major modes. > > That does not deliver an argument to change the meaning of RET. If there is

bug#51167: 29.0.50; org-indent-line broken

Andreas Röhler writes: > Sounds like a chain of confusion. > > A command called "indent-line" definitely should indent. org-indent-line indents just like every indentation function in every other major mode: if the syntactic convention calls for it, it indents or de-indents the current line;

bug#51167: 29.0.50; org-indent-line broken

Andreas Röhler writes: > With following stuff in org-mode buffer: > > * bla > asd > > M-x org-indent-line RET on second line has no effect. Org 9.5 changed the default value of org-adapt-indentation from t to nil, as that seemed to be what a lot of users expect[1], so org-indent-line should not

Re: Sad tweet

(Took the liberty of CC'ing Jonas to make sure he can correct any mischaracterization, and to show our support, such as it is) band...@gnu.org writes: > Ypo writes: > >> I've read this: >> >> "Contributing to Emacs is so frustrating. It's not worth it for minor >> things and if I cannot get some

Re: Bug: spurious change in list indent cursor motion [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]

Greg Minshall writes: > Kevin, > >> FWIW, during the latest poll somebody suggested making org-indent-line >> cycle through "syntactically valid" indentation levels when hitting TAB >> repeatedly, like python-indent-line-function; I like this idea. > > i think (*) the current "master" branch

Re: Bug: spurious change in list indent cursor motion [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]

Nicolas Goaziou writes: >> Note also that "- a" goes >> back to column 0. (FWIW I think that's a bit unwieldy; going back to >> column 0 on the /second/ would make more sense to me, as >> it would correspond to a "paragraph break") > > It would make it painful to insert a blank line within a

Re: Bug: spurious change in list indent cursor motion [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]

James Powell writes: > I open a new file, /tmp/demo.org, and I start a new list > by typing "- a".  It appears: > > - a > > What I expect: my cursor should now be at column 0.  This was the > behavior in 9.3.6 and it makes perfect sense. > > What happens instead: after upgrade to 9.4.4, the

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

Bastien writes: >> It is now, as of commit 0a651b746. > > ... and I broke some tests. Sorry for that. I will fix this next > week, unless someone does it before me. Here are two patches that set org-adapt-indentation to t for the tests which were implicitly relying on that behavior; that lets

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

Bastien writes: > Kévin Le Gouguec writes: > >> Great! One last snag that I can see: when inserting properties or >> clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented, >> but the /first/ :property: or CLOCK: line remains at column 0. > > Er

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

Bastien writes: > Kévin Le Gouguec writes: > >> A fews more moles to whack, maybe: >> >> - RET after an ":END:" starts an indented line, >> - "* headline RET text TAB" indents "text" (and subsequent RETs are then >> indente

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

Tim Cross writes: > Jean Louis writes: > >> If I set `org-adapt-indent' to 'headline-data, I get that same >> behavior that after pressing ENTER on headline line, position becomes >> indentend. So it does not make it right. >> >> My favour was the behaviour how it was before introduction of >>

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

Kévin Le Gouguec writes: > 'headline-data sounds like a reasonable default too, although I think it > still has some wrinkles[2]. > > [2] Typing "* headline RET" starts an indented line; further RETs keep > point indented until I type in something, after which RET

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

Re: Org 9.4.5

Detlef Steuer writes: > Would it be possible to have the changelog in the mail announcements? > Either as an attachment or just copied verbatim? FWIW, if you have the org-mode repo handy, you can hew out a GNU-style changelog with *breathes in* $ git log release_9.4.4..release_9.4.5

Re: Turning off all indentation in 9.4.4

Raoul Comninos writes: > I noticed a change in org since I updated to the latest version when it > comes to automatic indentation. I prefer to turn this off globally, > including for lists. I have tinkered with various settings but have had > no luck so far. ORG-NEWS provides these hints: > To

Re: org-fontify-done-headline t by default?

TRS-80 writes: > The change was so jarring, and in total contravention of my (otherwise) > nice looking Nord theme. Something like that might have put me off from > Orgmode /completely/ if I did not know how to quickly fix it. > > For all of above reasons (and probably some others, too!), I do

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > Kévin Le Gouguec writes: > >> 1.2. stumps me: is there an isearch API I can use while in the callback >> to know where the matches are located? > > I do not think that there is direct API for this, but the match should > be accessible throug

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > However, org-cycle-hide-drawers might be called in > isearch-open-invisible-temporary. This callback receives two arguments: - the overlay which contains a match, - whether we are un-hiding the overlay's span or hiding it back. To get the same behaviour as

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > My current plan is supporting the overlay-based approach even after > merging the branch (by default). So, overlays should be around for a > while and the issue with drawer visibility will be around as well, > unless you fix it. I will probably work on this in distant

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > Kévin Le Gouguec writes: > >> Since the changes in Org 9.4 aimed at improving performance, is there a >> test case somewhere in the "Mitigating the poor Emacs performance on >> huge org files" thread that could help ensure that a

Re: did behaviour of RET change again?

Bastien writes: > I see something wrong right now: RET after a headline should only try > to indent below the beginning of the headline with org-adapt-indentation > is t, but not nil or headline-data. > > For now, when org-adapt-indentation is headline-data, RET still indents. > > I will see

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > You will probably need to implement this from scratch (or use the > feature/org-fold branch from github.com/yantar92/org). Gotcha. TBH I don't know if I'll have the time to cook up a patch before 27.2 is released; all the same, I appreciate you taking the time to

Re: [9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > Kévin Le Gouguec writes: > >> The debugger only fires *after* we exit isearch, and by that time it's >> too late: my issue comes from all those logbooks cluttering the screen >> while I'm mashing C-s to iterate through matches. >&

[9.4] Fixing logbook visibility during isearch

Ihor Radchenko writes: > However, I can try to suggest a way to fix the issue on master. The way > isearch handles folded text in org is set from org-flag-region > (org-macs.el): > > (overlay-put o > 'isearch-open-invisible > (lambda ( _) (org-show-context

[PATCH][9.4] Mention org-adapt-indentation as escape hatch in ORG-NEWS

If it's not too late for this to make it into 27.2, I think this could make dealing with the electric-indent-mode kerfuffle easier for unsuspecting users. >From 829a98c8ee4ba8b914b9ac81bae510ae6f2820aa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= Date: Fri, 11 Dec 2020

Org 9.3.8 for Emacs 27.2?

Hi Org, It seems the Emacs maintainers are gearing up for the release of 27.2, the first bugfix version of Emacs 27[1][2]. 27.1 ships with Org 9.3, which has seen its last bugfix release with 9.3.8. Is there any way we[3] can help bring 9.3.8 into the emacs-27 branch in time for 27.2? Thanks

Re: Changed list indentation behavior: how to revert?

Tim Cross writes: > I am a little confused about the purpose of org-adapt-indentation > though. According to the org news file, to get back the old behaviour, > it says to explicity disable electric-indent mode using org-mode-hook. > There is no mention of org-adapt-indentation. Yep; as I

Re: Changed list indentation behavior: how to revert?

Jean Louis writes: > There is just slight difference, and that is what I learned from > introduction to Org mode that it is "plain text" kind of mode. I can > do and write how I wish. My habit comes from being used to indent when > I want and then to follow indentation in that specific

Re: Changed list indentation behavior: how to revert?

Detlef Steuer writes: > I'm constantly bitten by that change, but was too lazy to dig for the > cause. But now that I know, I want to add 2c. > > If one writes prose it looks much more natural to have > > * Healine > > start editing in column 1 of next row. > (Personally I would prefer to start

Re: Changed list indentation behavior: how to revert?

Jean Louis writes: > Indentation in fundamental mode: > > ** HereRET > I come here. > But only if I start indenting >Like hereRET >Then I continue here Hi Jean, My understanding of electric-indent-mode is that it tries to make "RET" equivalent to "insert newline; indent according to

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

Ihor Radchenko writes: > Thanks for reporting! I accidentally reintroduced the bug because of > mistake when converting org-hide-drawers to new folding library. > (:facepalm:). > > Should be fixed in the gist now. Can confirm, thanks! I understand from your answer to Bastien's query that this

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

Ihor Radchenko writes: >>> then M-x toggle-debug-on-error and M-: (org-make-manuals), but I can't >>> get a stacktrace. I'm guessing this is because this error (which IIUC >>> originates from org-back-to-heading in org.el) is a user-error; however, >>> if I change the function to raise a

Re: Default description for abbreviated links

Hello Bastien! Thank you for following up on this. Bastien writes: > Kévin Le Gouguec writes: > >> I like #+LINK keywords because they make documents self-sufficient: >> anyone opening my document can follow these links or export the buffer; >> they do not need to run

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

Hi! Ihor Radchenko writes: > The current version of the patch (against master) is in > https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef I'm probably missing something obvious, but when applying your patch on top of master[1], make fails when generating manuals: > emacs -Q

Check for master branch from Elisp (was: Release 9.3.8)

Kyle Meyer writes: > Can't you inspect the return value of org-git-version? That can work out, though unless I'm missing something, I need to move to the org-mode repository, ask "git branch --contains", and parse the output. Possible, but somewhat involved. (TIL: git-describe's

Re: Release 9.3.8

Bastien writes: >> - Will Emacs's maintenance branch (emacs-27) be updated with Org 9.3.8, >> so that Emacs 27.2 includes all bugfixes for 9.3? (If so, I can open >> a new report on Debbugs to track this, as suggested by Stefan K.) > > Yes, thanks. ACK; see bug#43268! >> - During the

Re: Release 9.3.8

Bastien writes: > Hi all, > > I'm releasing Org 9.3.8, a bugfix release. > > Enjoy! Thanks for this release  > The next release will be 9.4: if you have outstanding important bugs > you would like to point to or to report, please go ahead. No bug to report, however I've got a couple of

Re: [b...@gnu.org: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer]

> Boruch Baum writes: > >> In org-mode, when POINT is moved over an org-mode link, wouldn't it be >> reasonable for the value of that link to appear in the mini-buffer? The >> advantage of that is the user would know where the link points and what >> would happen if the link is opened (eg. would

Re: Bug#42184: org-fontify-whole-*-line in emacs 27

Kyle Meyer writes: > Okay, let's go with > > `((t :inherit shadow ,@(and (>= emacs-major-version 27) '(:extend t > > as the org-block spec then. Done; patch attached. >From 41ab9f8f0c2f02f1951a412265b01a9ac5fa5a96 Mon Sep 17 00:00:00 2001 From:

Re: Bug#42184: org-fontify-whole-*-line in emacs 27

Kyle Meyer writes: >> +(defmacro org--extended-face (attributes) >> + "Make face that extends beyond end of line. >> + >> +Up to Emacs 26, all faces extended beyond end of line; getting >> +the same behaviour starting with Emacs 27 requires :extend t." >> + `(nconc ,attributes (when (>=

Re: Bug#42184: org-fontify-whole-*-line in emacs 27

Kyle Meyer writes: > Kévin Le Gouguec writes: > >> Since 27.1-rc1 is out, I'd like to bump this; it'd be a shame if 27.1 >> shipped with this bug, which seems to be getting some attention (I just >> spotted a Reddit thread[1] about it, in addition to the origi

Re: Bug#42184: org-fontify-whole-*-line in emacs 27

/why_does_my_orgmode_look_different_to_leuven/ Kévin Le Gouguec writes: > Could Org maintainers weigh in on bug#42184? > > To recap my understanding of the issue: > > - org-fontify-whole-heading-line controls whether > org-set-font-lock-defaults includes the final newline in the headline >

[PATCH] Fix recommendation in ORG-NEWS (was: Binding RET to org-return-and-maybe-indent)

Jarmo Hurri writes: > Kévin Le Gouguec writes: > >> Can you tell me whether electric-indent-local-mode works better for >> you? If it does, I'll followup with a patch to ORG-NEWS. > > Seems to be working fine. Thank you very much. Thanks for the confirmation. Here

Re: Binding RET to org-return-and-maybe-indent

Jarmo Hurri writes: > * Demo of the effect of disabling elint > 1. Save this org into file =org-elint-disable.org= > 2. Save the following elisp into =minimal-org.el=, replacing the > location of org mode with your path: > > #+begin_src elisp >(add-to-list 'load-path

Re: Binding RET to org-return-and-maybe-indent

Jarmo Hurri writes: >> #+begin_src emacs-lisp >> (add-hook 'org-mode-hook (lambda () (electric-indent-mode -1))) >> #+end_src > > Unfortunately this has side effects: it changes at least the way > parentheses and indentation interact when opening a Babel source code > block. It might be a good

Re: Binding RET to org-return-and-maybe-indent

Jarmo Hurri writes: > Is there any downside to binding RET to org-return-and-maybe-indent? > > I want to remove RET indentation in org mode. For example > > # --- > * Demo of indentation > - when I press return at the end of the word

Default description for abbreviated links

Hello Org, I like #+LINK keywords because they make documents self-sufficient: anyone opening my document can follow these links or export the buffer; they do not need to run some Elisp to add to org-link-parameters. One thing I don't know how to customize, however, is how these links are

Re: Couple of issues with org block meta lines faces

Hi! Some points I think I can help with: Sébastien Miquel writes: >  1) begin-line applies to both begin and end lines. This might be > intended. If you define an org-block-end-line face, it gets applied instead. Yup, by default org-block-end-line :inherits from org-block-begin-line. >  

Re: [9.4] LOGBOOK visibility

Thank you for taking the time to make this write-up. Nicolas Goaziou writes: > With overlays, you can't have your cake > and eat it too. FWIW, I think Emacs has a branch (feature/noverlay) which has been reported to improve performance with overlays. AFAICT

Re: [9.4] LOGBOOK visibility

Ihor Radchenko writes: > (see the discussion in [1]). Ah, that makes sense! No idea how I managed to miss that thread. > I am currently working on a patch to rewrite the whole folding system. > Your issue should disappear once it is applied. Good to know! > Meanwhile, you

Re: [9.4] LOGBOOK visibility

I haven't reached the bottom of this rabbit hole yet. Since I think I've spent all the time I had to spend in this issue for the day, here's where I'm at. If I open my example file[1] with Org 9.3 and master (86fada6b5), and compare the overlays covering the hidden part of the first LOGBOOK

Re: [9.4] LOGBOOK visibility

Kévin Le Gouguec writes: > For example, in the attached file, if I search for "bug#5": > > - Org 9.3 keeps the drawers closed, > - Org 9.4 opens every drawer for bugs 4, 5 and 6. > > AFAICT Org 9.3 never opened these drawers unless either > org-startup-fold

[9.4] LOGBOOK visibility

Hi, I've noticed that LOGBOOK drawers are now (9.4) open by default when visiting an Org file, AFAICT as a result of org-startup-folded now defaulting to showeverything. That's not much of a problem by itself; what I find more of a hindrance is that even with "#+STARTUP overview", when one

Re: Breaking line inside list item

Sébastien Miquel writes: >> There is RET or C-j, depending on your settings. > > C-j (~org-return-indent~) does work, thank you. Just a heads-up: the next version of org-mode (9.4) will obey electric-indent-mode, which is a global minor mode that is turned on by default. When this mode is

Re: Setting org-todo-keywords through directory-local variables

Hello, I would like to re-submit this idea, now that I am reasonably sure that my implementation will not impact users who do not use the feature. (I understand that Org 9.4 is on the way. I am not asking for this feature to be included right now; I would like to get some feedback first, then

Re: [RFC] Rewrite org-(forward|backward)-paragraph

Hi Nicolas! I don't know how useful my feedback will be, since I'm not a heavy user of paragraph-based movement[1], but here goes! Nicolas Goaziou writes: > In any case, the purpose of this rewrite is to mimic more closely > expected behaviour from `forward-paragraph' and `backward-paragraph'

Re: Possible fix for :includes header argument in org-babel C source blocks

Bastien writes: > Brandon Guttersohn writes: > >> So this patch is sort of a >> new feature, but a trivial one. > > Agreed. Could you or Kevin propose a sentence to advertise this small > enhancement in etc/ORG-NEWS? Here goes nothing. >From b18f6dc66ea4a05c95a4ee6825723da4beaa1c83 Mon Sep

Re: Failing tests

Kévin Le Gouguec writes: > Absolutely. I've attached a patch to that effect. I just realized that these let-bindings probably deserved explanatory comments. Here is an updated patch: >From f996ec3a10a845abae2fa463ab0ea7a761af1707 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vi

Re: Failing tests

Kyle Meyer writes: >> I think I've narrowed this down to org-open-file running "less >> examples/att1/fileA" instead of visiting this file. > [...] >> Let-binding org-file-apps to '(("." . emacs)) makes the tests pass, but >> I don't know if that's the way we want to solve this. > > Thanks for

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

Eli Zaretskii writes: > Fixed. AFAICT you've scared the moles away, so I'll boldly close this report. Thanks a lot for the efficient whacking! (I guess xdisp.c is something we won't to touch with a 10-foot pole on the release branch, especially for a bug that users have lived with for so

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

Eli Zaretskii writes: > Should be fixed now on the master branch. Thanks a lot! I'm sorry I didn't notice it earlier, but I may have found another mole for you to whack; starting with the same recipe: > - emacs -Q > - C-x C-f repro.org > - M-x org-indent-mode > - M-: (insert "*

Failing tests (was: Possible fix for :includes header argument in org-babel C source blocks)

Kyle Meyer writes: > The source for that page is in the worg repo: > https://code.orgmode.org/bzg/worg/src/master/org-contrib/babel/languages/ob-doc-C.org Thanks for the pointer, and for applying the patches! >>> FAILED ob-tangle/jump-to-org >>> FAILED test-org-attach/dir > > :( > >

Re: Possible fix for :includes header argument in org-babel C source blocks

Brandon Guttersohn writes: > Apologies for the regression, and thank you for fixing it. I neglected > to run the tests before suggesting that fix -- I'll try not to do that > again.. No biggie, that got me to finally try out Babel ;) I don't know if it's been mentioned in the "issue tracker?"

26.3; org-indent-mode's line-prefix text property flickers near overlays

Hello, The line-prefix text property set by org-indent-mode sometimes vanishes when typing near a line where an overlay is applied. To reproduce: - emacs -Q - C-x C-f repro.org - M-x org-indent-mode - M-: (insert "* heading\ntext") - M-: (let ((ov (make-overlay (point-at-bol) (point-at-bol)))

Re: Possible fix for :includes header argument in org-babel C source blocks

Kévin Le Gouguec writes: > That leads me to believe that the coercion was an unintended side-effect > of (format …). Never mind, the ORG-NEWS entry for 9.1 shows an example of unquoted header, so I guess it is intentional. Here is a patch to fix the regression:

Re: Possible fix for :includes header argument in org-babel C source blocks

Kyle Meyer writes: > I think this discussion was on emacs-devel only, so here are some links > for others who might go looking for more context: > > https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01880.html > https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03051.html

Re: Possible fix for :includes header argument in org-babel C source blocks

Hi, Bastien writes: > Brandon Guttersohn writes: > >> Hey all, I think I may have a small fix for executing C source blocks >> in org-babel. Or, possibly just a bad case of user error. >> >> The issue (in emacs 27 with -q) is that it doesn't seem possible to >> specify non-system header files

Re: Setting org-todo-keywords through directory-local variables

Nicolas Goaziou writes: > This looks hackish. Any bit in particular? AFAICT hack-local-variables-hook is the expected way to perform plumbing that might be affected by file/directory-local variables. It is used by e.g. shell-script-mode, cc-mode, markdown-mode and AUCTeX, to name a few. The

Re: Setting org-todo-keywords through directory-local variables

Kévin Le Gouguec writes: > Can anyone confirm that this would (in principle) be the way forward, or > tell me if I am missing something[3]? I went ahead and cooked up a proof-of-concept patch, which (1) adds safe-local-variable properties to org-todo-keywords and org-todo-keyword

Re: issue tracker?

Anthony Carrico writes: > On 5/21/20 10:18 AM, Anthony Carrico wrote: >> which is a big ask for users. > > ... given that the community expressed that it would like to interact on > a mailing list without other user facing tooling. AFAICT, the only thing users have to do to participate in

Re: issue tracker?

Nicolas Goaziou writes: > - As pointed out, Org has a bug tracker : Emacs' Debbugs. See > . Org users do not send bugs > through it much. (In the event that they do, should whoever follows bug-gnu-emacs refer these users to emacs-orgmode?) > -

Re: issue tracker?

"James R Miller" writes: >> I think issue tracking could happen on a mailing list. If you tag an >> issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of >> the OPEN: issues to the list periodically (in theory). > > Something like that would be nice; the bot could even store

Setting org-todo-keywords through directory-local variables

Hello, I'd like to set org-todo-keywords and org-todo-keyword-faces through directory-local variables, to get rid of duplicate #+SEQ_TODO lines in my Org files[1]. Right now I see two obstacles for this to work: (1) org-set-regexps-and-options, which sets up a bunch of TODO-related

Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

Nicolas Goaziou writes: > Hello, > > Gregor Zattler writes: > >> with `org-return-follows-link` set to `t` in a read-only >> buffer I now get a `Buffer is read-only: #> notmuch-startpage.org>` error when pressing ENTER/RETURN >> with point on an org-mode link. > > Fixed. Thank you. Thanks for

Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

Gregor Zattler writes: > Dear Kévin, org-mode developers, > > with `org-return-follows-link` set to `t` in a read-only > buffer I now get a `Buffer is read-only: # notmuch-startpage.org>` error when pressing ENTER/RETURN > with point on an org-mode link. Oh, right, I added '*' to org-return's

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

Kévin Le Gouguec writes: > (I hope I got that right.) Except I forgot the explanatory comment, and I left a typo in the docstring. Ahem. diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 2b35535fa..caaf5ce58 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -102,6 +102

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

Nicolas Goaziou writes: > AFAICT, `newline-and-indent' doesn't accept any argument. Keeping it > introduces a build warning and test failures. Hence the removal. > > Since you were calling it with an argument I assume this may be > a novelty in Emacs 27. Wow, you're right. That caught me

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

Stefan Monnier writes: >> +(defmacro org-test-with-minor-mode (mode state body) >> + "Run BODY after setting MODE to STATE. >> +Restore MODE to its former state afterward." >> + (declare (debug (sexp sexp body)) (indent 2)) >> + `(let ((old-state ,mode)) >> + (,mode (if ,state 1 0)) >>

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

Nicolas Goaziou writes: > I fixed a typo and applied your patch. Thank you for fixing the typo in ORG-NEWS. I see you've removed ARG from the call to `newline-and-indent'; I don't have a strong opinion about this (though I don't see a reason not to keep it), but I guess the docstring of

  1   2   >