* 'false' list item @ 2021-02-15 17:37 Juan Manuel Macías 2021-02-21 6:56 ` Kyle Meyer 0 siblings, 1 reply; 16+ messages in thread From: Juan Manuel Macías @ 2021-02-15 17:37 UTC (permalink / raw) To: orgmode Hi, If a line in a paragraph starts with a digit (or letter) + period + space, Org misinterprets that as a list item. I almost always notice this only when I export my document, which is a nuisance. I wonder if there is any standard solution to that, or if I'm missing something... All that occurred to me is this "preventive" solution, using `highlight-regexp': #+begin_src emacs-lisp (defface my-lists-item-box '((t :weight bold :foreground "white" :background "orange")) "") (defun my-org-item-highlight () (highlight-regexp org-list-full-item-re 'my-lists-item-box)) (add-hook 'org-mode-hook 'my-org-item-highlight) #+end_src Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-15 17:37 'false' list item Juan Manuel Macías @ 2021-02-21 6:56 ` Kyle Meyer 2021-02-21 7:05 ` Tim Cross 2021-02-21 19:33 ` Juan Manuel Macías 0 siblings, 2 replies; 16+ messages in thread From: Kyle Meyer @ 2021-02-21 6:56 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías writes: > If a line in a paragraph starts with a digit (or letter) + period + > space, Org misinterprets that as a list item. I almost always notice > this only when I export my document, which is a nuisance. > > I wonder if there is any standard solution to that, or if I'm missing > something... All that occurred to me is this "preventive" solution, > using `highlight-regexp': It seems that your approach would do a good job of helping you catch cases that you don't want to be treated as lists. I'm not aware of any related functionality in Org, so I don't think you're missing something there. Once you know that there is a particular spot that you want to prevent from being interpreted as a list, you could add a zero-width space in front of it: (info "(org)Escape Character") I'm not sure if that's the sort of solution you're asking for, though. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 6:56 ` Kyle Meyer @ 2021-02-21 7:05 ` Tim Cross 2021-02-21 14:49 ` Juan Manuel Macías 2021-02-22 2:48 ` Greg Minshall 2021-02-21 19:33 ` Juan Manuel Macías 1 sibling, 2 replies; 16+ messages in thread From: Tim Cross @ 2021-02-21 7:05 UTC (permalink / raw) To: emacs-orgmode Kyle Meyer <kyle@kyleam.com> writes: > Juan Manuel Macías writes: > >> If a line in a paragraph starts with a digit (or letter) + period + >> space, Org misinterprets that as a list item. I almost always notice >> this only when I export my document, which is a nuisance. >> >> I wonder if there is any standard solution to that, or if I'm missing >> something... All that occurred to me is this "preventive" solution, >> using `highlight-regexp': > > It seems that your approach would do a good job of helping you catch > cases that you don't want to be treated as lists. I'm not aware of any > related functionality in Org, so I don't think you're missing something > there. > > Once you know that there is a particular spot that you want to prevent > from being interpreted as a list, you could add a zero-width space in > front of it: > > (info "(org)Escape Character") > > I'm not sure if that's the sort of solution you're asking for, though. If a line starts with a number, period and space, but that line is within a paragraph (i.e. no blank line above), then I don't think it should be interpreted as an enumerated list item. If this is what the OP is referring to, I would argue it is a bug. If it is a 'paragraph' starting with a number, period and space, then being interpreted as a list item would be 'normal'. -- Tim Cross ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 7:05 ` Tim Cross @ 2021-02-21 14:49 ` Juan Manuel Macías 2021-02-22 2:48 ` Greg Minshall 1 sibling, 0 replies; 16+ messages in thread From: Juan Manuel Macías @ 2021-02-21 14:49 UTC (permalink / raw) To: Tim Cross; +Cc: orgmode Hi, Tim Cross <theophilusx@gmail.com> writes: > If a line starts with a number, period and space, but that line is > within a paragraph (i.e. no blank line above), then I don't think it > should be interpreted as an enumerated list item. If this is what the OP > is referring to, I would argue it is a bug. If it is a 'paragraph' > starting with a number, period and space, then being interpreted as a > list item would be 'normal'. The problem occurs on the lines within a paragraph (no blank line above). I have uploaded this screenshot: https://gnutas.juanmanuelmacias.com/images/false-list-item.webm It also happens with a clean startup. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 7:05 ` Tim Cross 2021-02-21 14:49 ` Juan Manuel Macías @ 2021-02-22 2:48 ` Greg Minshall 2021-02-22 3:26 ` Tim Cross 1 sibling, 1 reply; 16+ messages in thread From: Greg Minshall @ 2021-02-22 2:48 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode Tim, > If a line starts with a number, period and space, but that line is > within a paragraph (i.e. no blank line above), then I don't think it > should be interpreted as an enumerated list item. If this is what the OP > is referring to, I would argue it is a bug. If it is a 'paragraph' > starting with a number, period and space, then being interpreted as a > list item would be 'normal'. i know this isn't precisely the discussion, but i use *unnumbered* lists, and i most often have no blank line separating the list from the paragraph above (or, indeed, below). i could get used to a modified requirement, to reduce the false positives, but, would want heads up (or, maybe, sigh, an option?). cheers, Greg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-22 2:48 ` Greg Minshall @ 2021-02-22 3:26 ` Tim Cross 2021-02-22 6:08 ` Greg Minshall 0 siblings, 1 reply; 16+ messages in thread From: Tim Cross @ 2021-02-22 3:26 UTC (permalink / raw) To: Greg Minshall; +Cc: emacs-orgmode Greg Minshall <minshall@umich.edu> writes: > Tim, > >> If a line starts with a number, period and space, but that line is >> within a paragraph (i.e. no blank line above), then I don't think it >> should be interpreted as an enumerated list item. If this is what the OP >> is referring to, I would argue it is a bug. If it is a 'paragraph' >> starting with a number, period and space, then being interpreted as a >> list item would be 'normal'. > > i know this isn't precisely the discussion, but i use *unnumbered* > lists, and i most often have no blank line separating the list from the > paragraph above (or, indeed, below). i could get used to a modified > requirement, to reduce the false positives, but, would want heads up > (or, maybe, sigh, an option?). > There is no plans to change anything as far as I know. What I wrote was mainly to show why we have the situation and that any proposed solution has its own drawbacks. Bottom line, we cannot easily prevent the 'false' list item issue without introducing either other issues or adding some additional syntax to indicate list items, which defeats the 'plain' aspects which many appreciate in org. Even the proposed 'solutions' still suffer from false positives. The question is probably, how can we 'flag' possible false positives in a convenient manner. For example, it has been suggested that some form of highlighting for list elements might make it easier to spot a false element lurking in a paragraph of text. this could possibly be useful, but I also worry about adding more font-locking and highlighting due to the potential to degrade performance further. We already have people running into issue with performance in large org files. -- Tim Cross ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-22 3:26 ` Tim Cross @ 2021-02-22 6:08 ` Greg Minshall 0 siblings, 0 replies; 16+ messages in thread From: Greg Minshall @ 2021-02-22 6:08 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode Tim, > There is no plans to change anything as far as I know. What I wrote was > mainly to show why we have the situation and that any proposed solution > has its own drawbacks. thanks. (i assumed that, but ...) > Bottom line, we cannot easily prevent the 'false' list item issue > without introducing either other issues or adding some additional syntax > to indicate list items, which defeats the 'plain' aspects which many > appreciate in org. Even the proposed 'solutions' still suffer from false > positives. yeah. i sort of wonder if one can roughly categorize our typical uses of org-mode into two types: - random scribbles, agendas, etc., where the consumer is "ourselves" for the most part - more formal presentations (web sites, papers), where the consumer is the broader world and, to the extent this is true, i wonder if some markup issues have a tension between those two uses. e.g., for a formal document, i might be willing to have "heavier" markup, to eliminate (...) false positives/negatives. (another example is in-line math markup, with dollar signs or backslah-parens.) cheers, Greg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 6:56 ` Kyle Meyer 2021-02-21 7:05 ` Tim Cross @ 2021-02-21 19:33 ` Juan Manuel Macías 2021-02-21 19:40 ` Diego Zamboni 2021-02-21 22:55 ` Kyle Meyer 1 sibling, 2 replies; 16+ messages in thread From: Juan Manuel Macías @ 2021-02-21 19:33 UTC (permalink / raw) To: Kyle Meyer; +Cc: orgmode Kyle Meyer <kyle@kyleam.com> writes: > It seems that your approach would do a good job of helping you catch > cases that you don't want to be treated as lists. I'm not aware of any > related functionality in Org, so I don't think you're missing something > there. > > Once you know that there is a particular spot that you want to prevent > from being interpreted as a list, you could add a zero-width space in > front of it: > > (info "(org)Escape Character") > > I'm not sure if that's the sort of solution you're asking for, though. Thanks for your advice, Kyle. Adding the U+200B char. works fine to avoid false positives. Anyway, like Tim Cross says, that situation maybe should be considered as a bug. I think the ideal behavior would be for Org to consider a list only when there is a blank line above. But, well thought out, I am afraid that it would not prevent false positives, as one may want perfectly write a list at the beginning of the document, or start a plain paragraph with (for example) a digit + a period + a space... Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 19:33 ` Juan Manuel Macías @ 2021-02-21 19:40 ` Diego Zamboni 2021-02-21 21:27 ` Samuel Wales ` (2 more replies) 2021-02-21 22:55 ` Kyle Meyer 1 sibling, 3 replies; 16+ messages in thread From: Diego Zamboni @ 2021-02-21 19:40 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: Kyle Meyer, orgmode [-- Attachment #1: Type: text/plain, Size: 1427 bytes --] Juan Manuel, YMMV depending on your needs and habits, but another workaround for this problem would be to use visual-line-mode instead of filling paragraphs. --Diego On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net> wrote: > Kyle Meyer <kyle@kyleam.com> writes: > > > It seems that your approach would do a good job of helping you catch > > cases that you don't want to be treated as lists. I'm not aware of any > > related functionality in Org, so I don't think you're missing something > > there. > > > > Once you know that there is a particular spot that you want to prevent > > from being interpreted as a list, you could add a zero-width space in > > front of it: > > > > (info "(org)Escape Character") > > > > I'm not sure if that's the sort of solution you're asking for, though. > > Thanks for your advice, Kyle. Adding the U+200B char. works fine to > avoid false positives. Anyway, like Tim Cross says, that situation > maybe should be considered as a bug. I think the ideal behavior would > be for Org to consider a list only when there is a blank line above. > But, well thought out, I am afraid that it would not prevent false > positives, as one may want perfectly write a list at the beginning of > the document, or start a plain paragraph with (for example) a digit + a > period + a space... > > Best regards, > > Juan Manuel > > [-- Attachment #2: Type: text/html, Size: 1982 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 19:40 ` Diego Zamboni @ 2021-02-21 21:27 ` Samuel Wales 2021-02-21 22:25 ` Juan Manuel Macías 2021-02-21 22:31 ` Tim Cross 2021-02-21 22:45 ` Kyle Meyer 2021-02-22 11:56 ` Eric S Fraga 2 siblings, 2 replies; 16+ messages in thread From: Samuel Wales @ 2021-02-21 21:27 UTC (permalink / raw) To: Diego Zamboni; +Cc: Juan Manuel Macías, Kyle Meyer, orgmode perhaps if there is no blank line above or below, then it could be not a list. On 2/21/21, Diego Zamboni <diego@zzamboni.org> wrote: > Juan Manuel, > > YMMV depending on your needs and habits, but another workaround for this > problem would be to use visual-line-mode instead of filling paragraphs. > > --Diego > > > > > On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net> > wrote: > >> Kyle Meyer <kyle@kyleam.com> writes: >> >> > It seems that your approach would do a good job of helping you catch >> > cases that you don't want to be treated as lists. I'm not aware of any >> > related functionality in Org, so I don't think you're missing something >> > there. >> > >> > Once you know that there is a particular spot that you want to prevent >> > from being interpreted as a list, you could add a zero-width space in >> > front of it: >> > >> > (info "(org)Escape Character") >> > >> > I'm not sure if that's the sort of solution you're asking for, though. >> >> Thanks for your advice, Kyle. Adding the U+200B char. works fine to >> avoid false positives. Anyway, like Tim Cross says, that situation >> maybe should be considered as a bug. I think the ideal behavior would >> be for Org to consider a list only when there is a blank line above. >> But, well thought out, I am afraid that it would not prevent false >> positives, as one may want perfectly write a list at the beginning of >> the document, or start a plain paragraph with (for example) a digit + a >> period + a space... >> >> Best regards, >> >> Juan Manuel >> >> > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 21:27 ` Samuel Wales @ 2021-02-21 22:25 ` Juan Manuel Macías 2021-02-21 22:31 ` Tim Cross 1 sibling, 0 replies; 16+ messages in thread From: Juan Manuel Macías @ 2021-02-21 22:25 UTC (permalink / raw) To: Samuel Wales; +Cc: orgmode Samuel Wales <samologist@gmail.com> writes: > perhaps if there is no blank line above or below, then it could be not a list. I think this solution would be fine, although plain paragraphs starting with digit/letter + period + space would be false positives. Anyway, some kind of highlighting in the items, a defined face as in markdown-mode (markdown-list-face), would be also helpful. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 21:27 ` Samuel Wales 2021-02-21 22:25 ` Juan Manuel Macías @ 2021-02-21 22:31 ` Tim Cross 2021-02-22 0:21 ` Juan Manuel Macías 1 sibling, 1 reply; 16+ messages in thread From: Tim Cross @ 2021-02-21 22:31 UTC (permalink / raw) To: emacs-orgmode Samuel Wales <samologist@gmail.com> writes: > perhaps if there is no blank line above or below, then it could be not a list. > Initially, that was my thought as well. Unfortunately, it isn't quite that straight forward. Consider the list 1. Item 1 2. Item 2 3. Item 3 The second item has no blank line above or below, but it is a list item. With the blank line approach, the list would have to be 1. item 1 2. item 2 3. item 3 which I doubt many would like. What I guess is really needed is a list 'environment' - once you see the first list item, following a blank line, your in a list environment until the next blank line. However, then, if you have list items which are multi-line items, you cannot have a blank line between items as that would signal a new list environment. Personally, if the items are longer, visually, I do like a blank line between the items. So now either we need to add some sort of list 'marker' or we need something else, such as saying a list must be indented further than the surrounding paragraphs i.e. if you had (using loren ipsum for text) ----- Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. 1. Mauris ac felis vel velit tristique imperdiet. Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu. Phasellus at dui in ligula mollis ultricies. Integer placerat tristique nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu. Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et dictum nunc justo sit amet elit. ----- the 1. line is not a list, but ----- Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. 1. Mauris ac felis vel velit tristique imperdiet. Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu. Phasellus at dui in ligula mollis ultricies. Integer placerat tristique nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu. Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et dictum nunc justo sit amet elit. --- the 1. is a list item i.e. being indented compared to surrounding text makes it a list item. Any further lines indented to that level or more (for sub lists) are also considered part of the list, until the next blank line. The problem with this of course is that if you have a sub-heading which only has a list of items, there is no surrounding text within that section, so how would you identify it was a list? The issue is, if we decide this is a bug, can we fix it? Is it a bug or is it just an accepted limitation of the org document format and what we have to do is ensure either no line starts with a '1. ' or we use something like a unicode character so that it doesn't look like a number+period+space and therefore not a list item? -- Tim Cross ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 22:31 ` Tim Cross @ 2021-02-22 0:21 ` Juan Manuel Macías 0 siblings, 0 replies; 16+ messages in thread From: Juan Manuel Macías @ 2021-02-22 0:21 UTC (permalink / raw) To: Tim Cross; +Cc: orgmode Tim Cross <theophilusx@gmail.com> writes: > The issue is, if we decide this is a bug, can we fix it? Is it a bug or > is it just an accepted limitation of the org document format and what we > have to do is ensure either no line starts with a '1. ' or we use > something like a unicode character so that it doesn't look like a > number+period+space and therefore not a list item? Interesting all the points you comment, and this paragraph is important. I'm thinking that without a clear and explicit environment (a begin/end marks), any possible solution will always have its exceptions. However, IMHO, I would not find desirable two explicit marks environment in the style of LaTeX, since this would go against the virtue of legibility and lightness in Org. I don't know if Markdown (on what it has in common with Org as a lightweight markup language) also has similar problems in lists formatting, since I hardly use Markdown and am not aware of its many implementations... I still think that highlighting the items would at least be a preventive solution for Org. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 19:40 ` Diego Zamboni 2021-02-21 21:27 ` Samuel Wales @ 2021-02-21 22:45 ` Kyle Meyer 2021-02-22 11:56 ` Eric S Fraga 2 siblings, 0 replies; 16+ messages in thread From: Kyle Meyer @ 2021-02-21 22:45 UTC (permalink / raw) To: Diego Zamboni, Juan Manuel Macías; +Cc: orgmode Diego Zamboni writes: > Juan Manuel, > > YMMV depending on your needs and habits, but another workaround for this > problem would be to use visual-line-mode instead of filling paragraphs. Note that filling paragraphs in Org should already guard against inadvertently creating a list item. (Some related discussion is at <https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>.) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 19:40 ` Diego Zamboni 2021-02-21 21:27 ` Samuel Wales 2021-02-21 22:45 ` Kyle Meyer @ 2021-02-22 11:56 ` Eric S Fraga 2 siblings, 0 replies; 16+ messages in thread From: Eric S Fraga @ 2021-02-22 11:56 UTC (permalink / raw) To: Diego Zamboni; +Cc: Juan Manuel Macías, Kyle Meyer, orgmode Hello all, > YMMV depending on your needs and habits, but another workaround for this > problem would be to use visual-line-mode instead of filling paragraphs. as Kyle has already mentioned, this is a well known limitation of org and no reasonable solution has been found in the past. I partly moved to visual-line-mode with org-indent-mode for this reason and this combination works very well for me. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-231-gf46925 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 'false' list item 2021-02-21 19:33 ` Juan Manuel Macías 2021-02-21 19:40 ` Diego Zamboni @ 2021-02-21 22:55 ` Kyle Meyer 1 sibling, 0 replies; 16+ messages in thread From: Kyle Meyer @ 2021-02-21 22:55 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías writes: > Kyle Meyer <kyle@kyleam.com> writes: > >> It seems that your approach would do a good job of helping you catch >> cases that you don't want to be treated as lists. I'm not aware of any >> related functionality in Org, so I don't think you're missing something >> there. >> >> Once you know that there is a particular spot that you want to prevent >> from being interpreted as a list, you could add a zero-width space in >> front of it: >> >> (info "(org)Escape Character") >> >> I'm not sure if that's the sort of solution you're asking for, though. > > Thanks for your advice, Kyle. Adding the U+200B char. works fine to > avoid false positives. Anyway, like Tim Cross says, that situation > maybe should be considered as a bug. I think the ideal behavior would > be for Org to consider a list only when there is a blank line above. You can find some previous discussion of this longstanding and known behavior at <https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-02-22 12:13 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-02-15 17:37 'false' list item Juan Manuel Macías 2021-02-21 6:56 ` Kyle Meyer 2021-02-21 7:05 ` Tim Cross 2021-02-21 14:49 ` Juan Manuel Macías 2021-02-22 2:48 ` Greg Minshall 2021-02-22 3:26 ` Tim Cross 2021-02-22 6:08 ` Greg Minshall 2021-02-21 19:33 ` Juan Manuel Macías 2021-02-21 19:40 ` Diego Zamboni 2021-02-21 21:27 ` Samuel Wales 2021-02-21 22:25 ` Juan Manuel Macías 2021-02-21 22:31 ` Tim Cross 2021-02-22 0:21 ` Juan Manuel Macías 2021-02-21 22:45 ` Kyle Meyer 2021-02-22 11:56 ` Eric S Fraga 2021-02-21 22:55 ` Kyle Meyer
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.