Automatically update plain list checkboxes when removing nested list items?
Hello, I have a question about plain list checkboxes. If I have a plain list, as follows: - [ ] Item 1 - [ ] Sub-item 1 - [ ] Sub-item 2 - [ ] Sub-item 3 when I complete sub-items 1 and 2, the list is as follows: - [-] Item 1 - [X] Sub-item 1 - [X] Sub-item 2 - [ ] Sub-item 3 Then, if it turns out that Sub-item 3 is unnecessary, I can delete it with C-k: - [-] Item 1 - [X] Sub-item 1 - [X] Sub-item 2 However, Item 1's checkbox is in the intermediate state, even though all of its sub-items have been completed. I'm wondering if there's a way that I can delete Sub-item 3 and update the Item 1 checkbox all at once. Right now, I have to move the cursor back up to Item 1 and hit C-c C-c to force the checkbox to update. Thanks, Rohit Patnaik
Re: How does =org-md-item= produce the correct indentation for nested lists?
Hello, Yes, that clarifies things quite a bit. I thought that the contents of the list item only included that specific item, when in reality it includes the item and all sub-lists. Thanks, Rohit
How does =org-md-item= produce the correct indentation for nested lists?
Hello, I was looking at the implementation for =org-md-item=, in ox-md.el, and I'm wondering how indentation logic for nested lists works. Specifically, I was looking at the following code: #+BEGIN_SRC elisp (concat bullet (make-string (- 4 (length bullet)) ? ) (pcase (org-element-property :checkbox item) (`on "[X] ") (`trans "[-] ") (`off "[ ] ")) (let ((tag (org-element-property :tag item))) (and tag (format "**%s:** "(org-export-data tag info (and contents (org-trim (replace-regexp-in-string "^" "" contents #+END_SRC and I'm wondering why it's adding indentation in front of the bullet. Naively, I would expect the result of this snippet, for an unordered list to be something like: =-[item contents]= That is, it concatenate the bullet, then three spaces (4 - length of bullet), then another four spaces, then the contents of the item. Instead, what I see is a four-space indent, followed by the bullet and its padding, followed by the item contents: =- [item contents]= This is the correct result, but I don't see how the code from ox-md.el produces that result. The reason I'm asking is because I have similar logic in the org-mode exporter I'm writing for PMWiki markup: https://github.com/quanticle/ox-pmwiki/blob/master/ox-pmwiki.el#L214 and I would like to change the logic so that instead of indenting with spaces, it repeats the list marker (** for a second level nested list, *** for 3 levels of nesting, etc). Thanks, Rohit Patnaik
Re: Best way to make the Org source tree?
>From reading `mk/targets.mk`, seems like `make update` runs the following: git checkout $(GIT_BRANCH) git remote update git pull make all I think `make all` also runs `make autoloads`. Personally, my update process is `git pull && make`, because until just now I didn't realize that `make update` was an option. -- Rohit Patnaik
Re: [BUG] Newlines after links are fontified with the org-link face after an incremental search
Confirmed fixed. Thanks for the quick turnaround! Rohit
Re: [BUG] Newlines after links are fontified with the org-link face after an incremental search
Hello, It seems like this fix regressed as a result of commit 5d186b499dde97f59a91dc11f4c4a15113d29f4d. After I updated to the latest version of org-mode again, I noticed that the fontification of newlines was back. When I created a branch that reverted 5d186b499dde97f59a91dc11f4c4a15113d29f4d, the fontification behaving as it should. Thanks, Rohit Patnaik
Re: Extraneous blank lines in when attempting to export org tables
> This is because ox-md adds a blank line between almost every element, > including table-rows (which ox-md does not care about). > Fixed, on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=85aafac41 Thanks for fixing this. I completely forgot that my export code is a derived backend from ox-md. Maybe, I should make it a standalone backend (or derive directly from ox-html, like ox-md does), to avoid further mysterious issues. Rohit
Extraneous blank lines in when attempting to export org tables
Hello, I'm currently working on an exporter that will allow org-mode to export to PMWiki markdown (https://github.com/quanticle/ox-pmwiki/), and I'm running into a problem when writing the export code to handle tables. When exporting table rows, I'm getting extraneous blank lines between table rows. My export code for tables is as follows: #+begin_src elisp (defun org-pmwiki-table-cell (table-cell contents info) "Transcode a TABLE-CELL from org to pmwiki format. CONTENTS is nil. INFO is a plist used as a communications channel." (let ((cell-alignment (org-export-table-cell-alignment table-cell info))) (cond ((eq cell-alignment 'left) (format "%s ||" contents)) ((eq cell-alignment 'right) (format " %s||" contents)) ((eq cell-alignment 'center) (format " %s ||" contents) (defun org-pmwiki-table-row (table-row contents info) "Transcode a TABLE-ROW element from org to pmwiki format. CONTENTS is the contents of the row. INFO is a plist used as a communications channel." (format "||%s" contents)) (defun org-pmwiki-table (table contents info) "Transcode a TABLE from org to pmwiki format. TABLE is the table element itself. CONTENTS is the contents of the table. INFO is a plist holding contextual information." contents) #+end_src When I run this code on the following table: #+begin_src org | Col 1 | Col 2 | Col 3 | ||| | | left aligned cell | centered cell | right aligned cell | #+end_src I expect to see the following output: #+begin_example ||Col 1 || Col 2 || Col 3|| ||left aligned cell || centered cell || right aligned cell|| #+end_example However, the actual output generated by the code is: #+begin_example ||Col 1 || Col 2 || Col 3|| ||left aligned cell || centered cell || right aligned cell|| #+end_example The contents of each cell are formatted correctly, but there's an additional newline between the two rows. How do I prevent this newline from being added? Thanks, Rohit Patnaik
Re: [BUG] Newlines after links are fontified with the org-link face after an incremental search
> Fixed, on main; for Emacs >=29. Will not be fixed for earlier Emacs versions. I've confirmed that it's fixed. Thanks so much for the fast turnaround! Rohit Patnaik
[BUG] Newlines after links are fontified with the org-link face after an incremental search
Hello everyone, I've noticed a potential regression in the way that org-mode fontifies links in the latest git main branch version of org-mode. When the user conducts an incremental search that matches a link that runs to the end of the line, for some reason the =org-link= face is extended to cover the newline as well. Detailed repro steps: 1. Run =make repro= from the =main= branch 2. Switch the scratch buffer to org-mode with =M-x org-mode= 3. Add two lines - The first line should be a link, for example: [[https://www.google.com][Link]] - The second line should be a blank line 4. Place the point at the beginning of the first line 5. Hit =C-s= to begin an incremental search and search for the link description (i.e. =Link=) 6. Hit =RET= to leave the search 7. Note that the link underline now seems to extend past the end of the link text 8. Place the point at the end of the line and hit =M-x describe-char=. You should see that the character is a =C-j=, and the face is =org-link= The above result does not occur when I check out the =release_9.6.17= tag, which is why I think it might be a regression. My version of emacs is: GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.8, Xaw3d scroll bars) of 2023-08-02 My operating system is Fedora Linux 39, running Gnome 45.3 on Wayland. Thanks, Rohit Patnaik
Re: Org Syntax Specification
I also want to chip in with a thank-you for the org syntax specification page. As someone who's working on a custom org exporter, this is a very useful resource for finding out how elements are structured within org-mode. Thanks, Rohit
Re: Do not show a TODO item in the global TODO list until certain date?
> (not a scheduled one, since I don't need to do it on a particular date) The `SCHEDULED' property is in fact the correct way to indicate that you wish to hide the task from the global to-do list until a particular date. `SCHEDULED' indicates the day upon which you wish to start working on the task. If there's a particular date by which the task has to be completed, the `DEADLINE' property is appropriate. The relevant org-mode manual page is: https://orgmode.org/manual/Deadlines-and-Scheduling.html I believe. -- Rohit
Re: Why do org-agenda-switch-to and org-agenda-goto put the point in different spots in the target buffer?
> org-agenda-switch-to jumps to the actual agenda match (usually a timestamp). > It may or may not be close to the headline (think of active timestamp inside > notes). Such behaviour, albeit undocumented, may be useful for some users. I'd > rather not change it. Okay, that makes sense. > Recentering is purely a visual thing. It should be safe to add. I've added the recentering behavior in the attached patch. The recentering part was more important for me than the point jumping to the heading, because sometimes the match would appear at the very top of the screen and I'd have to scroll up manually to see the heading. If the screen is centered on the match, then it's likely that the heading will also be visible in the window. Thanks, Rohit 0001-org-agenda.el-Make-org-agenda-switch-to-recenter-on-.patch Description: Binary data
Why do org-agenda-switch-to and org-agenda-goto put the point in different spots in the target buffer?
I've gotten back into using org-agenda to manage my todos, and I noticed an odd discrepancy in behavior. When I hit RET in the agenda buffer to go to the TODO entry in the original org file, I see that the point is on the DEADLINE line. However, when I hit TAB, I find that the point is placed at the beginning of the heading. Looking at the source of org-agenda.el, I find that TAB is bound to `org-agenda-goto', which does the following: (recenter (/ (window-height) 2)) (org-back-to-heading t) RET, on the other hand, is bound to `org-agenda-switch-to', which does not have these lines, and thus does not place the point on the heading. Is there a reason for this discrepancy between the two functions? I'm asking because I prefer the point placement behavior of `org-agenda-goto', but I use `org-agenda-switch-to' because switches to the target org file in the current window rather than opening a new window. Would there be any issues with me taking the recentering and point placement behavior from `org-agenda-goto' and adding it to `org-agenda-switch-to`? Thanks, Rohit
Re: [BUG] Markdown export of description list with nested list [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
As I understand it, the bug is in `org-md-item'. It formats the tag portion of the description with **%s**, and then simply concatenates the content. This is fine when the content is a simple string, but when the content includes line breaks (i.e. when content is itself a list), it doesn't realize that it needs to include a line break between the tag and the content. ox-html handles this case correctly because ox-html distinguishes between plain list types, using for ordered and unordered lists and & for description lists. I think this issue can be fixed by prefixing `contents' with a newline if `tag' is present and `contents' itself contains multiple lines. However, this feels like a hack, and I'd be open to better approaches. -- Rohit
In an export transcoder, when should I use org-element-property to get values vs. the contents parameter
I'm looking at function that handles transcoding inline code and verbatim text in ox-md: (defun org-md-verbatim (verbatim _contents _info) "Transcode VERBATIM object into Markdown format. CONTENTS is nil. INFO is a plist used as a communication channel." (let ((value (org-element-property :value verbatim))) (format (cond ((not (string-match "`" value)) "`%s`") ((or (string-prefix-p "`" value) (string-suffix-p "`" value)) "`` %s ``") (t "``%s``")) value))) My question is, why does org-md-verbatim use org-element-property to retrieve the text to be transcoded, when org-md-bold and org-md-italic use the contents parameter. In other words, couldn't the function be simplified to something like this: (defun org-md-verbatim (_verbatim contents _info) "Transcode VERBATIM object into Markdown format. CONTENTS is nil. INFO is a plist used as a communication channel." (format (cond ((not (string-match "`" contents)) "`%s`") ((or (string-prefix-p "`" contents) (string-suffix-p "`" contents)) "`` %s ``") (t "``%s``")) contents)) The broader context for my question is that I'm writing my own org exporter, and I'd like some more clarity on what the distinction is between getting the value of the element with org-element-property and relying on the export framework to pass the value to the transcoder via the contents parameter. Thanks, Rohit
Re: How to utilize Org mode editing without display formatting
Could you do this with a mode-hook? Something like: (add-hook 'org-mode-hook (lambda () (when (memq (buffer-file-name) 'list-of-files-to-not-highlight) (font-lock-mode -1 -- Rohit
Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
Thanks so much for making those changes and getting it merged. -- Rohit
Fwd: Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
> Since md backend is derived from html, is it necessary to define an > option specific to markdown or the value defined for HTML may be reused? > I am unsure which variant will be more convenient, so it is not more > than an idea that may be easily discarded. I considered reusing the value from the HTML exporter, but I rejected it, because the org-html-toplevel-hlevel defaults to 2. Reusing it would alter the existing default behavior for markdown exports, which I thought was undesirable. If you think it's okay to alter the existing behavior of Markdown exports, I could change the code to use org-html-toplevel-hlevel to control the top level heading level of both HTML and markdown exports. Thanks, Rohit
Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
> This contribution will be welcome. I've attached a patch which implements the change. I followed the pattern that ox-html uses to the greatest extent possible. I tested it by exporting org-mode files to markdown with the table of contents both enabled and disabled. I didn't see any errors, and I was able to make the top level heading a level 2 (or even level 3) heading rather than level 1. Thanks, Rohit 0001-Added-top-level-header-setting-for-md-export.patch Description: Binary data
[Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
Hello, I've been exporting several of my org-mode notes to markdown recently, and I've been running into an issue where I've had to manually adjust the level of the top level headings in my exported notes because the wiki system I'm importing the notes to reserves h1 (i.e. #) for page titles, using h2s (i.e. ##) for sections within the page itself. I noticed that ox-html.el has a org-html-toplevel-hlevel variable, which allows the user to set the heading level of top-level headings within the exported content. Would there be any problems with implementing a similar variable (e.g. org-md-toplevel-hlevel) to allow the user to set the heading level of top level headings within exported markdown content? It looks like it would be a small change, and I'd be happy to implement it myself, but I thought I'd run it by the list to see if there were any major issues that might arise from making this change. Thanks, Rohit Patnaik
Re: [O] Is it possible to "escape" time entries in to-do headings for org-agenda?
I managed to get my question answered on StackExchange [1]. It seems the solution is to turn off org-agenda-search-headline-for-time. Would it be possible to add a footnote to the time of day specification manual page [2] indicating that this is the variable that controls whether org-agenda scans headlines for timestamps in plain text? Right now, unless you already know that that variable exists, you have no idea what to look for in order to turn this feature off. [1]: https://emacs.stackexchange.com/questions/41203/how-do-i-escape-a-time-in-a-todo-entry-so-that-it-doesnt-show-up-on-the-time <https://emacs.stackexchange.com/questions/41203/how-do-i-escape-a-time-in-a-todo-entry-so-that-it-doesnt-show-up-on-the-time> [2]: https://orgmode.org/manual/Time_002dof_002dday-specifications.html#Time_002dof_002dday-specifications <https://orgmode.org/manual/Time_002dof_002dday-specifications.html#Time_002dof_002dday-specifications> > On Apr 24, 2018, at 2:11 PM, Nicolas Goaziou wrote: > > Hello, > > Rohit Patnaik writes: > >> Hello, >> >> According to the org-mode manual: >> >>> In the headline of the entry itself, a time(range) may also appear as plain >>> text (like ‘12:45’ or a ‘8:30-1pm’). >> >> Is it possible to "escape" this text so that strings like that are >> *not* interpreted as times or time ranges? Failing that, is it >> possible to disable the interpretation of plain text as time ranges? >> I have entries that have "time-like" strings, (ie. things like 7:16) >> that should not be interpreted as a timestamp. However, when I display >> such entries in org-agenda, these entries are displayed with a time >> prefix, which results in the text appearing garbled. > > It might be possible with a zero width space near the colons. > > Regards, > > -- > Nicolas Goaziou
[O] Is it possible to "escape" time entries in to-do headings for org-agenda?
Hello, According to the org-mode manual: >In the headline of the entry itself, a time(range) may also appear as plain >text (like ‘12:45’ or a ‘8:30-1pm’). Is it possible to "escape" this text so that strings like that are *not* interpreted as times or time ranges? Failing that, is it possible to disable the interpretation of plain text as time ranges? I have entries that have "time-like" strings, (ie. things like 7:16) that should not be interpreted as a timestamp. However, when I display such entries in org-agenda, these entries are displayed with a time prefix, which results in the text appearing garbled. Thanks, Rohit Patnaik
