Maintaining babel packages — a list of packages that need help?
Timothy writes: > As far as I know the only call for help maintaining Org has been with > babel packages. Otherwise you would have seen me volunteering :P I'd > like to do more if I get the opportunity. I’m currently in the process of enabling myself to contribute. Do we have a list of babel-packages that need maintenance? This is also something I’m personally interested in, because I use babel a lot, including in multi-language workflows. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: wip-cite status question and feedback
John Kitchin writes: > 5. I mostly think the citations should be displayed as plain text, i.e. > not replaced by a numbered overlay, or equivalent. I could see hiding > the [], but also guess that would be more confusing than beneficial. As someone who works author-year inline citations into the text, APA-style, e.g. "as seen in Goaziou et al. (2021) citations in Org shall soon be possible" Seeing that as "as seen in [1] citations in Org shall soon be possible" is worse than "as seen in [cite:@goaziou2021] et al. citations in Org shall soon be possible" I think what would be ideal, would be if common citation styles could define a method which produces a display string, like "Goaziou et al. (2021)". If nothing is defined, then no overlay should be produced. -- Timothy
Re: Concerns about community contributor support
Tim Cross writes: > ian martins writes: > >> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: >> >> [Noise] >> >> Timothy said there were 25 patches without response and the list goes back >> six months, so we're only talking about 50 emails per year. > That assumes there is a single 'owner' who accepts the responsibility to > respond to every patch submitted. That isn't the situation with open > source projects where people volunteer their time. > > Having someone respond to the author of a patch and provide some > meaningful feedback would be great, but I don't see how that can happen > in a project which is already stretched and with limited resources. > There has already been multiple messages requesting additional help and > for volunteers willing to put in the time needed to maintain parts of > org mode. Adding to that workload isn't going to help. As far as I know the only call for help maintaining Org has been with babel packages. Otherwise you would have seen me volunteering :P I'd like to do more if I get the opportunity. > [snip] > > I think you can classify patches into 3 basic types - > > 1. [Fixes] > > 2. [Extending existing stuff] > > 3. [New stuff] > > Asking volunteers to respond to patches of type 2 and 3 within some > nominated time period is probably unreasonable. I'd like to suggest that a response can just be "We've got your patch, it will take some time to go through and see ow it interacts with Org". > It also runs the danger of discouraging people from stepping up to > volunteer to help maintain parts of org. TBH I don't see how being asked to provide the odd cursory response would be that off-putting. 50 currently patches needing a response per year / say 3 maintainers ~= cursory quick email every 2-4 weeks on average just to say a patch has been seen, thanks for submitting it, and maybe that it might take a while to be reviewed. > This is why I think a better approach would be to provide more details > and explanation on patch submission which can help set the > expectations for the patch submitter and provide some guidance on what > to do if they want to encourage/ask for feedback. I think this would be a very good idea, I'll say a bit more below where you mention Worg. > This is also part of why I think patches of type 3 and possibly many > type 2 patches should be initially released as separate 'add on' > packages and made available via gitlab/github/melpa by the individual > responsible for writing the patch. The author would then be able to see > how useful/popular/desired their patch is, be able to ask for feedback > and be able to get issue/bug reports to refine their work. This could be > viewed as an 'incubator' like process. If such an enhancement/extension > turns out to be very popular or demanded by the org community, it could > then be migrated into either org core or the proposed org contrib > package (by which time, it would likely be more mature and stable than > it was when initially developed). It also has the advantage of not > impacting existing org users who are not interested in the > enhancement/extension. For an org user, little is more frustrating than > an enhancement/extension which results in them having to either modify > their workflow or update their often large repository of org documents. I think volume of email replies saying "I'd like this" is a bad measure for a few reasons. (1) I get the sense there's a fairly high degree of tacit approval, (2) I've seen the same idea presented simply at different times get very different responses based on how the initial replies reframed/directed the discussion. Additionally, if people who like it can "just use it", a patch may be well-liked and used a lot but not have many peoples speaking in support of it in the ML. In other words, I think that such a system could be too fickle. I suspect some good patches will easily "fall through the cracks" with such a method. I can think of a several merged patches which I consider a good idea which would not fare well under such a system. Then there's another concern if you're modifying parts of Org's internals --- they can be tweaked in Org, and then the overridden methods can cause errors in a number of ways. I know this very well, as I do this sort of thing in a few places in my config, e.g. I was affected by a change in org--mks-read-key. Is a patch author going to be interested in maintaining their patch in the hope that it one day gets merged with Org? This seems like a bit of a stretch to me. > If we were to provide a detailed explanation on how to contribute bug > fixes, enhancements and extensions on the worg site, contributors will > know what is required, will be able to set their expectations in -line > with how things work and have increased clarity regarding the structure > of the org mode project etc. > > I would be willing to start drafting such a page if the community > thought this would be worthwhile and be prepared to assist a
Re: List of ob-* maintainers
Aloha Kyle, Done. Thanks. There are quite a few unmaintained languages in core. All the best, Tom Kyle Meyer writes: Thomas S. Dye writes: Aloha Kyle, Thanks for this. I think the Worg list might be useful to indicate which languages don't have maintainers. Or, is the information in the source files sufficient? I don't know, but adding the information to the Worg table sounds fine to me. Thanks. -- Thomas S. Dye https://tsdye.online/tsdye
Re: Concerns about community contributor support
ian martins writes: > On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: > > Responding to essentially just flag you have seen the patch message > really only adds noise and may even 'drown out' those responses which > add real 'value' to any discussion. I also doubt that asking people to > do this would actually result in any actual change of behaviour by > subscribers. > > Timothy said there were 25 patches without response and the list goes back > six months, so we're only talking about 50 emails per year. That assumes there is a single 'owner' who accepts the responsibility to respond to every patch submitted. That isn't the situation with open source projects where people volunteer their time. Having someone respond to the author of a patch and provide some meaningful feedback would be great, but I don't see how that can happen in a project which is already stretched and with limited resources. There has already been multiple messages requesting additional help and for volunteers willing to put in the time needed to maintain parts of org mode. Adding to that workload isn't going to help. responses to patches really need to come from community members who are sufficiently interested in the patch to examine it or make comment on how useful they feel it would be. To some extent, if someone submits a patch and hears nothing, either they have failed to clearly explain what the patch does (and therefore did not tweak any interest) or it is a patch to introduce functionality which is of low interest to community participants. I think you can classify patches into 3 basic types - 1. Bug fixes. Patches which do not change functionality, but address bugs and performance bottlenecks in existing features. At present, this type of patch seems to get applied fairly quickly. 2. Patches which extend existing functionality. This type of patch requires significant consideration and evaluation. They can be time consuming to assess and a call needs to be made as to whether the additional complexity such enhancements add can justify the increased maintenance overhead such enhancements introduce. This is particularly challenging with org mode because org supports a diverse and sometimes complex range of workflows. Verifying an enhancement will not have adverse impact on some of these workflows is difficult and time consuming. Even apparently simple and straight-forward changes can have unexpected impact - consider for example the enhancement to support electric indent mode. This seemed fairly straight-forward and was a change which made org mode aligned with other Emacs modes and helps improve consistency withing Emacs across modes. However, it has had some adverse impact and caused some confusion because of how it interacts with existing org behaviour and configuration settings, such as with org indentation behaviour. 3. Patches which introduce new functionality. This type of patch also requires considerable resources to evaluate and adds to overall maintenance load. It is one thing to write an extension, but a completely different thing to maintain it over time. Even assessing the real demand for such extensions is challenging and time consuming and represents a significant demand on volunteers time. Asking volunteers to respond to patches of type 2 and 3 within some nominated time period is probably unreasonable. It also runs the danger of discouraging people from stepping up to volunteer to help maintain parts of org. This is why I think a better approach would be to provide more details and explanation on patch submission which can help set the expectations for the patch submitter and provide some guidance on what to do if they want to encourage/ask for feedback. This is also part of why I think patches of type 3 and possibly many type 2 patches should be initially released as separate 'add on' packages and made available via gitlab/github/melpa by the individual responsible for writing the patch. The author would then be able to see how useful/popular/desired their patch is, be able to ask for feedback and be able to get issue/bug reports to refine their work. This could be viewed as an 'incubator' like process. If such an enhancement/extension turns out to be very popular or demanded by the org community, it could then be migrated into either org core or the proposed org contrib package (by which time, it would likely be more mature and stable than it was when initially developed). It also has the advantage of not impacting existing org users who are not interested in the enhancement/extension. For an org user, little is more frustrating than an enhancement/extension which results in them having to either modify their workflow or update their often large repository of org documents. If we were to provide a detailed explanation on how to contribute bug fixes, enhancements and extensions on the worg site, contributors will know what is required, will be able to set their expectations in -line with
Re: (Not so) Short note about citations in Org
On Wed, Apr 21, 2021 at 8:35 PM Nicolas Goaziou wrote: > > Hello, > > "Bruce D'Arcus" writes: > > > Great! > > > > I just pulled down the branch. > > > > This is my first time trying to run off a development branch. > > > > I ran make from the root of the repo, and then: > > > > emacs -Q -l lisp/org.elc > > > > ... but then get this error: > > > > load-with-code-conversion: Cannot open load file: No such file or > > directory, oc > > Not so great, then! > > > Is there something else I should do? > > Do you have "oc.el" file in "lisp/" directory? You may want to augment > your load-path at an early step. Yeah, but it doesn't load. I added =(add-to-list 'load-path "lisp/")= to a load file, and that also didn't work for me. > You can also go low-tech and call `eval-buffer' on "org-element.el", > "oc.el", "org-element.el", "ox.el" and "org.el". This, however, did. I only tested export to HTML, but so far looks encouraging! Bruce
Re: Concerns about community contributor support
On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: > Responding to essentially just flag you have seen the patch message > really only adds noise and may even 'drown out' those responses which > add real 'value' to any discussion. I also doubt that asking people to > do this would actually result in any actual change of behaviour by > subscribers. > Timothy said there were 25 patches without response and the list goes back six months, so we're only talking about 50 emails per year.
Re: (Not so) Short note about citations in Org
Hello, "Bruce D'Arcus" writes: > Great! > > I just pulled down the branch. > > This is my first time trying to run off a development branch. > > I ran make from the root of the repo, and then: > > emacs -Q -l lisp/org.elc > > ... but then get this error: > > load-with-code-conversion: Cannot open load file: No such file or > directory, oc Not so great, then! > Is there something else I should do? Do you have "oc.el" file in "lisp/" directory? You may want to augment your load-path at an early step. You can also go low-tech and call `eval-buffer' on "org-element.el", "oc.el", "org-element.el", "ox.el" and "org.el". This should be enough for testing. Regards, -- Nicolas Goaziou
Re: (Not so) Short note about citations in Org
On Wed, Apr 21, 2021 at 7:34 PM Nicolas Goaziou wrote: > I just rebased "wip-cite-new" branch, which now includes citation > syntax, and an interface between external citation processors and the > rest of Org. I'll throw in a demo at the end of this message. TL;DR: > search for "Demo time". Great! I just pulled down the branch. This is my first time trying to run off a development branch. I ran make from the root of the repo, and then: emacs -Q -l lisp/org.elc ... but then get this error: load-with-code-conversion: Cannot open load file: No such file or directory, oc Is there something else I should do? Bruce
Re: wip-cite status question and feedback
Hello, "Bruce D'Arcus" writes: > In general (conceptually), if you have one footnote in text, and one > in a footnote, with a note style, both will be rendered as footnotes. > > So in an adapted version from earlier: > > > Text 1 [@cite:@a]. > Text 2[fn:1]. > > [fn:1] This is [cite:@b]. > > > Output would put both citations in respective footnotes. So it would produce the same output as --- Text 1 [fn::[@cite:@a]]. Text 2[fn:1]. [fn:1] This is [cite:@b]. --- ? If that's correct, this requires a specific tool in "oc.el", for example (defun org-cite-wrap-footnote (citation) "Wrap CITATION object within an anonymous footnote." ...) which can be used upon "exporting" the footnote, after having done appropriate checks. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
On Wed, Apr 21, 2021 at 7:51 PM Nicolas Goaziou wrote: > > Hello, > > András Simonyi writes: > > > This is a crucial point: when a note CSL style is used, the export has > > to generate footnotes "around" those citations which are not already > > in a footnote. > > Since citeproc-org generates only Org fragments, this is very simple > > to do (with anonymous footnotes), but for other formats it can be > > rather complicated. Would calling `org-export-data-with-backend' > > handle this? If yes then adding an argument to request this call > > would be very useful. > > No, I don't think `org-export-data' would handle this. It may require > a more specific tool. > > Do you have a small example (org + desired output) so I can experiment > with it? In general (conceptually), if you have one footnote in text, and one in a footnote, with a note style, both will be rendered as footnotes. So in an adapted version from earlier: Text 1 [@cite:@a]. Text 2[fn:1]. [fn:1] This is [cite:@b]. Output would put both citations in respective footnotes. I included this originally in CSL to make it possible for a user to switch between note-based and other styles without having to modify their documents. Bruce
Re: wip-cite status question and feedback
Hello, András Simonyi writes: > This is a crucial point: when a note CSL style is used, the export has > to generate footnotes "around" those citations which are not already > in a footnote. > Since citeproc-org generates only Org fragments, this is very simple > to do (with anonymous footnotes), but for other formats it can be > rather complicated. Would calling `org-export-data-with-backend' > handle this? If yes then adding an argument to request this call > would be very useful. No, I don't think `org-export-data' would handle this. It may require a more specific tool. Do you have a small example (org + desired output) so I can experiment with it? Regards, -- Nicolas Goaziou
(Not so) Short note about citations in Org
Hello, I just rebased "wip-cite-new" branch, which now includes citation syntax, and an interface between external citation processors and the rest of Org. I'll throw in a demo at the end of this message. TL;DR: search for "Demo time". As a reminder, the full citation syntax is [cite/style:common prefix ;prefix -@key suffix; ... ; common suffix] Everything is optional, except the brackets, "cite" and the colon. Also the citation must contain at least a key. So its minimal form is: [cite:@key] or its "suppress author" variant: [cite:-@key] A noteworthy difference with the last merge is that I removed the opportunity to add some Org syntax (emphasis, sub/superscript…) in prefixes or suffixes. It makes the code a bit simpler. Of course, I'm open to discussion about this change. The syntax also introduces three keywords (square brackets are for optional arguments): #+bibliography: filename #+print_bibliography: [style] #+cite_export: backend-name [bibliography-style] [citation-style] Now, the real novelty is the new "oc.el" library, which is an API to operate simply on citations. I paste here its commentary section. This library provides tooling to handle citations in Org, e.g, follow, fontify, and export them, respectively called "follow", "activate" and "export" capabilities. Libraries responsible for providing some, or all, of these capabilities are called "citation processors". Such processors are defined using `org-cite-register-processor'. Using this function, it is possible, in addition to giving it a name, to attach functions associated to capabilities. As such, a processor handling citation export must set the `:export-citation' property to an appropriate function. Likewise, "activate" capability require an appropriate `:activate' property, and, unsurprisingly, "follow" capability implies `:follow' property. As a user, the first thing to do is setting a bibliography, either globally with `org-cite-global-bibliography', or locally using one ore more "bibliography" keywords. Then one can select any registered processor for each capability by providing a processor name to the variables `org-cite-activate-processor' and `org-cite-follow-processor'. The "export" capability is slightly more involved as one need to select the processor providing it, but may also provide a default style for citations and bibliography. These three parameters, or triplet, can be set in `org-cite-export-processor' variable, or in a document, through the "cite_export" keyword. Eventually, this library provides some tools, mainly targeted at processor implementors. Most are export-specific and are located in the "Tools only available during export" section. The few others can be used directly from an Org buffer, or operate on processors. See "Generic tools" section. There are two points of view to consider here. As a user, as stated above, you first need to provide a bibliography, for all documents using the `org-cite-global-bibliography' variable, or for a single document (or a set of documents, using "setupfile" keyword) with #+bibliography: one-file.bib #+bibliography: another-file.ext #+bibliography: "some file with spaces" You can use both the variable and the keywords, in which case files are _accumulated_ in the list. Then when you (require 'org-cite-something) the "oc-something.el" library, in addition to possibly many other tools, registers a "citation processor", for example `something'. That processor may operate on any of the three entry points "activate", "follow", or "export". If you are not sure about which one it supports, you may inspect the processor with, e.g., (org-cite-processor-has-capability-p 'something 'follow) If this is non-nil, you can set `org-cite-follow-processor' to `something'. Once done, calling `org-open-at-point' on a citation starts whatever action the processor defined. If the variable is nil, nothing happens. If you need to use a different processor for a given document, consider using file local variables. Likewise, you can fontify citations according to a given processor using `org-cite-activate-processor'. This time, however, Org provides some fontification even when the variable is nil. The default set-up merely applies new `org-cite' and `org-cite-key' faces on citations. The "export" capability introduces the concept of "style", which is an _indication_ to the citation processor, which may or may consider applying. More precisely, a style can be set for citations and bibliography, at three levels from the most general to the most specific: (setq org-cite-export-processor '(something "bibstyle" "citestyle")) #+cite_export: something bibstyle citestyle #+print_bibliography: bibstyle [cite/citestyle:...] An export processor is required to support at least one default style for cita
Re: stability of toc links
as it has been a long time my original post is Message ID and the content is === when you link to a section using toc, you get a link like https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab will these links break if somebody copies them and pastes them elsewhere? what if you add a section? there doesn't seem to be a perfect solution, short of adding custom id or id to everything, but perhaps a fuzzy hash of the header and contents of the section could be used? or a strict hash of the header? is anything like this being done? just curious. === On 4/21/21, Samuel Wales wrote: > more below. [note the two samuels.] > > On 4/21/21, Samuel Loury wrote: >> advance what heading he will share, so he would have to add CUSTOM_ID >> everywhere, just in case. This sounds like a lot of unnecessary work. >> >> The solution of tec¹ appears to be a new generation of the html ids based >> on the heading content rather than apparently randomly generated, making >> the generated link become the same across new generations. >> >> I hope it clarified the discussion. > > it did improve it. thank you. the above is concise and clear. > > suppose reader A wants to send a link to reader B. > > one exported [i did not use org's publish facility] post is > https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html > . it has MANY sections. i turn off toc for a whole section and then > put a toc in that section just to make the main toc less forbidding. > here is the html for just the top few entries of the main toc -- > notice 3 links each with a hex code that changes. > > > Table of Contents > > > This post > The name of the law > Basic facts > > suppose i add a section after This post. Most links will now be > broken. A could have sent any of them to B as raw hex links. > > i just want the problem understood at the user level. i get that > there are possible implementation issues. > > i spent 16 years researching and writing the blog post. i don't want > links to be broken or to have to kludge in a bunch of custom id or org > id properties drawers just in case somebody links. even if drawers > are added to every linked section automatically, it's a lot of clutter > and slowness [org id searches are slow and drawers have performance > issues that are being worked on but not merged into maint yet]. that > is a lot of drawers just for links that might or might not be sent. > > i am limited in computer use so i will probably not pursue this > further if there is no interest. > > there is some interest. e.g. carsten said he thought tec's code or > somethign like it should be merged into org qua org. > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: stability of toc links
more below. [note the two samuels.] On 4/21/21, Samuel Loury wrote: > advance what heading he will share, so he would have to add CUSTOM_ID > everywhere, just in case. This sounds like a lot of unnecessary work. > > The solution of tec¹ appears to be a new generation of the html ids based > on the heading content rather than apparently randomly generated, making > the generated link become the same across new generations. > > I hope it clarified the discussion. it did improve it. thank you. the above is concise and clear. suppose reader A wants to send a link to reader B. one exported [i did not use org's publish facility] post is https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html . it has MANY sections. i turn off toc for a whole section and then put a toc in that section just to make the main toc less forbidding. here is the html for just the top few entries of the main toc -- notice 3 links each with a hex code that changes. Table of Contents This post The name of the law Basic facts suppose i add a section after This post. Most links will now be broken. A could have sent any of them to B as raw hex links. i just want the problem understood at the user level. i get that there are possible implementation issues. i spent 16 years researching and writing the blog post. i don't want links to be broken or to have to kludge in a bunch of custom id or org id properties drawers just in case somebody links. even if drawers are added to every linked section automatically, it's a lot of clutter and slowness [org id searches are slow and drawers have performance issues that are being worked on but not merged into maint yet]. that is a lot of drawers just for links that might or might not be sent. i am limited in computer use so i will probably not pursue this further if there is no interest. there is some interest. e.g. carsten said he thought tec's code or somethign like it should be merged into org qua org. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Using backticks for the inline code delimeter?
On Tue, Apr 20, 2021 at 4:24 PM John Kitchin wrote: > I have used an approach like the one here > https://endlessparentheses.com/define-context-aware-keys-in-emacs.html > > to make context aware key-bindings. > > THanks John. That post was very helpful -- really all I was looking for was (org-in-src-block-p), but the larger infrastructure is cool and I'll keep it around for a while to see if I end up reusing it.
Re: wip-cite status question and feedback
Dear All, On Sun, 18 Apr 2021 at 15:11, Nicolas Goaziou wrote: > I am also leaning towards removing the possibility to include Org syntax > (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly > useful (you can move the bold part outside of the citation object), and > yet, adds a layer of complexity on top of the citation object. > > Can we assume (global)prefix/suffix are just plain text? > well, I think there might be some legitimate use cases, e.g., (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103) here one might want cf. to be set in italics, and I can imagine situations in which emphasizing a phrase in a prefix/suffix can be useful, but IMHO we can certainly start with assuming just plain text. > In any case, Org has no clue about the "location" of the citation. It > can provide the suffix associated to the citation key, but it is up to > the citation processor to extract page information out of it. If this is > desirable, we need to provide the full citation object instead of the > key. I don't know if it is worth the trouble. It would definitely be useful for making possible more sophisticated opening actions. > > Am I correct in assuming that the returned bibliography should be > > rendered as a legitimate Org fragment regardless of the back-end? > > I think it should be rendered as target format, to be on par with > citation handling. > > You may, however, use Org format as an intermediate step, and then, call > `org-export-data-with-backend' (from "ox.el") on it. If this is > desirable, I need to also provide a fifth `info' argument to the list > above. This is a crucial point: when a note CSL style is used, the export has to generate footnotes "around" those citations which are not already in a footnote. Since citeproc-org generates only Org fragments, this is very simple to do (with anonymous footnotes), but for other formats it can be rather complicated. Would calling `org-export-data-with-backend' handle this? If yes then adding an argument to request this call would be very useful. > > > > This might not be an important point, but citeproc-el is rather > > citation list oriented in the sense that it processes the list of all > > citations and returns a list of their formatted counterparts, so it > > might be useful to provide this "bulk" API as well, at least as an > > optional addition. > > I don't think any addition to the suggested API is required. If you > cannot split citation processing, you may fill a temporary cache holding > all exports on first citation (the full list of citations objects is > provided right from the start), then read from that cache on subsequent > citations. > > WDYT? Basically I agree, it would probably be premature optimization to provide anything else at this point. > I don't understand what you call the "identity of the notes". Could you > provide an example? I meant only that knowing whether a citation is in a footnote or not is not enough -- if a numerical note index is available which specifies the precise position of the note among the footnotes then this is exactly the information what is needed. > Situation in nested footnotes can be ambiguous, tho. In the following > example, is the expected order @a then @b then @c? --8<---cut here---start->8--- Text[fn:1] [@cite:@c] [fn:1] This[fn:2] is [cite:@b]. [fn:2] [cite:@a] --8<---cut here---end--->8--- Yes, I think the order here is @a @b and @c. >> there is CSL-JSON and a CSL-YAML etc. If different "display" >> and "follow" processors will be able to handle different formats then >> the users might want to change those settings locally as well, based >> on the bibliography format, but I'm not sure what kind of >> infrastructure would be the best way of supporting this. (E.g., >> registering format support information about the processors and >> choosing on this basis?) >I don't have an idea about it either. This is not a blocker, tho. We can >revisit it later, once we have "something" working. Absolutely, in the long run probably a way of explicitly specifying the bibliography format/type will be needed, but just a (file)name is a good starting point. thanks & best regards, András > > infrastructure would be the best way of supporting this. (E.g., > > registering format support information about the processors and > > choosing on this basis?) > > I don't have an idea about it either. This is not a blocker, tho. We can > revisit it later, once we have "something" working. > > Thanks for your feedback. > > Regards, > -- > Nicolas Goaziou
Re: wip-cite status question and feedback
and for completeness from the org-ref point of view, probably all of them call something like (org-ref-find-bibliography) inside those functions to get a list of bib sources from a hierarchy of local definitions in the buffer to env vars, to a default source variable defined in elisp. I think something similar is done in the bibtex-completion commands. Bruce D'Arcus writes: > On Wed, Apr 21, 2021 at 3:57 PM John Kitchin wrote: > >> I guess that the actions I use most often when "opening" a citation are, >> opening the pdf, going to the webpage for it, and then opening the >> bibtex entry (usually to fix capitalization or something). In org-ref >> though, there are a whole bunch of other potential actions, like >> searching for related citations, copying the key or formatted citation >> to the clipboard, etc. I guess my point is there are a lot of things >> that opening might mean to different people. > > Good point, which I missed. > > In bibtex-actions, which uses bibtex-completion as a backend, I have > the following "open" commands: > > - open-pdf > - open-link (doi or url) > - open (pdf, or link if not present) > - open-entry (bibtex, to edit) > - open-notes (to review, edit) > > All of those backend functions take KEYS as input. > > Bruce -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Re: wip-cite status question and feedback
A big +1 to everything John said. On this: On Wed, Apr 21, 2021 at 4:26 PM John Kitchin wrote: > 4. I tend to have my follow function launch a hydra menu, which provides > many action choices. I think this is easier than trying to remember a lot of > different commands that also work at the citation at point. I started > this with helm, then ivy and now hydra. I can't tell if a new generation > of approaches like selectrum, or the package bibtex-actions will > eventually replace these. The approach I take to menus of contextual commands in bibtex-actions is to rely on the Embark package, which will associate categorized completion candidates with a keymap of commands, and so make the commands available in context, display the menus depending on how you configure it (default embark menu vs which-key). https://github.com/oantolin/embark So I have no code specific to this, except that a) I give the candidates a "bibtex" metadata category in completing-read, and b) I provide a keymap. The user has to specify the association between the two, or to their own custom keymap. Conceptually, I'd guess we want something similar; for it to be easy to use hydra or embark or whatever to associate commands/functions with citation items (keys). Bruce
Re: wip-cite status question and feedback
>>> - "fontification" is meant to give full access to face selection, what >>> is really displayed, additional keymaps, all using a single >>> function. >> >>> At the moment, I have no idea about what arguments would be useful. >>> I think John Kitchin gave ideas about this already on this ML. >>> I have to re-read his posts on the subject. In any case, feedback >>> welcome. For fontification in an org-file, what I currently find helpful in org-ref: 1. the citations have a face that makes them stand out (it is usually a green color, unless the key is not found in the bibfiles, and then it is red). I have a way to turn that off though, because it can cause performance issues in large documents with large bibliographies. 2. There is a tooltip that shows a lightly formatted reference. The tooltip is fairly crude, and not related to any particular bibliography style. It would be great if it did, but so far the effort to achieve that has been too high. With an integrated citation processor it might be better, but I am skeptical they will ever look quite like they would in a latex export, especially if you use latex code in your bibtex files. This tooltip only needs to be good enough in my opinion to tell what the key is representing at that point. 3. I like having keymaps on the citations. The most common use for me is to press S-up to sort a sequence of citations by year, followed by S-left and S-right to transpose citations in a sequence, followed by M-left/right to navigate across citations. 4. I tend to have my follow function launch a hydra menu, which provides many action choices. I think this is easier than trying to remember a lot of different commands that also work at the citation at point. I started this with helm, then ivy and now hydra. I can't tell if a new generation of approaches like selectrum, or the package bibtex-actions will eventually replace these. This isn't quite fontification, but since you can put keymaps on with fontification, it isn't fully indpendent either. 5. I mostly think the citations should be displayed as plain text, i.e. not replaced by a numbered overlay, or equivalent. I could see hiding the [], but also guess that would be more confusing than beneficial. >> >> I'm thinking about implementing a "fontification" solution which would >> use citeproc-el with a standard style to produce nice preview-like >> representations of the citations in the buffer. This would require >> basically the same pieces of information as citation export I think, >> although it might be made strictly local, working only with the >> single citation object plus the bibliography information. > > OK. Citation object and list of bibliography files as arguments are > a starting point. > >>> A citation processor does not need to provide integration in all these >>> areas. Users may be able to mix and match processors. This is another >>> (minor) point which is yet to be designed. How is a user supposed to >>> select a processor for each integration area? It could be done through >>> three variables, e.g., >>> >>> (setq org-cite-display-processor 'org-ref) >>> (setq org-cite-export-processor 'citeproc) >>> (setq org-cite-follow-processor 'default) >>> >>> I think it is unlikely for a user to locally select "display" and >>> "follow" processors. However, we need a way to use a local export >>> processor for a given document. I may need to introduce >>> a #+citation_processor keyword during export. Any other idea? >> >> All of these solutions seem to be good starting points. As for >> setting the "display" and "follow" processors locally, this leads to a >> question which probably has to be addressed at a certain point: that >> of bibliography formats. The Emacs world is currently rather BibTeX >> centered, but biblatex is an important (and rather different) >> alternative, and there is CSL as well which I expect to become more >> and more relevant (it's citeproc-el's native format). Moreover, these >> formats have some variants, e.g., for BibTeX there is also org-bibtex, >> for CSL there is CSL-JSON and a CSL-YAML etc. If different "display" >> and "follow" processors will be able to handle different formats then >> the users might want to change those settings locally as well, based >> on the bibliography format, but I'm not sure what kind of >> infrastructure would be the best way of supporting this. (E.g., >> registering format support information about the processors and >> choosing on this basis?) > > I don't have an idea about it either. This is not a blocker, tho. We can > revisit it later, once we have "something" working. This suggests that there is an API of required functions that have a defined interface for these. That is sort of what org-ref does to support helm, and a few ivy backends for completion. It is mostly done by defining some variables that point to functions in those backend libraries, and the variables are funcalled in a core library.
Re: wip-cite status question and feedback
On Wed, Apr 21, 2021 at 3:57 PM John Kitchin wrote: > I guess that the actions I use most often when "opening" a citation are, > opening the pdf, going to the webpage for it, and then opening the > bibtex entry (usually to fix capitalization or something). In org-ref > though, there are a whole bunch of other potential actions, like > searching for related citations, copying the key or formatted citation > to the clipboard, etc. I guess my point is there are a lot of things > that opening might mean to different people. Good point, which I missed. In bibtex-actions, which uses bibtex-completion as a backend, I have the following "open" commands: - open-pdf - open-link (doi or url) - open (pdf, or link if not present) - open-entry (bibtex, to edit) - open-notes (to review, edit) All of those backend functions take KEYS as input. Bruce
Re: wip-cite status question and feedback
I guess that the actions I use most often when "opening" a citation are, opening the pdf, going to the webpage for it, and then opening the bibtex entry (usually to fix capitalization or something). In org-ref though, there are a whole bunch of other potential actions, like searching for related citations, copying the key or formatted citation to the clipboard, etc. I guess my point is there are a lot of things that opening might mean to different people. in org-ref, with any of those, the first step is finding where the key sits in your bib-files, and then getting that entry. It is in a way a primitive citation processor before the one that is used at export. Ihor Radchenko writes: > Nicolas Goaziou writes: > >> In my mind, "opening" leads to the bibliography reference, not to the >> original document. IIUC, in this situation, the location does not matter >> much, does it? >> >> In any case, Org has no clue about the "location" of the citation. It >> can provide the suffix associated to the citation key, but it is up to >> the citation processor to extract page information out of it. If this is >> desirable, we need to provide the full citation object instead of the >> key. I don't know if it is worth the trouble. > > From my experience using org-ref for citations, going to the > bibliography reference is rarely useful. Most of time, I want to jump to > the document I am citing (or even page in the document). > > I think that full citation object should be worth passing to the > citation backend. > > Best, > Ihor -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Re: Using backticks for the inline code delimeter?
John Kitchin writes: >> The challenge can be in identifying the most appropriate key bindings. >> This can depend on the platform you use as well. When I was only using >> Linux, I used the 'super' key for this and it was great. However, when I >> also started using a mac, I had to define a new scheme. It can take a >> bit of work to setup initially, but I think it is worth the effort. I >> now have the same bindings in multiple modes, so regardless of whether >> I'm writing markdown, org, html, rich text, etc, I just hit the same key >> bindings to mark content as code, bold, italic, etc. > > On a Mac, you might find these useful. I don't use the right command and > option keys, so I redefine them as hyper and super. they are right under > my thumb, and convenient. > > (setq mac-right-command-modifier 'hyper) > (setq mac-right-option-modifier 'super) That is useful information. The 'hyper key is certainly overlooked and provides a very useful mechanism to create a whole set of new, possibly short, key bindings. I like the idea of re-tasking the right hand command/option keys as it is very rare I use them (command/option is most used via left hand side for me). -- Tim Cross
Re: Concerns about community contributor support
"Bruce D'Arcus" writes: > I've been thinking about this general issue over the past year, as > it's a common problem regardless of project, hosting platform, etc. > > I do agree in general that situations where submission of ideas and > patches languish without attention are a problem. > > But while I don't think there are any easy answers, I do think clarity > upfront can help. > > For example, perhaps there needs to be a prominent statement early on > this page, which states upfront how the community vets new ideas or > patches, what someone who submits such can expect, including in terms > of timeline, and how to interpret lack of response? > > https://orgmode.org/worg/org-contribute.html > Yes, we can certainly help manage expectations, which I think is going to be more effective. At the very least, it is a good place to start. Perhaps it would be worthwhile if everyone interested in this issue have a look at what is on worg about contributing and propose some additions/updates? Responding to essentially just flag you have seen the patch message really only adds noise and may even 'drown out' those responses which add real 'value' to any discussion. I also doubt that asking people to do this would actually result in any actual change of behaviour by subscribers. -- Tim Cross
Re: Concerns about community contributor support
Eric S Fraga writes: > On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote: >> 1. A patch looks useful to me, but I feel I don't know if it's a good > > [...] > >>"Thanks for submitting this. I'd use it. Hopefully a maintainer >>will take a look." > > Ian, > > I think you will find that a few of us do post answers like this every > now and again. I know that I do. > > The lack of answers to cases 2 & 3 are essentially showing a lack of > interest which is basically an (implicit) answer as well. It may seem > dismissive but, given the volume of email some of us have to deal with > in our day job, it's just reality, I would suggest, without it meaning > to be judgemental in any way. > > (now back to my day job ;-)) +1. If a patch is of interest to me, I usually respond. I don't respond to patches which are of no interest or which I don't understand. -- Tim Cross
Re: Using backticks for the inline code delimeter?
> The challenge can be in identifying the most appropriate key bindings. > This can depend on the platform you use as well. When I was only using > Linux, I used the 'super' key for this and it was great. However, when I > also started using a mac, I had to define a new scheme. It can take a > bit of work to setup initially, but I think it is worth the effort. I > now have the same bindings in multiple modes, so regardless of whether > I'm writing markdown, org, html, rich text, etc, I just hit the same key > bindings to mark content as code, bold, italic, etc. On a Mac, you might find these useful. I don't use the right command and option keys, so I redefine them as hyper and super. they are right under my thumb, and convenient. (setq mac-right-command-modifier 'hyper) (setq mac-right-option-modifier 'super) -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Re: wip-cite status question and feedback
On Wed, Apr 21, 2021 at 1:08 PM Nicolas Goaziou wrote: > I will take care about the default back-end (hopefully before the end of > the week but don't hold your breath), but can only provide guidance for > the conversion part. I hope there is enough motivated people to give it > a try. My lisp skills are rather weak, but I recently started a project called bibtex-actions, which is similar to ivy/helm-bibtex but for completing-read. If someone wants to help implement support for inserting citations using the new cite syntax, I've created an issue with some ideas here: https://github.com/bdarcus/bibtex-actions/issues/108 Bruce
Re: wip-cite status question and feedback
Hello, Matt Price writes: > As a user, is there any way I can participate at this point? I'm not in a > position to contribute code tight now but really do want to have this > feature as soon as possible. It's going to improve my students' lives quite > a bit. Thank you for your interest. I have completed step 2, barring some documentation to write. At this point, there is a defined citation syntax (step 1), and a complete API to operate on citations (step 2). I will rebase "wip-cite-new" branch and post a wrap-up soon. Once done, the next step is to write a limited default back-end, and, more importantly, to convert existing citation systems to use the API, and extend it if required. I will take care about the default back-end (hopefully before the end of the week but don't hold your breath), but can only provide guidance for the conversion part. I hope there is enough motivated people to give it a try. So, while participation is mostly code-related at this point, you can certainly comment about the usability of the API from a user POV. Of course, at this point, we need something that works well enough, not necessarily something feature complete. Also, if all goes well, there will be a need for a complete documentation in the manual… Hear, hear. Regards, -- Nicolas Goaziou
Re: stability of toc links
Hello, > The solution of tec¹ appears to be a new generation of the html ids based > on the heading content rather than apparently randomly generated, making > the generated link become the same across new generations. AFAICT, the link you send only contains code, not explanations nor design. In particular, I'm not sure to understand how one system can generate an ID based on the heading content and still limit itself to alphanumeric characters. For example, what ID are generated with the following document? --8<---cut here---start->8--- * こんにちは * ｺﾝﾆﾁﾊ --8<---cut here---end--->8--- Also, does the ID stay stable if you start the following document --8<---cut here---start->8--- * A :PROPERTIES: :CUSTOM_ID: こんにちは :END: --8<---cut here---end--->8--- and then edit it to become: --8<---cut here---start->8--- * B :PROPERTIES: :CUSTOM_ID: こんにちは :END: --8<---cut here---end--->8--- I hear about stability of links, which is a detail of implementation. We current only cache, and freeze, ID actually being referred to, but that could be extended. I'd link to make sure everyone understands the problems that the current implementation is trying to solve before throwing it out of the window. Regards, -- Nicolas Goaziou
Re: [PATCH] Startup option to separate macros arguments with an alternative string
Hello again.
I forgot to answer this question on your previous message, sorry...
Nicolas Goaziou writes:
> That being said, we can discuss syntax that is not depending upon some
> variable. For example macro names are written with a limited set of
> characters (alphanumeric, dash, underscore). We might allow the optional
> argument separator to be located right before the opening parenthesis,
> e.g.,
>
> {{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
> {{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
I think it's a very interesting idea. I've made this sketch (at least
as a proof of concept), what do you think of the approach?
Example (and code below):
#+macro: foo (eval (format "%s and %s" $1 $2))
{{{foo(xxx,zzz\, yyy)}}}
{{{foo|(xxx|zzz, aaa)}}}
{{{foo@(xxx@zzz, sss)}}}
{{{foo|(xxx|zzz\| aaa)}}}
{{{foo@(xxx@zzz\@ sss)}}}
#+begin_src emacs-lisp
(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
(format "\\(*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str
(concat (make-string (/ len 2) ?\\)
(if (zerop (mod len 2)) "\000" (format "%s" sep)
s nil t)
"\000"))
(defun org-element-macro-parser ()
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
a plist with `:key', `:args', `:begin', `:end', `:value' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
(when (looking-at
"{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z]*[^-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
(let ((begin (point))
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
(args (pcase (match-string-no-properties 4)
(`nil nil)
(a (org-macro-extract-arguments
(if (not (equal (match-string-no-properties 2) ""))
(match-string-no-properties 2)
",")
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))
(list 'macro
(list :key key
:value value
:args args
:begin begin
:end end
:post-blank post-blank))
(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
(format "\\(*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str
(concat (make-string (/ len 2) ?\\)
(if (zerop (mod len 2)) "\000" (format "%s" sep)
s nil t)
"\000"))
#+end_src
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hi all, Maxim Nikulin writes: > I think, new variant should be committed even it does not fix Juan's > case. He have not confirmed the fix yet. Sorry, I have been busy with other matters and had lost the thread of the discussion. I'm catching up on the messages... I have tried the Nicolas' patch (latest version) and I see that the items with emphasis are already ordered well. However, it seems that the problem with identical items with or without emphasis still persists: which items should go before and in what order? For example, in the following list I get: - /a/ - *a* - a - *b* - /b/ - b - /v/ - *v* - v Anyway, I think it is a minor problem (I can't think of many scenarios in real life where this problem is relevant). In a more realistic case, the result is correct: - lo /bueno/ - lo bueno - lo /vano/ - lo vano ... - /a/ - b - /v/ - *z* Best regards, Juan Manuel
Re: Concerns about community contributor support
I've been thinking about this general issue over the past year, as it's a common problem regardless of project, hosting platform, etc. I do agree in general that situations where submission of ideas and patches languish without attention are a problem. But while I don't think there are any easy answers, I do think clarity upfront can help. For example, perhaps there needs to be a prominent statement early on this page, which states upfront how the community vets new ideas or patches, what someone who submits such can expect, including in terms of timeline, and how to interpret lack of response? https://orgmode.org/worg/org-contribute.html Bruce
Re: Concerns about community contributor support
On Wed, Apr 21, 2021 at 9:27 AM Eric S Fraga wrote: > > On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote: > > 1. A patch looks useful to me, but I feel I don't know if it's a good > > [...] > > >"Thanks for submitting this. I'd use it. Hopefully a maintainer > >will take a look." > > Ian, > > I think you will find that a few of us do post answers like this every > now and again. I know that I do. > I didn't mean to imply that you or anyone else never does this. I actually don't do it myself, and on reflection I believe it is for the reasons I listed above (a patch may look helpful but I don't know for sure that it'll be good overall, or it applies to a part of the code that I've not looked at). I thought others might have the same reasons for not responding. The lack of answers to cases 2 & 3 are essentially showing a lack of > interest which is basically an (implicit) answer as well. It may seem > dismissive but, given the volume of email some of us have to deal with > in our day job, it's just reality, I would suggest, without it meaning > to be judgemental in any way. > Lack of interest /is/ an implicit answer. The question is if that is a good way to answer. I agree with Timothy that ignoring newcomers' first attempt at contribution is an effective way to drive people away. Is that worth it in order to reduce email?
Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag
On Wed, Apr 21, 2021 at 2:39 AM Dr. Arne Babenhauserheide wrote: > > Jens Lechtenboerger writes: > > > On 2021-04-20, Tim Visher wrote: > > > >> I guess regardless it sounds like if I were to go to the trouble of > making > >> a patch for this it would be good to make sure that it was behind an > option > >> and probably defaulting to the current HEAD behavior of including the > ASCII > >> markup with an option to strip the non-word characters from it. > > > > That would be great. > > It is something that could also benefit the LaTeX export. Having special > characters in the pdftitle can make the export fail, but those > characters (like @@latex:\something@@) can make the latex-compilation > fail. Awesome. Do you know whether there's an official way to share this sort of behavior between ox backends or is it just creating a function and calling it from both places or something? -- In Christ, Timmy V. https://blog.twonegatives.com http://five.sentenc.es
Re: Concerns about community contributor support
On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote: > 1. A patch looks useful to me, but I feel I don't know if it's a good [...] >"Thanks for submitting this. I'd use it. Hopefully a maintainer >will take a look." Ian, I think you will find that a few of us do post answers like this every now and again. I know that I do. The lack of answers to cases 2 & 3 are essentially showing a lack of interest which is basically an (implicit) answer as well. It may seem dismissive but, given the volume of email some of us have to deal with in our day job, it's just reality, I would suggest, without it meaning to be judgemental in any way. (now back to my day job ;-)) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: stability of toc links
Nicolas Goaziou writes: [...] > Samuel Wales writes: > >> i was referring to: >> >> Message ID <87v9dbelky@gmail.com> >> >> in this thread. >> >> [and other posts in this thread related to it.] > > Unfortunately, I won't have time to look at the whole thread anytime > soon. However, feel free to explain how "tec's fix" works, or point me > to the exact post where it is explained so I can understand it. > >> the problem as i see it is link stability in generated output. > > The links are stable if you publish a document. Note that you can even > "publish" a single document. > > For exported (i.e., one off documents), this is not so an issue (IMO) > since you have custom ID. I assume this was evoked in the thread. I think you are both talking about the same thing but have different judgment calls about it. Say you want to export an org file, then share the link to a friend to a heading, like https://mysite/#orgd260798 Imagine that for some reason, you re export the file, then new ids are generated and the links becomes broken. Nicolas Goaziou, I know you understand this and propose to use CUSTOM_ID to make those ids static. But IIUC, Samuel Wales does not know in advance what heading he will share, so he would have to add CUSTOM_ID everywhere, just in case. This sounds like a lot of unnecessary work. The solution of tec¹ appears to be a new generation of the html ids based on the heading content rather than apparently randomly generated, making the generated link become the same across new generations. I hope it clarified the discussion. My best, ¹ https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A signature.asc Description: PGP signature
Re: [Patch] to correctly sort the items with emphasis marks in a list
On 21/04/2021 03:37, Nicolas Goaziou wrote: Maxim Nikulin writes: (let ((s (org-sort-remove-invisible "A wrapping [[https://orgmode.org?a=b&c=d#e][link]] emphasis/" I expect "A wrapping link emphasis". Yet, your expectations are wrong. There is no link in the text above. Emphasized text starts at "/wrapping" and ends before "/?". Granted, this is a situation where the Org syntax is not very intuitive. Anyway, the new function is more accurate. I think, new variant should be committed even it does not fix Juan's case. He have not confirmed the fix yet. Maybe we should require a space after punctuation following emphasized text. I don't know. This is orthogonal to the current discussion. I still believe in my expectation, however I admit such limitation of parser. At first I have not recognized that the issue may be similar to https://orgmode.org/list/CAH+Wm4-_XHUZKFTf=ztbfncpvqwkbeoegs8epym+8spmu8l...@mail.gmail.com/ Anyway for my example workaround is to add more markers before, inside, and after the link. Maybe I will look closer at Tom's parser if it solves ambiguity in the same way. In the meanwhile I have tried (benchmark-run 1 (org-sort-list t ?a)) in a file (1100 lines) obtained using I don't think performance is really an issue. Of course, the suggested function is clearly slower than the current one. It is OK since difference is not really huge, especially taking into account that new variant was not compiled. Do you still have problem with locale dependency of added tests? I can not guess what could be its source and expect that test should work reliably. Disregard "/3" in the subject of the patches. Third change is your code. >From c2c46d133e80ffa2323618ac88a1902e63ba1efc Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Mon, 19 Apr 2021 19:06:36 +0700 Subject: [PATCH 1/3] More tests for `org-sort-list' * lisp/org.el (org-verbatim-re): Add to the docstring a statement concerning subgroups meaning. * testing/lisp/test-org-list.el (test-org-list/sort): Add cases with text emphasis. Stress in comments that it is significant whether locale-specific collation rules ignores spaces. * testing/lisp/test-org.el (test-org/org-sort-remove-invisible): Add tests for `org-sort-list' helper. --- lisp/org.el | 3 ++- testing/lisp/test-org-list.el | 34 +- testing/lisp/test-org.el | 25 + 3 files changed, 60 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c2738100f..3d4f5553a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3685,7 +3685,8 @@ After a match, the match groups contain these elements: 5 The character after the match, empty at the end of a line") (defvar org-verbatim-re nil - "Regular expression for matching verbatim text.") + "Regular expression for matching verbatim text. +Groups 1-5 have the same meaning as in `org-emph-re' pattern.") (defvar org-emphasis-regexp-components) ; defined just below (defvar org-emphasis-alist) ; defined just below diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el index 3689a172f..cc7914c8d 100644 --- a/testing/lisp/test-org-list.el +++ b/testing/lisp/test-org-list.el @@ -1225,7 +1225,39 @@ b. Item 2" (equal "- b\n- a\n- C\n" (org-test-with-temp-text "- b\n- C\n- a\n" (org-sort-list t ?A) - (buffer-string)) + (buffer-string + ;; Emphasis in the beginning. + (should + (equal "- a\n- /z/\n" + (org-test-with-temp-text "- /z/\n- a\n" +(org-sort-list t ?a) +(buffer-string + (should + (equal "- *a*\n- z\n" + (org-test-with-temp-text "- z\n- *a*\n" +(org-sort-list t ?a) +(buffer-string + ;; Emphasis of second word. + ;; Locales with significant spaces (C, es_ES, pl_PL) + ;; are more sensitive to problems with sort. + (should + (equal "- a b\n- a /z/\n" + (org-test-with-temp-text "- a /z/\n- a b\n" +(org-sort-list t ?a) +(buffer-string + (should + (equal "- a *b*\n- a z\n" + (org-test-with-temp-text "- a z\n- a *b*\n" +(org-sort-list t ?a) +(buffer-string + ;; Space role in sorting. + ;; Test would fail for locales with ignored space, e.g. en_US, it works + ;; in C and currently rare locales having significant space (es_ES, pl_PL) + (should + (equal "- Time stamp\n- Timer\n" + (org-test-with-temp-text "- Timer\n- Time stamp\n" +(org-sort-list t ?a) +(buffer-string)) ;; Sort numerically. (should (equal "- 1\n- 2\n- 10\n" diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index f6fb4b3ca..3f74b3f35 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -8262,4 +8262,29 @@ two (provide 'test-org) +(
Re: Concerns about community contributor support
Heinz Tuechler writes: > Tim Cross wrote on 21.04.2021 11:50: >> I find bug fixes are applied very quickly. Enhancements and extensions >> are introduced more conservatively, but I think that is a positive >> rather than negative aspect of org development. For many users, org is >> already very feature rich/complete. > > This is my view as an org user too. I read this list with interest and > appreciate bug fixes. Similar to what Eric stated, much of my work flow > depends on org. Therefore my main interest is in stability and > consistency of org. I just want to jump in before the "Re:" becomes inaccurate, I don't think stability and consistency has much to do with responding to contributions, it just changes what the response may be --- which is another matter. -- Timothy
Re: BNF grammar (was Concerns about community contributor support)
Hello, I just saw your message, and I wonder if there's an "official" channel to discuss these efforts. I have no experience in theoretical parsing/lexing, but I'm interested in learning and spending some time on externalizing org-mode parsing to make it actually available outside of Emacs. I have a bunch of questions like "how do you currently setup your test harness for that ?" "Do you know the current limitations of this model ?" and stuff like that. At least, I could try to use that BNF grammar with something like LPeg, to see if I can get a somehow working lua parser for org-mode (going for lua here because I'd prefer an easy-to-embed / small-runtime-dependency parsing helper basically) Seeing this was a great news for the day to me, so thanks :) Gerry Agbobada
Re: Concerns about community contributor support
Timothy, thanks for raising this. I agree with everything you've said in this thread. I think it may be a hard problem to solve, but maybe we can start by just trying to improve. To be clear the problem I'm talking about is that potential contributors sometimes receive no response from the list. Maybe it could help to normalize somewhat generic responses. Here are some possible situations where we might not respond to a patch submission, followed by a potential response we might consider: 1. A patch looks useful to me, but I feel I don't know if it's a good idea for org in general, or maybe I think it is but I cannot apply the patch because (I'm not a maintainer, I don't have elisp experience, I haven't signed the copyright release, etc) "Thanks for submitting this. I'd use it. Hopefully a maintainer will take a look." 2. A patch does not look useful to me, but I can see how it may be useful to someone else and it was posted a while ago and no one has commented yet. "Thanks for submitting this. It looks like this affects an org feature that not many of us use. Sorry, but it might not get much attention." 3. A patch does not look useful to me, and can't imagine how it is useful in any context. "What is your use case?" These trite responses may be seen as mailing list noise, but I don't think so. They assure the patch submitter that their patch has been seen and at least for (1) they signal to maintainers that the patch would be useful to somebody. There are volunteer maintainers for the codebase, and volunteers who help with the mailing list. Maybe someone who wants to help with this could check Bark once in a while and respond to submissions that have been missed or post them to the list to put them in front of everyone again.
Re: Concerns about community contributor support
Tim Cross wrote on 21.04.2021 11:50: I find bug fixes are applied very quickly. Enhancements and extensions are introduced more conservatively, but I think that is a positive rather than negative aspect of org development. For many users, org is already very feature rich/complete. This is my view as an org user too. I read this list with interest and appreciate bug fixes. Similar to what Eric stated, much of my work flow depends on org. Therefore my main interest is in stability and consistency of org. best regards, Heinz
Re: Concerns about community contributor support
Jean Louis writes: > It should be clear that more maintainers and developers with direct > access are needed for patches to be applied timely. > > I am sure that those on emacs-devel mailing list, Emacs developers, > they could help on that, but maybe some of them do not observe this > mailing list. > > Number of not applied patches does not seem to be that large. > > Project leader shall have his team and delegate them to other > developers. > > This situation badly contradicts to Org mode purposes which is meant > to manage patches. > > Maybe there shall be a published list of developers and project > managers, so that this type of communication may be addressd > properly. As now original poster explained the problem, but I did not > see response from none of pushers, I mean those who have repository > access. > > So how many people are there who have repository access? > > Who is not busy but willing to apply at least 1-5 patches pending? > I'm not sure I agree with this analysis. As Timothy mentioned a few times, the issue is NOT about the time taken to apply patches. It is about a lack of feedback regarding the state of the patches. Increasing the number of people with the ability to apply patches/changes to the repository is unlikely to be helpful. It could in fact have the reverse result, leading to increased inconsistency and reduced stability. I find bug fixes are applied very quickly. Enhancements and extensions are introduced more conservatively, but I think that is a positive rather than negative aspect of org development. For many users, org is already very feature rich/complete. -- Tim Cross
Re: [PATCH] org.el (org-show-context-detail): add option 'ancestors-with-entry
Hi Nicolas, On Wed, Apr 21, 2021, at 5:15 PM, Cheong Yiu Fung wrote: > The first patch implements the changes. I took the liberty to show > entry of its ancestors > too (4 in the test case). Many users, I believe, rarely put text there, > so it does not > make a difference. I would like to rescind my previous comments. It's awkward for me to realize I do have a lot of ancestor text that I do not wish to be exported. Please ignore patches in the previous message and use the latest ones attached. Thanks! YiufungFrom 203364db88d25e5aea4cf295584617757c18591c Mon Sep 17 00:00:00 2001 From: Cheong Yiu Fung Date: Wed, 21 Apr 2021 16:27:03 +0800 Subject: [PATCH 2/2] org-manual.org: add hints for visible-only export --- 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 efe956877..16dd4a52f 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -11524,7 +11524,8 @@ further alter what is exported, and how. Toggle visible-only export. This is useful for exporting only certain parts of an Org document by adjusting the visibility of - particular headings. + particular headings. See also the variable + ~org-show-context-detail~ and the command ~org-sparse-tree~. ** Export Settings :PROPERTIES: -- 2.31.1 From ad1611831535a602c1d4b0bd8c92fea2ddde0551 Mon Sep 17 00:00:00 2001 From: Cheong Yiu Fung Date: Wed, 21 Apr 2021 16:26:14 +0800 Subject: [PATCH 1/2] org.el (org-show-context-detail): add option 'ancestors-full * lisp/org.el: Add option 'ancestors-full to `org-show-context-detail', update `org-show-set-visibility' accordingly * testing/lisp/test-org.el: Add tests. --- lisp/org.el | 15 ++- testing/lisp/test-org.el | 4 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 675a614e2..ac006eb6d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1199,6 +1199,8 @@ Allowed visibility spans are ancestors show current headline and its direct ancestors; if point is not on headline, also show entry + ancestors-full show current subtree and its direct ancestors + lineageshow current headline, its direct ancestors and all their children; if point is not on headline, also show entry and first child @@ -1240,6 +1242,7 @@ more context." (const minimal) (const local) (const ancestors) + (const ancestors-full) (const lineage) (const tree) (const canonical)) @@ -6758,9 +6761,9 @@ be shown." (defun org-show-set-visibility (detail) "Set visibility around point according to DETAIL. -DETAIL is either nil, `minimal', `local', `ancestors', `lineage', -`tree', `canonical' or t. See `org-show-context-detail' for more -information." +DETAIL is either nil, `minimal', `local', `ancestors', +`ancestors-full', `lineage', `tree', `canonical' or t. See +`org-show-context-detail' for more information." ;; Show current heading and possibly its entry, following headline ;; or all children. (if (and (org-at-heading-p) (not (eq detail 'local))) @@ -6775,14 +6778,16 @@ information." (org-with-limited-levels (cl-case detail ((tree canonical t) (org-show-children)) - ((nil minimal ancestors)) + ((nil minimal ancestors ancestors-full)) (t (save-excursion (outline-next-heading) (org-flag-heading nil))) + ;; Show whole subtree. + (when (eq detail 'ancestors-full) (org-show-subtree)) ;; Show all siblings. (when (eq detail 'lineage) (org-show-siblings)) ;; Show ancestors, possibly with their children. - (when (memq detail '(ancestors lineage tree canonical t)) + (when (memq detail '(ancestors ancestors-full lineage tree canonical t)) (save-excursion (while (org-up-heading-safe) (org-flag-heading nil) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index f6fb4b3ca..47732dfa3 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -7982,6 +7982,10 @@ CLOCK: [2012-03-29 Thu 10:00]--[2012-03-29 Thu 16:40] => 6:40" (should (equal '(0 7 8 9) (funcall list-visible-lines 'local nil))) (should (equal '(0 3 7) (funcall list-visible-lines 'ancestors t))) (should (equal '(0 3 7 8) (funcall list-visible-lines 'ancestors nil))) +(should (equal '(0 3 7 8 9 10 11) + (funcall list-visible-lines 'ancestors-full t))) +(should (equal '(0 3 7 8 9 10 11) + (funcall list-visible-lines 'ancestors-full nil))) (should (equal '(0 3 5 7 12) (funcall list-visible-lines 'lineage t))) (should (equal '(0 3 5 7 8 9 12) (funcall list-visible-lines 'lineage nil))) (should (equal '(0 1 3 5 7 12 13) (funcall list-visible-lines 'tree t))) -- 2.31.1
Re: Concerns about community contributor support
It should be clear that more maintainers and developers with direct access are needed for patches to be applied timely. I am sure that those on emacs-devel mailing list, Emacs developers, they could help on that, but maybe some of them do not observe this mailing list. Number of not applied patches does not seem to be that large. Project leader shall have his team and delegate them to other developers. This situation badly contradicts to Org mode purposes which is meant to manage patches. Maybe there shall be a published list of developers and project managers, so that this type of communication may be addressd properly. As now original poster explained the problem, but I did not see response from none of pushers, I mean those who have repository access. So how many people are there who have repository access? Who is not busy but willing to apply at least 1-5 patches pending? Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
Re: [PATCH] org.el (org-show-context-detail): add option 'ancestors-with-entry
Hi Nicolas, The first patch implements the changes. I took the liberty to show entry of its ancestors too (4 in the test case). Many users, I believe, rarely put text there, so it does not make a difference. But when someone write short notes at this location, I think it serves as brief "contextual" information for all its children, our target headline included. It may indicate the intention to include contextual information in output too, so I go with such guess. If user does not want it to be included, it is easier for him to work around (e.g., by creating a new heading and put text under), than the other way around, that is, to reveal text one by one. The second patch suggests how it can be integrated with `org-sparse-tree' in the manual. I think the new option, as the first visibility option to show subtree, would make `visible-only' option a lot more useful. Whether to include it in the manual I leave it to your consideration. Lastly I'd like to say thanks as a daily Org user, thank you for putting time in overseeing the project. Your efforts are appreciated by many :) Regards, Yiufung From d278837240c2cd03bc3ac448b8fb40d8c0866c5c Mon Sep 17 00:00:00 2001 From: Cheong Yiu Fung Date: Wed, 21 Apr 2021 16:26:14 +0800 Subject: [PATCH 1/2] org.el (org-show-context-detail): add option 'ancestors-full * lisp/org.el: Add option 'ancestors-full to `org-show-context-detail', update `org-show-set-visibility' accordingly * testing/lisp/test-org.el: Add tests. --- lisp/org.el | 18 -- testing/lisp/test-org.el | 4 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 675a614e2..80039c802 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1199,6 +1199,9 @@ Allowed visibility spans are ancestors show current headline and its direct ancestors; if point is not on headline, also show entry + ancestors-full show current headline, entry, subtree, current + headline's direct ancestors and their entries + lineageshow current headline, its direct ancestors and all their children; if point is not on headline, also show entry and first child @@ -1240,6 +1243,7 @@ more context." (const minimal) (const local) (const ancestors) + (const ancestors-full) (const lineage) (const tree) (const canonical)) @@ -6758,9 +6762,9 @@ be shown." (defun org-show-set-visibility (detail) "Set visibility around point according to DETAIL. -DETAIL is either nil, `minimal', `local', `ancestors', `lineage', -`tree', `canonical' or t. See `org-show-context-detail' for more -information." +DETAIL is either nil, `minimal', `local', `ancestors', +`ancestors-full', `lineage', `tree', `canonical' or t. See +`org-show-context-detail' for more information." ;; Show current heading and possibly its entry, following headline ;; or all children. (if (and (org-at-heading-p) (not (eq detail 'local))) @@ -6775,18 +6779,20 @@ information." (org-with-limited-levels (cl-case detail ((tree canonical t) (org-show-children)) - ((nil minimal ancestors)) + ((nil minimal ancestors ancestors-full)) (t (save-excursion (outline-next-heading) (org-flag-heading nil))) + ;; Show whole subtree. + (when (eq detail 'ancestors-full) (org-show-subtree)) ;; Show all siblings. (when (eq detail 'lineage) (org-show-siblings)) ;; Show ancestors, possibly with their children. - (when (memq detail '(ancestors lineage tree canonical t)) + (when (memq detail '(ancestors ancestors-full lineage tree canonical t)) (save-excursion (while (org-up-heading-safe) (org-flag-heading nil) - (when (memq detail '(canonical t)) (org-show-entry)) + (when (memq detail '(ancestors-full canonical t)) (org-show-entry)) (when (memq detail '(tree canonical t)) (org-show-children)) (defvar org-reveal-start-hook nil diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index f6fb4b3ca..36658d51d 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -7982,6 +7982,10 @@ CLOCK: [2012-03-29 Thu 10:00]--[2012-03-29 Thu 16:40] => 6:40" (should (equal '(0 7 8 9) (funcall list-visible-lines 'local nil))) (should (equal '(0 3 7) (funcall list-visible-lines 'ancestors t))) (should (equal '(0 3 7 8) (funcall list-visible-lines 'ancestors nil))) +(should (equal '(0 3 4 7 8 9 10 11) + (funcall list-visible-lines 'ancestors-full t))) +(should (equal '(0 3 4 7 8 9 10 11) + (funcall list-visible-lines 'ancestors-full nil))) (should (equal '(0 3 5 7 12) (funcall list-visible-lines 'lineage t))) (should (equal '(0 3 5 7 8 9 12) (funcall list-visible-lines 'lineage nil))) (should (equal '(0 1 3 5 7 12 13) (funcall list-visible-lines 'tree t))) -- 2.31.1 From 86adcab8a83c782b9a039aa9791
Re: stability of toc links
Hello, Samuel Wales writes: > i was referring to: > > Message ID <87v9dbelky@gmail.com> > > in this thread. > > [and other posts in this thread related to it.] Unfortunately, I won't have time to look at the whole thread anytime soon. However, feel free to explain how "tec's fix" works, or point me to the exact post where it is explained so I can understand it. > the problem as i see it is link stability in generated output. The links are stable if you publish a document. Note that you can even "publish" a single document. For exported (i.e., one off documents), this is not so an issue (IMO) since you have custom ID. I assume this was evoked in the thread. Link stability is also tied to publishing process because it needs a cache. And I lazily re-used the cache already implemented there. Regards, -- Nicolas Goaziou
Re: [PATCH] ob-tangle.el: Speed up tangling
Sébastien Miquel writes: > On second thought, I'm uneasy about my approach. If tangling fails, > the user might miss the error message since it is quickly replaced by > the tangling info. Ideally we should backup all the tangled files and > restore them all if a single one fails to ensure we're back to a > consistent state. > > I'm unsure what would be best practices here. In case of a remote > tangled files, I don't know if temporary files should be remote or > not, and what guarantees do emacs primitives such as ~rename-file~ > offer. Just 2c from me on how I'd like this to work as a user, when tangling fails: + Every file that could be tangled is tangled, or there's a variable which controls what to do on an error + Loud message at the end that lists all files which files failed to tangle -- Timothy
