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 org-html

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 m

[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 e

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 a

[BUG] Emphasis markers should be considered word constituents (was: [BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-m

> Jens Schmidt writes: > ... >> Well, I have one not-so-minor nit here: With that commit you cannot >> insert text *before* some text having hidden emphasis without breaking >> the emphasis. More concretely (in an empty org-mode buffer): >> (setq org-hide-emphasis-markers t) *foo*

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

Jack Kamm writes: > writes: > >>> > There is a related issue about EOLs, not just \r\n -- each line should >>> > be a maximum of 75 characters; this is handled by >>> > org-icalendar-fold-string >>> >>> May you please provide a lin

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

> It's in rfc5545 [1], referenced to from rfc7986 [2]. yes, that's it. There is also this validator that can check files against the spec: https://icalendar.org/validator.html Stpehen

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

writes: >> > There is a related issue about EOLs, not just \r\n -- each line should >> > be a maximum of 75 characters; this is handled by >> > org-icalendar-fold-string >> >> May you please provide a link to the iCalendar spec document section >

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

here is a related issue about EOLs, not just \r\n -- each line should > > be a maximum of 75 characters; this is handled by > > org-icalendar-fold-string > > May you please provide a link to the iCalendar spec document section > describing this requirement?

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

"Stephen J. Eglen" writes: >> https://list.orgmode.org/87355ikzwk.fsf@localhost/T/#m180c100587d3d88ab5787942271a546b51891996 > > Thanks for copying me in on this. > > There is a related issue about EOLs, not just \r\n -- each line should > be a maximum of 75 charac

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

.orgmode.org/87355ikzwk.fsf@localhost/T/#m180c100587d3d88ab5787942271a546b51891996 Thanks for copying me in on this. There is a related issue about EOLs, not just \r\n -- each line should be a maximum of 75 characters; this is handled by org-icalendar-fold-string I'll check out the revised code to see if this is still an issue. Stephen

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

Ihor Radchenko writes: > Sorry for the late reply. > > Do I understand correctly that all the ical lines must use \r\n? [1] Following up here that I have pushed a fix for the EOL issue in ox-icalendar: https://list.orgmode.org/87355ikzwk.fsf@localhost/T/#m180c100587d3d88ab5787942271a546b5189199

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

"Stephen J. Eglen" writes: > The lines from BEGIN:VEVENT to CATEGORIES:test inclusive have CR (^M) as well > as LF (^J) as newline [in the text above, I've converted the ^M to *** > to see them eaer. Is that intended? Uploading the file to > https://icalendar.org/validator.html gives me the err

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

Hello, just to confirm. The exporter is inconsistent in adding which kind of EOL sequence. Detlef Am Fri, 06 Jan 2023 08:30:41 + schrieb "Stephen J. Eglen" : > Hello, > > If I have a test file > > -- > > * test 1 > > <2

Bug report for ox-icalendar: newlines should be CRLF

Hello, If I have a test file -- * test 1 <2023-01-05 Thu 19:00-19:20> -- and then convert to an .ics file using C-c C-e c f I get the attached test.ics fil

Re: [RFC] :var x=list-name should be resolved into simple lists (item1 item2 ...); not nested ((item1) (item2) ...) (was: 2 'echo' bash instructions produce a table)

Ihor Radchenko writes: > The attached is a fix for this discrepancy with the manual. > > However, it looks like at least ob-java already tried to work around the > erroneous return value of org-babel-read-list. > > Hence, we at least need to announce this fix in ORG-NEWS. > > Or maybe there are o

[RFC] :var x=list-name should be resolved into simple lists (item1 item2 ...); not nested ((item1) (item2) ...) (was: 2 'echo' bash instructions produce a table)

lisp/test-ob.el (test-ob/simple-variable-resolution): Add new tests. * etc/ORG-NEWS (List references in source block variable assignments are now proper lists): Document the change. This commit fixes the broken promise in the manual section 16.4 Environment of a Code Block where the named referenc

Re: export to odt, but #text# should be coloured

I forgot to escape the quotation marks, of course. > "@@odt:@@\\1@@odt:@@" "@@odt:@@\\1@@odt:@@"

Re: export to odt, but #text# should be coloured

Hi, Since all formatting is defind as styles and styles are defined in separate (parts of the) files that make up an ODT file, this requires you to work with ODT styles. There may be a hack around it, I don't know. See the manual for how to use a style sheet with #+ODT_STYLES_FILE. (For a once-

Re: export to odt, but #text# should be coloured

On Thursday, 9 Jun 2022 at 20:37, Uwe Brauer wrote: > Now, how can I achieve something like this for the odt export? I have used something like the following in the past: (format "%s" contents) -- : Eric S Fraga, with org release_9.5.4-521-g1105da in Emacs 29.0.50

export to odt, but #text# should be coloured

Hi a short hack of the sort (interactive) (while (re-search-forward "#\\([^#]*\\)#" nil t) (replace-match "\\1"))) Allows me to export text like this #important# to HTML where the resulted text is colored in red. Now, how can I achieve something like this for the odt export? Reards Uwe

Re: [BUG] markdown blocks remain visible when they should be folded

Confirming fixed. Many thanks! Tom

Re: [BUG] markdown blocks remain visible when they should be folded

Tom Gillespie writes: > The markdown blocks remain visible and have the invisible > text property set to nil, when folded #+end_src will turn into > ... but the markdown remains visible. The whole block will > be left open if any of the markdown list or heading chars are > present in the block. >

[BUG] markdown blocks remain visible when they should be folded

One of the commits between ffdc508429c58716272743c0e0650bb721fd906a (good) and 67275f4664ce00b5263c75398d78816e7dc2ffa6 (bad) a change was introduced that broke folding for markdown blocks. I'm not sure of the exact commit because folding is completely broken for all the commits in between. Lookin

Re: org-->html text between @ should be red.

>>> "JMM" == Juan Manuel Macías writes: > I think this would work: > (setq org-export-filter-plain-text-functions > (remove 'my-html-red org-export-filter-plain-text-functions)) > Anyway, I recommend that you take a look at the documentation on filters > that Timothy pointed you to, as cus

Re: org-->html text between @ should be red.

Uwe Brauer writes: > (add-to-list 'org-export-filter-plain-text-functions 'my-html-red) > > How could I remove something from a list? I think this would work: (setq org-export-filter-plain-text-functions (remove 'my-html-red org-export-filter-plain-text-functions)) Anyway, I recommend t

Re: org-->html text between @ should be red.

>>> "JMM" == Juan Manuel Macías writes: > Uwe Brauer writes: >> Thanks very much it works as expected. However I just realized (and >> this is true also for the org-mime filter that the reg-exp has a flaw. >> >> I used the text >> >> >> =email:o...@mat.ucm.es= >> >> So there is only one @, n

Re: org-->html text between @ should be red.

Uwe Brauer writes: > Thanks very much it works as expected. However I just realized (and > this is true also for the org-mime filter that the reg-exp has a flaw. > > I used the text > > > =email:o...@mat.ucm.es= > > So there is only one @, nevertheless the exporter translated that to > email:ou

Re: org-->html text between @ should be red.

>>> "T" == Timothy writes: Hi Timothy > Hi Uwe, >> And every text between @ appears red. >> >> Can I have a similar setting when exporting an org file to html via the >> «normal» html exporter? > Have a look at the filter functions, such as > `org-export-filter-final-output-functions'. See >

Re: org-->html text between @ should be red.

>>> "JMM" == Juan Manuel Macías writes: > Uwe Brauer writes: >> Can I have a similar setting when exporting an org file to html via the >> «normal» html exporter? > Using a custom filter? > #+begin_src emacs-lisp > (defun foo (text backend info) > (when (org-export-derived-backend-p backen

Re: org-->html text between @ should be red.

Hi Uwe, > And every text between @ appears red. > > Can I have a similar setting when exporting an org file to html via the > «normal» html exporter? Have a look at the filter functions, such as `org-export-filter-final-output-functions'. See

Re: org-->html text between @ should be red.

Uwe Brauer writes: > Can I have a similar setting when exporting an org file to html via the > «normal» html exporter? Using a custom filter? #+begin_src emacs-lisp (defun foo (text backend info) (when (org-export-derived-backend-p backend 'html) (replace-regexp-in-string "@\\([^@]*\\

org-->html text between @ should be red.

Hi When I use org-mime-htmlize, then I can use the setting Render text between "@" in red color, you can use =org-mime-html-hook=, #+begin_src elisp (add-hook 'org-mime-html-hook (lambda () (while (re-search-forward "@\\([^@]*\\)@" nil t) (replace-match "\\

Re: Should be possible to export list items emphasized by default?

Ypo writes: > /1. Introduction/ > > It doesn't work as a list item > > 1. /Introduction/ > > It works as a list item but, when exporting, it doesn't export the > whole item emphasized. If I have understood correctly, you want to export the label emphasized as well, not just the item content... It

Should be possible to export list items emphasized by default?

Is it intended to not be able to emphasize the whole item of a list? Example: /1. Introduction/ It doesn't work as a list item 1. //Introduction// It works as a list item but, when exporting, it doesn't export the whole item emphasized. Best regards, Ypo

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

Hi Maxim, > Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data > [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! > /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and > /mnt/c/Users/toz/.emacs.d/elpa/org-plus-contrib-20200615/) > > Notice “mixed instal

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

In my previous message I forgot to mention the subject of the initial bug report: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.emacs.d/elpa

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

Dear Timothy and Maxim, the bug was caused by an advice. I am really sorry for the trouble I inflicted on you. Next time I will test more carefully. Btw, I corrected the real problem already in https://github.com/TobiasZawada/org-src-emph. Regards, Tobias Zawada

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

miliar how font lock works in Emacs. Is it necessary to wrap whole function? I do not see explicit operation with regexps. The only suspecting line is (org-font-lock-ensure) I am not sure whether the body of `org-src-font-lock-fontify-block' should be wrapped or its call site. Feel free

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

Hi Tobias, Thanks for your efforts. I have prepared a patch accordingly that wraps org-src-font-lock-fontify-block’s body with save-match-data (attached). If I don’t hear anything bad about it in the next few days, I’ll push it :) Please let me know if my commit message agrees with your understan

Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.emac

some text from the beginning up to the end of the last match in the Org buffer. Since the source buffer is smaller than the Org buffer ~match-beginning~ is smaller than it should be. This can slow down editing operations in org-mode with large source blocks to an extent to which org-mode becomes

ox variable not set when it should be?

this must be user error, but i am not sure where. i have: (with-eval-after-load 'ox ;; a whole bunch of settings and defuns and stuff that ;; would cause compiler warnings if it were not after load ox (setq org-export-with-tasks nil)) and yet, when i export a subtree, the value of that var

Re: [PATCH] repeat cookies should be in the same order as the repeats

Kyle Meyer writes: > Thanks for the patch. > >> [PATCH] repeat cookies should be in the same order as the repeats I've amended the commit (as requested off-list) and pushed (5272d97e5). Thanks again Dieter.

Re: [PATCH] repeat cookies should be in the same order as the repeats

Thanks for the patch. > [PATCH] repeat cookies should be in the same order as the repeats Convention nit: Ideally this subject would start with a "scope/file:", e.g. "manual:" or "org-manual.org:". Also, could you please add a changelog entry and TINYCHAN

[PATCH] repeat cookies should be in the same order as the repeats

--- doc/org-manual.org | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index ef2dad9ef..e78690993 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -5741,6 +5741,7 @@ expressions to process these values before inserting them

Re: should be

This one is a little 'tricky'. The tag means emphasis and is not the same as underline (browsers are free to 'interpret' emphasis as anything which will emphasise the text from surrounding text, which could be bold, italic, underline or a combination. If we changed underline to tags, I'm sure w

should be

For this org mode text: #+begin_src org - This text is /emphasized/ - This text is *in bold* - This text is _underlined_ - This text uses =a teletype font= #+end_src the follow is the HTML output: #+begin_src This text is emphasized This text is in bold This text is underlined This text uses a

Re: org-clip-link should be included in core

On Sat, May 23, 2020 at 10:14 AM Bastien wrote: > So IIUC the need is to easily remove the link part of a link. > > I pushed a change to make this easier. Now you can hit `C-c C-l' on > a link, empty the link part, keep the description and RET to get only > the description inserted as non-link t

Re: org-clip-link should be included in core

Hi Tory, thanks for reporting this here. torys.ander...@gmail.com (Tory S. Anderson) writes: > Per alphapapa's suggestion to bring this up to this list, it seems > that everyone (doom, spacemacs, and individuals) are rolling their own > of a functionality that should be include

org-clip-link should be included in core

Per alphapapa's suggestion to bring this up to this list, it seems that everyone (doom, spacemacs, and individuals) are rolling their own of a functionality that should be included in core: the ability to de-linkify text at point, leaving just the text without orgmode surroundings. One p

Re: org-adapt-indentation default should be nil [legibility 3/6]

On 2/10/20, Bastien wrote: > Hi Samuel, > > thanks for your feedback. > > Samuel Wales writes: > >> obviously, as a default not indenting text as you seem to propose is >> good for newcomers. that statement was in the context of accessibility. > > Perhaps, we will see! indeed we will get opini

Re: org-adapt-indentation default should be nil [legibility 3/6]

Hi Samuel, thanks for your feedback. Samuel Wales writes: > obviously, as a default not indenting text as you seem to propose is > good for newcomers. Perhaps, we will see! > as for org as it is now, with a mixture of at least 3 indentation > styles in the wild, idk. What I observed is that

Re: org-adapt-indentation default should be nil [legibility 3/6]

[this is addressed to bastien] hi, if you are thinking of changing the default to indenting meta lines and asking for opinions on that: fwiw, if org /were starting out/, i would propose that meta stuff not be indented at all either. then the regexps everywhere could be reliable. and it reduces

Re: org-adapt-indentation default should be nil [legibility 3/6]

Hi Texas and Adam, Adam Porter writes: >> Beginners are bad at making adjustments to keep heavily-indented >> prose legible. Thus the default should be nil. > > I think you have a better case for changing this setting. The default `org-adapt-indentation' can indeed be pr

Re: org-startup-truncated default should be nil [legibility 2/6]

Hi Texas, Texas Cyberthal writes: > #+begin_src elisp > (org-startup-truncated nil) > #+end_src I disagree. The whole discussion about mixing prose and code in the same buffer is interesting: ideas like mixing variable pitch fonts, truncating lines for specific parts of the buffer, etc. are al

Re: org-startup-truncated default should be nil [legibility 2/6]

Emacs has a giant normie-noob shaped hole in its intake funnel. The warnings against using Emacs on Windows on the download page are good, but not enough. Noobs need a positive recommendation of platform, and a practical one, not ideological. It should say something like: "If you've never coded, t

Re: org-startup-truncated default should be nil [legibility 2/6]

That's a great idea. And if the Org tutorial included an easy option to enable "PIM" mode for normie-noobs, so that Emacs starts behaving like a PIM instead of an IDE, that would be even better. Someone who's never coded before doesn't need IDE defaults. On Fri, Feb 7, 2020 at 8:37 AM Corwin Brust

Re: org-startup-truncated default should be nil [legibility 2/6]

Greetings, On Thu, Feb 6, 2020 at 5:33 PM Texas Cyberthal wrote: > No, that isn't what I'm saying. I'm quite happy with Emacs, especially > Spacemacs. However, I had a much harder adoption experience than > necessary, and I find that the barriers to entry are preventing > normie-noobs from choos

Re: org-startup-truncated default should be nil [legibility 2/6]

No, that isn't what I'm saying. I'm quite happy with Emacs, especially Spacemacs. However, I had a much harder adoption experience than necessary, and I find that the barriers to entry are preventing normie-noobs from choosing Org as a PIM. So I intend to fix that. On Fri, Feb 7, 2020 at 5:38 AM F

Re: org-startup-truncated default should be nil [legibility 2/6]

Okay, I get it: Emacs (especially vanilla) just doesn't meet your requirements. So be it! Horse for courses, as they say here in the UK. All I can say is that I find most, if not all, other tools so frustrating. I can never get them to work the way I want. With Emacs, I can. Yes, this means t

Re: org-startup-truncated default should be nil [legibility 2/6]

> I get this. My own approach is to simply use - at the start of the line and > then each of these demi-paragraphs becomes a list item which are wrapped > nicely (whether with visual or fill mode). The cost of this approach is that one can't distinguish between demi-paragraphs and actual bullet

Re: org-startup-truncated default should be nil [legibility 2/6]

On Thursday, 6 Feb 2020 at 20:09, Texas Cyberthal wrote: > A blank line is useful, yes. Use of demi-paragraphs implies use of > line breaks to signal stronger transitions. E.g., from my recent > workflow: I get this. My own approach is to simply use - at the start of the line and then each of th

Re: org-startup-truncated default should be nil [legibility 2/6]

No, I just didn't repeat everything. A blank line is useful, yes. Use of demi-paragraphs implies use of line breaks to signal stronger transitions. E.g., from my recent workflow: #+begin_quote turning the mic off/on manually also causes a pop so would need to pause recording first simpler to just

Re: org-startup-truncated default should be nil [legibility 2/6]

So, the only problem that you have, as far as I can tell, is that Emacs doesn't distinguish paragraphs by a single newline character but requires 2 instead? For me, a blank line between paragraphs is very useful to visually identify new paragraphs (or demi-paragraphs). For writing and for intra-p

Re: org-startup-truncated default should be nil [legibility 2/6]

auto-fill-mode is unsuitable for prose work, and especially for rough notes which rely on demi paragraphs. Demi-paragraphs are important for conveying uncertainty. Polished publishable prose can usually be written with proper syntax and paragraphs separated by blank lines, but the requisite foretho

Re: org-startup-truncated default should be nil [legibility 2/6]

On Thursday, 6 Feb 2020 at 17:46, Texas Cyberthal wrote: > auto-fill-mode definitely isn't what I want. Why not? Just curious. Before I switched to visual-line-mode for all org documents, I used auto-fill-mode for prose all the time. Together with fill-paragraph (M-q), this did the job very w

Re: org-startup-truncated default should be nil [legibility 2/6]

cs is crowd-configured and vanilla Emacs isn't. It doesn't make sense for vanilla Emacs to be more normie-noob friendly than Spacemacs, so I feel most of my Org legibility suggestions should be implemented on Spacemacs before vanilla, if at all. Vanilla documentation incompatibility due to

Re: org-startup-truncated default should be nil [legibility 2/6]

On Thursday, 6 Feb 2020 at 10:33, Texas Cyberthal wrote: > Visual line mode is annoying and unnecessary; Spacemacs users do not > need it because its defaults offer adequate paragraph navigation. I'm not sure I understand the conflation of visual-line-mode with paragraph navigation. Is it becaus

Re: org-startup-truncated default should be nil [legibility 2/6]

aphs. On Thu, Feb 6, 2020 at 10:33 AM Texas Cyberthal wrote: > > > If I understand correctly, you're arguing that defaults should be changed > > because you don't understand how Emacs works, and since you use Spacemacs, > > you don't even care how it works. >

Re: org-startup-truncated default should be nil [legibility 2/6]

> If I understand correctly, you're arguing that defaults should be changed > because you don't understand how Emacs works, and since you use Spacemacs, > you don't even care how it works. You understand incorrectly. You incorrectly asserted that all users must learn ho

Re: org-adapt-indentation default should be nil [legibility 3/6]

ead the body text of headings, then deeply > indenting it is contrary to the goal. If the goal is to see the depth > of headings, then the bodies should be folded. If folded mode doesn't > convey sufficient information, the solution is to rewrite the heading > titles to better s

Re: org-startup-truncated default should be nil [legibility 2/6]

called within the last week. If I understand correctly, you're arguing that defaults should be changed because you don't understand how Emacs works, and since you use Spacemacs, you don't even care how it works. May I suggest that you propose your changes on the Spacemacs repo.

Re: org-startup-truncated default should be nil [legibility 2/6]

should not have hit send on last email. meant to disengage completely. will do so now. last email was not an invitation to converse.

Re: org-startup-truncated default should be nil [legibility 2/6]

you do not know what every user needs.

Re: org-startup-truncated default should be nil [legibility 2/6]

i am feeling highly uncomfortable now. On 2/4/20, Texas Cyberthal wrote: >> many users need fully maximized emacs while still having legible paragraph >> width. > > Splitting windows vertically creates narrower columns. Unlike > truncation etc, window management actually is something all noobs m

Re: org-startup-truncated default should be nil [legibility 2/6]

> many users need fully maximized emacs while still having legible paragraph > width. Splitting windows vertically creates narrower columns. Unlike truncation etc, window management actually is something all noobs must learn. Narrower columns can increase reading speed, to a point. But wide colu

Re: org-startup-truncated default should be nil [legibility 2/6]

On 2/4/20, Texas Cyberthal wrote: > Prose should wrap at > window's edge many users need fully maximized emacs while still having legible paragraph width.

Re: org-adapt-indentation default should be nil [legibility 3/6]

text of headings, then deeply indenting it is contrary to the goal. If the goal is to see the depth of headings, then the bodies should be folded. If folded mode doesn't convey sufficient information, the solution is to rewrite the heading titles to better summarize the body text. I never use

Re: org-startup-truncated default should be nil [legibility 2/6]

e less noob-friendly the defaults, the lower the chances they successfully boostrap. Emacs noobs have enough to contend with. If learning the twenty ways to wrap lines can be skipped, it should be. Prose should wrap at window's edge; code should continue. That's the universal standard now. Ema

Re: org-adapt-indentation default should be nil [legibility 3/6]

The extra information value of indentation > reflecting outline depth is negligible; the heading already conveys > it. > > Beginners are bad at making adjustments to keep heavily-indented prose > legible. Thus the default should be nil. I think you have a better case for changing this

Re: org-startup-truncated default should be nil [legibility 2/6]

ion are likely to know > about it, whereas users who need line truncation off are unlikely to > know what it's called. > > Learning about line truncation is an unnecessary hurdle for beginners. > Therefore the default should be nil. visual-line-mode and toggle-truncate-lines are ba

org-startup-truncated default should be nil [legibility 2/6]

what it's called. Learning about line truncation is an unnecessary hurdle for beginners. Therefore the default should be nil.

org-adapt-indentation default should be nil [legibility 3/6]

already conveys it. Beginners are bad at making adjustments to keep heavily-indented prose legible. Thus the default should be nil.

Re: Format of Effort estimates should be mentioned in its Info node

Hi Kisaragi Hiu, > Done; I haven't done the copyright assignment paperwork with FSF, but > I guess it's fine since this is under the 15 line limit? Yes, thanks a lot. I've applied your commits to th master branch. I just added the TINYCHANGE cookie in the commit messages. > I copied a few exam

Re: Format of Effort estimates should be mentioned in its Info node

Done; I haven't done the copyright assignment paperwork with FSF, but I guess it's fine since this is under the 15 line limit? I copied a few examples from org-duration.el, which is what actually defines the format (org-refresh-effort-estimates). I also corrected the docstring of org-effort-pro

Re: Format of Effort estimates should be mentioned in its Info node

Hi Kisaragi Hiu, Kisaragi Hiu writes: > Currently, the Info node about effort estimates does not mention what > format should it be written in. This causes confusion, as a user might > assume that it's the same format as schedulers (10m, 6h, etc.) like I > did. > > Simply mentioning "Effort esti

Re: Format of Effort estimates should be mentioned in its Info node

Hi Jean-Christophe, Nicolas Goaziou writes: > I'm not sure would be pertinent to create a whole section for duration > format: these are not quite as ubiquitous as timestamps. However, they > are used here and there so it may be better to add a few words in the > appropriate sections, the main o

Re: Format of Effort estimates should be mentioned in its Info node

Hello, Jean-Christophe Helary writes: >> On Jan 4, 2020, at 14:20, Kisaragi Hiu wrote: >> >> It didn't work for me because I gave it "10m" which actually means 10 >> months, I've realized. >> >> Still, Durations as defined by org-du

Re: Format of Effort estimates should be mentioned in its Info node

> On Jan 4, 2020, at 14:20, Kisaragi Hiu wrote: > > It didn't work for me because I gave it "10m" which actually means 10 months, > I've realized. > > Still, Durations as defined by org-duration.el should be described in the > manual like h

Re: Format of Effort estimates should be mentioned in its Info node

It didn't work for me because I gave it "10m" which actually means 10 months, I've realized. Still, Durations as defined by org-duration.el should be described in the manual like how Timestamps are. 2020年1月4日 11:55 差出し人： k...@kyleam.com: > Kisaragi Hiu writes: > &

Re: Format of Effort estimates should be mentioned in its Info node

Kisaragi Hiu writes: > Currently, the Info node about effort estimates does not mention what > format should it be written in. This causes confusion, as a user might > assume that it's the same format as schedulers (10m, 6h, etc.) like I > did. > > Simply mentioning "Effort estimates need to have

Format of Effort estimates should be mentioned in its Info node

Currently, the Info node about effort estimates does not mention what format should it be written in. This causes confusion, as a user might assume that it's the same format as schedulers (10m, 6h, etc.) like I did. Simply mentioning "Effort estimates need to have the format H:MM" (copied from the

Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

\([^ > > > : ].+?[^ ]\|[^ > > > : ]\)>> > > > > That regex looks malformed, and will only match strings with 1 or 3 > > or > > more characters between << and >>. If someone knows what itʼs > > supposed > > to be matching we c

Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

knows what itʼs supposed > to be matching we can fix it. eg it looks like it wants to allow > > <>> > > Is that something that should be accepted? I fixed the regexp. Thank you. Regards, -- Nicolas Goaziou

Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

like it wants to allow <> Is that something that should be accepted? Robert

Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

┌ > │ L.append(i) > └ > > ┌ > │ ## Sage version > │ L=[] > │ for i in range(1,6): > │ > │ L > └ > > But using the same syntax in Python fails miserably: > > ┌ > │ #+name: Ah > │ #+begin_src python > │ L.append(i) > │ #+end_src &g

Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

t; └ > > > > > > > > ┌ > > > > │ ## Sage version > > > > │ L=[] > > > > │ for i in range(1,6): > > > > │ > > > > │ L > > > > └ > > > > > > > > But using the same syntax in Python fails miserably: > > >

[O] Bug: Variable comment-start-skip in the function org-agenda-skip is nil but should be a string. [9.1.13 (9.1.13-elpa @ ~/.emacs.d/elpa/org-20180716/)]

Hello dear list and thank you for looking at this stuff down below as well as org-mode and many other things. Best, PHF I get: Debugger entered--Lisp error: (wrong-type-argument stringp nil) looking-at(nil) org-agenda-skip() org-scan-tags(proposition_org/if_proposition_then_get_

Re: [O] Bug: Variable comment-start-skip in the function org-agenda-skip is nil but should be a string. [9.1.13 (9.1.13-elpa @ ~/.emacs.d/elpa/org-20180716/)]

Ok, I found how to correct it: (defun proposition_org/extract_posts (x) "file_name → [proposition_org]" (let ((file_name (expand-file-name x))) (cond ((file-exists-p file_name) (with-temp-buffer (insert-file-contents file_name) (org-mode) ;; <--- THIS

  1   2   >