Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I do make a serious point: by linking to liberapay who are actively > > searching for ways to get rid of proprietary software, those links are > > most likely to become usable without proprietary software once a > > practical method to donate without proprietary software exists. > > I agree that links to liberapay might someday work without the donor's > running nonfree software. But that is not likely to occur this year, > and for it to occur in this decade is a long shot. > > So please don't put links to liberapay into GNU package web pages. Please explain how you can argue that position when the FSF has such a link on their web page? Why is it OK for the FSF to do this to raise funds, but not acceptable for projects to do the same?
Re: [PATCH] Delete some Emacs 24 compat code
Samuel Wales writes: > i use git version, not elpa, so for me, mailing list could tip me off > as early as possible, but not too early, if it said in email subject > header line that in a known upcoming release, it has been decided that > a specified emacs version will no longer be supported [note: i presume > and hope this would not occur in just a plain git update for such a > thing but would get a release that gets noted in email and get that > advance notice], > > then upon seeig such email i can stop pulling from git until i am able > to upgrade emacs. [lots of stuff takes lots and lots of time for me > in my case] idk if practical, but just saying what seems like it > would be useful to me. > > i would then stay at something reasonably close to the first release > that does not support that version fo emacs. > While what your asking for may sound reasonable, I don't think it is practical. There is no sudden decision to stop supporting a version in the sense that suddenly, at that point, the version is no longer supported. We really only know that a past version is no longer supported when it stops working and is more than 2 releases behind the current Emacs version (any less and it is a bug which will get fixed). The supported version policy has already been communicated on this list. That policy will not change without notice, so you know exactly what is supported at all times. There is no precise point where we can send out a message saying a version is no longer supported. Best that can be done is say that any Emacs version older than two releases behind the current stable release is no longer supported. That doesn't mean it won't work, it just means if there are problems, they won't be fixed and there should be no expectation it will work if your running an unsupported Emacs version. Thing is, no testing is done against older versions, so it isn't always clear precisely when org stops working with an older unsupported version. Current stable version is 28. Therefore, if your running Emacs 25 or earlier, you *should not* pull updates from git as they may not be compatible with your Emacs version. When Emacs 29 is released, stop pulling from git if your running Emacs <= version 26. Of course, none of this is a big issue as you do build from git. Should you find your most recent pull is no longer compatible with the version of Emacs your running, it is trivial to revert to the version you were running before - you just need to do a checkout for the earlier revision and rebuild. As pointed out elsewhere in this thread, package.el has minimum version spec, so this isn't an issue for package.el users.
Re: Convert a Lisp expression to a tree diagram
Ihor Radchenko writes: > Invoking search across my notes and archives (all stored in Org, of > course) yielded the following: > > https://reddit.com/r/emacs/comments/u2ca5c/drawtreeel/ > https://reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/ > > linking to > > https://github.com/amno1/draw-cons-tree > https://github.com/zainab-ali/pair-tree.el (example: > https://teddit.namazso.eu/pics/w:2172_vetc0martyb61.png) > > Hope it helps. Thanks a lot, Ihor! There is some very juicy information there. > actual notes below: Awesome notes. Hats off to such a detailed capture (reminds me to give my poor org-capture templates some more love one day :-)) Best regards, Juan Manuel
Re: [PATCH] Delete some Emacs 24 compat code
idk about others, but as a luddite follower of bugfix/maint, if poissible and not too annoying to do, i would be interested in knowing, at the email subject header level, that the upcoming bugfix/maint release [state org version number] will not support <= [state emacs version number] so that i can prepare at my glacial luddite pace. this is probably already done, but making it prominent beforehand might help signal the need for changes with lots of time or simplify git stuff [e.g. pull soon as the last pull and make a note not to pull after that, which prevents the need for figuring out rebasing again]. On 6/30/22, Ihor Radchenko wrote: > Max Nikulin writes: > >> On 30/06/2022 18:19, Stefan Kangas wrote: >>> The attached patch deletes some Emacs 24 compat code. Org mode >>> supports Emacs 26 or later, according to: >>> https://orgmode.org/worg/org-maintenance.html#emacs-compatibility >> >> I have no particular opinion to which degree older Emacs versions should >> be supported, but I remember the following message: >> >> Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 >> https://list.orgmode.org/87fsrolmn9@gnu.org/ > > This is a valid point in general. However, Org mode already fails when > you try to load it using Emacs 24 (correct me if I am wrong). So, Org > cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do > not see much point keeping partial compatibility. > > There is a reason to keep old compatibility code only when Org works in > general and only some new optional libraries cannot be used. This is not > the case for Emacs 24, AFAIK. > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Delete some Emacs 24 compat code
i use git version, not elpa, so for me, mailing list could tip me off as early as possible, but not too early, if it said in email subject header line that in a known upcoming release, it has been decided that a specified emacs version will no longer be supported [note: i presume and hope this would not occur in just a plain git update for such a thing but would get a release that gets noted in email and get that advance notice], then upon seeig such email i can stop pulling from git until i am able to upgrade emacs. [lots of stuff takes lots and lots of time for me in my case] idk if practical, but just saying what seems like it would be useful to me. i would then stay at something reasonably close to the first release that does not support that version fo emacs. On 6/30/22, Ihor Radchenko wrote: > Samuel Wales writes: > >> idk about others, but as a luddite follower of bugfix/maint, if >> poissible and not too annoying to do, i would be interested in >> knowing, at the email subject header level, that the upcoming >> bugfix/maint release [state org version number] will not support <= >> [state emacs version number] so that i can prepare at my glacial >> luddite pace. this is probably already done, but making it prominent >> beforehand might help signal the need for changes with lots of time or >> simplify git stuff [e.g. pull soon as the last pull and make a note >> not to pull after that, which prevents the need for figuring out >> rebasing again]. > > org.el contains the following: > ;; Package-Requires: ((emacs "25.1")) > > So, if you install Org from ELPA using built-in Emacs package manager, > Org will fail to install on older Emacs versions (AFAIU). I am not sure > if package.el if going to fall back to earlier Org version though. > > In addition, we might also announce the oldest supported Emacs version > in https://orgmode.org/Changes.html. Either manually, or as a part of > some automated release script. Bastien, WDYT? > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Serving .org files for worg (was: Re: Library of babel help)
Max Nikulin writes: > On 30/06/2022 16:06, Tim Cross wrote: >> >>> Aren't they currently available? I can and I was always able to get the >>> org sources by changing the link from .html to .org. >> No, that doesn't work for me using either chrome or firefox. Chrome just >> keeps switching back to the HTML url and firefox just hangs, returning >> nothing. Bastien has sent me the nginx config being used, but I've not >> yet had a look at it. > > It is rather strange > > curl -I 'https://orgmode.org/worg/doc.org' > ... > Content-Type: application/octet-stream > > browsers should offer "save as" dialog in such case. It is possible to add > Content-Disposition header to force "save" prompt, but I am unsure if it the > best option. I would prefer some desktop-wide MIME handler, but there is not > specific type for org. text/plain will be likely handled by browsers > internally. > Unsure if something like "text/x-org" is better since anyway custom > configuration will be required. > > Tim, did you face the problem with some particular file? Browsers might try to > guess real MIME type from file content. If the problem is reproducible, you > may > experiment with "no sniff" header. There are 2 issues as I see it. 1. Just using the .org as the suffix of the url instead of the .html did not work for me using two different browser. However, it did work for ihor, so either I did something wrong or there is something in my setup which is preventing that from working. Need to investigate further. However, that is not my main issue. My main issue is that having to know you can change the suffix from .html to .org in order to get the source is insufficient. It won't be obvious to many users and will only make some sense to experienced org users. I think the link should be obvious and I think the server configuration should be set so that accessing the .org url gives a sensible result (i.e. prefer opening it as plain text to offering to download). My aim is to fix this, but I've not yet had time to even look at it. I do have the server config file, so am able to review that and will sort this out once time permits. One of the changes I have started to implement is to standardise the and the page header/footer sections to make them consistent across the worg site and get consistency with internal URLs (some a relative, some are absolute), some have hard coded values, other use site wide variables etc. The initial aim is to make the site consistent and the build process server independent. Ideally, anyone will be able to clone the repo, set a document root and run the build process to create a fully working local worg site. Little in this first stage is terribly contentious. Once this is done, the second stage is to work on improving the default style and make the worg content easy to discover/browse. There is likely to be varied opinions here and my intention will be to create a dev or uat site where interested uses can have a look and provide feedback/suggestions (as well as test). While I have made some progress, time is a little scarce at present and I'll only have a few hours each weekend for the next few weeks to work on this. However, I'm hoping some other commitments will scale down soon and I'll have more time to devote to this task. It is quite rewarding, just time consuming at present as I nail down all the moving parts!
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
Bhavin Gandhi writes: > Currently, when we call `org-auto-repeat-maybe', it adds > `org-add-log-note' to post-command-hook using `org-add-log-setup'. As > soon as we reach the question about 10 repeater intervals (the call to > `y-or-n-p' from `org-auto-repeat-maybe'), the post-command-hook gets > executed.[1] Bhavin, did you have a chance to send a bug report on this to Emacs devs? Best, Ihor
Re: Alternatives to clocking in/out for reporting time
make list of (ts . header) pairs [at least bare ia], rounding all tses to hour, sort -u by ts, seq-group-by on ts to get (hour. headers)? or do i not get it? On 6/30/22, Russell Adams wrote: > On Wed, Jun 29, 2022 at 07:11:10PM -0700, Samuel Wales wrote: > I appreciate that! That's really what I'm asking for is ideas. I don't > mind writing a bit of code, but I'm not sure where to start. usually opposite for me. health reasons impede coding.
Re: Convert a Lisp expression to a tree diagram
Juan Manuel Macías writes: >> actual notes below: > > Awesome notes. Hats off to such a detailed capture (reminds me to give > my poor org-capture templates some more love one day :-)) This capture template is public: https://github.com/yantar92/org-capture-ref Best, Ihor
Re: Serving .org files for worg (was: Re: Library of babel help)
On 01/07/2022 04:48, Tim Cross wrote:
1. Just using the .org as the suffix of the url instead of the .html did
not work for me using two different browser. However, it did work for
ihor, so either I did something wrong or there is something in my setup
which is preventing that from working. Need to investigate further.
However, that is not my main issue.
I do not think that a chance of such event is noticeable, but you may
observe different behavior because you tried to access different files.
More likely you get files saved to Downloads.
Tim, likely you can not work with browsers unless significant
customization is applied. Generally it is better to have virtual
machines with popular environments and as little modifications as
possible. Unfortunately just now I am preparing to move my VMs to
another disk, so I would prefer to postpone setting up another instance
suitable for such purpose.
My main issue is that having to know you can change the suffix from
.html to .org in order to get the source is insufficient. It won't be
obvious to many users and will only make some sense to experienced org
users. I think the link should be obvious and I think the server
configuration should be set so that accessing the .org url gives a
sensible result (i.e. prefer opening it as plain text to offering to
download).
I do not mind to have explicit link to .org file. It may be placed to
the header section with table of contents and the donation link. Such
link may be like
https://git.sr.ht/~bzg/worg/tree/master/item/org-artwork.org (I have no
idea if it may add noticeable load to Drew DeVault's servers). However
SourceHut does not highlight org sources currently. On the other hand it
does not try to render them formatted, so sources are visible. Another
problem is long lines. Unfortunately they are not wrapped and the
following causes discrepancy with line numbers, so I can not suggest a fix:
/* main.min.112ca73b.css | https://git.sr.ht/static/main.min.112ca73b.css */
.code-view .highlight pre {
white-space: pre-wrap;
}
The initial aim is to make the site consistent and the build process
server independent. Ideally, anyone will be able to clone the repo, set
a document root and run the build process to create a fully working
local worg site. Little in this first stage is terribly contentious.
I am afraid, to run local instance of worg, it would be necessary to
explicitly specify MIME type for .org files otherwise they may be
attributed to Lotus.
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > I agree that links to liberapay might someday work without the donor's > running nonfree software. But that is not likely to occur this year, > and for it to occur in this decade is a long shot. > > So please don't put links to liberapay into GNU package web pages. Clarification: Links to Liberapay do work without running non-free software (you can try opening the link yourself). It is only the payment process that does not work. But we may still try to put some alternative free payment method in the project description on https://liberapay.com/org-mode Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
your opinion is noted. mine remains, but maintainers are welcome to do as they think is right. i stated what i thoguht might be useful for my ase. no further discussion needed. On 6/30/22, Tim Cross wrote: > > Samuel Wales writes: > >> i use git version, not elpa, so for me, mailing list could tip me off >> as early as possible, but not too early, if it said in email subject >> header line that in a known upcoming release, it has been decided that >> a specified emacs version will no longer be supported [note: i presume >> and hope this would not occur in just a plain git update for such a >> thing but would get a release that gets noted in email and get that >> advance notice], >> >> then upon seeig such email i can stop pulling from git until i am able >> to upgrade emacs. [lots of stuff takes lots and lots of time for me >> in my case] idk if practical, but just saying what seems like it >> would be useful to me. >> >> i would then stay at something reasonably close to the first release >> that does not support that version fo emacs. >> > While what your asking for may sound reasonable, I don't think it is > practical. There is no sudden decision to stop supporting a version in > the sense that suddenly, at that point, the version is no longer > supported. We really only know that a past version is no longer > supported when it stops working and is more than 2 releases behind the > current Emacs version (any less and it is a bug which will get fixed). > > The supported version policy has already been communicated on this > list. That policy will not change without notice, so you know exactly > what is supported at all times. > > There is no precise point where we can send out a message saying a > version is no longer supported. Best that can be done is say that any > Emacs version older than two releases behind the current stable release > is no longer supported. That doesn't mean it won't work, it just means > if there are problems, they won't be fixed and there should be no > expectation it will work if your running an unsupported Emacs version. > > Thing is, no testing is done against older versions, so it isn't always > clear precisely when org stops working with an older unsupported > version. > > Current stable version is 28. Therefore, if your running Emacs 25 or > earlier, you *should not* pull updates from git as they may not be > compatible with your Emacs version. When Emacs 29 is released, stop > pulling from git if your running Emacs <= version 26. > > Of course, none of this is a big issue as you do build from git. Should > you find your most recent pull is no longer compatible with the version > of Emacs your running, it is trivial to revert to the version you were > running before - you just need to do a checkout for the earlier > revision and rebuild. As pointed out elsewhere in this thread, > package.el has minimum version spec, so this isn't an issue for > package.el users. > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
org-table-sort-lines (numerically) leaves 0 separated
Hi I have the following table | name | marks | |---+---| | Auser | 0.5 | | Buser | 2 | | Cuser | 0 | | Duser | 2 | | Euser | 0 | | Fuser | 3 | | Guser | | | Huser | 0 | | Iuser | | | Juser | 6 | If I sort the second column numerically I obtain | name | marks | |---+---| | Cuser | 0 | | Euser | 0 | | Guser | | | Huser | 0 | | Iuser | | | Auser | 0.5 | | Buser | 2 | | Duser | 2 | | Fuser | 3 | | Juser | 6 | Which is bizarre, why is 0 not connected to the rest of the numerical entries? -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: Convert a Lisp expression to a tree diagram
arthur miller writes: > This one draws graph of cons cells (lists): > > https://github.com/amno1/draw-cons-tree > > I never tried with random s-expressions, but I guess you could pass > them in as lists? Hi, Arthur, Thank you for the pointer to draw-cons-tree. I didn't know this package, I'll take a look. Best regards, Juan Manuel
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I do make a serious point: by linking to liberapay who are actively > searching for ways to get rid of proprietary software, those links are > most likely to become usable without proprietary software once a > practical method to donate without proprietary software exists. I agree that links to liberapay might someday work without the donor's running nonfree software. But that is not likely to occur this year, and for it to occur in this decade is a long shot. So please don't put links to liberapay into GNU package web pages. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: Proposal: 'executable' org-capture-templaes
Max Nikulin writes:
> On 26/06/2022 11:50, Arthur Miller wrote:
>> Max Nikulin writes:
>>>
>>> By state I mean some structure opaque to menu package. It just receives it
>>> from
>>> caller as an optional argument and (when given) later passes it to
>>> handler. Maybe it is alien approach in LISP, but in C (where closures are
>>> impossible) it is a widely used technique. Functions having callback
>>> argument
>>> usually have another void* one that is later passed as an argument of the
>>> callback function in addition to other data.
>> I understand, I have done my share of C, and know what you mean. Say
>> posix thread will take a void* to user data, and pass it on. This is
>> exactly what this is about. It is just that we don't need an extra
>> structure to pass around. We have a menu entry, which *is* the user
>> data.
>
> You a right, it is not strictly necessary that menu should be aware of state.
> I
> expect some helper though, e.g.
>
> ;;; -*- lexical-binding: t; -*-
> (defun org-menu-multiinstance-stateful (menus args)
> (let* ((buffer-name (or (plist-get args :buffer-name)
> "*Select menu*"))
>(state (plist-get args :state))
>(handler (plist-get args :handler))
>(handler-closure
> (and handler
> state
> (lambda (entry _)
>(funcall handler entry state)
> (when state (org-plist-delete args :state))
> (when handler (org-plist-delete args :handler))
> (plist-put args
> :buffer-name
> (generate-new-buffer-name buffer-name))
> (apply #'org-select
> (if handler-closure
> (mapcar
> (lambda (menu)
> (append menu (list :org-select-handler
>handler-closure)))
> menus)
>menus)
> args)))
> (provide 'org-multimenu)
>
> To be able to call menu as
>
> (load (expand-file-name "org-multimenu"))
> (org-menu-multiinstance-stateful
> `((("1" "one" 1)
> ("2" "two" 2)))
> :state (format-time-string "%T")
> :text "Some heading"
> :buffer-name "*Test menu*"
> :handler (lambda (entry state)
> (org-select-quit) ; it does not kill the buffer
> (message "handler %S %S" entry state)))
I might be missunderstanding you now, but from this example it seems to me that
you see menu entries as something that aims for the menu itself, while state is
some user data?
The "menu data" here is just: "1" and "one" in the first entry, and simillary
"2" and "two" in the second entry. After those, client code can put whatever it
desires: ("1" "one" . lots of client state .). So for example client
could have something like ("1" "one" 1 (format-time-string "%T")).
However that might be tedious to type for each entry, so maybe we could pass an
optional "menu-global" state (or entry) that is passed to the user. So it would
be:
(lambda (entry state)
(org-select-quit) ; it does not kill the buffer
(message "handler %S %S" entry state)))
Reason for optional: I prefer simplicity. I think the idea to lump together
menu selection with user state as it is done in org-capture-templates is really
good. Kudos to whomever came up with that one!
I like it because it puts everything into one place, we don't need to update
display and logic separately but everything is in an entry. I think it is good,
and I would like to keep that simplicity. I wouldnt like to suddenly separate
user state and menu state, because it would negate that fundamental idea.
> I do not like how to closures are represented in elisp stack traces
> (e.g. JavaScript engines in browsers tries hard to give some debug names for
> anonymous functions). It should not be a problem when passed handler is a
> named
> function (not a lambda) despite closure in the adjacent frame.
>
> However I would expect that menu handler is not aware if menu is implemented
> using buffers. From my point of view handler should not have buffer argument.
I understand, and I agree it is not very beautiful design :). The problem is
when
client code provides its own handler. In the beginning I used a flag,
org-select-transient, to signal the menu should go away, but that wasn't very
clean either. The solution is maybe to never give total control to user handler,
but to always wrap/call user handler and finnish in menu's own handler. That way
we can use a flag to signal some state. I don't know, just thinking loud at the
moment; will have to test.
> What I missed in your current implementation is ability to change text of menu
> entries in response to action. E.g. "C-c C-e" ox dispatcher has some options
> and
> user should see current values.
The buffer text is just dead text; menu entries are a graphical display for the
user, not really interactive in the sense that it will update itself upon some
user action, unless user picks submenu or returns from one.
>
Re: [PATCH] Delete some Emacs 24 compat code
Samuel Wales writes: > idk about others, but as a luddite follower of bugfix/maint, if > poissible and not too annoying to do, i would be interested in > knowing, at the email subject header level, that the upcoming > bugfix/maint release [state org version number] will not support <= > [state emacs version number] so that i can prepare at my glacial > luddite pace. this is probably already done, but making it prominent > beforehand might help signal the need for changes with lots of time or > simplify git stuff [e.g. pull soon as the last pull and make a note > not to pull after that, which prevents the need for figuring out > rebasing again]. org.el contains the following: ;; Package-Requires: ((emacs "25.1")) So, if you install Org from ELPA using built-in Emacs package manager, Org will fail to install on older Emacs versions (AFAIU). I am not sure if package.el if going to fall back to earlier Org version though. In addition, we might also announce the oldest supported Emacs version in https://orgmode.org/Changes.html. Either manually, or as a part of some automated release script. Bastien, WDYT? Best, Ihor
Re: Library of babel help
Ihor Radchenko writes: > Tim Cross writes: > >> 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. > > The latest manual has the correct link. I assume that you have fixed it. > I guess that some of your questions do no apply anymore. > Correct. I made some minimal changes to address the worst failing aspects. However, a lot more work to do to really clean things up. Bastein applied the patches I sent in and has given me write access. However, I think I will probably create a new branch to do the updates/changes and make them available to view (somewhere) as they will be significant and I want a clean rollback strategy in case things go wrong (especially as I will be re-defining the whole build process for worg and probably making significant changes to the styling). . >> 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? > > Aren't they currently available? I can and I was always able to get the > org sources by changing the link from .html to .org. > No, that doesn't work for me using either chrome or firefox. Chrome just keeps switching back to the HTML url and firefox just hangs, returning nothing. Bastien has sent me the nginx config being used, but I've not yet had a look at it. My recollection is that there use to be a link in the footer which you could use to get the source (org file). I think an explicit link is better than relying on 'knowing' you can change the extension to .org (even if it did work) as that is just a little to close to 'secret guild knowledge' for my tastes. Some of the documentation for worg implies the sources are supposed to be in worg/source - allowing you to put a link to the sources (or any source) inside the org file. This would likely also make the nginx config cleaner as you can specify more accurately what is to be served from where.
Re: PDF export, table of contents and internal links
Sébastien Gendre writes: > If I learned LaTeX syntax in the past, I never take enough time to learn > how work each compilation possibility. I feel lost with all the > pdflatex, teklive, lualatex, double or quadruple compilation, etc. The problem of multiple compilations is not related, in general, to the TeX engine being used (pdfTeX, XeTeX, LuaTeX) but to LaTeX itself, which continually needs to write and read auxiliary files. If, in addition, you need to use citations, add an analytical index or other elements to your work, you will also have to call the corresponding engines (bibtex, biber, xindy, etc.) and compile again. And to all this is added that there are specific packages that also need more than one compilation. So it's often the best idea to let latexmk take care of all that instead of compiling manually. You may be interested in taking a look at another TeX format, ConTeXt, not as popular as LaTeX but very powerful. It has certain advantages over LaTeX. For my workflow, I prefer LaTeX. But there are users who can be better served by ConTeXt, and they should be aware of it. Unlike LaTeX, whose concept is of a minimal kernel that can be extended by packages, ConTeXt starts from a monolithic kernel, which includes everything or almost everything. In other words, it is not necessary to load a package for this, another package for that, etc. Its interface is more minimalist than the LaTeX interface and its compilation process is (I think) faster. And, on the Org side, we luckily already have a ConTeXt exporter, ox-context, written by Jason Ross: https://github.com/Jason-S-Ross/ox-context/ There is a very complete introductory manual to ConTeXt written by Joaquín Ataz López, with translations into various languages, including English and French: https://github.com/contextgarden/not-so-short-introduction-to-context > Do you have good articles or book to suggest about this part of LaTeX ? A good read might be: /The Not so Short Introduction to LaTeX2e/ (https://scholar.google.com/scholar?q=the not so short introduction to latex2e) And if you dare to program at a low level in pure TeX, this is very good: /TeX for the Impatient/ (http://mail.tug.org/TUGboat/tb11-4/tb30ads.pdf) > To come back to "org-latex-pdf-process", I only added "-shell-escape" > for the minted package. To have beautify code block. But maybe it exist > better solution ? Someone have experience with Engrave Faces ? The -shell-escape flag only makes sense if you need to call an external process during compilation (as in the case of minted). It is also necessary if you need to use an indexing engine like xindy. But apart from these cases and some more, an org user will have more advantages using babel. I use Minted, but I'm not convinced. It also has some problems with certain LaTeX packages. I have Engrave Faces on my TODO list to try. And possibly I will migrate to it... Best regards, Juan Manuel
Re: Alternatives to clocking in/out for reporting time
On Wed, Jun 29, 2022 at 07:11:10PM -0700, Samuel Wales wrote: > a few things taht are probably all completely obvious or investigated > or irrelevant just in case. just brainstorm. I appreciate that! That's really what I'm asking for is ideas. I don't mind writing a bit of code, but I'm not sure where to start. > do you have everything relevant in the same subtrees? i.e. not > wanting granular, can you search upward for a dominating entry kind of > like git searching upward for the .git dir or so? property drawer > could control what's a dominating entry. you probably thoguht of this > or of having whatever categories as tags or categories in entries > though. in any case that would clock. you could even have clocking > clock into that no matter wher eyou are via some timer in principle. > just a brainstorm. you said dynamic som perhaps there is no > dominating entry for each category though. The core issue is I want to report on total time as an aggregate, not on time per task. Clock reporting gives me precise time accounting for a specific task. I want to fill whole hours with whatever tasks happened at those times chronologically. > org-time-stamp-rounding-minutes and org-clock-rounding-minutes . i > presume you don't find them relevant. I saw that. Interesting they don't appear to change the result, they modify the input when you record the time by rounding. > reminder: inactive ts in the clocked notation is usualy treated > separately by org [i.e. not hte same type of ts] from bare ia. I had considered perhaps converting inactive timestamps into clocking records. Unfortunately I think the core issue remains in aggregating by task, not by time. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
[PATCH] Delete some Emacs 24 compat code
The attached patch deletes some Emacs 24 compat code. Org mode supports Emacs 26 or later, according to: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility From 6e854576494f918c36cdd0ce698793574af494df Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 30 Jun 2022 13:06:21 +0200 Subject: [PATCH] Delete some Emacs 24 compat code Org mode supports Emacs 26 or newer: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility * lisp/org-compat.el (org-set-transient-map) (org-font-lock-ensure): Delete compat aliases. Update callers. (org-define-error): Redefine as obsolete function alias for `define-error'. Update callers. (string-suffix-p): Delete compatibility definition. * lisp/org-fold-core.el (org-fold-core--seq-partition): Redefine as obsolete function alias for `seq-partition'. Update callers. * lisp/org-macs.el (org-without-partial-completion): Redefine as obsolete function alias for `progn'. --- lisp/org-clock.el | 2 +- lisp/org-compat.el| 37 + lisp/org-fold-core.el | 24 lisp/org-goto.el | 2 +- lisp/org-macs.el | 13 + lisp/org-src.el | 2 +- lisp/org-table.el | 6 +++--- lisp/org.el | 4 ++-- lisp/ox-html.el | 2 +- lisp/ox-odt.el| 2 +- lisp/ox-org.el| 2 +- lisp/ox.el| 2 +- 12 files changed, 18 insertions(+), 80 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 7d99e5087..e0b2d3ce6 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2122,7 +2122,7 @@ fontified, and then returned." (org-mode) (org-create-dblock props) (org-update-dblock) -(org-font-lock-ensure) +(font-lock-ensure) (forward-line 2) (buffer-substring (point) (progn (re-search-forward "^[ \t]*#\\+END" nil t) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index baad39459..85f66587a 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -904,12 +904,6 @@ context. See the individual commands for more information." ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data)) (w32-get-clipboard-data -;; `set-transient-map' is only in Emacs >= 24.4 -(defalias 'org-set-transient-map - (if (fboundp 'set-transient-map) - 'set-transient-map -'set-temporary-overlay-map)) - ;;; Region compatibility @@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'." string) (apply 'kill-new string args)) -;; `font-lock-ensure' is only available from 24.4.50 on -(defalias 'org-font-lock-ensure - (if (fboundp 'font-lock-ensure) - #'font-lock-ensure -(lambda ( _beg _end) - (with-no-warnings (font-lock-fontify-buffer) - ;; `file-local-name' was added in Emacs 26.1. (defalias 'org-babel-local-file-name (if (fboundp 'file-local-name) @@ -994,29 +981,7 @@ Pass COLUMN and FORCE to `move-to-column'." (defun org-release () "N/A") (defun org-git-version () "N/A !!check installation!!")) - - -;;; Functions for Emacs < 24.4 compatibility - -(defun org-define-error (name message) - "Define NAME as a new error signal. -MESSAGE is a string that will be output to the echo area if such -an error is signaled without being caught by a `condition-case'. -Implements `define-error' for older emacsen." - (if (fboundp 'define-error) (define-error name message) -(put name 'error-conditions - (copy-sequence (cons name (get 'error 'error-conditions)) - -(unless (fboundp 'string-suffix-p) - ;; From Emacs subr.el. - (defun string-suffix-p (suffix string ignore-case) -"Return non-nil if SUFFIX is a suffix of STRING. -If IGNORE-CASE is non-nil, the comparison is done without paying -attention to case differences." -(let ((start-pos (- (length string) (length suffix - (and (>= start-pos 0) - (eq t (compare-strings suffix nil nil - string start-pos nil ignore-case)) +(define-obsolete-function-alias 'org-define-error #'define-error "9.6") ;;; Integration with and fixes for other packages diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el index 88072852d..287686c01 100644 --- a/lisp/org-fold-core.el +++ b/lisp/org-fold-core.el @@ -1304,25 +1304,9 @@ property, unfold the region if the :fragile function returns non-nil." ;; Move to next fold. (setq pos (org-fold-core-next-folding-state-change spec pos local-to -;;; Hanlding killing/yanking of folded text - -;; Backward compatibility with Emacs 24. -(defun org-fold-core--seq-partition (list n) - "Return list of elements of LIST grouped into sub-sequences of length N. -The last list may contain less than N elements. If N is a -negative integer or 0, nil is returned." - (if (fboundp 'seq-partition) - (seq-partition list n) -(unless (< n 1) - (let ((result '())) -(while
bug#56312: 28.1; URI discrepancy between `thing-at-point' and `org-open-at-point'
> I think this may be a duplicate of bug#42483. Oops, sorry. Yet what I stated above reinforces the rationale; the current situation is somewhat random. Thanks a lot Lars (BTW you helped at a recent bug report by me - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55607), and thanks beforehand, the org team. Regards.
Re: Change both width and height of R plot in SRC block
On 30 June 2022, Gerardo Moro wrote: I have been trying for over a year to change the output plot size when using Orgmode SRC blocks with R. I have tried both using orgmode settings and R settings. I have a table from which I take some values. #+name: cost #+begin_src R :results output file graphics :file imag/cost.jpg :var tab=cost You can put height and width attributes for the image into the source block header: #+begin_src R :results output file graphics :file imag/cost.jpg :var tab=cost :width 800 :height 400 (You mention #+attr_org, but there's a bad colon in what you quote.) If this doesn't work, please give a reproducible example, and we can figure it out. The code you quote doesn't work because we don't have the cost data. Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
[BUG] [WORG] Updating the list of hooks/commands/options on Worg section of https://orgmode.org/worg/org-maintenance.html is obsolete
"Updating the list of hooks/commands/options on Worg" section of https://orgmode.org/worg/org-maintenance.html is referring to mk/eldo.el which does not exist. >From git history, eldo.el is now located inside worg/code/eldo.el The other linked file - https://orgmode.org/worg/doc.html is supposed to be autogenerated by eldo.el, but eldo.el is never used in WORG's publish.sh. We should at least update the https://orgmode.org/worg/org-maintenance.html page to reflect the new script location. In addition, it is probably a good idea to auto-generate worg/doc.org during publishing. Best, Ihor
Re: Library of babel help
Tim Cross writes: >> The latest manual has the correct link. I assume that you have fixed it. >> I guess that some of your questions do no apply anymore. > > Correct. I made some minimal changes to address the worst failing > aspects. However, a lot more work to do to really clean things up. > Bastein applied the patches I sent in and has given me write access. > However, I think I will probably create a new branch to do the > updates/changes and make them available to view (somewhere) as they will > be significant and I want a clean rollback strategy in case things go > wrong (especially as I will be re-defining the whole build process for > worg and probably making significant changes to the styling). . Thanks again for working on this! WORG really needs more care. >>> 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? >> >> Aren't they currently available? I can and I was always able to get the >> org sources by changing the link from .html to .org. > > No, that doesn't work for me using either chrome or firefox. Chrome just > keeps switching back to the HTML url and firefox just hangs, returning > nothing. Bastien has sent me the nginx config being used, but I've not > yet had a look at it. My recollection is that there use to be a > link in the footer which you could use to get the source (org file). I > think an explicit link is better than relying on 'knowing' you can > change the extension to .org (even if it did work) as that is just a > little to close to 'secret guild knowledge' for my tastes. FYI, I am using Qutebrowser, which uses qtwebengine (5.15.5) under the hood. https://orgmode.org/worg/org-contribute.org makes my Qutebrowser displays download save dialogue. The .org file is also downloaded using Firefox-100.0. No hanging. Having a link to .org source in the footer is a good idea. Also, I recall someone complaining that there is not .pdf version of Org manual. I guess that similar feature could be useful in WORG. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
Ihor Radchenko writes: > We usually put obsolete aliases into org-compat.el instead of sprinkling > them across the various .el files. Please move the > define-obsolete-function-alias statements to org-compat. Thanks, please find attached an updated patch. From aa0637c22ff1465a19d4007f1e9d16cc0df9972c Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 30 Jun 2022 13:06:21 +0200 Subject: [PATCH] Delete some Emacs 24 compat code Org mode supports Emacs 26 or newer: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility * lisp/org-compat.el (org-set-transient-map) (org-font-lock-ensure): Delete compat aliases. Update callers. (org-define-error): Redefine as obsolete function alias for `define-error'. Update callers. (string-suffix-p): Delete compatibility definition. * lisp/org-fold-core.el (org-fold-core--seq-partition): Delete private function and update callers to use `seq-partition'. * lisp/org-macs.el (org-without-partial-completion): Move from here... * lisp/org-compat.el (org-without-partial-completion): ...to here. Redefine as obsolete function alias for `progn'. --- lisp/org-clock.el | 2 +- lisp/org-compat.el| 38 ++ lisp/org-fold-core.el | 22 ++ lisp/org-goto.el | 2 +- lisp/org-macs.el | 13 - lisp/org-src.el | 2 +- lisp/org-table.el | 6 +++--- lisp/org.el | 4 ++-- lisp/ox-html.el | 2 +- lisp/ox-odt.el| 2 +- lisp/ox-org.el| 2 +- lisp/ox.el| 2 +- 12 files changed, 16 insertions(+), 81 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 7d99e5087..e0b2d3ce6 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2122,7 +2122,7 @@ fontified, and then returned." (org-mode) (org-create-dblock props) (org-update-dblock) -(org-font-lock-ensure) +(font-lock-ensure) (forward-line 2) (buffer-substring (point) (progn (re-search-forward "^[ \t]*#\\+END" nil t) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 10c125a2c..d8104e7e7 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -904,12 +904,6 @@ context. See the individual commands for more information." ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data)) (w32-get-clipboard-data -;; `set-transient-map' is only in Emacs >= 24.4 -(defalias 'org-set-transient-map - (if (fboundp 'set-transient-map) - 'set-transient-map -'set-temporary-overlay-map)) - ;;; Region compatibility @@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'." string) (apply 'kill-new string args)) -;; `font-lock-ensure' is only available from 24.4.50 on -(defalias 'org-font-lock-ensure - (if (fboundp 'font-lock-ensure) - #'font-lock-ensure -(lambda ( _beg _end) - (with-no-warnings (font-lock-fontify-buffer) - ;; `file-local-name' was added in Emacs 26.1. (defalias 'org-babel-local-file-name (if (fboundp 'file-local-name) @@ -994,29 +981,8 @@ Pass COLUMN and FORCE to `move-to-column'." (defun org-release () "N/A") (defun org-git-version () "N/A !!check installation!!")) - - -;;; Functions for Emacs < 24.4 compatibility - -(defun org-define-error (name message) - "Define NAME as a new error signal. -MESSAGE is a string that will be output to the echo area if such -an error is signaled without being caught by a `condition-case'. -Implements `define-error' for older emacsen." - (if (fboundp 'define-error) (define-error name message) -(put name 'error-conditions - (copy-sequence (cons name (get 'error 'error-conditions)) - -(unless (fboundp 'string-suffix-p) - ;; From Emacs subr.el. - (defun string-suffix-p (suffix string ignore-case) -"Return non-nil if SUFFIX is a suffix of STRING. -If IGNORE-CASE is non-nil, the comparison is done without paying -attention to case differences." -(let ((start-pos (- (length string) (length suffix - (and (>= start-pos 0) - (eq t (compare-strings suffix nil nil - string start-pos nil ignore-case)) +(define-obsolete-function-alias 'org-define-error #'define-error "9.6") +(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6") ;;; Integration with and fixes for other packages diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el index 88072852d..68a777de9 100644 --- a/lisp/org-fold-core.el +++ b/lisp/org-fold-core.el @@ -1304,25 +1304,7 @@ property, unfold the region if the :fragile function returns non-nil." ;; Move to next fold. (setq pos (org-fold-core-next-folding-state-change spec pos local-to -;;; Hanlding killing/yanking of folded text - -;; Backward compatibility with Emacs 24. -(defun org-fold-core--seq-partition (list n) - "Return list of elements of LIST grouped into
Re: [PATCH] Delete some Emacs 24 compat code
On 30/06/2022 18:19, Stefan Kangas wrote: The attached patch deletes some Emacs 24 compat code. Org mode supports Emacs 26 or later, according to: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility I have no particular opinion to which degree older Emacs versions should be supported, but I remember the following message: Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 https://list.orgmode.org/87fsrolmn9@gnu.org/ Org is made of many areas and partial backward-compatibility can still be useful. When people report compatibility problems with Emacs <26, we can guide them so that they enhance org-compat.el. It is not because we don't promise compatibility for Emacs < 26 that we should prevent backward-compatibility for Emacs < 26, and the all-or-nothing approach would actually prevent it.
Re: org-agenda-prefix-format and tab stops
On Thu, 30 Jun 2022 at 14:52, Ihor Radchenko wrote: > > Michael Maurer writes: > > > Here's how it looks vs. how I want it to look https://imgur.com/a/5YfTeZh > > See org-agenda-todo-keyword-format. > > Best, > Ihor Oh wow, that's exactly it. Thanks the both of you.
Re: org-agenda-prefix-format and tab stops
Michael Maurer writes: > Here's how it looks vs. how I want it to look https://imgur.com/a/5YfTeZh See org-agenda-todo-keyword-format. Best, Ihor
Re: [PATCH] describe how to override Author
Robert Pluim writes: > >> Occasional committers would probably not read org-maintenance.org, and > >> those are the people this section is aimed at, I think. Plus itʼs the > >> kind of thing you need to catch early: once the commit has been pushed > >> itʼs too late. > > Ihor> Not really. org-contribute.org is the page directly linked from > Ihor> orgmode.org. It is aiming for new contributors with no write access. > > This particular change is in "Your first commit as an Org > maintainer". Perhaps that node should be moved to org-maintenance.org? I do not think so. I am seeing this section as a "crash course" for the new maintainers. We should only provide the critical information there. Not too much, not too less. Something to not scare people with the details. The elaborate details should be in org-maintenance.org, which is directly mentioned at the end of the "first commit" section. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
Stefan Kangas writes: > The attached patch deletes some Emacs 24 compat code. Org mode > supports Emacs 26 or later, according to: > https://orgmode.org/worg/org-maintenance.html#emacs-compatibility Thanks! I have some comments. > ;;; Integration with and fixes for other packages > diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el > index 88072852d..287686c01 100644 > --- a/lisp/org-fold-core.el > +++ b/lisp/org-fold-core.el > ... > +(define-obsolete-function-alias 'org-fold-core--seq-partition > #'seq-partition "9.6") > diff --git a/lisp/org-macs.el b/lisp/org-macs.el > index da68d8b8f..07c177b0b 100644 > --- a/lisp/org-macs.el > +++ b/lisp/org-macs.el > @@ -70,18 +70,7 @@ > ... > +(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6") ^#'progn We usually put obsolete aliases into org-compat.el instead of sprinkling them across the various .el files. Please move the define-obsolete-function-alias statements to org-compat. Best, Ihor
Re: Convert a Lisp expression to a tree diagram
Juan Manuel Macías writes:
> Sorry for the slight offtopic. I'd like to be able to graphically
> convert (from a src block) a Lisp expression to a tree diagram, similar
> to trees used in (human) syntax and grammar, especially generative
> grammar (this is a web app for generating such trees:
> http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack
> using the 'forest' package (here's a related thread with pros and cons:
> https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree),
> but I was wondering if anyone knows of any more emacs/elisp/org friendly
> packages/solutions. Some time ago I saw an Emacs package that could
> convert a Elisp expression into an ascii text tree diagram, but I can't
> remember its name and I can't find it anywhere...
Invoking search across my notes and archives (all stored in Org, of
course) yielded the following:
https://reddit.com/r/emacs/comments/u2ca5c/drawtreeel/
https://reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/
linking to
https://github.com/amno1/draw-cons-tree
https://github.com/zainab-ali/pair-tree.el (example:
https://teddit.namazso.eu/pics/w:2172_vetc0martyb61.png)
Hope it helps.
Best,
Ihor
actual notes below:
* CANCELLED /u/zainab-ali [Reddit:emacs] (2021) M-x emacs-reddit:
pair-tree: a learning tool for visualizing Elisp lists :BOOKMARK:misc:CANCELLED:
SCHEDULED: <2021-03-28 Sun>
:PROPERTIES:
:ID: 1443107e70e8b4e1d6d17499e546a8603b98d03e
:CREATED: [2021-01-19 Tue 10:09]
:Source:
[[https://www.reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/]]
:ARCHIVE_TIME: 2021-04-02 Fri 16:15
:ARCHIVE_FILE: ~/Org/notes.org
:ARCHIVE_OLPATH: Topics/Software/Emacs \ org-mode/No deadline
:ARCHIVE_CATEGORY: Emacs[D]
:ARCHIVE_TODO: CANCELLED
:ARCHIVE_ITAGS: COMMON NOREFILE NODEADLINE SKIP
:END:
:LOGBOOK:
- State "CANCELLED" from "NEXT" [2021-03-28 Sun 23:59]
CLOCK: [2021-03-28 Sun 23:57]--[2021-03-28 Sun 23:59] => 0:02
- Refiled on [2021-02-27 Sat 20:47]
- Refiled on [2021-01-19 Tue 10:20]
:END:
:BIBTEX:
#+begin_src bibtex
@misc{1443107e70e8b4e1d6d17499e546a8603b98d03e,
author = {/u/zainab-ali},
howpublished = {Reddit:emacs},
keywords = {emacs},
note = {Online; accessed 19 January 2021},
title ={M-x emacs-reddit: pair-tree: a learning tool for
visualizing Elisp lists},
url =
{https://www.reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/},
year = 2021,
}
#+end_src
:END:
* CANCELLED /u/__g_p__ [Reddit:emacs] (2022) draw-tree.el
:BOOKMARK:misc:CANCELLED:
:PROPERTIES:
:TITLE:draw-tree.el
:BTYPE:misc
:ID: Reddit-emacs-/u/__g_p__2022-draw-tree-el-78e
:AUTHOR: /u/__g_p__
:CREATED: [2022-04-13 Wed 22:50]
:HOWPUBLISHED: Reddit:emacs
:KEYWORDS: emacs
:NOTE: Online; accessed 13 April 2022
:RSS: https://www.reddit.com/r/emacs/comments/u2ca5c/drawtreeel/.rss
:URL: https://www.reddit.com/r/emacs/comments/u2ca5c/drawtreeel/
:YEAR: 2022
:ARCHIVE_TIME: 2022-04-29 Fri 17:33
:ARCHIVE_FILE: ~/Org/notes.org
:ARCHIVE_OLPATH: Topics/Software/Emacs \ org-mode/No deadline
:ARCHIVE_CATEGORY: Emacs[D]
:ARCHIVE_TODO: CANCELLED
:ARCHIVE_ITAGS: COMMON NOREFILE NODEADLINE SKIP
:END:
:LOGBOOK:
- State "CANCELLED" from "TODO" [2022-04-28 Thu 22:56]
- Refiled on [2022-04-14 Thu 08:00]
:END:
Re: [PATCH] describe how to override Author
> On Thu, 30 Jun 2022 21:19:36 +0800, Ihor Radchenko > said: Ihor> Robert Pluim writes: >> >> Occasional committers would probably not read org-maintenance.org, and >> >> those are the people this section is aimed at, I think. Plus itʼs the >> >> kind of thing you need to catch early: once the commit has been pushed >> >> itʼs too late. >> Ihor> Not really. org-contribute.org is the page directly linked from Ihor> orgmode.org. It is aiming for new contributors with no write access. >> >> This particular change is in "Your first commit as an Org >> maintainer". Perhaps that node should be moved to org-maintenance.org? Ihor> I do not think so. I am seeing this section as a "crash course" for the Ihor> new maintainers. We should only provide the critical information there. Ihor> Not too much, not too less. Something to not scare people with the Ihor> details. I guess we disagree about whether knowing about the distinction between 'Author:' and 'Commit:' is critical or not. For a free software project correct attribution of changes is very important, so committers should pay attention to it (and by extension the documentation should educate them about it at the earliest opportunity). But youʼre the maintainer :-) Ihor> The elaborate details should be in org-maintenance.org, which is Ihor> directly mentioned at the end of the "first commit" section. In "Where can I track bugs, patches and updates?" or somewhere else? BTW, Iʼm having trouble parsing this sentence from there: You don't much more: confirming bugs is a critical contribution. Thereʼs at least one word missing betweeen "donʼt" and "much" there. Robert --
Re: Change both width and height of R plot in SRC block
Gerardo Moro writes: > I have been trying for over a year to change the output plot size when > using Orgmode SRC blocks with R. I have tried both using orgmode settings > and R settings. Have you tried :with and :height header arguments? > I have a table from which I take some values. It would be more helpful if you provided a completely reproducible example that others can also run. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
Ihor Radchenko writes: >> ;;; Integration with and fixes for other packages >> diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el >> index 88072852d..287686c01 100644 >> --- a/lisp/org-fold-core.el >> +++ b/lisp/org-fold-core.el >> ... >> +(define-obsolete-function-alias 'org-fold-core--seq-partition >> #'seq-partition "9.6") Also, thinking a bit more. Do we need to obsolete the private function? I think it is safe to remove it completely. Best, Ihor
Convert a Lisp expression to a tree diagram
Hi all, Sorry for the slight offtopic. I'd like to be able to graphically convert (from a src block) a Lisp expression to a tree diagram, similar to trees used in (human) syntax and grammar, especially generative grammar (this is a web app for generating such trees: http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack using the 'forest' package (here's a related thread with pros and cons: https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree), but I was wondering if anyone knows of any more emacs/elisp/org friendly packages/solutions. Some time ago I saw an Emacs package that could convert a Elisp expression into an ascii text tree diagram, but I can't remember its name and I can't find it anywhere... Best regards, Juan Manuel
Re: [PATCH] Delete some Emacs 24 compat code
Max Nikulin writes: > On 30/06/2022 18:19, Stefan Kangas wrote: >> The attached patch deletes some Emacs 24 compat code. Org mode >> supports Emacs 26 or later, according to: >> https://orgmode.org/worg/org-maintenance.html#emacs-compatibility > > I have no particular opinion to which degree older Emacs versions should > be supported, but I remember the following message: > > Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 > https://list.orgmode.org/87fsrolmn9@gnu.org/ This is a valid point in general. However, Org mode already fails when you try to load it using Emacs 24 (correct me if I am wrong). So, Org cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do not see much point keeping partial compatibility. There is a reason to keep old compatibility code only when Org works in general and only some new optional libraries cannot be used. This is not the case for Emacs 24, AFAIK. Best, Ihor
Re: [PATCH] New remote resource download policy
On 29/06/2022 22:27, Timothy wrote: Max Nikulin writes: I also really don’t like how `org-mks' so forcefully grabs all keyboard input. I can see it being nice to jump back to the buffer and see where the resource is being used, which isn’t really possible using `org-mks'. An idea: a menu entry that displays location in the org file that caused the prompt. However it may require enough work to pass context data to the function rendering menu. I see you point concerning blocking modal prompt and I do not like it as well. Have you seen the following thread: Arthur Miller. Proposal: 'executable' org-capture-templaes. Wed, 22 Jun 2022 14:13:51 +0200. https://list.orgmode.org/am9pr09mb49771cf015daecbf3e5f955e96...@am9pr09mb4977.eurprd09.prod.outlook.com If it were merged already, would it be enough for you to implement the dialog or the proposal lacks some features necessary for smooth user experience? The reason why I asked about `org-mks' is expectation of UI consistency withing Org. It might help users having customized `display-buffer-alist' Eric S Fraga. Re: Bug: org-no-popups disregards display-buffer-fallback-action Sun, 14 Nov 2021 19:37:30 +. https://list.orgmode.org/87tugeedfp@ucl.ac.uk Eric S Fraga. window management for logging and capturing notes. Sun, 10 Oct 2021 18:01:56 +0100. https://87zgrgke4b@ucl.ac.uk I still do not like code adding a menu close enough to existing one, but I will not object any more.
Re: Serving .org files for worg (was: Re: Library of babel help)
On 30/06/2022 22:45, Max Nikulin wrote: On 30/06/2022 16:06, Tim Cross wrote: No, that doesn't work for me using either chrome or firefox. Chrome just keeps switching back to the HTML url and firefox just hangs, returning nothing. Tim, have you checked your Downloads folder? It may be full of .org files you tried to download from worg. Chromium just saves files unless it is explicitly configured to display save dialog. Behavior of Firefox changed around version 100 toward this direction (and I have to tweak setting to restore older behavior with /tmp for files intended to be opened in external applications).
Serving .org files for worg (was: Re: Library of babel help)
On 30/06/2022 16:06, Tim Cross wrote: Aren't they currently available? I can and I was always able to get the org sources by changing the link from .html to .org. No, that doesn't work for me using either chrome or firefox. Chrome just keeps switching back to the HTML url and firefox just hangs, returning nothing. Bastien has sent me the nginx config being used, but I've not yet had a look at it. It is rather strange curl -I 'https://orgmode.org/worg/doc.org' ... Content-Type: application/octet-stream browsers should offer "save as" dialog in such case. It is possible to add Content-Disposition header to force "save" prompt, but I am unsure if it the best option. I would prefer some desktop-wide MIME handler, but there is not specific type for org. text/plain will be likely handled by browsers internally. Unsure if something like "text/x-org" is better since anyway custom configuration will be required. Tim, did you face the problem with some particular file? Browsers might try to guess real MIME type from file content. If the problem is reproducible, you may experiment with "no sniff" header.
Re: [PATCH] worg - Reflect the removal of org-mac-link.el from org-contrib
Hi Ihor, Aimé Bertrand writes: org-mac-link was removed from org-contrib with https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6. This is a patch (attached) for Worg to reflect the changes. Thanks for the patch! --- a/org-contrib/index.org +++ b/org-contrib/index.org @@ -110,14 +110,6 @@ the package -- it will hopefully have some documentation. Written by /Christopher Suckling/. [[contribfile:lisp/org-mac-iCal.el][Link to raw file]]. -- [[file:org-mac-link.org][/org-mac-link.el/ -- grab links from various mac applications]] :: - Grab the current link or selection from an open mac application and - insert it as a hyperlink at point in an org-mode document. Written - by /Anthony Lander/, /John Wiegley/ and /Christopher Suckling/. - This file replaces the earlier org-mac-message.el and - org-mac-link-grabber.el. - [[contribfile:lisp/org-mac-link.el][Link to raw file]]. Rather than removing the package description completely, it should be moved to the External section. Took your advice and moved the package description to the External section. diff --git a/org-contrib/org-mac-link.org b/org-contrib/org-mac-link.org deleted file mode 100644 index 2b2582e9.. --- a/org-contrib/org-mac-link.org +++ /dev/null I have looked into README.org in https://gitlab.com/aimebertrand/org-mac-link and I notice that it contains less information compared to org-mac-link.org. It would be useful to provide the missing details in the new README.org if you plan to maintain the documentation there instead of WORG. Left the documentation here and updated page to reflect the changes to the package. Also Added URLs to external sources. -** [[file:org-contrib/org-mac-link.org][org-mac-link]] -- Hyperlink to items in mac applications - grab the current link or selection from an open mac application and - insert it as a hyperlink at point in an org-mode document. Written - by /Anthony Lander/. - ** [[file:org-contrib/org-mac-mail-link.org][org-mac-mail-link]] -- Hyperlink to messages in Mail.app A small elisp file that addresses linking to Mail.app messages directly via the =org-capture= system. For wider application - support check out [[file:org-contrib/org-mac-link.org][org-mac-link]]. + support check out [[https://gitlab.com/aimebertrand/org-mac-link][org-mac-link]]. [[file:org-contrib/org-mac-mail-link.org][org-mac-mail-link]] is not changed and will become dead line after applying this patch. Left the page here. There shouldn't be any dead lines after the patch. New patch file attached. >From 6d3e5b319670574fb47a74ed3139990077190406 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aim=C3=A9=20Bertrand?= Date: Thu, 30 Jun 2022 18:55:34 +0200 Subject: [PATCH] Reflect the removal of org-mac-link.el from org-contrib * org-contrib/index.org: move org-mac-link.el to external section * org-contrib/org-mac-link.org: Add more supported Apps. Add URL to Repo. Add MELPA URL. --- org-contrib/index.org| 16 org-contrib/org-mac-link.org | 26 ++ 2 files changed, 26 insertions(+), 16 deletions(-) diff --git a/org-contrib/index.org b/org-contrib/index.org index 308168fc..1d329475 100644 --- a/org-contrib/index.org +++ b/org-contrib/index.org @@ -110,14 +110,6 @@ the package -- it will hopefully have some documentation. Written by /Christopher Suckling/. [[contribfile:lisp/org-mac-iCal.el][Link to raw file]]. -- [[file:org-mac-link.org][/org-mac-link.el/ -- grab links from various mac applications]] :: - Grab the current link or selection from an open mac application and - insert it as a hyperlink at point in an org-mode document. Written - by /Anthony Lander/, /John Wiegley/ and /Christopher Suckling/. - This file replaces the earlier org-mac-message.el and - org-mac-link-grabber.el. - [[contribfile:lisp/org-mac-link.el][Link to raw file]]. - - /org-mairix.el/ -- hook mairix search into Org for different MUAs :: Written by /Georg C. F. Greve/. [[contribfile:lisp/org-mairix.el][Link to raw file]]. @@ -299,6 +291,14 @@ See [[file:../exporters/index.org][Exporters]]. - [[http://ozymandias.dk/emacs/org-import-calendar.el][/org-import-icalendar.el/]] -- import iCal events in an Org buffer :: Written by /Vagn Johansen/. +- [[file:org-mac-link.org][/org-mac-link/ -- grab links from various mac applications]] :: + Grab the current link or selection from an open mac application and + insert it as a hyperlink at point in an org-mode document. Written + by /Anthony Lander/, /John Wiegley/ and /Christopher Suckling/. + This file replaces the earlier org-mac-message.el and + org-mac-link-grabber.el. + [[https://gitlab.com/aimebertrand/org-mac-link][project page]]. + - [[https://github.com/sigma/org-magit][/org-magit/]] -- basic support for [[https://github.com/magit/magit][magit]] links :: Written by /Yann Hodique/. diff --git
[PATCH] Fix typos
Please see the attached. From 5ecf4e9613993a520844b78880bf57c04f193880 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 30 Jun 2022 17:33:03 +0200 Subject: [PATCH] ; Fix typos --- lisp/org-element.el | 14 +++--- lisp/org-fold-core.el| 10 +- lisp/org-persist.el | 14 +++--- lisp/org-src.el | 2 +- lisp/org.el | 2 +- lisp/ox-latex.el | 12 ++-- lisp/ox-texinfo.el | 2 +- testing/lisp/test-org-element.el | 2 +- testing/lisp/test-ox-publish.el | 2 +- 9 files changed, 30 insertions(+), 30 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 2a826bdbb..8964770f0 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -700,7 +700,7 @@ is cleared and contents are removed in the process." ;; DATUM is i.e. a headline, it's property list (`:title' ;; in case of headline) can contain parsed objects. The ;; objects will contain `:parent' property set to the DATUM - ;; iteself. When copied, these inner `:parent' propery + ;; itself. When copied, these inner `:parent' propery ;; values will contain incorrect object decoupled from ;; DATUM. Changes to the DATUM copy will not longer be ;; reflected in the `:parent' properties. So, we need to @@ -1289,7 +1289,7 @@ parser (e.g. `:end' and :END:). Return value is a plist." (category (catch 'buffer-category (unless org-element-org-data-parser--recurse (org-with-point-at end - ;; Avoid recusrive calls from + ;; Avoid recursive calls from ;; `org-element-at-point-no-context'. (let ((org-element-org-data-parser--recurse t)) (while (re-search-backward "^[ \t]*#\\+CATEGORY:" (point-min) t) @@ -6092,7 +6092,7 @@ completing the request." (log org-element--cache-size 2)) (org-element-cache-reset) (throw 'org-element--cache-quit t))) - ;; Done deleting everthing starting before END. + ;; Done deleting everything starting before END. ;; DATA-KEY is the first known element after END. ;; Move on to phase 1. (org-element--cache-log-message @@ -6664,7 +6664,7 @@ The function returns the new value of `org-element--cache-change-warning'." ;; `org-element--cache-submit-request'). After the edit, we want to ;; look if there was a sensitive removed during edit. ;; FIXME: This is not the most efficient way and we now - ;; have to delete more elemetns than needed in some + ;; have to delete more elements than needed in some ;; cases. A better approach may be storing the warning ;; in the modification request itself. (let ((org-element--cache-change-warning-before org-element--cache-change-warning) @@ -6748,7 +6748,7 @@ that range. See `after-change-functions' for more information." "This variable controls how buffer changes are handled by the cache. By default (when this variable is nil), cache re-parses modified -headlines immidiately after modification preserving all the unaffected +headlines immediately after modification preserving all the unaffected elements inside the headline. The default behaviour works best when users types inside Org buffer of @@ -6870,7 +6870,7 @@ known element in cache (it may start after END)." ;; costly. Instead, we should better re-parse only the ;; headline itself when possible. If a headline is still ;; starting from old :begin position, we do not care that - ;; its boundaries could have extended to shrinked - we + ;; its boundaries could have extended to shrunk - we ;; will re-parent and shift them anyway. (and (eq 'headline (org-element-type up)) (not org-element--cache-avoid-synchronous-headline-re-parsing) @@ -7154,7 +7154,7 @@ The element is: %S\n The real element is: %S\n Cache around :begin:\n%S\n%S\n%S" (cdr (org-element--cache-find (org-element-property :begin real-element) 'both))) (org-element-cache-reset)) -;;; Cache persistance +;;; Cache persistence (defun org-element--cache-persist-before-write (container associated) "Sync cache before saving." diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el index 68a777de9..212fa09a8 100644 --- a/lisp/org-fold-core.el +++ b/lisp/org-fold-core.el @@ -162,7 +162,7
RE: Convert a Lisp expression to a tree diagram
This one draws graph of cons cells (lists): https://github.com/amno1/draw-cons-tree I never tried with random s-expressions, but I guess you could pass them in as lists? Originalmeddelande Från: Juan Manuel Macías Datum: 2022-06-30 16:20 (GMT+01:00) Till: orgmode Ämne: Convert a Lisp expression to a tree diagram Hi all, Sorry for the slight offtopic. I'd like to be able to graphically convert (from a src block) a Lisp expression to a tree diagram, similar to trees used in (human) syntax and grammar, especially generative grammar (this is a web app for generating such trees: http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack using the 'forest' package (here's a related thread with pros and cons: https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree), but I was wondering if anyone knows of any more emacs/elisp/org friendly packages/solutions. Some time ago I saw an Emacs package that could convert a Elisp expression into an ascii text tree diagram, but I can't remember its name and I can't find it anywhere... Best regards, Juan Manuel
Re: Library of babel help
Tim Cross writes: > 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. The latest manual has the correct link. I assume that you have fixed it. I guess that some of your questions do no apply anymore. > 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? Aren't they currently available? I can and I was always able to get the org sources by changing the link from .html to .org. Best, Ihor
Re: [PATCH] Improve look of agenda on graphical displays
Stefan Kangas writes: > The attached patch improves the look of the agenda time grid and > separator line on graphical displays. It was inspired by > org-modern.el by Daniel Mendler. Applied onto main via 998a0aacd. Best, Ihor
Re: [PATCH] Improve "Speeding Up Your Agendas" chapters
Stefan Kangas writes: > Ihor Radchenko writes: > >> Applied onto main via a722f6f8e with amendment to the commit message. > > It seems like i bungled the patch: two typos are fixed in the attached. > Thanks. I swear I did check for this... Still missed. Applied onto main via 381a2ae4d after removing the trailing "." from the commit message. Best, Ihor
Re: [PATCH] worg - Reflect the removal of org-mac-link.el from org-contrib
Aimé Bertrand writes: > org-mac-link was removed from org-contrib with > https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6. > > This is a patch (attached) for Worg to reflect the changes. Thanks for the patch! > --- a/org-contrib/index.org > +++ b/org-contrib/index.org > @@ -110,14 +110,6 @@ the package -- it will hopefully have some documentation. >Written by /Christopher Suckling/. >[[contribfile:lisp/org-mac-iCal.el][Link to raw file]]. > > -- [[file:org-mac-link.org][/org-mac-link.el/ -- grab links from various mac > applications]] :: > - Grab the current link or selection from an open mac application and > - insert it as a hyperlink at point in an org-mode document. Written > - by /Anthony Lander/, /John Wiegley/ and /Christopher Suckling/. > - This file replaces the earlier org-mac-message.el and > - org-mac-link-grabber.el. > - [[contribfile:lisp/org-mac-link.el][Link to raw file]]. Rather than removing the package description completely, it should be moved to the External section. > diff --git a/org-contrib/org-mac-link.org b/org-contrib/org-mac-link.org > deleted file mode 100644 > index 2b2582e9.. > --- a/org-contrib/org-mac-link.org > +++ /dev/null I have looked into README.org in https://gitlab.com/aimebertrand/org-mac-link and I notice that it contains less information compared to org-mac-link.org. It would be useful to provide the missing details in the new README.org if you plan to maintain the documentation there instead of WORG. > -** [[file:org-contrib/org-mac-link.org][org-mac-link]] -- Hyperlink to items > in mac applications > - grab the current link or selection from an open mac application and > - insert it as a hyperlink at point in an org-mode document. Written > - by /Anthony Lander/. > - > ** [[file:org-contrib/org-mac-mail-link.org][org-mac-mail-link]] -- > Hyperlink to messages in Mail.app > A small elisp file that addresses linking to Mail.app messages > directly via the =org-capture= system. For wider application > - support check out [[file:org-contrib/org-mac-link.org][org-mac-link]]. > + support check out > [[https://gitlab.com/aimebertrand/org-mac-link][org-mac-link]]. [[file:org-contrib/org-mac-mail-link.org][org-mac-mail-link]] is not changed and will become dead line after applying this patch. Best, Ihor
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > Yes, sad to say they should not directly offer donation methods. > > > So they should rather link to liberapay, so it is not a direct offer? > > You can't make a serious point by twisting words. I do make a serious point: by linking to liberapay who are actively searching for ways to get rid of proprietary software, those links are most likely to become usable without proprietary software once a practical method to donate without proprietary software exists. But yes, wrapping that into a cheeky answer is not the most effective way to make this point. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Change both width and height of R plot in SRC block
Oh my god, this works! I honestly tried everything but... Apologies. Where can I read more about the possible options at header in source blocks? Thanks! El jue, 30 jun 2022 a las 15:50, Ihor Radchenko () escribió: > Gerardo Moro writes: > > > I have been trying for over a year to change the output plot size when > > using Orgmode SRC blocks with R. I have tried both using orgmode settings > > and R settings. > > Have you tried :with and :height header arguments? > > > I have a table from which I take some values. > > It would be more helpful if you provided a completely reproducible > example that others can also run. > > Best, > Ihor >
Re: Change both width and height of R plot in SRC block
Aloha Gerardo, Please see this Worg page: https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html All the best, Tom Gerardo Moro writes: Oh my god, this works! I honestly tried everything but... Apologies. Where can I read more about the possible options at header in source blocks? Thanks! El jue, 30 jun 2022 a las 15:50, Ihor Radchenko () escribió: Gerardo Moro writes: > I have been trying for over a year to change the output plot > size when > using Orgmode SRC blocks with R. I have tried both using > orgmode settings > and R settings. Have you tried :with and :height header arguments? > I have a table from which I take some values. It would be more helpful if you provided a completely reproducible example that others can also run. Best, Ihor -- Thomas S. Dye https://tsdye.online/tsdye
Re: Org mode export accessibility
"T.V Raman" writes: > 1. Accessibility as word used in isolation has now become mostly >meaningless, to be concrete one has to ask "Accessibility to whom"? > > 2. So in the following, everything I say is with respect to users with >visual impairments. This is exactly the perspective I was hoping to hear from you. Though this thread is not dedicated to visual impairments. (I guess you also did not touch the question of color blindness). > 3. It's incorrect to define "Accessibility" in terms of a specific >user access tool or technology -- that usage is marketing jargon >for a specific Access Solution like a screenreader --- so I refrain in > general from >defining this in terms of Screenreaders. Yet, in order to simplify the efforts needed to read a document exported from Org mode one needs to use some kind of tool/technology. Unless a common standard exist in this area, we have to support at least the most common Access Solutions (prioritizing Free software, if possible). >From you message, it does not look like there is any common standard. > With those meta-thoughts out of the way: > > A: Org-generated documents are mostly well-structured documents, and ... > B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to ... > C: pdftex and pdflatex were built in the late 90's by a student in ... > D: All that said, it is likely still easier to go from org->HTML ... Do I understand correctly that you have no issues with reading documents exported using current version of Org? > E: Finally, note that in (D) I said "machine processable" not > "Accessible"; machine-processable is a pre-requisite to "repurpose " > what you publish, and making that result usable by different user > communities is a direct consequence of suche machine-processability. I understand. But one can similarly say that .org files are "machine processable" and Org export code is not strictly necessary. Yet, it ends up extremely useful in practice. I suspect that the exported documents can similarly be improved to reduce the amount of efforts required from visually impair users to read such documents. The question is what kinds improvements can be made on Org side. Best, Ihor
Change both width and height of R plot in SRC block
Hi, I have been trying for over a year to change the output plot size when using Orgmode SRC blocks with R. I have tried both using orgmode settings and R settings. I have a table from which I take some values. #+name: cost #+begin_src R :results output file graphics :file imag/cost.jpg :var tab=cost library(ggplot2) ggplot(tab, aes(x = date, y = cost)) + geom_line(color="darkgreen") + geom_point() + scale_x_date(date_breaks = "1 day", date_labels = "%b %d") + theme(axis.text.x = element_text(angle = 90)) + scale_y_continuous(breaks=seq(100,200,1)) + ylim(100, 200) #+end_src The resulting plot (only showing the x axis) is squared, so the resulting X axis is not legible at all: #+RESULTS: cost [image: image.png] I have spent months to try to figure out how to have a non-square plot showing in Orgmode, to no avail. This presses me to stop using Emacs for graphing altogether. I have head that this has more to do with R than with Emacs, but I have tried all the R code advice out there. I also have tried of course the #+attr_org: :width 600px :height:300px, but it only considers the width, so I end up with another square. If any of you has a solution, much appreciated! Best, G. Moro
Re: org-agenda-prefix-format and tab stops
Here's how it looks vs. how I want it to look https://imgur.com/a/5YfTeZh I tried messing around with tabstops in the headlines, but realized quickly that the level of headline (I think) has an influence over the number of tabstops in org-agenda. So basically you have to vary the amount of tabstops per headline, to get a uniform layout in the org-agenda view. So a more elegant solution would be to specify a layout for org-agenda-view, that determines the position of todo-items and the text immediately following them. On Thu, 30 Jun 2022 at 04:33, Samuel Wales wrote: > > i am not understanding what you are trying to do. do you have headers > before other columns? are you perhaps looking for > org-agenda-todo-keyword-format ? or is it the prefix format that is > varying for you? > > > On 6/29/22, Michael Maurer wrote: > > hi, > > > > I've discovered org-agenda-prefix-format, but can't figure out how to > > add a tab-stop after every todo-item. So basically that the headlines > > are aligned regardless of the character-length of the todo-item. My > > current setup looks like this: > > > > (setq org-agenda-prefix-format > > '( > > (agenda . " %?-12t% s") > > (timeline . " % s") > > (todo . " %i %-12:c") > > (tags . " %i %-12:c") > > (search . " %i %-12:c")) > > > > but messing around with the -12 variable doesn't seem to change > > anything. Probably missing something. > > > > > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com
Re: [PATCH] describe how to override Author
> On Wed, 29 Jun 2022 18:10:00 +0800, Ihor Radchenko > said: Ihor> Robert Pluim writes: >> Iʼd be worried if the org maintainer(s) didnʼt know how to override >> Author :-) Ihor> I have bad news for you... Simply because I never ever had a need to do Ihor> it :) Not like selecting this option from Magit dispatch is difficult. But you were at least aware that it was possible :-) >> Occasional committers would probably not read org-maintenance.org, and >> those are the people this section is aimed at, I think. Plus itʼs the >> kind of thing you need to catch early: once the commit has been pushed >> itʼs too late. Ihor> Not really. org-contribute.org is the page directly linked from Ihor> orgmode.org. It is aiming for new contributors with no write access. This particular change is in "Your first commit as an Org maintainer". Perhaps that node should be moved to org-maintenance.org? Ihor> More elaborate things like backwards compatibility, copyright process Ihor> assistance, etc are documented in org-maintenance.org. Ihor> Modifying submitted diffs/patches appears to lay within the more Ihor> elaborate category IMHO. Ihor> I guess that you intended to attach the updated patch, but haven't? No, since weʼre still discussing where it should go. Robert --
Re: org-babal-R-command
Naresh Gurbuxani writes: Can you escape spaces with backslash? (setq org-babel-R-command “c:/Program\ Files/Microsoft/R\ Open/R-3.5.1/bin/R.exe —slave —no-save”) Another way is to use single quotes: (setq org-babel-R-command “'c:/Program Files/Microsoft/R Open/R-3.5.1/bin/R.exe' —slave —no-save”) Thanks, Payas > In my windows computer, R is installed at c:/Program Files/Microsoft/R > Open/R-3.5.1/bin > > Notice two spaces: “Program Files” and “R Open” > > How can I set the variable org-babel-R-command? > > I tried > (setq org-babel-R-command “c:/Progra~1/Microsoft/R Open/R-3.5.1/bin/R.exe > —slave —no-save”) > > But the space between R and Open is a problem. What is the solution? > > Thanks, > Naresh > > Sent from my iPhone --
