Re: Proposal: 'executable' org-capture-templaes
Ihor Radchenko writes: > Tim Cross writes: > >> I'm not sure I really understand the exact goal you have here. To me, it >> feels like yet another input selection/menu/completion scheme and I'm >> not clear on how it will be an improvement or why do something >> 'different' in org compared to other modes etc. However, I also don't >> have any problems using the existing capture interface, so perhaps I >> just don't have the number or complexity of capture choices to expose >> issues/limitations wiht the existing approach. >> >> The main 'concern' (well, not really a concern, but ) I have is that >> Emacs already has far too many solutions along this line, which makes it >> harder to get a consistent UI. I also feel this is one of those areas >> which appears to be really easy to 'fix' or improve, but also has a lot >> of hidden complexity which only becomes evident once lots of different >> users and workflows try to use it. > > Let me clarify my vision of this thread. > > 1. Arthur is interested to implement something similar to org-capture >menu. We can help him with this regardless of our stance on whether >to include the result into Org. > > 2. Org mode has multiple implementations of menu. Menus for org-capture, >org-export, org-todo, org-set-tags-command, and org-agenda are all >implemented independently creating redundancy in our codebase. > > 3. Because of the redundancy, there has been a proposal in the past to >switch from our existing menus to transient. However, it will be a >breaking change. We would prefer to support old menus as well (at >least for a handful of years) > > 4. If Arthur's implementation turns out sufficient to replicate the >"look and feel" or our existing menus, we can use it instead. This >will at least reduce the amount of menu code in Org. We can also take >this opportunity to make the menu backend selectable: the old menus, >Arthur's menu backend, transient. Then, we can eventually drop the >old menus backend and leave Arthur's + transient. They will be much >easier to maintain, especially if Arthur's implementation can be >distributed as separate package (even if not, one menu implementation >is easier than multiple that we have now). Hello, and sorry for long time no hear ... thought I would had something last weekend, but it took a bit longer time. Anyway, I have been playing and testing a bit, and didn't want to prolong discussion untill I have something to show. So here is a small prototype. It is just a rough sketch of the idea. The idea is simple: just ordinary keymap, with automated mode and keymap creation from templates. It uses simple template format to specify a key and a label to display in a buffer for the user. It can either return the template back to some callback, or it can use the 3rd argument as "executable" and wrap it in an interactive lambda to tuck into the keymap. I think that it is the minimum required. Rest is a boilerplate. It also puts declaration of gui and logic in same place (the template). For example org-capture defines its own template language, so it is just to give the chosen template to org-capture. This is what org-mks does, pretty much. I have just refactored the org-capture in an example to show that it is possible to implement the equivalent with almost no changes, more than it does not use org-mks under the hood. There is no code saving there. However, when it comes to org-agenda, as I see from the current implementation it does not use org-mks at all, but does something very similar on it's own, with ui and logic hardcoded in `org-agenda-get-restriction-and-command'. In this example the mode map approach seems slightly more convenient. I don't know, in org-agenda-test, I haven't implemented all of org-agenda, restrictions, prefixes and some other stuff, mostly because I don't really understand the implementation. I didn't want to sitt too long and figure out how stuff works, if the fundamental approach is not acceptable, but I have implemented quite few of the menu choices, at least to show the pattern. As said, it is just a rough sketch to illustrate the idea. I am not sure myself if it is good idea or not. I have implemented it so it works with org-capture templates, and I hope it wasn't too much of extra "customizations" tossed in. "Horizontal" menu was needed to simulate org-agenda looks, otherwise the code would be much smaller. Also to note is that the "logic" does not use anything in buffer on display, so it would be possible for someone interested to "rice" it up after the drawing is done, so the customization options could be further reduced. To answer some questions I have seen in mails, sorry for late answeres: @Ihor I really don't have problem with "read key". Originally I just wanted to extend org-capture templates to do a bit extra :). Actually org-mks and similar approach is really efficient in terms of resource (no minor/major modes
LoB elsipgantt sample input table
Hi All, I'm currently trying to cleanup some of the blocks and examples in the library-of-babel.org file on worg. One of the more interesting code blocks is elispgantt, which can generate a Gantt chart from data supplied in a table. It is based on code originally submitted by Eric Fraga and modified by Tom Dye. . The big limitation with this code sample is that there is no description of the format of the input table, nor is there any example. I think this greatly limits the usefulness of the code block. Could someone who uses this block (or has used it) who knows what the format of the input table should be either provide a sample table or a description of the format so that I can add it to the file? This would be much easier than me having to try and reverse engineer things. (I did look in the list archives, but was not able to find anything which helped). thanks, Tim
Re: [accessibility] worg obscures text
thank you. classic works best for me. a tiny bit made for smaller fonts [perhaps ragged right or 1 column would work better] but it is completely usable and i would not mention such a nit except for your interest. [as an indicator of right column column width in classic page style, with smallest legible font size during daylight, worg toc currently takes 26 mouse pagescroll clicks to get to end from top. toc at top taking whole page [a 1 column design] and the items flowed but with decent margins would take fewer clicks as that would be a bit more width. larger fonts would make the number of clicks more. just fyi.] [of the other styles, one is white bg so cannot use at night [because i have not found a good darkerner extension that does not require running a binary blob to install it which i stubbornly refuse to do. the one i use, dark reader, does not work on some pages for some reason, and it has other issues re blue on black and too much blue or so]; zenburn is too bright and uncontrasty for me; and one or two are obscuring as mentioned. for my personal use, with my current settings, classic is definitely good enough. also, for some reason i rarely go to worg.] On 6/15/22, Tim Cross wrote: > > Samuel Wales writes: > >> on this page, i cannot read the rhs of paragraphs near the top because >> the menu and up home elements obscure the text. >> https://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development >> . >> >> i use very large fonts. i have latest esr firefox maximized to the >> large monitor. an even larger monitor is not an option. >> >> this is probably a minor issue for me as i can probably use ublock to >> completely remove those elements. of course that would mean not >> having those elements but that is ok if there is a table of contents >> in teh text. i think there is not though. also, o that particular >> patge i can scroll, read paragraph, scroll again. so i am just >> reporting so that the issue is known. i blieve i mentioned it yers >> ago but idk if it got notated. > > Something worth pointing out in case you were not aware of it is that > the worg pages are defined with alternative stylesheets. Unfortunately, > alternative stylesheet support is not well supported by browsers. > However, firefox is one that does support them and as you are a firefox > users, you may be in luck. > > From the 'view' menu, you can select the "Page style" option, which will > let you select from 1 of three provided styles - default, zenburn and > classic. > > In your case, you will likely find the classic style easier to work with > as the fonts can be scaled without some content obscuring other (it > doens't use the Z index to keep things 'on top'). > > Note that I am working on improving the look of worg and all of this > will likely change. However, it turns out it isn't as simple as a few > patches. There is quite a bit of work required to get things 'up to > spec', especially with respect to accessibility and responsiveness for > multiple screen sizes. > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Orgmode plain list bullet : change automatically with list depth
grr i meant "item 1" not "level 1". On 6/16/22, Samuel Wales wrote: > i wonder if org could do the semantics in the text, while > fontification could do the appearance only. > > org allows you to change the bullet style [real text bullets rather > than fontification] upon demotion. > > thus, you can have it consistent that demoting + from top level will > create - on level 2 for 1 item. until you change it. > > but org does not enforce by level. so you can't keep the results of > your demotion strategy in the rest of the list. an enforced scheme > would have it so that a change to new bullet style at a level, or > level 1 otherwise, would style that level. > > so perhaps via a hook, lists could enforce bullet style by level > instead of by demotion. > > then fontification would change bullet style according to the real > bullet style. same result for op. just a brainstorm. > > > On 6/14/22, Ihor Radchenko wrote: >> DEBRY.Edouard writes: >> >>> But it breaks the org file. >> >> What do you mean by "breaks the org file"? >> >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Orgmode plain list bullet : change automatically with list depth
i wonder if org could do the semantics in the text, while fontification could do the appearance only. org allows you to change the bullet style [real text bullets rather than fontification] upon demotion. thus, you can have it consistent that demoting + from top level will create - on level 2 for 1 item. until you change it. but org does not enforce by level. so you can't keep the results of your demotion strategy in the rest of the list. an enforced scheme would have it so that a change to new bullet style at a level, or level 1 otherwise, would style that level. so perhaps via a hook, lists could enforce bullet style by level instead of by demotion. then fontification would change bullet style according to the real bullet style. same result for op. just a brainstorm. On 6/14/22, Ihor Radchenko wrote: > DEBRY.Edouard writes: > >> But it breaks the org file. > > What do you mean by "breaks the org file"? > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [BUG] Unescaped #+ lines in WORG example blocks (was: [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system))
Ihor Radchenko writes: > Max Nikulin writes: > >>> --- a/org-tutorials/org-jekyll.org >>> +++ b/org-tutorials/org-jekyll.org >>> @@ -172,7 +172,7 @@ * Creating an org File to be Published with Jekyll >>> >>> Below is a short extract from one of my org files showing my setup: >>> >>> -#+BEGIN_EXAMPLE org >>> +#+BEGIN_EXAMPLE >>> #+STARTUP: showall indent >>> #+STARTUP: hidestars >>> #+BEGIN_EXPORT html >> >> It is not the scope of this patch but looks like missed commas to escape >> leading "#". > > You are right. We need someone to look through worg pages and spot all > such instances. > (Help appreciated) > Just FYI I plan to go through all the worg files and run org-lint over them as well as fix up the many problems I've found so far with broken links, missing images, missing macros, examples not in example blocks etc. So while I'd appreciate any help on offer, don't worry too much about fixing some of these as I will get to them eventually. One area I would definitely like some help with though are those org files not in english. For example, there is an org tutorial written in Spanish which is generating bad link errors. Unfortunately, I'm limited to only one language, so not 100% sure on the right fix (it looks like examples of how to do links in org, but they are not in example blocks, so org throws an error when doing the export to html. .
Re: [DISCUSSION] Refactoring fontification system
On 08/06/2022 09:02, Ihor Radchenko wrote: Max Nikulin writes: Can you (and other interested users) try the following value of org-script-display and let me know if it looks acceptable: (defconst org-script-display '(;; The values are tweaked to not change ;; the line height. ((raise -0.1) (height 0.7)) ((raise 0.25) (height 0.7)) I do not mind. High symbols like "(|)" cross middle line a bit, but since it is not TeX and superscript can not be above subscript it should not cause any problem with overlapping. ;; Alternative properties for tables. ;; FIXME: We cannot change the text ;; height because it will alter the ;; symbol width and thus break the ;; table alignment (at least, until ;; org table are aligned via pixel ;; width). ((raise -0.5)) ((raise 0.5))) The issue with increased vertical space between vertical bars might be alleviated a bit by using e.g. 0.35 instead of 0.5. I hope, subscripts and superscripts are still distinguishable. However, it currently uses x1.5 line height for tables creating empty space between vertical | separators. It looks like a typo for me. It would make more sense to make table lines compact, not vice versa. Am I missing something? git blame gives 0618aeafb39dbf78e753348eaeaddbb7f8104cd0 It seems smaller font breaks horizontal alignment in tables. Thanks! Now it is crystal clear what was the reason behind the different fontification inside/outside the tables. I will add the explanation to comments.
Re: [BUG] [9.6 (9.6-??-971eb68 @ c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)]
Lourens van der Vliet writes: > Remember to cover the basics, that is, what you expected to happen and > > what in fact did happen. You don't know how to make a good report? See Could you kindly tell us what exactly happened? Best, Ihor
Re: [PATCH] Escape single left quotes in docstrings
Robert Pluim writes: > The emacs-29 byte compiler now complains about unescaped single left > quote. Patch attached. Thanks! Applied onto main via e9da29b6f. Best, Ihor
Re: [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system)
Max Nikulin writes: >> -#+begin_example org >> +#+begin_example >> ,* Parent capturing statistics [2/20] >>:PROPERTIES: >>:COOKIE_DATA: todo recursive > > It is consistent with other examples in the manual. Only one snippet is > wrapped into "#+begin_src org" and it is a recent addition caused a long > discussion on Shakespeare's poetry. I am curious why #+begin_src is used > for elisp examples, but not for org markup. I am not sure. In theory, the only significant difference could be that #+begin_src org could be fontified natively on export (some time in future; they are not now), which might be slightly confusing. In any case, I applied the Org manual patch onto main via 0cc4f492f. > For worg pages #+begin_example to #+begin_src substitution may be a > better option than dropping language. You are right. Would you mind checking if there are any #+begin_example cases in worg with no language specified that are also worth converting into #+begin_src? Best, Ihor
[BUG] Unescaped #+ lines in WORG example blocks (was: [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system))
Max Nikulin writes: >> --- a/org-tutorials/org-jekyll.org >> +++ b/org-tutorials/org-jekyll.org >> @@ -172,7 +172,7 @@ * Creating an org File to be Published with Jekyll >> >> Below is a short extract from one of my org files showing my setup: >> >> -#+BEGIN_EXAMPLE org >> +#+BEGIN_EXAMPLE >> #+STARTUP: showall indent >> #+STARTUP: hidestars >> #+BEGIN_EXPORT html > > It is not the scope of this patch but looks like missed commas to escape > leading "#". You are right. We need someone to look through worg pages and spot all such instances. (Help appreciated) Best, Ihor
Re: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES
Sébastien Miquel writes: > Ihor Radchenko writes: >> We actually have 2 options here: >> 1. Change the docstring >> 2. Change the template >> >> Can moving [PACKAGES] up break the existing configs? It might. >> I am inclined to change the docstring instead. > > Thanks for having a look at this. > > It makes more sense for a package in PACKAGES to depend on a > DEFAULT-PACKAGE than vice versa. > ... > I've also just checked that by default, for document export, > DEFAULT-PACKAGES are inserted before PACKAGES --- the default > templates from =org-latex-classes= do not include =DEFAULT-PACKAGES= > nor =PACKAGES=, and in this case, =org-splice-latex-header= adds both > default packages and packages at the end, with default packages coming > first. > > =org-format-latex-header= is only used to generate images for preview, > and in some cases by ob-latex to compile a document from a LaTeX src > block. Thanks for the clarification! Now, your patch makes much more sense. Can you update the commit message explaining the above shortly and linking to this thread? Best, Ihor
Re: [BUG] Cursor is moved after changing list bullets
Daniel Fleischer writes: > Ihor Radchenko [2022-06-14 Tue 21:30] wrote: > >> I am unable to reproduce using any of the supported Emacs versions. >> Could you please provide more concrete steps? Or better a test. > > Create a file called `list.org` with the following: > ... > Then put the cursor on one of the hyphens... Thanks! I missed the part that cursor should be on one of the hyphens. Fixed via 707d3a093 on main. Best, Ihor
Re: Org mode and Emacs (was: Convert README.org to plain text README while installing package)
Having read the whole thread now: oof. Thank you Ihor for shepherding that and for the performance improvements! With regard to the key-bindings straw man. I guess I'm a bit of an outsider on this one, because I started writing org documents by just typing them in and only over time learning some of the bindings. Maybe having an org-markup-mode or something like that would be a way to provide a sandbox for the +recalcitrants+ newcomers? It might also be a nice way to a/b test them on whether the Emacs editing commands really are as good as they think they are (said the evil-mode user). With regard to ... everything else. I guess at this point it is unsurprising that (for lack of a better term) the uninitiated in the dark corners of org syntax frequently think that syntactic extensions are advisable, skipping over the consideration of possible. Given the opportunities that seem to be lurking in the thread, it seems like it would be good to have some examples of how the e.g. texinfo semantic markup could (or could not) be implemented using existing org syntax. The suggestion to use custom link types seems very practical. It requires no new syntax, and is basically fully extensible for semantic markup needs. I say this having recently spent time reworking the paragraph grammar and the lexer needed to enable it in laundry for the 3rd (or is it 4th?) time. Say it with me: No new syntactic forms! We have more than enough syntax to enable all the extensibility that pretty much anyone will ever need (we just have to document how to use it). In-document extensibility of link types might be possible if we get my regularized keyword syntax implemented, if that were done then all the configuration could in-principle live in a setup file (I have a response on the syntax thread drafted, will try to get back to it). Nesting markup inside code or verbatim seems more difficult because they are intentionally terminal. I am also unfamiliar with texinfo so will be of no help with the examples, but I do look forward to them. Best! Tom
Re: Orgmode plain list bullet : change automatically with list depth
DEBRY.Edouard writes: > I mean that all custom set faces disappear, just try, if it works for > you i am interested I see. FYI, you can try to run M-x font-lock-debug-fontify to identify the problem. The issue you are seeing is because org-element-at-point alters match data and thus your (match-beginning 1) are not returning what you expect (they return nil). Best, Ihor
Re: Library of babel help
Tim Cross writes: > Hi All, > > in my attempt to fix up some issues on the Worg site, I'm finding there > is considerably more things broken than I initially realised. One of > these things is 'the library of babel". > > There is a link to the library-of-babel.org file on worg from within the > Emacs manual. This link is currently failing with a 404 error. However, > if you use the link embedded in the actual worg pages, you will get a > link to the library-of-babel.org file hosted in the git repository on > sourcehut, not worg. (it would appear that either the current build > process is not copying the *.org files to the web server or the web > server has not been configured to allow access to *.org files and always > redirects you to the *.html version). > > I believe the reason the link to the HTML file is failing is because the > conversion from *.org to *.html is failing because of invalid emacs lisp > in the org file source blocks. The problem is there are 5 references to > flet, which was deprecated in Emacs 24.3. > > To my questions - > > 1. Has anyone got a more recent version of the library-of-babel.org file > which has the fet references replaced with something more appropriate > (perhaps cl-flet, cl-letf or noflet)? > > If nobody has, then I can have a go at fixing it up, but as I don't use > it, I will have trouble making sure it works correctly. > > 2. I seem to recall that at one point, you could view the *.org sources > of pages on worg. I think this was a useful feature and we should > re-enable it. However, I suspect the nginx server will need some > tweaking. Is updating the server config to allow *.org access a > reasonable thing to do? > > 3. What should we do about the manual? We could (temporarily at least) > change the reference to point to the current (broken) version in the > sourcehut git repository or we can leave it until the file is again > being served by the worg server or . Something else I forgot to mention just in case someone is looking at the git repository. There are actually two library-of-babel.org files. One is in the root folder and the other is in org-contrib/babel. The file org-contrib/index.org actually links to the version in the root folder and not the one in the same folder as it is located. Looking at them both, I think the one in org-contrib/babel is older (certainly smaller wiht fewer code blocks). Ironically, it doesn't have the flet issue. I plan to move the org-contrib/babel/library-of-babel.org file to the archive directory to avoid confusion in future.
Re: Orgmode plain list bullet : change automatically with list depth
I mean that all custom set faces disappear, just try, if it works for you i am interested Ihor Radchenko writes: > --- > Attention, ce courriel provient d'Internet. L'emetteur n'est peut-etre pas > celui que vous pensez. > Merci de considerer ce point en lisant ce courriel, avant d'y repondre, de > cliquer sur > les liens ou d'ouvrir les pieces jointes. > --- > > DEBRY.Edouard writes: > >> But it breaks the org file. > > What do you mean by "breaks the org file"? > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ ___ This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. Ce courriel et ses pieces-jointes sont envoyes de maniere confidentielle et doivent etre traites avec attention. Si vous n'etes pas le destinataire, merci de le detruire et d'en informer son auteur. Vous ne devez pas copier, utiliser, reveler ou diffuser son contenu a quiconque.
Re: Publish to HTML and LaTeX/PDF with cross-file links?
On 2022-06-16, at 09:55, Tim Cross wrote: > Jens Lechtenboerger writes: > >> [...] >> More precisely: For HTML export, a link like >> [[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to >> “foo.html#custom-id”, which is what I want. >> >> However, for LaTeX/PDF export, the hyperlink points to the source >> file “foo.org”, which in my case is a broken link. I would like >> that to be “foo.pdf” (or even something pointing at the proper >> section in the PDF file). >> >> Is this (easily) possible? >> > > I think what you need is an export filter function for links in latex > exports. Have a look at the docstring for variable > org-export-filter-link-functions. > > As a very basic example, the following should work > [...] Thank you for the suggestion! I am still undecided which way to go. Maybe a refactoring of code from ox-html (to be usable across backends) would be appropriate here. Best wishes Jens
Library of babel help
Hi All, in my attempt to fix up some issues on the Worg site, I'm finding there is considerably more things broken than I initially realised. One of these things is 'the library of babel". There is a link to the library-of-babel.org file on worg from within the Emacs manual. This link is currently failing with a 404 error. However, if you use the link embedded in the actual worg pages, you will get a link to the library-of-babel.org file hosted in the git repository on sourcehut, not worg. (it would appear that either the current build process is not copying the *.org files to the web server or the web server has not been configured to allow access to *.org files and always redirects you to the *.html version). I believe the reason the link to the HTML file is failing is because the conversion from *.org to *.html is failing because of invalid emacs lisp in the org file source blocks. The problem is there are 5 references to flet, which was deprecated in Emacs 24.3. To my questions - 1. Has anyone got a more recent version of the library-of-babel.org file which has the fet references replaced with something more appropriate (perhaps cl-flet, cl-letf or noflet)? If nobody has, then I can have a go at fixing it up, but as I don't use it, I will have trouble making sure it works correctly. 2. I seem to recall that at one point, you could view the *.org sources of pages on worg. I think this was a useful feature and we should re-enable it. However, I suspect the nginx server will need some tweaking. Is updating the server config to allow *.org access a reasonable thing to do? 3. What should we do about the manual? We could (temporarily at least) change the reference to point to the current (broken) version in the sourcehut git repository or we can leave it until the file is again being served by the worg server or .
