Re: org-babel not finding executables when using direnv [Was: Re: ob-sql is not finding psql when using direnv+guix]
"Adolfo De Unanue" writes: > On Wed, May 12, 2021, at 08:49, Cook, Malcolm wrote: >> > > >I am using Guix with direnv. >> > > >> > > What is your shell? >> > > >> > >> > My shell is bash, originally I was using zsh and I thought that was the >> > problem, so I switched to bash and still not working. >> > >> > > How/When do you "hook direnv into your shell" (https://direnv.net/)? >> > > >> > >> > In the .profile file, at login. >> > >> > > > In an specific folder I am installing and using psql and postgresql >> > > > using direnv+guix as follows: >> > > >use guix --manifest=cdpp-manifest.scm >> > > > >> > > >export PGUSER=food_user >> > > >export PGPASSWORD=some_password >> > > >export PGDATABASE=food >> > > > >> > > >layout postgres >> > > >> > > When are you doing this? >> > > >> > > a) in the "specific folder"'s .envrc file? >> > > b) in an org-mode shell block that you execute prior to the sql block? >> > > c) ?? >> > >> > Option (a) >> > >> > >> > > You seem to be following [Per\-project >> > > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) >> > > but with guix instead of nix. Nice. >> > > >> > >> > Yep, great post. direnv + guix change the way I develop software, do data >> > science and write lectures and papers. >> > >> > > If you enter the directory and then call emacs, earthing should just >> > > work, no changes neede. >> > > >> > >> > It works for almost everything (sql-buffers, python buffers, etc), except >> > for org-babel sql blocks. >> > >> > I am using EXWM, so emacs is always on. >> > >> > >> > > If you want to tell emacs to adopt the environment established by a >> > > .direnv, you probably want [direnv integration for >> > > emacs\.](https://github.com/wbolster/emacs-direnv) >> > > >> > >> > emacs-direnv was my first choice, but then I changed to envrc >> > (https://github.com/purcell/envrc) . In both I got the error. >> > >> >> I see. Envrc looks superior. Good to know. >> >> You've covered all my bases. Shooting in the dark, I would >> confirm/check the following: >> > > I have news: > > It fails for python too. Using the same files as before and this block: > > #+begin_src python > import pandas as pd > import matplotlib.pyplot as plt > #+end_src > > It finds matplotlib, but fails to find pandas. I tried the same trick as > before > (but with the python executable, no psql), added the line > > (org-babel-python-command . ".direnv/.guix-profile/bin/python3") > > but is not working. > > But if I am in shell, or in a python buffer or in a inferior-python process > Emacs is finding all the libraries and executables. > > So, I am assumming that the problem lies in how org-babel searchs the path ... This is very unlikely. If there were issues in this area, we would be seeing many more bug reports. More likely is that the PATH variable doesn't contain what you think it does. First thing I would do is try running the following source block +being_src emacs-lisp (getenv "PATH") +end_src and verify the direnv bin directory is actually in your path. Emacs will inherit the path from the shell running when emacs is started. Changes made in your shell after Emacs has started will have no effect on the PATH variable for emacs. You mentioned at one point your running exwm. If you are not running exwm in a login shell and your not sourcing your ~/.profile prior to starting Emacs/exwm (assuming the direnv settings and path are setup there), then the path variable is not going to have the direnv bin directory. Either you need to ensure the appropriate direnv bin directory is in your path before starting exwm or you need to add a configuration step (e.g. possibly a hook function) which will add the direnv bin directory using setenv. -- Tim Cross
Re: [PATCH] Fontification for inline src blocks
Timothy writes: > Thank you for the detailed feedback :) > > Ihor Radchenko writes: > >> Timothy writes: >> >>>> I do not like abusing prettify-symbols-mode. What if it is not enabled? > > If you know of another way of accomplishing text-replacement which > changes back when the cursor enters the region, please let me know. > >>> Ah, it does it anyway at the moment. >> >> Hmm. You are right. You are calling compose-region directly. Note, that >> you do not add 'decompose-region function for automatic region >> destruction (see help:pretty-symbol-pattern-to-keyword). > > Isn't the same effect achieved by the remove-list-of-text-properties call? > >> If I understand correctly (I did not really install your patch), if you have >> composed region, disable font-lock, and try to edit the region, edits >> will be invisible. Or imagine setting org-inline-src-prettify-results to >> nil in already fontified buffer. > > I just tried "setting org-inline-src-prettify-results to nil in already > fontified buffer." and the region just decomposed and stayed that way. > >> Also, you may find help:font-lock-extra-managed-props useful. That way, >> you will not have to manually remove composition and other non-standard >> properties during fontification > > Hmmm, from a look I can't tell exactly how these are "managed". Are they > just removed when a region is processed? > >> why are you even removing 'face? It should be already done by font-lock). > > I tried removing such calls, and everything still worked, so this is no > longer done. > >>>> What will happen if user toggles prettify-symbols-mode in Org buffer? >>> >>> This seems to be toggled nicely by prettify-symbols-mode too. >> >> I would not expect it to. Why would prettify-symbols-mode interfere with >> Org mode native fontification if it is not strictly necessary? > > Well, I guess this is a by-product of using prettify-symbols-start/end, > see my note at the start of this email about not being aware of anything else. > >> P.S. Nitpick: You do not need to run fontification in while loops. Just >> fontifying next match before limit should be enough. Font-lock will call >> the function again if needed. > > I'm guessing for this to work I'd need to return the final char > fortified? Or is the moving of point enough? > > Maybe related - I've noticed this doesn't seem to work with multiple > src_ blocks per line, might you have any insight here? > > This may or may not be something to consider but ... What is the impact of using this technique for accessibility and users of assistive technology like text-to-speech or braille displays? I'm currently not in the position to test this patch, but once I get some environments for testing sorted out, I should be able to try it out. >From an accessibility perspective, behaviour which changes what is 'displayed' based on cursor position is often confusing for things like text-to-speech. In the past, I have run into issues with prettify symbols because it results in either less meaningful content (e.g. unicode numbers rather than defined character names) or additional spoken text which makes it difficult to understand. Things like overlays, tooltips or features which make display different from underlying character content can often be problematic with assistive technology. -- Tim Cross
Re: URLs with brackets not recognised
Rudolf Adamkovič writes: > Maxim Nikulin writes: > >> I do not think it is a bug. Plain text links detection is a kind of >> heuristics. It will be always possible to win competition with regexp. >> Consider it as a limitation requiring some hints from an intelligent >> user. > > I disagree. URLs are well-specified. Per RFC 3986, the characters > allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?]. Org mode should > implement proper URL detection, not asking its users "to give it some > hints" and using "a kind of heuristics". A string either is a valid URL > per the relevant RFCs or it is not. > Limitations with plain text links are documented in the manual, with an explanation of why you need to use the org link insertion commands to created a valid link which escapes the problematic characters. As this is defined and documented behaviour, I don't see how it can be considered a bug. You might consider it a frustrating or even unnecessary limitation, but not a bug. I'm sure a patch which improves org handling of plain urls would be considered. However, previous attempts at such enhancements have either resulted in significant performance impact or unexpected and unwanted side effects. In short, this is a non-trivial problem to solve. As the need for such use cases in plain text links is a small use case and as you can have those links using org link syntax, it would be very hard to justify a patch which may have adverse performance impact for all users. This change could be considered a feature enhancement, but it is not a bug. -- Tim Cross
updates.orgmode.org giving 502 Bad Gateway Error
FYI the updates.orgmode.org page is giving a 502 Bad Gateway error when I try to access it. -- Tim Cross
Re: Q: ox-md does not translate link searches to #bookmarks in markdown [9.4.4 (release_9.4.4 @ /snap/emacs/current/usr/share/emacs/27.2/lisp/org/)]
Phil Marneweck writes: > Hi > > Is this by design? > > I expected to following > > [[file:some-file.org::#some-heading][some text]] > > to translate to this > > [some text](some-file.md#some-heading) > > So in org-md-link I would have thought that the default would be more like > this > > (t (if (not desc) (format "<%s>" path) > (format "[%s](%s%s)" desc path (or (org-element-property :search-option > link) "" > > You would of course have to do some sanity checking on search-option to just > take care of id versus headline searches etc. > I'm not sure if this is by design or because of limitations in the markdown dialect used by org mode (see http://daringfireball.net/projects/markdown) or just a bug. My suspicion, after a quick review of the markdown syntax on the daringfireball site is that search links are not supported. This is one of those examples of the problems arising from a format type which does not have a specification. There are numerous different markdown dialects and org had to select one. Problem is, everyone gets use to a particular dialect and then is often disappointed when org's dialect does not match their expectations. One reason we also have the github flavoured markdown exporter. -- Tim Cross
Re: The fate of ditaa.jar (9.4.5.)
TEC writes: > Tim Cross writes: > >> I also had to install textlive, plantuml, graphviz, taskjuggler, >> ledger, sqlite and many other things. > > Perhaps it would be good to make a table of > > | software | needed for | package name | download page | > > and/or prompt users when an action requiring another executable is > undertaken if it isn't found. Useful additional documentation, assuming it can be maintained, is rarely a bad idea. A table on worg (with maybe a link in the manual) which lists all the org (and contrib) features, external dependencies and link to canonical source would probably be a good idea. I find it hard to remember how I worked out all the dependencies as I adopted org as it was so long ago and I was already a heavy user of many of the tools/dependencies of org. This makes it challenging to appreciate how hard it can be for someone knew to org. On the other hand, if we make it overly easy/automatic, we run the risk of disempowering the user and making them more dependent on assistance from others. Finding the right balance between informative and concise is a challenge. If we provide too much information, it can be overwhelming, too little and it can be confusing. I find it harder to write good documentation than good code! -- Tim Cross
Re: (void-variable timestamp-up) when building an agenda buffer
Alan Schmitt writes: > [[PGP Signed Part:Undecided]] > Hello, > > It seems the problem is deeper than that: I cannot use any code that > uses =org-dlet=… I’m on emacs 27.2. > > I did a quick test with no configuration, so the problem seems to be in > my config, but I’m cursious if this rings a bell for anyone. > > Thanks, > The type of error you appear to be seeing is common with a broken install. In your config, are you installing org from orgmode.org or melpa rather than just using the version bundled with Emacs 27.2? If so, it is likely that you have a 'mixed' install. This can happen if org is loaded when you try to install or update the org version. A common problem is not realising that something in your init file is causing org to be loaded during startup - then when you try to do a package update, you get a broken build. If your not installing org from a package, then it is likely something else in your init file and unfortunately, you may have to do the painful bisecting and debugging to find the cause. -- Tim Cross
Re: The fate of ditaa.jar (9.4.5.)
"Dr. Arne Babenhauserheide" writes: > [[PGP Signed Part:Undecided]] > > Tim Cross writes: >> I agree. As pointed out already, just bundling the jar file is not >> sufficient as you need a java runtime as well. > > Java is available in my distribution, ditaa is not. Removing ditaa from > org means that I have to do manual installation and configuration, while > with ditaa bundled, org-mode can simply note that I need java installed. > I get that. However, this is of course not the case for many users (Mac, Windows). Having to install additional software to realise org functionality is normal for much of org-mode. In fact, I had to install ditta when I first used it because it wasn't bundled. That was not an issue and no surprise given I also had to install textlive, plantuml, graphviz, taskjuggler, ledger, sqlite and many other things. I understand the convenience for users argument. However, I think we also need to consider the maintenance overheads and consistency aspects as well (including dealing with bug reports when it doesn't work). >> If we bundle it, we also need to ensure it is updated if/when new jar >> versions are released. > > We can do that, but we don’t have to. As long as the bundled jar works, > it is much better than no jar. And users can use newer version as they > like by changing the jar-path. > > Note that this isn’t about security, since even if an old version of > ditaa should turn out to be vulnerable, this would still be less > dangerous than a shell-block. Therefore old versions of ditaa are > completely fine. > My thoughts were more about bugs and confusing deprecation warnings which can arise when using an older jar file with a more recent jre. Ultimately, it will fall to whoever steps up to maintain ditta support to decide. -- Tim Cross
Re: Highlighting and Background Colour for Source Code
Christopher Dimech writes: >> Sent: Tuesday, May 11, 2021 at 4:50 PM >> From: "Tim Cross" >> To: emacs-orgmode@gnu.org >> Subject: Re: Highlighting and Background Colour for Source Code >> >> >> Christopher Dimech writes: >> >> > Currently currently handles the highlighting of programming languages >> > through >> > "Code Blocks". Could org-mode have the capability of highlighting a whole >> > buffer >> > with a particular language highlight typeface. >> > >> >> Sorry, I don't quite understand what exactly your asking for? > > Suppose I have an elisp file and I change to org-mode by hitting "M-x > org-mode". > The code does not get highlighted because it is not embedded within org-babel > construct. > > If I have a programming language file with some org-mode heading commands in > it, > and change to org-mode, it would be neat to have language highlighting > available. > OK, now I think I understand. Basically, with full org-mode, this is not possible and I don't think it is actually want you want. Once you switch modes, say from elisp mode to org mode, a lot more changes than just the font locking. Keybindings, various support minor modes and lots more. The 'normal' Emacs way to handle what you are looking for is to add a minor mode. A minor mode is used to add some level of functionality to a buffer without losing the major mode settings. Normally, you only have one major mode associated with a buffer and often that mode is augmented with a bunch of minor modes. For example, outshine mode is a minor mode which adds some org-like functionality to non org-mode buffers. Have a look at https://orgmode.org/worg/org-tutorials/org-outside-org.html I think that might give you some ideas to get you started. You may need a few different minor modes to get the full setup you want and you will likely need to do some customisation of key bindings etc to get things how you like it. -- Tim Cross
Re: Highlighting and Background Colour for Source Code
Christopher Dimech writes: > Currently currently handles the highlighting of programming languages through > "Code Blocks". Could org-mode have the capability of highlighting a whole > buffer > with a particular language highlight typeface. > Sorry, I don't quite understand what exactly your asking for? > I have also seen that within code blocks, the background is uses a colour > that is > different from the background colour of the buffer. Is there a capability > that > the code block background is set to the buffer background colour. I think more often than not, this is determined by the Emacs colour theme your using. I've noticed that some themes colour src block backgrounds differently from the rest of the buffer background and some don't. I noticed this because I do like src blocks to have a different background and some of the themes I like fail to do this, so I had to customize them. You can try customizing your theme. Have a look at M-x list-colors-display to see a list of all the faces being used. Look for ones with your theme name or a name which looks like it might be the background face for src blocks (you can also see the colours and look for that. Once you have made the changes, look at M-x customize-theme and save your changes as a new customized theme. -- Tim Cross
Re: The fate of ditaa.jar (9.4.5.)
Nick Dokos writes: > Jarmo Hurri writes: > >> Greetings. >> >> I pulled the latest master and noticed that contrib has been moved into >> a separate repository. I also cloned this contrib repository, but can >> not find the file >> >> scripts/ditaa.jar >> >> in the repo. In fact, there is no directory scripts in the repo. >> >> The documentation in the latest master states that >> >> Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now >> packaged into the org-contrib repository. >> >> How should I proceed? Should I build this separately >> >> https://github.com/stathissideris/ditaa > > You don't need to build it: it's available in the release area > > https://github.com/stathissideris/ditaa/releases > >> >> or will it still be included into contrib? > > In general, I think it's a better idea to point to the canonical sources > and document how to integrate it into Org mode, than bundle things like > that, but I have no idea how things are going to go. I'm sure there will > be some problems that will need fixing one way or another. I agree. As pointed out already, just bundling the jar file is not sufficient as you need a java runtime as well. If we bundle it, we also need to ensure it is updated if/when new jar versions are released. Better to clearly document where to get the dependencies and point to the appropriate installation instructions. I think we also need to keep in mind that we are currently in a bit of a transition stage with the move to using ELPA and non-gnu ELPA. There will be teething problems needing to be worked through both before and after the transition. -- Tim Cross
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Timothy writes: > Eric S Fraga writes: > >> Is the verse package loaded automatically already? I did not see any >> change in the patch to that aspect and when I export a simple test, the >> package is not loaded. > > Wouldn't it be nice if there was something in-between loading the > kitchen sink and manually adding packages*... [ foreshadowing ;) ] Will be interesting to see what you are 'foreshadowing'. Personally, I find the current options pretty flexible with 'org-latex-classes and support for the macro like placeholders [PACKAGES, DEFAULT_PACKAGES, EXTRA and their negators] and the ability to add packages with LATEX_HEADER and LATEX_HEADER_EXTRA file options. I'm often quite surprised how little people seem to take advantage of 'org-latex-classes and the LATEX_CLASS; file option to define custom document formats. You can easily define an 'empty' class which only includes packages you add with LATEX_HEADER: or LATEX_HEADER_EXTRA for example. It is with 'tweaking' Latex packages I've seen people get into trouble. There can often be some unexpected results when you fail to load or load packages in a different order. Testing is notoriously difficult as you also need a lot of different test input data to get good coverage and adequately test the impact changes to loaded Latex packages causes. Without detailed knowledge of the latex based exporters, it isn't always obvious how/where specific Latex packages are used. It would be important to ensure any mechanism designed to make it easier to customize what packages are loaded that we don't also end up generating more bug rports about broken export formatting. -- Tim Cross
Re: Moving some lisp/ob-*.el files to org-contrib - your advice?
Bastien writes: > Hi all, > > Less code is less bug and less maintainance. So I'm considering > moving these files to the new (unmaintained) org-contrib repo at > https://git.sr.ht/~bzg/org-contrib: > > - ob-abc.el --- Org Babel Functions for ABC > - ob-asymptote.el --- Babel Functions for Asymptote > - ob-coq.el --- Babel Functions for Coq > - ob-ditaa.el --- Babel Functions for ditaa > - ob-ebnf.el --- Babel Functions for EBNF > - ob-hledger.el --- Babel Functions for hledger > - ob-J.el --- Babel Functions for J > - ob-ledger.el --- Babel Functions for Ledger > - ob-lilypond.el --- Babel Functions for Lilypond > - ob-mscgen.el --- Babel Functions for Mscgen > - ob-picolisp.el --- Babel Functions for Picolisp > - ob-vala.el --- Babel functions for Vala evaluation > > I suggest a criterium for keeping ob*.el files in Org could be that > the extension is known by Emacs _or_ that the supported language is > well-established. > +1 on this and the list of proposed languages. Do any of these ob-* files have FSF copyright i.e. author assigned copyright to FSF. Just wondering, given the contrib package will live in non-gnu repo, if this is something we need to be concerned about or not? Strikes me there is nothing written in stone here, so if a language becomes popular and it has maintainers, we can always review the decision to move it 'out' and when justified, move back into core. I think it is good having a clear distinction and the idea that if your using a contrib package, it is 'best effort only' and not guaranteed to work with the most recent org version compared to 'core', which has an expectation it works with most recent org version. -- Tim Cross
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
Jean Louis writes: > * Tim Cross [2021-05-02 11:52]: >> >> Jean Louis writes: >> >> > * Bastien [2021-05-02 09:10]: >> >> Various discussions convinced me that `org-adapt-indentation' should >> >> be nil by default. >> >> >> >> With `electric-indent-mode' being activated by default in Emacs, the >> >> current behavior is that RET after a headline moves the point below >> >> the beginning of this headline, not the beginning of the line, which >> >> might surprise users. >> >> >> >> Indentation is quite sensitive: what do you think of setting a new >> >> default value of nil for `org-adapt-indentation' in Org 9.5? >> > >> > Yes, it should be nil just as it was in beginning. >> > >> > But there is one problem that I encountered since that was introduced, >> > namely I do like properties being indented under the first letter of >> > heading or on 3rd place. >> > >> > Like this below, however, C-c C-x p will create properties indented >> > only if org-adapt-indentation is t >> > >> > * Heading >> > :PROPERTIES: >> > :ARCHIVE: new >> > :END: >> > >> > But if org-adapt-indentation is nil, it will be like: >> > >> > * Heading >> > :PROPERTIES: >> > :ARCHIVE: new >> > :END: >> > >> > and I remember that behavior before the introduced change was that >> > properties were intended, which does look nicer for properties. >> > >> > But I definitely do not prefer cursor to come indentend after writing a >> > header like: >> > >> > * Heading >> > C >> > ursor on C >> > >> > >> >> Sounds like you want the 'headline-data value for this variable. Please >> check the documentation. > > If I set `org-adapt-indent' to 'headline-data, I get that same > behavior that after pressing ENTER on headline line, position becomes > indentend. So it does not make it right. > > My favour was the behaviour how it was before introduction of > indentation change: > > - after headline, cursors went to beginning of line; I find it > usable, as that is where I write text. > > - if I ever wanted to enter properties with C-c C-x p, those were > automatically > indented, > > But OK I can personally get used, especially that I these months avoid > using any properties in Org mode. > > > "GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version > 1.17.4, Xaw3d scroll bars) > of 2021-05-02" This is exactly what headline-data does. I suspect what your running into is electric-indent-mode and you need to turn it off to get the behaviour you want. So set org-adapt-indentation to hedline-data and turn off electric-indent-mode and you will get the indentation style you are after. The issue here isn't that org-adapt-indentation changed. The issue is that the effect of this setting changed when org mode was updated to be consistent with the rest of emacs and honour electric-indent-mode, which is enabled by default in emacs. Previously, org ignored this wider Emacs default setting. The poll is to decide if we should change this long standing default due to the side effects from enabling electric-indent-mode. Enabling electric-indent-mode was done to make org mode consistent with other Emacs modes, so disabling it by default would be inconsistent with Emacs defaults. I'm not sure the full impact of enabling electric-indent-mode was realised at the time. With org, I think the general principal is to try and have defaults set to the 'least surprising' value, particularly for new users. -- Tim Cross
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
Jean Louis writes: > * Bastien [2021-05-02 09:10]: >> Various discussions convinced me that `org-adapt-indentation' should >> be nil by default. >> >> With `electric-indent-mode' being activated by default in Emacs, the >> current behavior is that RET after a headline moves the point below >> the beginning of this headline, not the beginning of the line, which >> might surprise users. >> >> Indentation is quite sensitive: what do you think of setting a new >> default value of nil for `org-adapt-indentation' in Org 9.5? > > Yes, it should be nil just as it was in beginning. > > But there is one problem that I encountered since that was introduced, > namely I do like properties being indented under the first letter of > heading or on 3rd place. > > Like this below, however, C-c C-x p will create properties indented > only if org-adapt-indentation is t > > * Heading > :PROPERTIES: > :ARCHIVE: new > :END: > > But if org-adapt-indentation is nil, it will be like: > > * Heading > :PROPERTIES: > :ARCHIVE: new > :END: > > and I remember that behavior before the introduced change was that > properties were intended, which does look nicer for properties. > > But I definitely do not prefer cursor to come indentend after writing a > header like: > > * Heading > C > ursor on C > > Sounds like you want the 'headline-data value for this variable. Please check the documentation. Note that there was a bug with this setting which has recently be fixed. So if you tried it previously and found it didn't quite work correctly, try it again in current maint version.
Re: [POLL] Breaking change: removing `org-speed-commands-user'
Bastien writes: > As discussed in https://orgmode.org/list/87v9hzzhrn@gmail.com the > proposal is to allow users to customize *all* speed keys, not just > some of them through `org-speed-commands-user'. > > By merging `org-speed-commands-default' and `org-speed-commands-user' > into a single `org-speed-commands' option, we make this possible, but > this change will ignore people's `org-speed-commands-user' config, so > this is a breaking change. > > Do you think this change could be too sensitive for users? I don't really have a position on this. However, my 'gut' tells me that anyone who has used org-speed-commands-user will be able to adapt to the change without too much inconvenience. A clear NEWS entry will help. -- Tim Cross
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
Bastien writes: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the beginning of this headline, not the beginning of the line, which > might surprise users. > > Indentation is quite sensitive: what do you think of setting a new > default value of nil for `org-adapt-indentation' in Org 9.5? +1. I think it will be less surprising for users and those who want that type of indentation can easily enable it. -- Tim Cross
Re: Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)
What about running emacs -Q and then opening the org file. Does the syntax highlighting work then? Dominick Samperi writes: > Changing the suffix to .org does not help. Still the first file opened > does not colorize. > I first observed this problem about six months ago (and have been > using a function > key to fix with 'org-mode-restart). > > The problem does not appear on a new desktop, running > the same version of Emacs, same version of org-mode, and same .emacs.d. > > The only notable difference between the new machine and the older machines > where the problem occurs is that the newer machine has an solid state drive, > whereas the other machines have conventional hard drives. > > On Fri, Apr 30, 2021 at 8:51 PM Samuel Wales wrote: >> >> what if .org? >> >> On 4/30/21, Dominick Samperi wrote: >> > The first org mode file opened (.txt suffix) is not colorized. To force >> > colorize I use 'org-mode-restart. Subsequently opened txt files are >> > properly colorized. This happens under Windows 10 using Emacs 27.1 and >> > 27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu >> > Linux. >> > >> > Oddly, the problem does not appear on my new desktop (Lenovo). It >> > happens on my ASUS laptop. I'm using the same version of org-mode and >> > Emacs on both machines. >> > >> > I copied .emacs.d from the desktop to the laptop >> > to be sure the environments are the same, and I installed Emacs 27.1 >> > and 27.2 on the laptop. The colorize problem occurs on the laptop no >> > matter the environment. It also occurred with my old desktop. >> > >> > >> >> >> -- >> The Kafka Pandemic >> >> Please learn what misopathy is. >> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html -- Tim Cross
Re: stability of toc links
Nicolas Goaziou writes: > Hello, > > Samuel Loury writes: > >> The publish feature only means exporting several files at once. > > You can publish a single file, too. It makes sense when a file is always > exported to the same location, possibly with the same configuration. > >> IIUC, what was written was that when using the publish feature, the exported >> html pages will be coherent and a link in one document pointing to >> another document of the same publish call won't be broken. >> >> But IIUC, publishing the whole stuff again will result in totally >> different links. They will still be coherent and no broken link from one >> document of the whole to another. But a browser bookmark pointing the >> published lot the first time won't work with the same lot the second >> time. >> >> Did I understand correctly? > > That's correct. > > Org provides a mechanism, called `org-export-get-reference', for > creating internal references, which relies on randomness + cache. But it > explicitly removes internal references not actually used from there (see > `org-publish--store-crossrefs'). Keeping those references instead would > make all links stable, of course. > Given this is not the first time we have seen a similar discussion regarding link stability for external references, perhaps it would be good to summarise and put it on worg for reference? First attempt - let me know if I've got it close! - If you need stability in TOC links between generated versions, use Org's publish facility rather than plain HTML export. - Publish can be used to publish a single file. - 'something' in the published output needs to reference the TOC links to ensure consistency. HTML export lacks the internal caching/tracking necessary to have internal link consistency across exported versions. Adding such capability would significantly complicate the HTML export code base. This is hard to justify when this export facility is also used for things like HTML fragments and because internal link stability is only required in a sub-set of use cases. The org publish facility already includes the necessary internal facilities to support internal link consistency across published versions. You can use publish to publish a single file. Currently, the internal links need to be referenced/used in order to ensure consistency across published versions. If stability of TOC links across versions is required, using publish is the preferred mechanism. If we would want to make it easier for the user to create published pages with consistent internal TOC links, we would be better off enhancing the publish mechanism rather than trying to add such facilities to the HTML export function. -- Tim Cross
Re: Big problem: org agenda freezes my process
torys.ander...@gmail.com (Tory S. Anderson) writes: > I've been trying to debug a nearly show-stopping issue for a few weeks now; > the > next step is a more thorough bisection of my setup, but I wanted to send this > in > case anyone else experiences this or already knows the solution. > > Lately, when I try to view an orgmode agenda it seems that two things make it > cause my emacs CPU threat to spin to max and freeze up, which is a huge > problem > since I'm an exwm user and live in my agenda view. As far as I've been able to > tell, when an item from today is clocked into multiple times in the same day, > it > prompts most agenda actions to result in a freeze and some kind of loop that > is > binding up my system. It has some gaps, so if I spam C-g I will eventually, > usually, escape given 30 seconds to 2 minutes. > > I first ran into this problem thinking it was because I had an entry with a > "+1d" note on it, so it would always show up; but inconsistent results led me > to > the more precise discovery that it's apparently when it is logged in to > multiple > times in the day AND when it is shown with =(org-agenda-show-log t)=, which I > had on my default. At its worst, even moving the cursor in the agenda buffer > would trigger the freezing, let alone actually clocking in/out of anything. > However, when I am not showing the log, it seems like it's ok. I've tried > =toggle-debug-on-quit" but I don't recognize anything in the stack trace that > actually tells me what it is doing when it spins to a halt. > > I'm currently on org mode version 9.3.7. I've tried with different versions > but > without a change in behavior. This, combined with the fact that the issues > seem > to have begun in the past month, indicates that it probably isn't orgmode > itself > causing this issue, but I haven't located what it IS yet. If anyone has ideas > on > how to debug this without a bisection, or an has dealt with this before, I'm > more than eager to hear it; in the meanwhile, I'll perform a more thorough > bisection of my init file as time permits. > Does the problem also occur if your not running exwm? I stopped using exwm for a very similar reason i.e. every now and then, I would try to do something and the CPU load would peak, everything would become unresponsive and either I had to wait (for minutes) or start killing things to try and get back control. Probably first thing to do is see if you can reproduce the issue without exwm. If you can, the next thing to do would be to come up with a minimal org config and recipe to reproduce as this will allow others here to try and help debug the issue. BTW I gave up on exwm as I found a few issues and found it often got slow. I switched to Stumpwm (Common Lisp WM), which I found great as I was then able to have a window manager which worked like Emacs, could have same keyboard interface and could be modified 'on the fly' with lisp. I only stopped using it when I started experimenting with Wayland. -- Tim Cross
Re: async export and then do something with file
Matt Price writes: > Hi everyone, > > I am wondering if I can perform and export asynchronously and then, without > tying up emacs, wait around for the export to finish and then perform > some other task, like upload the file to a server. Has anyone tried this > before? I think perhaps the easiest thing to do would be to use async.el or > some similar third-party, but I can't tell what the preferred method is. I > would love osme guidance! > The asynchronous export should be possible and I've seen some proposed patches for this discussed recently. The challenge is your second part. In other languages, you could use something like a 'future' (Clojure) or a Promise (Javascript), but I'm not 100% sure with Elisp. I suspect you would need to create the async process and use the :sentinal option to pass in a process sentinal function, which is essentially a function that will run whenever the status of a process changes. The sentinal would need to watch for a status change which indicates the process has finished and then call whatever your post-export actions are. HTH Tim -- Tim Cross
Re: [PATCH] ol.el: Fix confusing variable name
"Aaron L. Zeng" writes: > * ol.el (org-link--open-help): Fix a confusing variable name. No > behavior changes. > > TINYCHANGE > --- > lisp/ol.el | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lisp/ol.el b/lisp/ol.el > index 62ea6d2bc..617223cb5 100644 > --- a/lisp/ol.el > +++ b/lisp/ol.el > @@ -1325,8 +1325,8 @@ PATH is the sexp to evaluate, as a string." >"Open a \"help\" type link. > PATH is a symbol name, as a string." >(pcase (intern path) > -((and (pred fboundp) variable) (describe-function variable)) > -((and (pred boundp) function) (describe-variable function)) > +((and (pred fboundp) function) (describe-function function)) > +((and (pred boundp) variable) (describe-variable variable)) > (name (user-error "Unknown function or variable: %s" name > > (defun org-link--store-help () Hi Aaron, thanks for the patch. It looks straight forward, does seem to be less confusing and in-line with the intention of the code and is only a tiny change, so I think it should be applied. Tim -- Tim Cross
Re: stability of toc links
Samuel Wales writes: > hi trs, > > thank you. i can imagine that could be useful for a lot of users, but > for me, as i said in my op, "short of adding custom id > or id to everything" --- i didn't want to add custom id. i will try > to clarify why in case it is useful. > > in addition to performance, and clutter, there is a semantic issue in > my case. typically, if i see that there is a properties drawer, i > know that it is there because of an org id or a manual custom id or a > special purpose of my own. if i know it, i don't need to open it. > > however, adding custom id automatically for so many links means that > there is a new meaning for properties drawers [namely, for stable > linking done automatically]. i would have to open the drawer to > determine if i personally wanted something there. > > and thus, the extra properties drawers would cause effort and > distraction in this semantic sense, where i would be opening them > because i would be thinking "did i really have a reason to add a > properties drawer here? i don't recall so... better check" > > also, there is the issue that if i decide not to include something in > the toc, it will still have a properties drawer lying around. > > > in the op, i was not looking for a solution for one blog post, but > thought a general solution for all org users might be possible. > > and this would likely be at the html level, probably by using e.g. > header text, fuzzy or strict hashes, or a combination. > > when tec posted his html level code, it looked like the right type of > solution to the problem. i have not tried it, however. > > i hope that clarifies. tec said he originally did not get much > interest. then there was interest on this thread. then nothing. > A question to help me understand this issue. If I understand correctly, exporting to HTML does not guarantee stability of TOC links. If you export as HTML, send someone a link from the toc and then re-export the document, the link will possibly be broken. Essentially, exporting to HTML has no guarantee of stability in toc links. However, if you use publish instead of exporting to HTML, there is a guarantee of stability in toc links. When publishing a second time, the link will be consistent and still valid. If you want stability in toc links, why not use publish instead of export to html? Is there some difference between the two mechanisms which prevents you from being able to use publish instead to get stable links?
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Timothy writes: > Colin Baxter writes: > >> Debian 9.13 may be old but updates are still made available. While >> Debian supports the os-version and therefore by implication emacs-24, I >> feel org-mode shouldn't deliberately break that support. > > I have to admit, I'm not sure why Org support should stretch so far > back. If it was a standalone thing, I could see it, but as it's > vendored with Emacs I'm not sure why we don't just do stable Emacs - 1 > (i.e. 26.3 ATM). I don't think we can set an absolute limit. It really depends on what has changed in Emacs. For example, if Emacs adds some feature or capability which really improves org performance, we might decide to drop older versions sooner to try and get everyone onto a more performant version. On the other hand, if new versions of Emacs don't really add any significantly beneficial changes, we might continue to support older versions for longer. We also need to consider changes in the Emacs release cycle. In recent years, this seems to have been faster than it use to be. Emacs 24.5 was released in April 2015, which is only 6 years ago. Emacs 25.3 was less than 4 years ago. People do tend to upgrade their hardware every 3 - 5 years and it can take distributions 2+ years to update the version they are shipping, so in general, we probably do need to support major versions for up to 5 or so years after release. However, this also needs to consider the adding of lexical binding as a significant enhancement. The next 'big one' is likely to be native compilation support for *.el files. I do think it is probably time to drop support for Emacs 24 in the next major release. However, we cannot drop it 'mid release'. -- Tim Cross
Re: How to use `open` to handle `message:*` links on macOS
Tim Visher writes:
> Hi Diego and Alexander,
>
> Thanks for the tips here. I finally got around to trying them out. Here's
> what I ended up with and it's working perfectly.
>
> (defun timvisher-org-link-mac-mail-open-link
> (mid _)
> (start-process "open-link" nil "open" (format "message://%%3C%s%%3E"
> mid)))
>
> (defun timvisher-org-link-mac-mail-add-message-links
> ()
> (org-link-set-parameters
>"message" :follow #'timvisher-org-link-mac-mail-open-link))
>
> (eval-after-load 'org
> '(timvisher-org-link-mac-mail-add-message-links))
>
> Pairing that with my org-capture TODO Current Mail Template is a dream come
> true. :)
>
> (defun timvisher-org-current-mail-get-selected-message-subject
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get subject of item 1 of (selection
> as list)")
> (buffer-substring-no-properties (point-min) (- (point-max) 1
>
> (defun timvisher-org-current-mail-get-selected-message-id
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get message id of item 1 of
> (selection as list)")
> (browse-url-url-encode-chars
> (buffer-substring-no-properties (point-min) (- (point-max) 1))
> "[/]")))
>
> (defun timvisher-org-current-mail-get-link-string
> ()
> (let ((subject (timvisher-org-current-mail-get-selected-message-subject))
> (message-id (timvisher-org-current-mail-get-selected-message-id)))
> (org-link-make-string (format "message:%s" message-id)
> subject)))
>
> (defun timvisher-org-current-mail-get-body-quote-template-element
> ()
> (let ((body (setq body (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get content of item 1 of
> (selection as list)")
> (buffer-substring-no-properties (point-min) (- (point-max)
> 1))
> (format "
>
> #+begin_quote
> %s
> #+end_quote"
> (string-join
> (seq-reduce
> (lambda (acc next)
> (if (string= next (or (car (last acc)) ""))
> acc
> (append acc (list next
> (mapcar (lambda (string)
> (let ((string (string-trim string)))
> (if (string= "" string)
> string
> (format " %s" string
> (split-string body "\n"))
> '())
> "\n"
>
> (setq org-capture-templates
> '(…
> ("twcm" "TODO Work Current Mail" entry
> (file+headline "~/Dropbox/todo/work.org" "Inbox")
> "* TODO %(timvisher-org-current-mail-get-link-string)
>
> %U%(timvisher-org-current-mail-get-body-quote-template-element)" :prepend t
> :immediate-finish t)
> …))
>
> Thanks so much! :)
I think this would be great content to add to the worg site. Would you
be willing to add this, plus a short outline of the issue you needed to
resolve so that others might benefit from your experience?
--
Tim Cross
Re: [PATCH] Bug: fragile org refile cache
Ihor Radchenko writes: > Samuel Wales writes: > >> would it be more useful if it automaticaly generated the cache instead >> of telling you to runt he command to do so? > > I think so. To be frank, I do not understand the reason why it is not > done by default. > >> if a solid, perhaps unified, cache existed, would org-id use it too? > > Sure. Why not? I imagine such cache can store the following info: > > org files in system -> per-file cache -> per-heading cache -> ... > I suspect the reason it is not done automatically is that getting that right for all use cases is very hard to do without adding adverse impact to performance. A cache which is marked as 'dirty' too often results in too frequent cache refresh operations, but at the same time, determining what changes in an org file actually invalidate the cache can be a process intensive operation. Allowing the user to force cache refresh when needed is likely a reasonable compromise. I recall having a lot of trouble getting org-refile to work well for me. I use it a lot, but it was so long ago, I don't recall how I got to my final configuration (I think I may have modified my workflow to work better with what I was able to get working reasonably reliably and efficiently). I now tend to refile to a fairly static set of paths, so all works OK. Sorry I cannot provide anything more substantial. I do understand your frustration, but not sure what the right fix is. I can see having a cache which is automatically refreshed when necessary will be problematic to get working for all use cases. Having the ability to turn automatic refresh on/off and having the ability to manually force a refresh will likely always be required. -- Tim Cross
Re: [WDYT, mini] key h in agenda for quick help
Bastien writes: > Timothy writes: > >> Great to hear! I think this would probably be developed as a branch like >> wip-cite-new > > Yes. > >> , and it would need transient to be installed (via ELPA?) on >> Emacs <28, but I think it has the potential to both: >> - Improve the user experience, and >> - Remove Org's own home-cooked transient-ish interfaces, >>so leave us with less code to watch over > > Yes, exactly. Also there is plan to include Transient in Emacs core, > so this makes this move even more appealing: > > https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00944.html I would also suggest that if we were going to have a 'help' key, rather than describe mode, it might be better to link to the info manual (you could just link to the agenda section of the manual). I've rarely found describe mode to be terribly useful (there are exceptions). However, I have used modes which have bound a help key to a section in the info manual and I've found that much more useful. The depth of information is usually better (what people looking for help probably want) and once your in the info pages, moving to cross references and other possibly relevant sections is very easy. I also think adding transient mode would be beneficial in a number of areas of org. In addition to reducing code maintenance, it would increase consistency with other Emacs modes etc. -- Tim Cross
Re: Concerns about community contributor support
Bastien writes: > Hi Tim, > > thank you very much for your detailed answer. > > Tim Cross writes: > >> Yes, but with some caveats. > > Thank you! > >> For these reasons, I'm probably not the best person to assist with the >> review and guidance for patches aimed at adding/extending functionality. > > The role of a "contributor steward" is to address the issues Timothy > originally raised about contributors not receiving answers when they > take the time to send a patch or a bug report, it is not about making > technical decisions. Of course, your advice as a long-time user on > these decisions is always very welcome. > >> However, I would be happy to >> >> - Assist in trying to reproduce and confirm bugs >> - Assist in extracting additional information and providing >> guidance/clarification for bug reports >> - Assist with documentation >> - Provide some guidance on patches, particularly bug fixes. > > That's exactly what is badly needed to discharge core maintainers from > routine tasks and to let them focus on technical stuff. > > This has basically been my role in my early years of maintainership: > making sure to keep this list as welcoming as possible, to continue to > attract new people with new ideas (and new bug report). This is a > somewhat undervalued role, but a deeply necessary one -- so again, > thanks for helping here. > >> My time availability can vary greatly depending on work. > > That's no problem. We have a team of Tim's :) > >> Also, as a >> blind user, my ability to reproduce bugs can sometimes be hampered by >> the necessity of running Emacspeak in conjunction with org mode (they >> can sometimes interfere with each other). However, apart from that, more >> than happy to help where I can, so if your happy, sign me up! > > If the task becomes too much for you, you can always say that you > won't be available for a while. > > Thanks! OK, consider me 'singed up". Today I will see if I can re-jig my mail system to make it easier to track and respond. As Timothy seems to be doing a fine job 'catching up' with what is already on updates.orgmode, I'll leave that alone and will focus on responding to new bug reports, patches etc which come through the list. I'll also setup a 'clean' virtual image so that I have a vanilla, clean Emacs config I can use for evaluating/reproducing bugs (current emacs stable 27.2). . What is our position with bugs which can only be reproduced in the current development version of Emacs? I'd expect we track them, but focus more on Emacs stable given that dev is a moving target and any bugs may be resolved by later changes in Emacs? Finally, is it also necessary to monitor org bugs reported to the emacs bug tracker or are they sent on to the emacs-orgmode list via some other process? (I currently do monitor emacs-devel but not the bug tracker). -- Tim Cross
Re: Concerns about community contributor support
Bastien writes: > Hi Tim, > > Tim Cross writes: > >> I agree and am willing to help if I can. > > Great! Would you agree to be "officially" appointed to this role, > with Timothy? I put quotes on "officially": when moving toward the > new maintainance team, I'd like to list maintainers and their roles, > including the "contributor stewards". If you prefer not to publicly > appear but still work on this, that's perfectly okay too, of course. > Yes, but with some caveats. As may have already been picked up by some, I'm extremely conservative regarding the addition of new features and enhancements to org mode. I have considerable concern regarding both the performance and maintainability of the mode and worry about the increasing complexity in options, performance impact from increasingly complex font locking just to have more 'eye candy' at the cost of sluggish behaviour for large files and striking the right balance between the 'richness' of org file functionality and consistency in exporters or source block handling. I really would hate to see org mode end up like MS word with 90% of users only using 10% of the functionality with 90% unused functionality just becoming a burden to maintainers. For these reasons, I'm probably not the best person to assist with the review and guidance for patches aimed at adding/extending functionality. However, I would be happy to - Assist in trying to reproduce and confirm bugs - Assist in extracting additional information and providing guidance/clarification for bug reports - Assist with documentation - Provide some guidance on patches, particularly bug fixes. My time availability can vary greatly depending on work. Also, as a blind user, my ability to reproduce bugs can sometimes be hampered by the necessity of running Emacspeak in conjunction with org mode (they can sometimes interfere with each other). However, apart from that, more than happy to help where I can, so if your happy, sign me up! >> One thing I do think would be helpful, particularly for documentation on >> maintenance of org mode, would be a clear outline of project goals and >> philosophy. Some of this would be 'concrete' statements, such as the >> minimum supported Emacs version, size of contribution and requirements >> to sign FSF copyright assignment paperwork, inclusion of acceptance >> tests, documentation, maintenance of backwards compatibility, API >> stability etc. Other parts would be more 'fuzzy' guidelines, such as >> avoiding complexity and 'blow out' in options/arguments, balancing >> features and maintainability, what should become part of org core and >> what should be in contributions or a completely separate add on package >> and what guidelines are used in assessing extensions/enhancements for >> inclusion etc. >> >> It will be challenging to define this as there are a wide diversity of >> views and priorities amongst the community. However, I think it would be >> an overall benefit for both the community and on-going development of >> org mode. >> >> While I would be happy to help with this, I think the initial content at >> least needs to come from current key maintainers and if possible, some >> input from Carsten would be good. > > Fully agreed. Input from old timers will be precious, too. I will > work on this as we are transitioning to the new maintainance team. > > Also, I commit to achieve this transition by August, 1st. This may > seem a bit far away, but there is really no rush here, and I want to > ensure we have a smooth transition. All your efforts greatly appreciated. It is a lot of effort and herding cats often takes a lot longer then anticipated! -- Tim Cross
Re: Concerns about community contributor support
Bastien writes: > Dear Timothy, > > thanks for raising this points so carefully, they are important. > > I see three distinct problems: > > 1. The lack of response and/or follow-up when people contribute by >sending bug reports or patches on the list. > > 2. The lack of maintainance on documenting the contribution process >and the correct expectations for future contributors. > > 3. The inherent difficulty to move the Org codebase forward. > > I won't comment on (3). For (1) and (2), I suggest appointing a > "contributor steward" with these responsibilities: > > 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.) > 2. Maintain the documentation for contributors. > 3. Help contributors enhancing their patches. > 4. Try to reproduce bugs (and confirm them for updates.orgmode.org) > 5. Make sure patch contributors are not left with no answer. > > You started (1), which is really appreciated. > > Tim and others mentioned (2), and that's certainly needed too. > > (3) has historically been the role of the maintainer and of the core > contributors, but helping with this is very welcome: knowing the doc > at https://orgmode.org/worg/org-contribute.html by heart, educating > contributors on the commit messages, etc. This all helps. > > (4) is perhaps the most daunting task: I even think we could have > someone only dedicated to this very important task. Just count the > number of times Nicolas says "I cannot reproduce this." Each time, > there is a real bug that is *not* fixed... > > (5) is not about systematically welcome patch submitters with a > message (that would be annoying) but to monitor updates.orgmode.org > and decide what to do with a patch that didn't receive feedback: > either say thanks and ping the list for why you think the patch > deserves more attention, or thanks and dismiss the patch, or another > answer. > > What do you think? Would you be willing to take this role? > > If not, that's perfectly okay, I'll send a call for help. > Hi Bastien et. al. I agree and am willing to help if I can. One thing I do think would be helpful, particularly for documentation on maintenance of org mode, would be a clear outline of project goals and philosophy. Some of this would be 'concrete' statements, such as the minimum supported Emacs version, size of contribution and requirements to sign FSF copyright assignment paperwork, inclusion of acceptance tests, documentation, maintenance of backwards compatibility, API stability etc. Other parts would be more 'fuzzy' guidelines, such as avoiding complexity and 'blow out' in options/arguments, balancing features and maintainability, what should become part of org core and what should be in contributions or a completely separate add on package and what guidelines are used in assessing extensions/enhancements for inclusion etc. It will be challenging to define this as there are a wide diversity of views and priorities amongst the community. However, I think it would be an overall benefit for both the community and on-going development of org mode. While I would be happy to help with this, I think the initial content at least needs to come from current key maintainers and if possible, some input from Carsten would be good. -- Tim Cross
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Anthony Carrico writes: > On 4/20/21 12:55 AM, Tim Cross wrote: >> The error from libreJS is correct - public domain is not a valid >> license. > > Everyone is licensed to use public domain works (except to obtain a copyright > on > them). I think you mean that libreJS is working by design when it blocks them, > which is apparently the case. What I meant is that Public Domain is not a license - it means the content cannot be copyrighted, which effectively means it is compatible with a free license, but the content lacks a formal license. The CCO also puts the content into the public domain, but also includes a formal license as a fallback, which can be beneficial in some jurisdictions. > >> As this is a GNU project and correct licensing is important... > > Emacs is a GNU project, but org-mode export is a document processor, and the > goal here was to avoid including licensed content in an Author's exported > documents. Appreciate the intention. Perhaps we need to clarify what exactly we are licensing here - the content or the Javascript added to the content to facilitate presentation. The content should be covered by whatever license the author prefers. The Javascript on the other hand, if generated by Org, should probably be covered by the GPL as it is 'created' by org. If the document author has not written the Javascript, I'm not sure they have the right to set the license on it, especially if it was generated as part of software covered by the GPL. The CC0 is appropriate for content which is in the public domain. It is essentially equivalent to public domain, but with a fallback trivial free license, which can be a useful addition in some jurisdictions. However, it is less suitable for software (i.e. Javascript) because it lacks any protection from patent trolling. -- Tim Cross
Re: Concerns about community contributor support
ian martins writes: > On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: > > Responding to essentially just flag you have seen the patch message > really only adds noise and may even 'drown out' those responses which > add real 'value' to any discussion. I also doubt that asking people to > do this would actually result in any actual change of behaviour by > subscribers. > > Timothy said there were 25 patches without response and the list goes back > six months, so we're only talking about 50 emails per year. That assumes there is a single 'owner' who accepts the responsibility to respond to every patch submitted. That isn't the situation with open source projects where people volunteer their time. Having someone respond to the author of a patch and provide some meaningful feedback would be great, but I don't see how that can happen in a project which is already stretched and with limited resources. There has already been multiple messages requesting additional help and for volunteers willing to put in the time needed to maintain parts of org mode. Adding to that workload isn't going to help. responses to patches really need to come from community members who are sufficiently interested in the patch to examine it or make comment on how useful they feel it would be. To some extent, if someone submits a patch and hears nothing, either they have failed to clearly explain what the patch does (and therefore did not tweak any interest) or it is a patch to introduce functionality which is of low interest to community participants. I think you can classify patches into 3 basic types - 1. Bug fixes. Patches which do not change functionality, but address bugs and performance bottlenecks in existing features. At present, this type of patch seems to get applied fairly quickly. 2. Patches which extend existing functionality. This type of patch requires significant consideration and evaluation. They can be time consuming to assess and a call needs to be made as to whether the additional complexity such enhancements add can justify the increased maintenance overhead such enhancements introduce. This is particularly challenging with org mode because org supports a diverse and sometimes complex range of workflows. Verifying an enhancement will not have adverse impact on some of these workflows is difficult and time consuming. Even apparently simple and straight-forward changes can have unexpected impact - consider for example the enhancement to support electric indent mode. This seemed fairly straight-forward and was a change which made org mode aligned with other Emacs modes and helps improve consistency withing Emacs across modes. However, it has had some adverse impact and caused some confusion because of how it interacts with existing org behaviour and configuration settings, such as with org indentation behaviour. 3. Patches which introduce new functionality. This type of patch also requires considerable resources to evaluate and adds to overall maintenance load. It is one thing to write an extension, but a completely different thing to maintain it over time. Even assessing the real demand for such extensions is challenging and time consuming and represents a significant demand on volunteers time. Asking volunteers to respond to patches of type 2 and 3 within some nominated time period is probably unreasonable. It also runs the danger of discouraging people from stepping up to volunteer to help maintain parts of org. This is why I think a better approach would be to provide more details and explanation on patch submission which can help set the expectations for the patch submitter and provide some guidance on what to do if they want to encourage/ask for feedback. This is also part of why I think patches of type 3 and possibly many type 2 patches should be initially released as separate 'add on' packages and made available via gitlab/github/melpa by the individual responsible for writing the patch. The author would then be able to see how useful/popular/desired their patch is, be able to ask for feedback and be able to get issue/bug reports to refine their work. This could be viewed as an 'incubator' like process. If such an enhancement/extension turns out to be very popular or demanded by the org community, it could then be migrated into either org core or the proposed org contrib package (by which time, it would likely be more mature and stable than it was when initially developed). It also has the advantage of not impacting existing org users who are not interested in the enhancement/extension. For an org user, little is more frustrating than an enhancement/extension which results in them having to either modify their workflow or update their often large repository of org documents. If we were to provide a detailed explanation on how to contribute bug fixes, enhancements and extensions on the worg site, contributors will know what is required, will be able to s
Re: Using backticks for the inline code delimeter?
John Kitchin writes: >> The challenge can be in identifying the most appropriate key bindings. >> This can depend on the platform you use as well. When I was only using >> Linux, I used the 'super' key for this and it was great. However, when I >> also started using a mac, I had to define a new scheme. It can take a >> bit of work to setup initially, but I think it is worth the effort. I >> now have the same bindings in multiple modes, so regardless of whether >> I'm writing markdown, org, html, rich text, etc, I just hit the same key >> bindings to mark content as code, bold, italic, etc. > > On a Mac, you might find these useful. I don't use the right command and > option keys, so I redefine them as hyper and super. they are right under > my thumb, and convenient. > > (setq mac-right-command-modifier 'hyper) > (setq mac-right-option-modifier 'super) That is useful information. The 'hyper key is certainly overlooked and provides a very useful mechanism to create a whole set of new, possibly short, key bindings. I like the idea of re-tasking the right hand command/option keys as it is very rare I use them (command/option is most used via left hand side for me). -- Tim Cross
Re: Concerns about community contributor support
"Bruce D'Arcus" writes: > I've been thinking about this general issue over the past year, as > it's a common problem regardless of project, hosting platform, etc. > > I do agree in general that situations where submission of ideas and > patches languish without attention are a problem. > > But while I don't think there are any easy answers, I do think clarity > upfront can help. > > For example, perhaps there needs to be a prominent statement early on > this page, which states upfront how the community vets new ideas or > patches, what someone who submits such can expect, including in terms > of timeline, and how to interpret lack of response? > > https://orgmode.org/worg/org-contribute.html > Yes, we can certainly help manage expectations, which I think is going to be more effective. At the very least, it is a good place to start. Perhaps it would be worthwhile if everyone interested in this issue have a look at what is on worg about contributing and propose some additions/updates? Responding to essentially just flag you have seen the patch message really only adds noise and may even 'drown out' those responses which add real 'value' to any discussion. I also doubt that asking people to do this would actually result in any actual change of behaviour by subscribers. -- Tim Cross
Re: Concerns about community contributor support
Eric S Fraga writes: > On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote: >> 1. A patch looks useful to me, but I feel I don't know if it's a good > > [...] > >>"Thanks for submitting this. I'd use it. Hopefully a maintainer >>will take a look." > > Ian, > > I think you will find that a few of us do post answers like this every > now and again. I know that I do. > > The lack of answers to cases 2 & 3 are essentially showing a lack of > interest which is basically an (implicit) answer as well. It may seem > dismissive but, given the volume of email some of us have to deal with > in our day job, it's just reality, I would suggest, without it meaning > to be judgemental in any way. > > (now back to my day job ;-)) +1. If a patch is of interest to me, I usually respond. I don't respond to patches which are of no interest or which I don't understand. -- Tim Cross
Re: Concerns about community contributor support
Jean Louis writes: > It should be clear that more maintainers and developers with direct > access are needed for patches to be applied timely. > > I am sure that those on emacs-devel mailing list, Emacs developers, > they could help on that, but maybe some of them do not observe this > mailing list. > > Number of not applied patches does not seem to be that large. > > Project leader shall have his team and delegate them to other > developers. > > This situation badly contradicts to Org mode purposes which is meant > to manage patches. > > Maybe there shall be a published list of developers and project > managers, so that this type of communication may be addressd > properly. As now original poster explained the problem, but I did not > see response from none of pushers, I mean those who have repository > access. > > So how many people are there who have repository access? > > Who is not busy but willing to apply at least 1-5 patches pending? > I'm not sure I agree with this analysis. As Timothy mentioned a few times, the issue is NOT about the time taken to apply patches. It is about a lack of feedback regarding the state of the patches. Increasing the number of people with the ability to apply patches/changes to the repository is unlikely to be helpful. It could in fact have the reverse result, leading to increased inconsistency and reduced stability. I find bug fixes are applied very quickly. Enhancements and extensions are introduced more conservatively, but I think that is a positive rather than negative aspect of org development. For many users, org is already very feature rich/complete. -- Tim Cross
Re: Using backticks for the inline code delimeter?
Matt Price writes: > On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, wrote: > > autofrettage writes: > > > Quick and Dirty: Bind key '`' to ~ in Emacs? > > > > (I guess it is clear I haven't thought about the consequences.) > > You can add that just to the Org-mode map. That wouldn't be too bad, > there's always C-q. > > Is it possible to bind a key in org-mode but bind it back to another > character if you're in a special environment, eg a code block? That would > probably be my preference. So "`" inserts "~" when you're writing text but > "`" in an elisp or markdown SRC block, for instance. > > I guess just write a function that checks context? Presumably all the > overloaded keybindings do this already but I guess I don't really know how > they > do so. > Yes, you can do that. However, results can vary. The 'bottleneck' is in determining context. If that is easy, typically no problems. However, if you need something complex or need to scan a large part of the buffer to determine the context, then it can be problematic. > I do in general wish it were easier to switch between writing markdown and > writing org, since I often have to write markdown for work. > Sounds like what you really need to do is define a set of key bindings which use the same bindings in both org and markup modes (different bound functions obviously). Instead of entering the character for 'code' using org syntax when in org and markdown syntax when in markdown, you just train your fingers to hit the key binding you have defined for entering 'code'. One nice advantage of this approach is that you can define functions such that if you hit that key binding it will insert the mode specific character if no region is selected, but if a region is selected, wrap that region using the nominated character. This is handy when editing a document because if you come across a section and want to have it rendered has code, bold, underlined etc, you can just select the target region and hit the appropriate key and job done. The other nice thing about this approach is you can generalise this further to other modes, even HTML. You then think in terms of either formatting or semantics (depending on how you define the bindings) and not the lower level syntax. The challenge can be in identifying the most appropriate key bindings. This can depend on the platform you use as well. When I was only using Linux, I used the 'super' key for this and it was great. However, when I also started using a mac, I had to define a new scheme. It can take a bit of work to setup initially, but I think it is worth the effort. I now have the same bindings in multiple modes, so regardless of whether I'm writing markdown, org, html, rich text, etc, I just hit the same key bindings to mark content as code, bold, italic, etc. -- Tim Cross
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Kyle Meyer writes: > Jorge P. de Morais Neto writes: > >> Hi. The HTML export has JavaScript that LibreJS does not recognize as >> free. > > Thanks for noting this. That's certainly not ideal. > >> My first attempt at an workaround (inspired by the Org Mode mailing >> list) was merely encoding the ampersand in the magnet link, but that >> *did not make LibreJS happy*. Then I checked LibreJS manual and saw >> this excerpt: >> >> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1 >> >> Public domain is not a license (see >> https://www.gnu.org/licenses/license-list.html#PublicDomain). If >> you want to release your work to the public domain, the FSF >> recommends using CC0. >> >> Then I came up with a successful workaround. I included the following >> code in my Org Mode customization file: > > Hmm, the public domain switched happen with 471054136 (ox-html.el: Use > classList and put in the public domain, 2020-09-05) and the associated > thread is > > https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/ > > (+cc author and committer) > >> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS >> (with-eval-after-load 'ox-html >> (setq org-html-scripts >> (string-replace "\ >> // @license >> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a=public-domain.txt >> Public Domain" >> "\ >> // @license >> magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08dn=cc0.txt >> CC0-1.0" >> org-html-scripts))) >> >> This works; it makes LibreJS happy. > > Okay. Anthony/Bastien/others, thoughts on using CC0 instead? The error from libreJS is correct - public domain is not a valid license. As this is a GNU project and correct licensing is important, I don't think there is any option other than to change the line to reference the CC license (or any appropriate free license). If 'public domain' was used due to some other issue, either we have to verify the code is covered by a free (not just open source) license or replace it with code that is and is acceptable by the FSF. -- Tim Cross
Re: Concerns about community contributor support
David Masterson writes: > Tim Cross writes: > >> I suspect the best model for moving forward is for new features and >> enhancements to be initially implemented as add on contribution packages >> rather than as extensions/enhancement to the core 'org-mode' package. >> Such packages, if found to be popular or useful to a large number of >> org-mode users could then be considered for inclusion as part of the >> main org-mode package. The nature of elisp makes this type of model very >> suitable as you can modify almost any aspect of org-mode via add on >> packages in a consistent and stable manner and avoid impacting the core >> functionality until the extension/enhancement has matured >> sufficiently. > > What is the current status of having a BNF (or...?) parser for Org > files? In particular, the parser rules that could then be adopted by > tools that use Org files on other systems (iPhone, Android, ...)? Given > the availability of parser generators (bison...), this would be good for > breaking into smartphones where Emacs doesn't run. While not BNF, Tom Gillespie has been working on documentation of the org grammar as part of a broader objective to make it easier for other external tools to parse org files. Below is a message he recently posted to the list. Note that I think this is a slightly different topic to the development/maintenance of org-mode. The external packages I was referring to are still Elisp based packages. Non-Elisp tools which can parse and possibly edit org files would be a good thing for accessing org files on other devices and outside of Emacs. However, such tools will always be more limited because of the complexity of adding things like multiple export formats, babel tangling of src blocks etc (most of which was really only viable in Emacs because Emacs already had support for much of that functionality - a subtle point of org mode often overlooked is that what it primarily did was take existing Emacs functionality and 'wrapped' it in a UI layer to provide a more consistent and 'directed' interface to existing Emacs functionality). > From Tom Gillespie > Dear all, >Here is a draft of a formal grammar for Org mode [1]. It is still > in a rough state, despite quite a bit of work. However, following some > changes to improve performance for parsing real (big) Org files, I > think it is time to share it with the community so that we can start > to gather feedback. There are a number of opportunities that I have > found for simplifying the org grammar (sometimes by extending it to > make it more regular, and in the process adding useful features) that > are much easier to understand with this grammar in hand as a > reference. The grammar itself is implemented using Racket's #lang brag > (see [2] for an overview of brag's syntax). I had considered trying to > break it up into literate sections in an Org file, but for now decided > to leave it as a single file to simplify the development workflow. As > a result the full implementation is fairly long [3]. Comments and > feedback would be greatly appreciated. Best! > Tom > 1. https://github.com/tgbugs/laundry > 2. https://docs.racket-lang.org/brag/#%28part._.The_language%29 > 3. https://github.com/tgbugs/laundry/blob/master/org-mode/parser.rkt -- Tim Cross
Re: Concerns about community contributor support
Timothy writes: > Tim Cross writes: >> This is a common development path for a successful project. Kent Beck >> (extreme/agile development) has been focusing a bit on this with his 3x >> development model (eXplore, eXpand, eXtract). (see >> https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539). >> To some extent, we are in an expand/extract stage for org mode. Focus is >> on addressing performance and extracting core functionality - new >> 'features' need to demonstrate a high level of 'return on investment'. >> At this stage, enhancing or extending the functionality is a slower and >> more cautious process which requires greater justification than was >> common in the 'explore' stage. > > Interesting link, thanks. Org being in the expand/extract stage > certainly rings true to me from my exposure. > > That said, I don't see why being in this stage of development means we > don't need to acknowledge people's attempted contributions. > This is probably just a reflection of how a largely community driven approach works. There isn't really anyone with a responsibility to respond or reply to a patch within some acceptable 'time'. There is a very limited number of people who have commit rights and who do apply patches etc. At this time, priority appears to be given to patches which fix existing behaviour (bug fixes) over ones which extend or modify existing behaviour (enhancements and new features). I suspect the level of response something receives is a reflection of the level of relevance or interest to others on the list. Personally, I don't respond to messages which either - Don't have relevance to how I use org mode. - I don't understand the objective or reason/rationale. - I don't agree or believe the idea is a good one. Sometimes I will reply if I feel (very subjective) the idea would have negative consequences in general or I think there is a simpler alternative solution. However, often I will take a wait and see approach before contributing anything. > My concern is centred around the lack of /response/ to people sending > in patches. Radio silence for *six months* after sending in a > contribution seems ridiculous to me. > I don't think it is ridiculous. I think it is more a reflection of how less formal and structured approaches work. I can understand why someone who has put in the effort to create and submit a patch would appreciate some feedback, but I'm not sure an expectation or desire for feedback is sufficient. Personally, I feel that if you make a patch submission, you sometimes need to 'sell' the patch. This is especially true if the patch is not a basic bug fix. Having developed a patch, it is easy to become very close to it and assume aspects of the patch or what it is proposing are self evident. It can be challenging to put yourself in the shoes of someone encountering the patch for the first time and consider how your submission will come across. Simply submitting the patch and expecting feedback may not be sufficient and followup posts will be required to either clarify, remind or encourage feedback. > This is an interesting thought. Putting aside the fact that this is > somewhat tangential to points I wished to discuss, I have a number of > reservations: > + Many patches are modifying core functionality, and would not be > suitable as an add-on (e.g. [1], [2], [3], and more) There is no limit on what additional external 'add on' packages can do. They can easily modify core functionality. This is one of the core benefits/strengths of lisp languages. I can redefine a core function in my add on package and provided my package is loaded after the core, my redefined version of the function will be what is executed when the core uses that function. For example, I have a heavily 'patched' version of org mode, but I never actually change the core org code. Instead, I have my own org configuration which redefines and modifies core functionality which I wanted changed to suit my requirements. I'm not totally clear about what sort of acknowledgement you want/expect for patch submissions. I get the impression it is more than a simple "thank you for your patch" and rather more detailed review/feedback of your patch. For the latter case, it is likely more a reflection of available resources - in particular, people with the necessary elisp skill to be able to review and provide valid feedback and available time for those limited resources. My observation, which is just one view, is that bug fixes get priority and other patches get attention based on a combination of community interest, available time and the 'squeaky wheel' principal. This relates to my point about needing to 'sell' your patch. For example, I had a quick look at some of the patches you referenced. None of them had any relevance to my use of
Re: Concerns about community contributor support
"Thomas S. Dye" writes: > Aloha Timothy, > > working on Org mode (my interpretation), Nicolas Goaziou took over most of the > coding work. His brief was clearly to put the Org mode code into better > order, > which he did with astonishing efficiency and expertise (at least from my often > ignorant and confused perspective). His work on the syntax, exporter, linter, > and manual represents IMHO an outstanding contribution to Org mode. I'm sure > there are other important contributions that I'm not remembering right now. > My > point is that the project changed from one that was expanding its own vision > of > what it might be to one that was working to ensure that it wouldn't collapse > from its own weight. > Totally agree. The work Nicolas has put in to consolidate, stabilise and clarify the org code base has been critical to the long term viability of the project. I very much appreciate the work he has contributed and the many times he has assisted me in understanding how things work within org-mode. > Kyle Meyer is the next step in this direction, whose efforts have helped tame > the discussions on the Org mode list with a remarkable facility for threading > together the various strands of discussion, some of which have histories that > comprise several years. Combined with a command of git, his work has brought > the > discussion into closer contact with the development of the code base. > Also agree. Getting the right balance between features, stability and maintenance is extremely challenging. This is especially so with org-mode as it has a level of flexibility which makes for a very wide set of use cases. Identifying what should be part of 'core' and what would be better off as an extension or add-on is often challenging. What may seem like a great addition/enhancement for one may be of no benefit to another or may actually complicate their use case. It can be challenging to understand and interpret all these different perspectives and determining the optimal forward direction. > These changes mean that contributions need to be checked for contributions to > Nicolas' project and also fit into the history of discussion and development. > The Org mode project now resembles a scholarly discipline that moves slowly > and > deliberately toward a more or less well defined goal. The days when Carsten > would bang out a new feature during his train ride home from work are gone. This is a common development path for a successful project. Kent Beck (extreme/agile development) has been focusing a bit on this with his 3x development model (eXplore, eXpand, eXtract). (see https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539). To some extent, we are in an expand/extract stage for org mode. Focus is on addressing performance and extracting core functionality - new 'features' need to demonstrate a high level of 'return on investment'. At this stage, enhancing or extending the functionality is a slower and more cautious process which requires greater justification than was common in the 'explore' stage. > > Bastien did recently call for maintainers, though IIRC he was interested in > ox-* > and ob-* maintainers more than org-* maintainers. If enough good programmers > heed his call, then there might be some progress on the concerns you raise. > But, my sense is that patches to Org mode proper will continue to be adopted > slowly and deliberately. It would be a shame if that pace put off talented > programmers, but my sense FWIW is that the pace might be necessary until the > code base is fully tamed. > >From my perspective, I see bug fixes applied fairly quickly. Enhancements and extensions are applied more conservatively, which I think is the correct approach. I suspect the best model for moving forward is for new features and enhancements to be initially implemented as add on contribution packages rather than as extensions/enhancement to the core 'org-mode' package. Such packages, if found to be popular or useful to a large number of org-mode users could then be considered for inclusion as part of the main org-mode package. The nature of elisp makes this type of model very suitable as you can modify almost any aspect of org-mode via add on packages in a consistent and stable manner and avoid impacting the core functionality until the extension/enhancement has matured sufficiently. -- Tim Cross
Re: On the protection of emails in the archives
Jean Louis writes: > Sorry Tim. While that is my opinion, it is not meant to be taken > personally, I am corresponding with many people with Google account, > that is really nothing personal. > Your statement was personal and if that was not your intent, then think before you post and ensure what you write is what you mean. > My opinion is for safety of users and awareness, though. Would you > stubmle upon similar opinions on websites, it would not be taken that > way. I did not mean to. > Completely irrelevant. I did not join the org list to be lectured by you on privacy or your Google paranoia. I'm sure you can find a more appropriate outlet for such opinions. > Examples of privacy nightmare: > https://medium.com/digitalprivacywise/why-you-should-stop-using-google-chrome-6c934c9a827c > > Example of surveillannce: > https://en.wikipedia.org/wiki/PRISM_(surveillance_program) I'm not at all interested in your opinion on Google. This is an org mail list. If it does not relate to org or the list, I don't think it belongs here. -- Tim Cross
Re: On the protection of emails in the archives
Jean Louis writes: > Nobody should use Google for emails. Why trust some 100,000 staff > members with personal information? Please do not tell me what I should or shold not do. I am an adult and am perfectly capable of making up my own mind thank you. -- Tim Cross
Re: On the protection of emails in the archives
Kyle Meyer writes: > Guillaume MULLER writes: > >> Hi all, >> >> I recently sent an email on this mailing list (see >> https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/ >> ) >> >> Since then, I'm receiving spams on the email address I used to send >> the message. >> >> After some research, it seems that this email address only appears on >> 2 websites, notably this orgmode.org mailing list archive. > > Your email address can also be harvested from the lists.gnu.org > archives. Inspect the output of > > $ curl -fSsL > https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00125.html > $ curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2020-07 > >> Would it be possible to configure the archive to obfuscate / hide the >> email addresses inorder to protect its users? > > <https://orgmode.org/list> and its upstream source > <https://yhetil.org/orgmode> are public-inbox > (<https://public-inbox.org/>) archives. There's an option (disabled by > default) to configure address obfuscation. However, in my view email > obfuscation is giving you a false sense of security. Ignoring other > ways spammers get your address, you're posting to a public space, and > your address can be harvested (and, as shown above, not just from these > public-inbox archives). > > And this isn't something specific to Org mode's archives. Just as some > examples, take a look at <https://lore.kernel.org/git/>, > <https://issues.guix.gnu.org/>, > <https://lists.sr.ht/~sircmpwn/sr.ht-discuss/>, or > <https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00285.html>. > > Anyway, that being said and despite my opinion on this, I'm considering > turning on obfuscation at <https://orgmode.org/list> and > <https://yhetil.org/orgmode>. There's at least one issue that'd need to > be fixed before doing so though: > <https://public-inbox.org/meta/87a6q8p5qa@kyleam.com/>. I totally agree. I have no issue if 'hiding' email addresses can be done and has no other unfortunate side effects, but I don't believe it actually achieves much, so don't care if the default is not changed. I think you have to accept that the email address you use in public mail lists is going to be harvested and as others have mentioned, a lot of email harvesting occurs when someone who has your address in their address book has their system compromised. The only sane action is good spam filtering. While I know a lot of people complain about the Google gmail spam filtering, for me it is remarkably accurate. It is unusual for me to see even a couple of spam messages in my inbox every few months. My spam/junk box usually gets around 10-15 messages a day and occasional messages flagged as spam which are not (usually because the sender's mail server isn't doing SPF or any of the other spam prevention headers correctly). Takes me about 1 minute to scan and 'delete forever' each day, so no big problem. -- Tim Cross
Re: First steps exporting to tex
> Hi Tim
> I have been exporting from orgmode to PDF time ago, but very basic PDFs,
> playing with some basic options of orgmode. When I tried to produce a
> meeting minute with a logo in the heading, I decided that I should learn
> better a way of exporting, because the minute meeting was a first
> challenge, but many more would come. For example, for that task I started
> with this code, which I think it goes far beyond what the "LaTeX
> Defaults" can offer (I must yet "play around" a lot with it):
> #+BEGIN_SRC
> #+options: toc:nil
> #+options: num:1
> #+options: d:nil
> #+export_file_name: BORRAR
> #+options: broken-links:mark
> #+LaTeX_header_extra: \usepackage{fancyhdr}
> #+begin_export LaTeX
> \thispagestyle{fancy}
> \lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
> CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO
> ANAGRAMAS/SELLO1_grueso.png}}
> \rhead{Student Name: John Doe\\
> Student ID: 1234\\
> Course: IDB 601 (Fall 2020)}
> #+end_export
> #+END_SRC
> The buffer I exported my meeting notes from has much more information which
> is not related with meetings nor with the logo. So I foresaw 3 things:
> 1 A fast cluttering of the buffers with LaTeX headings would happen, as I
> will learn more about LaTeX and I will want to add more and more
> packages.
> 2 A need for flexibility to be able to export different kinds of documents
> from the same buffer, ideally achieved just by changing a line (or few lines)
> in the buffer. Although, from my example, it seems that ~#+begin_export...~
> contents can't be added in that way.
> 3 A great potential if it were possible to use already existing, and well
> curated, LaTeX templates frictionless through orgmode.
> I find quite useful to analyse the default generated TeX file though.
> Best regards
OK, now I understand your objectives a bit more there are a couple of
things I would recommend.
Org is already fully setup to provide a clean and consistent way to do
much of what you are currently achieving with export latex blocks and
which can avoid much of the clutter in your org files. The way you are
customizing the latex etc is OK for 'one off' type hacks, but isn't the
best solution for crating a standard format.
Have a look at the documentation for org-latex-classes. In this
variable, you can define your own 'pseudo' classes, which you can then
use in your org file with a simple #+LATEX_CLASS: line. This will take
care of all the preamble stuff, plus more (it uses other org variables,
such as ones for listing default 'usepackage' lines and other preamble
lines, so read the documentation carefully).
So, you could add a 'meeting' class to that variable and when you need
to do an org file for meetings, just add #+LATEX_CLASS; meeting at the
top of your org file and your ready to go.
This is what I did for my 'work' class, which produces documents
that included my employers logo, branding colours, fonts, font sizes,
heading formats etc. Now when I need to produce a work document, I just
add the #+LATEX_CLASS: header and then just write a normal org file. I
actually had a number of these custom 'class' definitions.
Really nice thing is that if I find something needs to be tweaked or
changed, I just have to fix the org-latex-classes and related
definitions and know that if I re-export any of my org files that use
them, they will all get the fix (no need to edit each individual org
file to apply the fix).
--
Tim Cross
Re: Idea for handling timezones
Greg Minshall writes: > Russell, > >> I would not suggest using UTC. I believe one of the reasons timestamps >> didn't include TZ information was to keep them short and human >> legible. Solutions with overlays to change a timestamp reduce the >> usefulness of the plain text reading of Org (ie: less, grep, >> etc). Storing timestamps with UTC is really a shortcut for the >> computer, not the user. > > i wonder if this is perhaps another place where "org mode as simple > text" conflicts with "org mode to solve difficult problems". that comes > up from time to time (using dollar signs as delimiters for math is one > recent example, another is "-" being "filled" into column one and taken > as an item in a new list). > > it's a hard line to straddle. > I think you are correct. There are fairly frequent issues associated with timestamps and much of it is due to the tension between trying to have something which is human friendly and having something which lends itself to being used for calculations or in an environment where the timezone regularly changes (i.e. from someone who travels a lot). Adding timezone infomation to timestamps by default is not difficult. Org uses Emacs' time handling functions under the hood and supports setting custom timestamp formats. If I was someone who regularly moved between timezones, I would definitely modify the default format to ensure timezone information is recorded with the timestamp. This would at least let the user know what timezone was being referenced when the timestamp was created and what needs to be done to (even mentally) convert it to whatever the current timezone is. For any calculations involving timestamps, the only sane way to do things is to convert all timestamps to UTC, perform the calculation and if necessary, convert back to localtime for final result. It was mentioned elsewhere in this thread that issues associated with DST changes are OK because they occur early in the morning and not much happens around then. However, this ignores use cases that depend on calculation of time intervals. Provided all calculations are performed using UTC, everything should work as long as timestamps include TZ info. I don't like the idea of having a header variable which records the timezone. I think this will be a source of errors and confusion and just won't work well for many setups (for example, people like me who have many org files with timestamps in them). I feel a better result would be to - Update default timestamp format to include timezones - Add a new function which would either (or all of) - Convert an existing timestamp to a specified tz - Convert all timestamps in a file to a specific tz - Convert all timestamps in agenda files to a specific tz - Convert all timestamps in all org files to a specific tz User can then run the function as required (for example, after changing timezone location). - Ensure all exporter back ends support the ability to set an export timestamp function, allowing changing/stripping of TZ data during export as you frequently want a more concise format in exported documents. I believe this is already supported to some extent. The other things we could probably add is a timestamp display tooltip/overlay which could be defined to popup when the mouse/cursor is on the timestamp and which would display the timestamp in some timezone which the user could specify as an option and which defaults to whatever the local timezone is at the time. Then, when you see a timestamp which is in lets say US EDT and your in Tokyo, moving your cursor or placing your mouse on that timestamp would display a tooltip showing the local time equivalent. -- Tim Cross
Re: First steps exporting to tex
Ypo writes:
> Good morning
>
> After reading your interesting advices, I've decided to start my path through
> LaTeX. I have been some hours trying to start, with little result, but I
> hope that once established a *workflow* the results will come and the new
> invested time will be directed just to get better and better results.
>
> My doubts:
>
> a. As first step for my workflow, it seems convenient to use a "template"
> with the LaTeX preambles. So maybe the many existing LaTeX
> templates can be used quickly with orgmode. I found several options and
> opinions. Which one is the best way?
>
> 1 #+SETUPFILE: template.setup -> doesn't seem the ideal way, because the
> template.setup file must be modified adding #+latex_class to each of
> the lines.
> 2 template.tex -> this could be added to the SETUPFILE: #+LATEX_HEADER:
> \input{template.tex}. But it seems to have no effect on the PDF
> output. BTW, I can't use emacs HOME path (~/) in the input header, like
> \input{~//export//template.tex}. This is my template.tex file content:
> \usepackage{fancyhdr}
> \thispagestyle{fancy}
> \lhead{\includegraphics[width=4cm]{jpg.jpg}}
> \rhead{Student Name: Name\\
> Student ID: 1234\\
> Course: IDB 601 (Fall 2020)}
> 3 Another friend told me that .sty templates were the best way.
> 4 I see some people that create customized LaTeX classes and add the desired
> class to the orgmode buffer.
> 5 Also we can see this intricate transformation of a LaTeX template into
> orgmode. How to Migrate LaTeX Template into org-mode
> 6 ...
>
> b. I think that in a good integration, every character shown on orgmode
> should be exported into the PDF output. For example "CENTRE LINE
> SYMBOL": ℄
> How can this integration be done?
>
> I have more doubts, but I will keep reading and trying to solve them
>
> Best regards
Why do you think you need any of this for your 'first steps'. Start by
just writing your org file and exporting it to latex or pdf. Then, once
you have your first document, see what you think needs changing and come
back and ask advice on what you need to do to make the changes you want.
In your first document, don't use any latex commands, header options or
anything else - just write your document using standard org mode.
Org already sets up a reasonable starting default. Once you know what
the default is, then we can discuss what you may need to change. For
many documents, you may not need to change much at all and you may not
need any templates - for example, you will likely want to change the
margin sizes (this is a common request) or you may want to see what some
of the other 'standard' latex document classes are like. All of this can
be achieved with just minor configuration of org mode.
The org export to latex only needs to be as complicated as you need it
to be. Org has variables which can be used to add/remove things from the
preamble and once you have those configured, you don't have to put
anything in the org file itself. Start simple and add as you find a need
rather than try to start with something complex which might not be
necessary.
--
Tim Cross
Re: Idea for handling timezones
shironeko writes: > Hi everyone, > > I, like many others on this list, have to move between timezones quite > frequently. As I gathered from the archive, it seems the main complexity in > supporting timezones is the difficulty revolving the change of timestamp > format. > So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at > the start of the file like so > > #+TIMEZONE: America/Toronto > > This specifies the timezone of all timestamps in the file. Together with it, > there can be a function called e.g. org-shift-time, that shifts all the > timestamp in the file to another specified timezone and updates the keyword. > Of > course, care needs to be taken when dealing with dates without time, e.g. it > should be treated as at time 00:00 when it is alone or as the start of a time > range, and be treated as at time 24:00 when it is the end of a time range. > > Then there could be hooks that offer to run the function automatically when it > detects the user's system or emacs is set to a different timezone as in the > file > (e.g. when they open the file, or opens the agenda). This will make sure the > timestamps always aligns with their current one (if they wish). > I'm sorry, but I don't like this idea. In general, I think it is the wrong approach and not sophisticated enough to work with the complexities associated with timestamps. This is actually a very hard problem and not one which can be adequately addressed with something this simple. Problems include 1. Timzone alone is not sufficient. Offsets from UTC change due to daylight savings times etc. 2. You can easily have timestamps from different timezones in the same org file 3. Storing timestamps in local time is problematic because of the inherent ambiguity this can have (again, due to daylight savings times and what occurs at the 'cut over' time). 4. Sometimes, you may want the timestamp to reflect the date/time as it was when recorded and don't want it to 'change' because your now viewing it in a different timezone etc. Personally, I think timestamp 'storage' and timestamp 'display' need to be treated separately. I also think all relevant information (timezone, offset) need to be stored with the timestamp. I also think the fundamental base timestamp should be stored as UTC, allowing all time calculations to be consistent (free of daylight savings time changes). The user can then manage how the value is displayed by setting timezone and offsets as appropriate (with perhaps the default being the local system settings or whatever offset/tz was stored with the timestamp itself). It is very difficult to predict or understand all the use cases for timestamps. Therefore, any scheme must be extremely flexible. Experience has taught me that one critical component is that at the lowest level, many problems are avoided if the value is in UTC. Problem is, UTC is not terribly human friendly. Luckily, this can largely be automated for many common use cases. Unfortunately, it does also mean that if you are someone who frequently moves between many timezones, your situation will be more complicated. ne of the most frustrating parts of working with timestamps is daylight saving times. This causes complications at so many levels. In particular, I hate the fact change over dates often change and more often than not, those changes are based around politics and at the whim of politicians, which makes programatic handling more complex than it needs to be. -- Tim Cross
Re: Including Email Address in the Reply in Mailing-list
I have no issue with this suggestion and am happy to try and comply. The challenge for many will be that they either - need to remember to remove the email details manually (line/header automatically added by mail client) while sorting out either - how to modify mail client for all replies (may not be appropriate for non-ML replies), or - how to modify mail client for just ML replies My personal belief is that if you subscribe to a public mail list, you need to accept that your email address will be 'out there' - more generally, over time, your email address is going to be harvested regardless and your better off trying to improve filtering and spam detection than any attempt to minimise the address appearing in archived content on-line. Off now to try and work out how to change the reply header in my mail clients! Husain Alshehhi > Hello all, > > I just noticed that some of us here, when replying, include the email of > the sender of the previous email in the response as part of body of the > email. This email address shows up in plain text in the mailing > list[1]. This is certainly done without any ill-intentions, but that > could cause the email address to receive quite a bit of spam if spammers > crawl these pages. > > I suggest refraining from doing so, and instead use the name. Please let > me know what you think. > > [1] this is an example: > https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00042.html -- Tim Cross
Re: Font lock in org+elisp confused with ?\[
I'm forwarding this to the emacs-orgmode list as this is something org maintainers probably need to see. On Thu, 1 Apr 2021 at 15:43, Arthur Miller wrote: > > Is it me or is it a bug? > > When in org mode in an elisp block, this seems to confuse syntax > checker: > > #+begin_src emacs-lisp > (progn > (if (= (following-char) ?\]) > (forward-char -1)) > ) > #+end_src > > Identation seems to think it is one level extra, and it also shows as > error. Same of course when testing for ?\[. > > It does evaluate correctly. Ordinary elisp buffer does not have problem > with this, only when in code blocks in org-mode or elisp mode.I can send > in some screenshot with errors if needed. > > > -- regards, Tim -- Tim Cross
Re: Using backticks for the inline code delimeter?
Joost Kremers writes: > On Fri, Apr 02 2021, Tim Cross wrote: >> Getting backticks to font-lock correctly is relatively easy. Getting the >> exporters to understand the new syntax is more of a challenge > > Don't the exporters work off of some intermediate representation, like Pandoc > does? I kinda thought that was what `org-element.el` was all about... > > And of course I meant to type ~org-element.el~ there... :D Yes, at least most of the core ones should. However, I would still expect some surprises and of course there are no guarantees regarding the contrib and other external ones. Despite attempts to abstract the syntax to make it 'flexible', I would be surprised if there is not functionality in some of the exporters which has implicit assumptions regarding the syntax being used and is not isolated from such changes. Note that I'm not saying this cannot be done or even that is should not be done. I just want to highlight that just making changes to how org deals with it at the 'presentation' layer may not be sufficient and that you would have to verify there are no unexpected side effects in any of the exporters. If you wanted to keep backwards compatibility or make using ` and alternative to ~, you would also need to decide/verify things like `word~ (i.e. mixed delimiters) are handled correctly (i.e. simple regex with alternatives would not be sufficient - would need to be a match which allowed both but ensured matching values). Of course, there is a big difference between making a change to org and making a change to an individual's own org instance. So if we are talking about how someone can hack their own org instance to use ` instead of ~, it can be much simpler as they don't have to worry about the bits they don't use or backwards compatibility. The downside then becomes just the hassle of maintaining your hacks over subsequent org releases. One reason why I would probbly go with a method which just changes how I input data. For example, I would define a function which inserts ~ or if a region is marked, surrounds it in ~ and then just bind that to a key, never using ~ or ` directly to mark text. -- Tim Cross
Re: Using backticks for the inline code delimeter?
Samuel Wales writes: > n.b. everybody knows better in this thread, but the docstring of > org-emphasis-alist seemed to me like `test` + reload would fontify. Getting backticks to font-lock correctly is relatively easy. Getting the exporters to understand the new syntax is more of a challenge as is how to deal with backwards compatibility so that all your existing org files don't need to be modified. -- Tim Cross
Re: About exporting
Eric S Fraga writes: > On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote: >> And there is a final thing which (for me) seem to work better in >> latex-mode compared to org. That's jumping to the ``next error'' with >> some key stroke. That's important, LaTeX's own error output it quite >> poor, but jumping to error locations is vital. > > Yes, this is an issue I have as well. And the fact that the error > messages are for the LaTeX lines, not the org lines, so you end up > sometimes having to look at the LaTeX code and then go back to the org > file. This definitely adds friction! > >> I would not be surprised if some of that is somehow supported by org as >> well (for TeX), only I have not figured it out, or perhaps I was too >> lazy to figure it out how. > > No, I don't think there's anything (at the moment) to help with this. I > would love to be proven wrong, mind you! Org always has more > capabilities than I know... the only small bit of help I've found is org-lint, which has helped me find issues in the past. Doesn't help track down errors from *.tex -> pdf etc, but often an error in the org file causes the errors in the *.tex export. Having said that, I find the most common cause of errors in the *.tex export is due to in-line Latex in my org file. I rarely run into errors due to export of 'normal' org content. When I do run into problems, I just open the *.tex file in Auctex mode and track it down that way. Usually, it isn't too hard to work out where that relates back to the source org file. Being able to do that semi-automatically would be nice, but I think something that would be very difficult to implement. You would need something to parse the tex error output, extract text which could be then searched for in the org file. As mentioned, the problem is tex errors don't always contain that information, so you would probably also have to parse the tex file and then try to map that back to the corresponding part of the org file (which assumes of course that it is the org data which has caused the issue and not something relating to latex package or package configuration). -- Tim Cross
Re: Using backticks for the inline code delimeter?
"Dr. Arne Babenhauserheide" writes: > George Mauer writes: >> - lists with dashes, org supports that just fine > > or stars (not possible with org) or plus (in org). > >> *bold text* with stars, again org already does this > > Note that this does not match markdown: Markdown uses *emphasis* and > **strong**. > >> `backtick code`, org doesn't handle this and actually uses the tilde as a >> delimeter which is extra jarring since its a strikethrough in many chat apps > > tilde or equals. > > - list > *bold* > =code= > > Adding more syntax is a slippery slope, because then `foo` can never be > used for anything else, and there is a limited amount of usable syntax > elements. > Yes, I think this is potentially a bad idea. Org parsing is already slow enough without adding yet more syntax and font-locking complexity. I also suspect this is not as simple as just adding this to org parsing - all backends and many contributed packages would likely also need to be updated to understand the new syntax. So probably not a trivial change and a change which is likely to have real impact wrt backwards compatibility. Part of the issue here is that there is no markdown 'standard'. There are a number of markdown 'flavors' or dialects. Org is just another one (and one of the older ones at that). -- Tim Cross
Re: Starting from 9.5, Org contrib will be distributed as a separate NonGNU ELPA package
Allen Li writes: > Bastien writes: > >> Hi all, >> >> starting from Org 9.5, org-contrib will be distributed as a NonGNU >> ELPA package. You will find it here: https://elpa.nongnu.org/nongnu/ >> >> See for https://orgmode.org/list/87wnzfy60h@bzg.fr/ for context. >> >> Thanks, > > Will there be an overlapping period (and if not, can we add such a > period)? For example, have one release where org-contrib is still > shipped, and the NonGNU repos are available. That gives users such as > myself a period to switch over without things breaking immediately. > > If I understand correctly, the current plan is that users using > org-contrib will have their configs break immediately when they upgrade > to 9.5, forcing them to do both the 9.5 upgrade and switchover to NonGNU > simultaneously. It's easier if we can first safely upgrade to 9.5, then > switch to NonGNU repos, and in the next release org-contrib can be removed. I agree an overlap would be useful. This will give maintainers of 'canned' configs, like spacemacs and doom time to update their setups. However, just to clarify. As I understand it, after 9.5, there will no longer be an 'org-plus-contrib' package. Those who now use org-plus-contrib will need to update their config to install org (fro ELPA) and org-contrib (from NONGNU ELPA). The good news is nothing will break. When you do an update, there just won't be an updated org-plus-contrib and you will remain on 9.5. Only after you have updated your config will you get a version > 9.5. -- Tim Cross
Re: Adding Quick Notes in Org-mode Agenda View Inserts then In Drawer in Reverse Order
t my notes to HTML, exporters will ignore the >LOGBOOK, and I would like to export my notes. > b. Notes are ordered in reverse: newer notes are put first. > > Because of this behavior, I suspect that I am hijacking the notion of > "status change notes" and using them as notes. > > My questions are: > > 1. Am I using the notes correctly in org? > 2. If not, what is equivalence of adding quick notes into a task >(ideally, with time stamp of sort)? > 3. If yes, then how can I work around the limitations (a) and (b)? -- Tim Cross
Re: About exporting
Martin Steffen writes: > > There is one case where I do _NOT_ use org for such documents (though I > use org basically most things I do), and that is > > collaborative editing, > > working together on a document (maybe shared by git), at least with a > document of some amount of complexity and typesetting requirement. > Yes, this is still the big unresolved challenge. The sad truth is people think editing using word and 'track changes' is a good way to do collaborative documents. I found it was actually pretty bad once you had more than 2 people working on the document. It really only worked well if the collaborators worked in serial i.e. one after the other and you had a single file which just had track changes on it. My 'solution', which wasn't great, but which I still preferred to fighting word and track changes, was to send out the document exported as ascii from org, to each collaborator and told them 'just edit it, don't worry about formatting, I'll fix that'. I would then use diff on the returned ascii files to combine them back into a single ascii file, convert that back to ork and then export the final form in whatever format was required. This had a couple of advantages and disadvantages - Advantages were I had control over the final document. Was actually useful to release PDFs stamped with 'draft' until agreement was reached and then issue a single final document. It is amazing how much confusion can exist in large organisations because multiple versions of some document are floating around and people lose track of which was the final version. Other advantage was I simply didn't have to deal with word. Even doing all the diff combining (using Emacs of course!) and re-formatting was faster for me with org than fighting with word and trying to get a good looking final word document which contains heaps of conflicting styles etc. (dig into the metadata for a Word document which has been shred and edited by multiple people and you will know what I mean!). Disadvantages included some people just not being able to deal with editing a plain ascii document - just too use to word processing and found the whole process frustrating. Also, in some situations, people hated giving up control of the document. The other somewhat ironic disadvantage was that the organisation was use to ugly and badly formatted word documents which had a heap of organisation format 'policy' which you had to comply with (type of font, font size, margins, line spacing etc. I had to 'uglify' the latex output in order to make the documents look like other documents produced in the organisation. This took a bit of effort, but at least once it was done, I could re-use the setup. Funny thing was, whenever I produced a document which was just produced with un-uglified Latex, I would typically get comments about what a nicely formatted document it was. Nobody ever said that with documents which complied with the organisation's 'policy'! -- Tim Cross
Re: org-adapt-indentation not honored prior to Org 9.4?
Kyle Meyer writes: > Mike Kupfer writes: > >> Over the weekend I upgraded my Emacs from 27.1 (Org 9.3) to 27.2-rc2 >> (Org 9.4). I noticed that Org mode behaves differently, even with >> "emacs -Q". >> >> In 27.1, if I visit foo.org and type "* header RET", point is put in the >> first column. In 27.2, point is put in column 3. >> >> AFAIK, I'm not using electric-indent-mode; at least it's not shown in >> the minor mode list in the modeline. > > electric-indent-mode has been enabled by default since Emacs 24. If you > run `C-h v electric-indent-mode` under emacs -Q, you should see that its > value is t. > >> org-adapt-indentation is t in both Emacs 27.1 and Emacs 27.2. Was there >> a bug fix that went into Org 9.4 such that org-adapt-indentation is now >> honored? > > Not that I'm aware of. However, Org was changed to respect the > electric-indent-mode value: d3e6b5800 (Make RET and C-j obey > `electric-indent-mode', 2020-05-05) > > https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/T/#u > >> Could the change in behavior be documented in the ORG-NEWS >> file in Emacs? > > Here's what ORG-NEWS says under the 9.4 release: > > *** =RET= and =C-j= now obey ~electric-indent-mode~ > > Since Emacs 24.4, ~electric-indent-mode~ is enabled by default. In > most major modes, this causes =RET= to reindent the current line and > indent the new line, and =C-j= to insert a newline without indenting. > > Org mode now obeys this minor mode: when ~electric-indent-mode~ is > enabled, and point is neither in a table nor on a timestamp or a link: > > - =RET= (bound to ~org-return~) reindents the current line and indents > the new line; > - =C-j= (bound to the new command ~org-return-and-maybe-indent~) > merely inserts a newline. > > To get the previous behaviour back, disable ~electric-indent-mode~ > explicitly: > > #+begin_src emacs-lisp > (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) > #+end_src > > Alternatively, if you wish to keep =RET= as the "smart-return" key, > but dislike Org's default indentation of sections, you may prefer to > customize ~org-adapt-indentation~ to either =nil= or ='headline-data=. Hi Kyle, one thing I think might help (maybe too late) would be to put the entries for both electric-indent-mode and org-adapt-indentation so that they are together in the release notes as they do interact with each other and often people stop looking once they see one and not the other (they are currently a fair 'distance' apart in the file). I suspect we will see a few of these as the changes an interaction between those two things are not terribly intuitive. -- Tim Cross
Re: About exporting
may need you to manually add line breaks or an included image may need some size hints etc. > ODT: I take this one as a lower level solution than LaTeX, but it looks > easier to tame, and it even allows to use templates, for example to make > reports in > the workplace. Do you think it is worth focusing on ODT exporting? Could it > be a definitive solution to publish papers and books directly from orgmode? > ODT exporting sends some error message to me, but at least I understand it. > I've never liked the ODT output. I find the documents I produce using ODT to be 'uglier' than those with Latex. However, if I need to produce the document in a format which allows others to edit it, ODT can be useful. > HTML: I have seen some themes designed to export in LaTeX format using HTML. > Here we would have the "definitive tool": The power of LaTeX in the > versatility that could give the use of different themes for different > purposes. But, do you think it could get, some day, the quality of a direct > LaTeX export? > No errors by my side when exporting to HTML. > No, because they serve different purposes. Latex is superior in every way when it comes to producing a PDF or a printed document. HTML is superior when you want to display the content in a browser. HTML is terrible when you want to print the output. I think it is a mistake to try and just focus on one export format. The great benefit of org mode is that you can export in multiple formats with minimal or no changes to the source. If you need to export in a format which will allow others to edit the document, ODT is great, if you need to export to publish on the web, HTML, if you need a PDF Latex, if you need a presentation, either beamer or something like reveal. They all have a role to play. A better use of time is getting to know org and how it can be configured so that you can setup your export environments with defaults which suit your requirements. When I see people modifying *.tex files generated by org, it is often because they have not worked out how to add the additional packages or set the configuration for those packages in org. -- Tim Cross
Re: Shutting down Org ELPA: No new release of Org on Org ELPA after Org 9.5
Thanks Bastien. To clarify, does this mean org 9.6 will be the first version only released via GNU elpa (i.e. bug fixes for 9.5 will still be released via Org elpa e.g. 9.5.1)? Tim Bastien writes: > Hi all, > > over the years, Org ELPA at https://orgmode.org/elpa/ has been useful > to make it possible to install Org and Org+Contrib as ELPA packages, > but maintaining a separate ELPA space just for Org is not necessary. > > Org 9.5 will be the last release to be distributed on Org ELPA. After > 9.5, we won't use Org ELPA for new releases. Past releases will still > be available, though maybe not indefinitely. > > The Org package will continue to be available through GNU ELPA (from > https://elpa.gnu.org/packages/) and a new Org-Contrib package will be > available from https://elpa.nongnu.org/nongnu/. > > Only stable releases will be distributed through both GNU and NonGNU > ELPA repositories. For those who want to test the unstable version of > Org, please install Org from Git: > > ~$ git clone https://code.orgmode.org/bzg/org-mode.git > > See https://orgmode.org/manual/Installation.html#Installation > > If you used Org ELPA and are affected by this change, please tell us > if this change affects you. > > Thanks! -- Tim Cross
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Uwe Brauer writes: >>>> "TC" == Tim Cross writes: > >> Diego Zamboni writes: > >>> I have seen differences in this behavior depending on the Emacs >>> build. The emacs-mac port >>> (https://github.com/railwaycat/homebrew-emacsmacport) >>> seems to intercept certain Mac-specific keybindings such as C-space >>> and C-M-space and gives them their "Mac meaning", e.g. to bring up >>> Spotlight or the >>> symbol chooser. I could never figure out how to disable this behavior. >>> >>> Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) >>> and this no longer happens. >>> > >> Normally, you need to disable those 'shortcuts' at the OS level i.e. >> under the keyboard shortucts item in macOS preferences panel. Problem is >> any macOS shortcut will grab the keys before Emacs sees them. Not sure >> how the emacs-plus version gets around this. > > Right, it seems and issue of the OS shortcuts as C-space is for > switching keyboards (US->spanish>etc etc).[1] > > Do you know how to change or disable them? > I'm not on a mac at present, but from memory it is under system preferences -> keyborad -> shortcuts.
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Diego Zamboni writes: > I have seen differences in this behavior depending on the Emacs build. The > emacs-mac port (https://github.com/railwaycat/homebrew-emacsmacport) > seems to intercept certain Mac-specific keybindings such as C-space and > C-M-space and gives them their "Mac meaning", e.g. to bring up Spotlight or > the > symbol chooser. I could never figure out how to disable this behavior. > > Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) and > this no longer happens. > Normally, you need to disable those 'shortcuts' at the OS level i.e. under the keyboard shortucts item in macOS preferences panel. Problem is any macOS shortcut will grab the keys before Emacs sees them. Not sure how the emacs-plus version gets around this.
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Uwe Brauer writes: > Hi > > Does anybody know how to achieve the traditional binding of > C-space to set-mark-command on MacOS (for emacsformacos)? > > Shift arrow down works, but will not work for a lot of features in org > mode. > Have you verified c-space is not being used by the macOS UI as a shortcut for something like spotlight search? I now use spacemacs, but when I used my own setup, I don't recall having to do anything special to get this behaviour apart from disabling macOS shortcuts. -- Tim Cross
Re: trivial software engineering'ish question: switching org's
Greg Minshall writes: > hi. i occasionally want to switch from the org package to a git > version, then back again. and, i want to avoid the dread "mixed > installation". > > i'm wondering is there a way people do this other than simply > installing/deleting the package version? > As I understand it, the critical part is when Emacs compiles the org files to get the *.elc versions. Provided you do not have any org functionality loaded during that compilation process, everything should be OK. The 'mixed' versions problem arises because you go to compile a different version and Emacs includes definitions already loaded from another version, generating *.elc files with mixed versions. Once org is compiled, the critical part is having the org version you want show up first in the load-path, so the problem becomes one of just managing the load-path entries appropriately. You could just ensure the version you want is higher in the load-path or you could go the 'paranoid' route and have code which removes the version you don't want from the load-path. In the past, what I've done is have the git version of org in a specific directory which I build with a separate process from the command line using the make recipes in the repository - essentially just configuring and running make. I then have some code in my init.el file which sets that version at the start of my load-path when I want to run it and which I comment out when I just want to run the version installed by package.el. I also use the use-package macro to load my org configuration and have two different blocks for that - one loading the git repo version and one loading the org-plus-contrib version I normally use. I just comment out the one I don't want to use. I probably could write some elisp to automate this, but to be honest, I switch between org versions so rarely, commenting/uncommenting parts of my init.el file is easy enough. I don't do any of that at the moment as I've not needed to run from the git repo since I switched to spacemacs and the spacemacs setup already has the necessary workflow to ensure new versions of org are compiled in a clean environment. Have not yet thought about how I will need to add git based org when using spacemacs. Suspect All I'll need to do is adjust the load-path as part of the init to reference the git sources before any org functionality is loaded. -- Tim Cross
Re: Bug: crash exporing to html [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
> ("w3m" :store org-w3m-store-link) ("file+sys")
> ("file+emacs")
> ("shell" :follow org-link--open-shell)
> ("news" :follow #[257 "\301\300\302Q!\207" ["news"
> browse-url ":"] 5 "\n\n(fn URL)"])
> ("mailto" :follow #[257 "\301\300\302Q!\207" ["mailto"
> browse-url ":"] 5 "\n\n(fn URL)"])
> ("https" :follow #[257 "\301\300\302Q!\207" ["https"
> browse-url ":"] 5 "\n\n(fn URL)"])
> ("http" :follow #[257 "\301\300\302Q!\207" ["http"
> browse-url ":"] 5 "\n\n(fn URL)"])
> ("ftp" :follow #[257 "\301\300\302Q!\207" ["ftp"
> browse-url ":"] 5 "\n\n(fn URL)"])
> ("help" :follow org-link--open-help) ("file" :complete
> org-link-complete-file)
> ("elisp" :follow org-link--open-elisp) ("doi" :follow
> org-link--open-doi))
> org-latex-format-headline-function
> 'org-latex-format-headline-default-function
> org-link-elisp-confirm-function 'yes-or-no-p
> org-latex-format-inlinetask-function
> 'org-latex-format-inlinetask-default-function
> org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
> org-html-format-headline-function 'org-html-format-headline-default-function
> )
--
Tim Cross
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
Andreas Eder writes: > On Fr 19 Mär 2021 at 13:33, Eric S Fraga wrote: > >> With respect to the topic at hand, I believe it's the result of the same >> tendency that Excel users have of using spreadsheets (aka tables) for >> everything, something I hate when I'm given some Excel sheet that I need >> to modify and where entries are huge paragraphs. The UI in Excel is >> horrible for these types of tables. I would hate to see org go in the >> same direction. > > +1 for that > Unfortunately I have to deal with this type of people at work. > In my world, I suspect project managers would be liked a lot more if they had never discovered excel! Funny thing, survived for years without the scourge of excel, but noticed it creeping in more around 2007 or so, then by 2015 it was everywhere - project plans, requirement specifications, software testing and even software/API design documentation. I didn't mind when the core of the document was still about linked cells with calculated values which would change based on changes in various cell entries - that is what spreadsheets are for. However, often now, I'm presented with a spreadsheet (or workbook) with not a single calculation or cell formula - it is just about formatting. In many ways, workbooks are being treated like a poor persons slow inefficient database with a really poor interface. More than once, I've taken these spreadsheets and extracted the data into an org file with headings, sub-headings, TODOs and lists, possibly with a couple of clock tables and been far better off. In one project, we were really lucky because there was multiple Emacs users and we were able to get org used as the primary data format for managing the project (we even used taskjuggler to generate the diagrams needed for steering committee). Unfortunately, that is a very rare situation and most of the time, we are forced to use excel simply because it is a format available to everyone on every platform. This I think is the key problem - MS Office and excel in particular have become ubiquitous and now people think the way information is presented in spreadsheets is the 'default' or acceptable way to format data (i.e. tables with large columns cntaining paragraphs of data). IMO tables are really only a good presentation format when you can see the whole table in a page or screen. Once you need to navigate around large cells, columns, rows, it is really just about navigation around the data and I find is often less efficient or useful and navigation around a well structured org file. Where excel has us beat is in sharing of information and enabling others to add/update the data. Everyone has access to excel or excel compatible software, hardly anyone uses org (as a proportion of total users, doesn't mean org doesn't have a lot of users). -- Tim Cross
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
Eric S Fraga writes: > On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote: >> I am a little concerned about the expansion and addition of features in >> org mode when there seems to already be a challenge with respect to >> maintenance and bug fixing. Personally, I would prefer an org mode which >> is consistent and reliable over one with large numbers of features that >> is less stable and slower. > > +1 on this. > > With respect to the topic at hand, I believe it's the result of the same > tendency that Excel users have of using spreadsheets (aka tables) for > everything, something I hate when I'm given some Excel sheet that I need > to modify and where entries are huge paragraphs. The UI in Excel is > horrible for these types of tables. I would hate to see org go in the > same direction. > Those excel 'workbooks' are the absolute worst. I sometimes wonder if project managers would be more popular if they hadn't decided to use that as their primary tool. The UI to navigate through those spreadsheets is horrible. The other problem is that tables with large cells of 'paragraph' like data are not terribly nice from an accessibility perspective. They can be difficult to navagate and things like screen readers can find it difficult to 'render' the content in a sensible manner i.e. where the spoken representation 'makes sense'. It has also been stated that the Latex exporter won't be a problem as tabularx (and other Latex packages) will just handle this. Sadly, I don't think it is that simple. I have used that package a lot over the years and there have been times I've had to render tables with multiple columns and rows. While the various latex table like packages do provide a much better outcome for tables with more complex cell structure, it is rare that you don't need to do a fair amount of tweaking to actually get good looking complex tables. Handling a cell with a couple of lines may be fine, but it is very easy to hit the limits of what the package can handle without some tweaking. This is where I think things begin to fall down. My suspicion is that the amount of work needed to make the Latex exporter handle the majority of common use cases for this new syntax is much larger and more complex than it seems and getting this to work reliably and consistently will be extremely difficult. We can be pretty certain that if we introduce some additional syntax to allow for multi-line cells and perhaps multi-row+multi-column cells, if the exporters do not render good looking output for every use case, bugs will be reported. I also have no idea how this will impact some of the other exporters, such as odt, texinfo etc. I do think we can probably add additional functionality to make working with more complex tables in org files somewhat easier from an editing perspective. I do have some concern over the potential performance impact, but in general, feel this is probably the easier part of the challenge. > In many cases, I believe that a simple text based database format would > be more appropriate. I wonder if the time would be better spent > providing native support for GNU recutils [1] in org instead. It could > even have a table like export... > That would be an interesting exercise. However, it does add another dependency and in some ways breaks the 'everything as text' philosophy (though I guess the last 'rendering' in the org file is still all text). To some extent, discussions like this remind me of the early days of the web where tables were used as the primary formatting 'tool'. Remember those horrible web pages which consisted of deeply nested tables? We learnt pretty quickly what a bad idea that turned out to be. I wonder if part of the issue here is with the different characteristics of displays and formatted or printed output. Displays have the property of being 'infinite' - a row can be as long as you like and a column can be as high as you like. With the growth in large screens many users now have windows far wider than the old 80 characters that were standard in old terminals. This tends to make tables a more appealing 'layout' facility as you can have a number of columns with multiple rows fitting on the screen. However, now you have a new problem - how do you map this very wide structure to a fixed width, relatively narrow, sheet of paper? The advantage of 80 characters was that generally, you could fit that on a standard sheet of paper. It is also a good width for reading, allowing you to take in multiple 'blocks' of text at a time. Really wide text can look ok, but many find such wide text more difficult to read as you have to scan long lines and cannot easily take in a 'block' at a time. I think there is probably some very good reasons multi-row cells were not supported in org mode initially. I suspect the reasons are not necessarily obvious until you try to implement such support. I could
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
Timothy writes: > Tim Cross writes: > >> In principal, it wold be great to be able to support multi-row columns. >> However, I'm not sure how easily this can actually be implemented in a >> consistent and maintainable manner. > > Mmmm, this of feels like something where you'll quickly learn how hard > it is/isn't when you try to implement it. > >> From watching these discussions in the past, I think the big stumbling >> block is how easily multi-row columns can be added and maintained in the >> various export formats. Some are easy, like HTML, but others are less >> so. In particular, I know from my many years working with Latex, >> multi-row columns are not straight-forward. There are lots of edge cases >> to deal with and it is hard to get a consistent result programatically. >> >> Proposals like this one can seem simple and straight-forward on the >> surface. However, implementation is another matter. All of the exporters >> will need to be updated to handle this new syntax and it will probably >> take a fair bit of work to handle it correctly in just plain org files >> (formatting, highlighting etc). > > Currently if you were to try this content with the proposed syntax, > content is just put in the top left cell of the group. This seems like a > reasonable fallback to me. Then for HTML we have colspan/rowspan, and > for LaTeX there's \multicolumn and with the multirow package \multirow. > > FWIW just formatting would need to be updated for Org files. > Highlighting is fine as is. > >> If this was something people were prepared to put the time into >> implementing, I think it must be done in a completely separate feature >> branch and would need to be fully tested (including all back end >> exporters) before it can be merged into the mainline branch. It would >> also be important to profile and ensure it does not have significant >> impact on performance. >> >> I am a little concerned about the expansion and addition of features in >> org mode when there seems to already be a challenge with respect to >> maintenance and bug fixing. Personally, I would prefer an org mode which >> is consistent and reliable over one with large numbers of features that >> is less stable and slower. > > I appreciate this concern, but I do think that the ability to have > multi-col/row cells is invaluable in many large tables, and so would be > a very good addition to Org. We can debate how easy or hard this is to implement indefinitely. What is needed is for someone to implement a working version which is consistent, reliable and provides expected results across all export environments. The devil is in the details and I suspect that once you start trying to implement the feature is when many of those challenges become clear. My view is 'go for it'. Just create a new feature branch and implment the functionality in that branch. We can then try using it and see where it works and where it doesn't. Once this is done, a call can be made as to whether it should be implemented in the main code base -- Tim Cross
Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
Atlas Cove writes: > On 18/03/2021 14:26, Timothy wrote: >>Interesting suggestion you have here. >>On a related note, I wonder if you might have seen this thread I raised >>a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/ >>The discussion has died down (unfortunately), but the idea is still on >>my mind. >> >>-- >>Timothy > > I'd like to propose to fold my discussion into yours. In principal, it wold be great to be able to support multi-row columns. However, I'm not sure how easily this can actually be implemented in a consistent and maintainable manner. >From watching these discussions in the past, I think the big stumbling block is how easily multi-row columns can be added and maintained in the various export formats. Some are easy, like HTML, but others are less so. In particular, I know from my many years working with Latex, multi-row columns are not straight-forward. There are lots of edge cases to deal with and it is hard to get a consistent result programatically. Proposals like this one can seem simple and straight-forward on the surface. However, implementation is another matter. All of the exporters will need to be updated to handle this new syntax and it will probably take a fair bit of work to handle it correctly in just plain org files (formatting, highlighting etc). If this was something people were prepared to put the time into implementing, I think it must be done in a completely separate feature branch and would need to be fully tested (including all back end exporters) before it can be merged into the mainline branch. It would also be important to profile and ensure it does not have significant impact on performance. I am a little concerned about the expansion and addition of features in org mode when there seems to already be a challenge with respect to maintenance and bug fixing. Personally, I would prefer an org mode which is consistent and reliable over one with large numbers of features that is less stable and slower. -- Tim Cross
Re: How to get shell source blocks to read my profile?
variables from the login process (as it is the parent of all) and any variables exported by parent processes in the process hierarchy (such as any exported as part of an interactive shell which sourced .bashrc for example) or is defined and exported in a parent (such as part of a shell script which then executes the command which creates the child process. So, in general, you don't want to run all or many of your processes as a login shell. At the very least it is wasting resources and at the worst it could actually cause confusion or break things because it is causing things to be run multiple times which should only be run once. I suspect some of the confusion here is being cause because of the different model approach used by the Mac OS. On the mac, you actually have at least two process trees (I'm not a mac expert, so it is possible there are more than two - in fact I'm pretty sure there are, but for explanation purposes). On the mac you have your login process tree and your 'dock' (launcher) process tree. The dock process tree is not rooted as the child of a login shell, so there is no sourcing of .profile and it is not an interactive shell, so no .bashrc either. The execution environment associated with processes it spawns (such as when you run a command) only consist of the global system environment setup by the system prfile in /etc/profile, /etc/paths and /etc/paths.d and any environment variables created and exported by the process itself (i.e. using the setenv command in your emacs init.el). Whether emacs is run in terminal mode or in GUI mode has nothing to do with what environment context it has. The context is determined by the environment context of the process parent. So a common way to ensure your .profile environment variables are available in Emacs when it is run from the dock is to use a shell wrapper script which first sources .profile to create and export the variables in .pofile and then run emacs. Often you won't just make it a login shell, but simply source .profile. It is this script which is added to the dock and is executed to start Emacs, ensuring it has your .profile variables set and exported to the child process, Emacs. In turn, any child processes created by Emacs will also include this environment context (such as wehn you open an emacs terminal, run M-x shell or execute org source blocks). The other approach is to just add the variables you need using 'setenv' i your emacs init.el file. Often, there are only a few additional variables you want inside of Emacs and child processes it creates, so adding them to your init.el file is not hard. The one which is most often needed is updates to the PATH variable to add additional directories to search for executable files. You can use setenv to do this or you can use the exec-path package or you can do what I do, which is add these additional paths to /etc/paths.d. I don't bother with the wrapper script on the Mac. There are only a couple of additional variables I need defined, so I set them in my init.el using setenv. -- Tim Cross
Re: How to get shell source blocks to read my profile?
George Mauer writes: > Thanks a lot! The interactive/non-interactive was indeed the core issue. > Extra frustrating because it seems like supplying `--rcfile` does nothing if > you > *do* use `-c` but *don't* use `-i`...ah ad-hoc cli design. > It certainly can seem rather ad hoc. However, it actually makes sense on some levels. If you use -c your telling the shell to execute a command and then exit. By definition, this is non-interactive. This is covered in the manual. Where it becomes confusing is when your mixing in different options as some override others. So, provided you include -i with -c, it will be forced into interactive i.e. -i overrides the non-interactive status added with -c. If you add -s, telling the shell to read input from stdin, you also override non-interactive status. The other possible solution to your situation is to ensure Emacs runs inside an environment which has all your exported variables i.e. inside your login shell environment. There are a few ways to do this, but probably the easiest is to create a script which opens a login shell, then calls Emacs (may need to use open - not sure) and Emacs will inherit your environment. Advantage is that processes you then spawn from within Emacs will also inherit that environment. You then add this script as the executable in the dock rather than calling Emacs directly. One thing to watch out for is that if your also using oh-my-zsh, it setups up some aliases with the name emacs which actually call emacsclient. This can be confusing as it means running just 'emacs' in the shell will run the alias and not actually run Emacs directly. Things can be even more confusing as there are also multiple ways to install Emacs on the mac and they are all slightly different with respect to how they setup things. What I find hardest with writing shell stuff is that I simply don't seem to do it much anymore. My brain cache is just too small and when I find it necessary to write a shell script again, all that knowledge has been flushed! Once upon a time, many moons ago, I could write shell scripts that used sed, awk, cut, uniq etc without even needing to look at the man pages. These days, I have to check the bash man page just to remember what the expr operators are! -- Tim Cross
Re: How to get shell source blocks to read my profile?
> unless one of the > options were specified. I think each is named specific to each shell name but > oftentimes you chain them together in practice. > There is also a difference between interactive and non-interactive shells. I suspect this is the root cause of your issue. The source block being run are non-interactive. -- Tim Cross
Re: How to get shell source blocks to read my profile?
nv | grep GIM > #+end_src > > #+RESULTS: > > That is *still* nothing! > > Sanity is restored slightly when I run > > #+begin_src shell :results list > bash --login -c env | grep GIM > #+end_src > > which *does* indeed visit ~.bash_profile~ but only slightly. > > What is going on, and is there a straightforward way in which I can get shell > block to read from a profile? -- Tim Cross
Re: Culling org files (notion of Types, many small vs few big files)
TRS-80 writes: > On 2021-03-04 16:11, Samuel Wales wrote: > I have some other custom agenda functions as well, for things like > periodic reviews (in the GTD sense) and others. Org's Agenda really > is essentially just like a database query engine when you get right > down to it (except storing in plain text of course). > I thinink I would agree with this. The agenda is a lotmore than just an 'agenda'. I tend to view it as a 'query result', which just displays my query in different ways. sometimes it is similar to what most people would think of as an agenda, but often it is 'something' completely different. -- Tim Cross
Re: org-capture-templates: %date is too long
Uwe Brauer writes:
>>>> "RP" == Robert Pluim writes:
>
>>>>>>> On Thu, 04 Mar 2021 15:22:21 +0100, Uwe Brauer
> said:
>Uwe> Sorry, you misunderstood me, this time string, inserts the time
> string,
>Uwe> when I execute the capture, but I want to extract the time string,
> when
>Uwe> the message was received. This is why I used
>Uwe> %:date
>Uwe> in my first attempt, that works but inserts
>Uwe> Tue, 2 Mar 2021 19:35:03 +0100
>
>Uwe> Which I find way too long.
>
>Uwe> Just
>Uwe> Tue, 2 Mar 2021
>
>Uwe> Would be fine or 02.03.2021
>
>Uwe> But not the hour, seconds etc
>
>> It looks like the %:date handling respects the
>> 'org-time-stamp-formats' variable, so if you can arrange for that to
>> be let-bound appropriately during the capture process, it might do the
>> right thing.
>
> Hm that variable is set to
>
> Its value is ("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
>
> So if I call with a prefix it inserts
> <2021-03-04 jue 21:19>
>
> But nothing like +0100
>
> I am not acquainted with let-bound (only with let)
>
> So are you saying I should may use defadvice to modify org-capture?
Capture templates allow inclusion of an arbitrary elisp expression with
%(EXP). You could try defining an elisp function which accepts %:date as
an argument (i.e. a string arg) and formats it using normal elisp date/time
functions and
returns the result as a string and then call that function within your
template?
--
Tim Cross
Re: Culling org files
TRS-80 writes: > On 2021-03-03 16:59, Samuel Wales wrote: > I have come to similar conclusion about "don't let org files get too > big." Besides agenda speed, I think it is just easier to > conceptualize things when each file covers only a limited scope, trees > are more shallow, etc. > > So, lately (last year or more), I have been trying a "many small (up > to perhaps medium)" instead of "few big" files approach (along with > some custom tooling) and it has been working /a lot/ better for me. I > really feel on top of things for the first time in a long time. My > agenda is not cluttered. I can focus on important things, while not > losing track of the rest, etc. > I agree with this. I have a similar approach. I consider the file system and org files to be the initial 'structure' and have many smaller files rather than a couple of very large ones. Only a subset of files play a role in the agenda (I'm still experimenting with two different approaches for this - one uses a couple of functions which can dynamically change the agenda list and the other uses a naming convention which is used as the basis of a search to determine what is included in the agenda. Final rsult will likely be a combination). My use pattern also constantly evolves as my requirements and priorities change. It is and probably always will be, a work in progress! -- Tim Cross
Re: Tips on maintaining history in Org Mode
David Masterson writes: > Tim Cross writes: > >> David Masterson writes: >> >> For me, my TODOs are setup so that they record a date stamp for when >> they were added and whenever they change state e.g. started, done, >> delegated etc. > > So, you use progress logging. Yes. > >> For non-TODO items, I will often put an inactive timestamp in the >> heading title. > > Do your headings become busy? > Some would feel they are 'busy'. I always put the timestamp at the beginning of the heading, so there is a regular pattern (not much different from the leading heading stars) and I've just got use to it, so I don't really see it now. > What would you use to then make a list of all meetings you had last year? For me, archiving is about data I'm unlikely to need again, but just in case I do, it is in the archive. I rarely look at my archives. However, when I do archive, I will usually archive into a 'year' file. So, to find all the meetings held in 2015, I would open that archive file and search for entries with the tag MEETING (I also have a tag for PHONE). -- Tim Cross
Re: Tips on maintaining history in Org Mode
David Masterson writes: > There are many ways of maintaining history in a group of Org files: > 1. Archive within a file > 2. Archive to a separate (archive) file > 3. Special TODO types for history > 4. Special TAG types for history > 5. etc. > > My question is, if you have meetings/phone calls as TODOs, what is the > preferred way to handle when they move into history so that, *much* > later, you can easily produce a list of all of the meetings/phone calls > with dates and times of them? The issue (I think) is, when you mark the > TODO as DONE, you lose the info of what the TODO was originally. > A lot will depend on your requirements. For me, my TODOs are setup so that they record a date stamp for when they were added and whenever they change state e.g. started, done, delegated etc. For non-TODO items, I will often put an inactive timestamp in the heading title. I also make extensive use of the ability to add timestamp entries as part of capture templates - for exmaple, my notes and even the file of bookmakrs (RUIs) I have. -- Tim Cross
Re: 'false' list item
Greg Minshall writes: > Tim, > >> If a line starts with a number, period and space, but that line is >> within a paragraph (i.e. no blank line above), then I don't think it >> should be interpreted as an enumerated list item. If this is what the OP >> is referring to, I would argue it is a bug. If it is a 'paragraph' >> starting with a number, period and space, then being interpreted as a >> list item would be 'normal'. > > i know this isn't precisely the discussion, but i use *unnumbered* > lists, and i most often have no blank line separating the list from the > paragraph above (or, indeed, below). i could get used to a modified > requirement, to reduce the false positives, but, would want heads up > (or, maybe, sigh, an option?). > There is no plans to change anything as far as I know. What I wrote was mainly to show why we have the situation and that any proposed solution has its own drawbacks. Bottom line, we cannot easily prevent the 'false' list item issue without introducing either other issues or adding some additional syntax to indicate list items, which defeats the 'plain' aspects which many appreciate in org. Even the proposed 'solutions' still suffer from false positives. The question is probably, how can we 'flag' possible false positives in a convenient manner. For example, it has been suggested that some form of highlighting for list elements might make it easier to spot a false element lurking in a paragraph of text. this could possibly be useful, but I also worry about adding more font-locking and highlighting due to the potential to degrade performance further. We already have people running into issue with performance in large org files. -- Tim Cross
Re: 'false' list item
Samuel Wales writes: > perhaps if there is no blank line above or below, then it could be not a list. > Initially, that was my thought as well. Unfortunately, it isn't quite that straight forward. Consider the list 1. Item 1 2. Item 2 3. Item 3 The second item has no blank line above or below, but it is a list item. With the blank line approach, the list would have to be 1. item 1 2. item 2 3. item 3 which I doubt many would like. What I guess is really needed is a list 'environment' - once you see the first list item, following a blank line, your in a list environment until the next blank line. However, then, if you have list items which are multi-line items, you cannot have a blank line between items as that would signal a new list environment. Personally, if the items are longer, visually, I do like a blank line between the items. So now either we need to add some sort of list 'marker' or we need something else, such as saying a list must be indented further than the surrounding paragraphs i.e. if you had (using loren ipsum for text) - Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. 1. Mauris ac felis vel velit tristique imperdiet. Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu. Phasellus at dui in ligula mollis ultricies. Integer placerat tristique nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu. Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et dictum nunc justo sit amet elit. - the 1. line is not a list, but - Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. Nullam tempus. Mauris ac felis vel velit tristique imperdiet. Donec at pede. Etiam vel neque nec dui dignissim bibendum. Vivamus id enim. Phasellus neque orci, porta a, aliquet quis, semper a, massa. Phasellus purus. Pellentesque tristique imperdiet tortor. Nam euismod tellus id erat. 1. Mauris ac felis vel velit tristique imperdiet. Pellentesque dapibus suscipit ligula. Donec posuere augue in quam. Etiam vel tortor sodales tellus ultricies commodo. Suspendisse potenti. Aenean in sem ac leo mollis blandit. Donec neque quam, dignissim in, mollis nec, sagittis eu, wisi. Phasellus lacus. Etiam laoreet quam sed arcu. Phasellus at dui in ligula mollis ultricies. Integer placerat tristique nisl. Praesent augue. Fusce commodo. Vestibulum convallis, lorem a tempus semper, dui dui euismod elit, vitae placerat urna tortor vitae lacus. Nullam libero mauris, consequat quis, varius et, dictum id, arcu. Mauris mollis tincidunt felis. Aliquam feugiat tellus ut neque. Nulla facilisis, risus a rhoncus fermentum, tellus tellus lacinia purus, et dictum nunc justo sit amet elit. --- the 1. is a list item i.e. being indented compared to surrounding text makes it a list item. Any further lines indented to that level or more (for sub lists) are also considered part of the list, until the next blank line. The problem with this of course is that if you have a sub-heading which only has a list of items, there is no surrounding text within that section, so how would you identify it was a list? The issue is, if we decide this is a bug, can we fix it? Is it a bug or is it just an accepted limitation of the org document format and what we have to do is ensure either no line starts with a '1. ' or we use something like a unicode character so that it doesn't look like a number+period+space and therefore not a list item? -- Tim Cross
Re: 'false' list item
Kyle Meyer writes: > Juan Manuel Macías writes: > >> If a line in a paragraph starts with a digit (or letter) + period + >> space, Org misinterprets that as a list item. I almost always notice >> this only when I export my document, which is a nuisance. >> >> I wonder if there is any standard solution to that, or if I'm missing >> something... All that occurred to me is this "preventive" solution, >> using `highlight-regexp': > > It seems that your approach would do a good job of helping you catch > cases that you don't want to be treated as lists. I'm not aware of any > related functionality in Org, so I don't think you're missing something > there. > > Once you know that there is a particular spot that you want to prevent > from being interpreted as a list, you could add a zero-width space in > front of it: > > (info "(org)Escape Character") > > I'm not sure if that's the sort of solution you're asking for, though. If a line starts with a number, period and space, but that line is within a paragraph (i.e. no blank line above), then I don't think it should be interpreted as an enumerated list item. If this is what the OP is referring to, I would argue it is a bug. If it is a 'paragraph' starting with a number, period and space, then being interpreted as a list item would be 'normal'. -- Tim Cross
Re: state of the art in org-mode tables e.g. join, etc
Greg Minshall writes: > John, > >> Is there a state of the art in using org-tables as little databases >> with joins and stuff? > > i have to admit i do all that with an R code source block. (the dplyr > package has the relevant joins, e.g. dplyr::inner_join().) and, in R, > ":colnames yes" as a header argument gives you header lines on results. > (maybe that's ?now? for "all" languages?) > For really complex joins and ad hoc queries, I would do similar or put the data into sqlite. For more simple ones, I just define a table which uses table formulas to extract the values from the other tables - the downside being the tables need to have the same data ordering or the formulas need to be somewhat complex. Provided the tables have the same number of records in the same order, table formulas are usually fairly easy. I did think about writing some elisp functions to use in my table formulas to make things easier, but then decided I was just re-inventing and well defined database solution and figured when I need it, just use sqlite. However, it has been a while since I needed this level of complexity, so perhaps things have moved on and there are better ways now. -- Tim Cross
Re: Turning off all indentation in 9.4.4
Kyle Meyer writes: > TRS-80 writes: > >> On 2021-02-04 12:45, Kévin Le Gouguec wrote: > [...] >>> ORG-NEWS provides these hints: >>> >>>> To get the previous behaviour back, disable ~electric-indent-mode~ >>>> explicitly: >>>> >>>> #+begin_src emacs-lisp >>>> (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) >>>> #+end_src >>>> >>>> Alternatively, if you wish to keep =RET= as the "smart-return" key, >>>> but dislike Org's default indentation of sections, you may prefer to >>>> customize ~org-adapt-indentation~ to either =nil= or ='headline-data=. > [...] >> Unfortunately, unless I am doing something wrong, none of these options >> seem to really restore the previous behavior. I have set >> ~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes >> to column 0. However, unfortunately, TAB now no longer jumps to the >> indentation level of the previous block (for example, so I can insert a >> code block or other block structure into a plain list at the correct >> level). > > I think you're talking about the following behavior. > > * a > foo > > With org-adapt-indentation at nil (or the new headline-data value), foo > doesn't get indented. This behavior is not new to 9.4. If you try with > 9.3.8 and org-adapt-indentation is set to nil, it also will not indent. > Step through org--get-expected-indentation to see how the different > values of org-adapt-indentation are handled. > > So, if I'm reading your preferences correctly, it sounds like you want > just the first suggestion in the above snippet, leaving > org-adapt-indentation at its default value: > > (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) I think it might be slightly more complicated. For me, here is what I would like 1. Draws and planning data indented according to the headline level (i.e. headline-data) 2. No indentation on 'normal' lines UNLESS I indent the first line of the paragraph/block. Then, once I do indent that first line, after hitting return, I can hit tab and it will indent to the same level as the proceeding line. I thought this was the behaviour I use to have before org was updated to comply with electric-indent mode. I could be wrong. Currently, if I have org-adaptive-indent set to 'heading-data, if I manually indent a line, I cannot indent subsequent lines to the same level. Tab does nothing and I have to hit spaces. I need to go back through the possible combinations to make sure I didn't miss something. However, it seems I can have drawers/planning lines indented to the headline level with org-adaptive-indent set to heading-data, but then cannot indent individual paragraphs/blocks inside the heading with tab or I set org-adaptive-indent to nil and manually indent the draw/planning lines and then can manage content indentation as I use to. None of this is critical as it is really just aesthetics (i.e. does not affect exports), but it did seem to be more DWIM before than it is now. -- Tim Cross
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > hi tim, > > tanks for your replies. > > 1. the same problem occurs without any * in the buffer. It will occur with any of the markup special characters e.g. *, =, _, +, / > > 2. the emphasis regexps are supposed to be limited to a few lines. Are they? What is 'a few'? This also won't work if you use visual-line-mode and don't use auto-fill (as your paragraphs are then just one long line). > > 3. they are also supposed to not try to match dissimilar delimiiters. > Not quite sure what you mean here. > the problem is that > > hi =something > > stops all emphasis of all types in the entire rest of hte bguffer even > if the buyffer contains many lines. this sems unusual to me. > > it does not break anything befofre it. > > so i think your hypothesis of what i am talking about might possibly > not match what i am talking about at all. > I'm not disagreeing with what your saying. I think the reason the rest of the file doesn't get parsed correctly is because the single markup character has made the syntax inconsistent and broken. The problem is I don't think there is a good fix for this which doesn't introduce other problems. If the regexp which does the matching is supposed to limit its search to just a specific number of lines, then perhaps it is broken. However, I'm not sure what 'a few lines' really means (2?, 5?, 10?). I also know from past experience that trying to define font-lock matches which work in such a way is complex, error prone and often results in a considerable performance hit. Bottom line, if you want to use the characters reserved for markup purposes as just plain characters, you have to somehow quote them or mark them as being 'verbatim' characters. I do think it would be useful to have something in the manual on this under the markup section. -- Tim Cross
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > to answer your question: i expected it to just skip the non-emphasis. > not emphasizing the rest of the buffer seemed quite unusual. > I guess the problem is the same - how does org know when it is just a * and when it is the beginning of some emphasis text? We could make it that such markup only works on words, allowing the code to only consider two * as emphasis if there are no spaces, otherwise treat as just a *, but that would be inconvenient when you want to emphasis a phrase or a couple of words. We could change the regexp to only consider it an emphasis block if both markers are on the same line, but again, potentially inconvenient and it would fail for those who use visual-line mode where there paragraphs are just 1 long line. In short, can understand what your saying, but not sure there is a viable fix which doesn't have a heap of other consequences. Basically, if you want to use the 'markup' characters as normal characters, you need to either escape them or put them inside a verbatim directive. -- Tim Cross
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > hi tim, > > it isn't malformed, so definitely not looking to be told it's > malformed. it is just text that is not emphasis. > > if you think the function works as expected by skipping the rest of > the buffer, then never mind. > > i was, in that case, just emphasizing that the code floating around > that is used to fontify the agenda is going to break. so nm. > OK, that makes more sense. I guess you need to escape the * e.g. \* to turn off its 'special' meaning or put it between = to make it a 'verbatim' value. To be honest, I've never run into this issue, but I tend to not use '*' in my text unless it is for emphasis. -- Tim Cross
Re: [bug] org-do-emphasis-faces breaks with incomplete emphasis
Samuel Wales writes: > in fundamental mode [to eliminate any extra stuff]: > > === > hi > /hi/ > hi =test > hi > hi > hi > /hi/ > hi > *hi* > hi > hi > hi > === > > m-: (org-do-emphasis-faces nil) RET > > everything after =test does not get emphasized. > > there is code floating around that calls hte function directly instead > of via font lock. so even if font lock or org mode forgive this, that > code does not seem to. and idk whether it is forgiven or if there are > unintended consequences. > > e.g. to emphasize in agenda. which, not sure why it isn't? I'm not clear on what you are expecting/wanting here. If you have badly formed markup, syntax highlighting and other functions can be expected to fail. Are you expecting something more informative, like an error message saying you have an unterminated emphasis marker or similar? If so, while it might be possible, I suspect it would come at a high cost from a performance perspective, especially in large org files. For example, at what point do you decide the closing marker is missing rather than just a little further along? At what point do you begin doing the checking - after typing the first marker, after the first character, after the first space (noting that all this checking comes at a performance cost)? What does org-lint tell you when you have such malformed markup in your document? Would that be sufficient to track down issues when they occur? If org-lint is not picking it up or is not providing enough detail to help resolve the issue, perhaps tweaking it would be worthwhile. -- Tim Cross
Re: Turning off all indentation in 9.4.4
TRS-80 writes: > > I have been struggling with this as well. After reading this email, I > gave it another try. > > Unfortunately, unless I am doing something wrong, none of these options > seem to really restore the previous behavior. I have set > ~org-adapt-indentation~ to ~'headline-data~, and now pressing RET goes > to column 0. However, unfortunately, TAB now no longer jumps to the > indentation level of the previous block (for example, so I can insert a > code block or other block structure into a plain list at the correct > level). > I can report I'm seeing the same behaviour. While now I only get indent after a heading, I cannot hit tab to indent to the same level as the last line to insert things like a code blcok or even a new paragraph at the same indent level. -- Tim Cross
Re: [PATCH] tweaks to ox-html style
Jens Lechtenboerger writes: > On 2021-02-12, Kyle Meyer wrote: > >> TEC writes: >> >>> Hi All, >>> >>> This is just some tweaks to the styling in ox-html that I think may >>> appeal (and prevent ridiculously long lines on non-small displays, which >>> are an issue for legibility). >>> >>> I also took the opportunity to remove the (obsolete) CDATA strings and >>> make the CSS more consistently formatted. If you don't want this to >>> get its own commit, please just squash it. >>> >>> Style changes: >>> - Restrict max content width, and centre >>> - tweak styling of source code blocks >> >> I'm sure there are plenty of opinionated ox-html users on the list. Is >> anyone willing to provide feedback on this series? Please don't assume >> you need commit access to provide reviews. > > Hi there, > > I do not know why the CDATA lines exist. I don’t see a reason to > keep them (patch 0001), but that might be a lack of understanding on > my part. > > Patch 0003 is about whitespace fixes. > > Patches 0002, 0004, 0005 change defconst styling. I don’t have a > strong opinion here. However, if they are changed now, what about > turning them into defcustoms? Then each of us would be entitled to > their own opinion ;) > > The docstring for org-html-head-include-default-style says that > org-html-style-default (a defconst proposed to be changed here) > should not be changed. Why not? > I think I pretty much agree here. IMO I think all the CSS styling in an export should be defined with defcustom. CSS has come a long way since the original HTML exporter was written and I think it is best to put this power in the hands of the author. I realise some of this CSS styling can be complex if we want good looking HTML exports and making it available to be changed by the user could result in an increase in issues relating to inconsistent or ugly output, but I think provided the defaults are good, this risk is warranted. My only question is whether we should continue to modify the current html exporter or whether it would be better to rename the existing exporter as xhtml exporter and do a new clean html exporter that is just html5 and css3 and which does not attempt to be xhtml compliant? Others have mentioned on the list that they believe it is important to keep xhtml compatibility. This would satisfy that requirement and at the same time, enable a new html exporter that can take full advantage of changes introduced with html5 while keeping the exporter smaller and cleaner (and easier to maintain). BTW I think it would be nice if the html export was able to produce/use a separate CSS file rather than in-line styles. This would make it easier to drop exported HTML files into existing sites with custom styles or update the look of exported files without needing to re-export or manually edit. The complication is with exporting of HTML snippets, where you probably want in-line styles. -- Tim Cross
Re: OT: M-S-$ Not Working
Maxim Nikulin writes: >> Were you able to get any assistance with this on the Emacs devel list? > > There was a thread in 2009, no results however. Unsure if it reasonable > to raise the question again without a proposal how to solve the problem. > > https://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00031.html > I think it would be worth raising again. There has been significant changes since 2009 (that message was prior to Emacs 23 release), especially with respect to CJK, MULE, UTF-8 and input methods. It is possible new solutions are now available. -- Tim Cross
Re: OT: M-S-$ Not Working
Maxim Nikulin writes: > On 06/02/2021 13:28, Tim Cross wrote: >> >> In general, standard Emacs key bindings are robust and reliable. If a >> standard key binding like M-S $ doesn't work, first step is to try emacs >> -Q. > > Sorry, but I do not agree that key bindings are robust in emacs. I use > English and Russian keyboard layouts. Last years most of application > could handle shortcuts independently of active layout (E.g. Ctrl+C and > Ctrl+V works for copy-paste even if Russian layout is currently chosen.) > In Emacs, only Control + Latin C works, Control + Cyrillic S (the same > physical key) is undefined. Location of punctuation symbols depends on > active layout, "$" is absent in Russian layout at all. It is extremely > inconvenient to switch to US layout before any shortcut. Emacs uses its > own input methods, but it means that desktop environment should treat > emacs in a special way in respect to keyboard layouts. I have a kind of > solution, I found its variants in blog posts. It is quite tricky, so I > do not consider it as reliable and suitable for any user. As I'm limited by the weakness of only understanding one alphabet, I don't have any experience of things once you move away from an 'english' based alphabet. However, I do find it surprising there isn't a simpler solution to switch between the different layouts in a consistent way which updates key bindings to something appropriate. I've not seen many editors with the same level of support for different alphabets and writing direction as Emacs and there are many keyborad layouts which don't include the '$' key. At the end of the day, it really just comes down to mapping of key codes - the 'image' on the key itself (and even the location) is largely irrelevant. I imagine 'live' switching between different input methods could be very complicated, but making the complicated easy is something Emacs tends to be good at. Were you able to get any assistance with this on the Emacs devel list? Like it or not, computers are very english centric (and US english at that). Maybe the issues you have encountered just need to be highlighted and for there to be someone able to assist to enable the situation to be improved? It may be a simple as improving the mapping of key codes and tweaking the key translation table to improve the situation? If you haven't done so, I would encourage you to start a new thread on emacs-devel where you outline your key binding issues. I have frequently found solutions on blogs and other forums only to find later there is a far easier solution. I would expect many Russian speaking users have encountered the same challenges. The Emacs devs have always seemed pretty open to improving support for different languages and character sets and once they understand the issue, will typically respond with improvements fairly quickly provided someone is will ing to help test etc. The hard part is defining the issue - once it is understood, a solution is often not too far away. -- Tim Cross
Re: OT: M-S-$ Not Working
Marcin Borkowski writes: > Hi Bo, > > I know your problem is resolved now, but in case you don't know, check > also what `C-h c' does (and `C-h k' is also useful at times). In > general, spending 20 minutes on looking through what `C-h C-h' says > might save you some trouble later;-). > This is good advice. I would add that if you find that Emacs does not respond, even to say that the key is not bound or defined, it is typically a sign that something in the environment e.g. window manager or X (or Wayland) layer is not passing the key press through. These are layers which are often overlooked and I've seen people spend hours inside Emacs trying to work out what the issue is, only to later find it is at a different layer (OS, windowing environment, window manager, etc). In general, standard Emacs key bindings are robust and reliable. If a standard key binding like M-S $ doesn't work, first step is to try emacs -Q. If that still does not work, odds are high it is an issue outside of Emacs. Most common causes are WM shortcuts, modified input device definitions (as seems to be the culprit here) and modified modmap settings. Utilities like 'xev' can be useful here (not sure what wayland has). When I install a new system (regardless of platform, linux, mac, windows), my first task is usually to remove or remap shortcuts. These days, most environments use super, alt, meta and control based shortcuts, many of which interfere with my Emacs. I rarely use super in my Emacs key bindings, so often I remap useful WM shortcuts to use super. -- Tim Cross
Re: Free up C-c SPC/org-table-blank-field?
Eric Abrahamsen writes: >> Does it actually need a key binding? I've never used it and just use >> to move to the next field, leaving the field blank. > > I assume it's meant for blanking a field you've already typed something > into. But yes, I can't imagine it's a heavily-used command, and I > suspect the C-c binding is mostly mnemonic: "make this field > contain only blanks". > I guess that makes sense, but not convinced the use of a valuable key binding is justified given the need. Then again, others probably have vastly different use cases to mine. >>>> >>>> What do people think about making it a no-op when not on a table >>>> (letting it fall through to the global map), or putting it in a keymap >>>> text property on tables, or otherwise not hogging the binding? >>> >>> In my view, the first would be fine, and the second also unless someone >>> chimes in with a technical reason not to. For the last, perhaps `C-c >>> C-SPC' would be an okay replacement, though I'd assume that would break >>> some users' muscle memory in a surprising and unpleasant way. >> >> I'm not familiar with how this is all put together inside org mode. >> If it is possible to configure things so that it is only bound when >> inside a table and does not shadow other bindings for that sequence >> outside a table, I think that would be a positive change. However, I do >> also note that this is the type of change which tends to cause 'ripples' >> and may have unexpected impact in other areas, such as other packages, >> predefined or 'canned' emacs configurations etc. > > The way Org handles these situations now is to have a command that is > named for its actual keybinding (eg `org-shiftmetaleft'), which then > examines its context and dispatches to various other functions. That's a > bit odd and not really how it's done in Emacs -- but I am not proposing > we change this as it is pretty fundamental to how Org is set up and > would wreck a bunch of stuff if it were changed. > > I thought Emacs might have some easy way to let a key event "fall > through" to other keymaps, but I haven't been able to find anything > immediately obvious. Maybe I can ask on emacs.devel... > I don't believe there is one. I think the basic model is a hierarchy of key maps with bindings and the first match wins. I guess the only option is to add a more sophisticated context test and only perform the action if the context is inside a table cell. If not inside a table cell, either perform some function which makes sense. It could be that on loading, org checks to see if there is a binding and stores that as the default action outside of tables or if we have some action which would make sense, bind to that or keep it simple and have it defined as a user option which defaults to a noop and allow the user to define something if they want? Since switching to spacemacs and its 'evil' key binding model, I've become very aware of the dangers associated with modes that try to be too clever when it comes to key bindings. I think they are really quite a personal thing and best kept as simple as possible. In general, org has been reasonably successful with its rather 'advanced' approach, but there have been times I've found it frustrating. Smart key bindings are great when they do what you expect, but when they don't -- Tim Cross
Re: OT: M-S-$ Not Working
Bo Grimes writes: > I beg your indulgence. I am confident this isn't an Emacs problem, let > alone an org problem, but my eyes hurt from searching for an answer, > and this list, the only one I subscribe to, is populated with gurus. I > promise never to use it this way again. > > OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter > GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) > > M-S-$ does not spellcheck word. It will work from the menu bar, and it > will work if I drop into a tty and run Emacs. Emacs gives no > response in the minibuffer in the GUI when I press M-S-$. M-x > describe-key M-S-$ does nothing. C-h b C-s 'spell' reveals that indeed > M-S-$ is bound to spellcheck word. And other M-S- keys work like M-S-> > just fine. > > There has to be some keybinding outside Emacs taking precedence. I have > gone through dconf-editor until my eyes bleed. Done gsettings > list-recursively org.gnome.desktop.wm.keybindings | sort | more and > gone line by line. I have done dconf dump / > dconf.dump and read > through them all, in addition to checking PopOS' keybindings in > Settings. And trying a different keyboard. > > Nothing in Tweeks, dconf, or Settings uses M-S-$, but I disabled > anything that uses Shift anyway (nothing uses $). No joy. I don't want > to rebind it for this machine only, nor do I want to go through the > hassle of installing a different DM/WM. > > StackExchange, et.al are full of problems with the the M key, but not > one specific keychord only. > Do you see the same behaviour if you run emacs -Q? -- Tim Cross
Re: patch: ob-clojure improvements
OK. As the patch is over 6 months old, it would be good if the original
author can confirm it is still the latest version and if not, re-send
the most recent version.
Christopher Miles writes:
> <#secure method=pgpmime mode=sign>
>
> I checked this thread, seems the original first email of thread contains the
> patch. And it's not merged into Org git yet.
>
> Tim Cross writes:
>
> OK, will push it up the todo list. Where can I get the latest version of the
> patch or has it been added into the org git repo?
>
> Christopher Miles writes:
>
> <#!secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review.
>
> Tim Cross writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements.
> However, right now, I'm a tad busy and haven't had time to review what has
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source,
> some guidance would be appreciated.
>
> Org Mode has contribution guide here
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go
> incrementally, one small change at a time, or should I just get everything
> working first? If it turns out to be a bigger work, should I ask for
> permission to work in a branch and get access to pushing things to it? Maybe
> things just move slowly, because obviously you can't force maintainers to
> drop everything and concentrate effort to get your things in. Maybe I just
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support for
> ob-clojure.el - Adds a header parameter to override org-babel-clojure-backend
> - Adds :args param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
> {:mvn/version \"0.13.2\"}}}'" (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I have
> never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
Tim Cross
Re: Free up C-c SPC/org-table-blank-field?
Kyle Meyer writes: > Eric Abrahamsen writes: > >> Hi all, >> >> The C-c SPC keybinding is pretty prime property (it's also, according to >> Emacs conventions, meant to be reserved for the user, though I know >> that's already out the window with Org), > > Based on my reading of (info "(elisp)Key Binding Conventions"), I think > `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but > instead into the this group: > > Sequences consisting of ‘C-c’ followed by any other ASCII > punctuation or symbol character are allocated for minor modes. > Using them in a major mode is not absolutely prohibited, but if you > do that, the major mode binding may be shadowed from time to time > by minor modes. > Agreed. > But, either way, I don't disagree with what you say next. > >> and it's currently bound to `org-table-blank-field', which is useless >> unless you... happen to be in a table. I don't use tables often (or >> blank fields when I do), which means this binding is effectively just >> removed. Does it actually need a key binding? I've never used it and just use to move to the next field, leaving the field blank. >> >> What do people think about making it a no-op when not on a table >> (letting it fall through to the global map), or putting it in a keymap >> text property on tables, or otherwise not hogging the binding? > > In my view, the first would be fine, and the second also unless someone > chimes in with a technical reason not to. For the last, perhaps `C-c > C-SPC' would be an okay replacement, though I'd assume that would break > some users' muscle memory in a surprising and unpleasant way. I'm not familiar with how this is all put together inside org mode. If it is possible to configure things so that it is only bound when inside a table and does not shadow other bindings for that sequence outside a table, I think that would be a positive change. However, I do also note that this is the type of change which tends to cause 'ripples' and may have unexpected impact in other areas, such as other packages, predefined or 'canned' emacs configurations etc. -- Tim Cross
Re: patch: ob-clojure improvements
OK, will push it up the todo list. Where can I get the latest version of
the patch or has it been added into the org git repo?
Christopher Miles writes:
> <#secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review.
>
> Tim Cross writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements.
> However, right now, I'm a tad busy and haven't had time to review what has
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source,
> some guidance would be appreciated.
>
> Org Mode has contribution guide here
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go
> incrementally, one small change at a time, or should I just get everything
> working first? If it turns out to be a bigger work, should I ask for
> permission to work in a branch and get access to pushing things to it? Maybe
> things just move slowly, because obviously you can't force maintainers to
> drop everything and concentrate effort to get your things in. Maybe I just
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support
> for ob-clojure.el
> - Adds a header parameter to override org-babel-clojure-backend - Adds :args
> param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
> {:mvn/version \"0.13.2\"}}}'"
> (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I
> have never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
Tim Cross
Re: bug#44824: 27.1; Org export as pdf and open file does not open it
Lars Ingebrigtsen writes: > Eli Zaretskii writes: > >>> This doesn't work: >>> M-x shell RET xdg-open /tmp/test.pdf RET >> >> How about asking the xdg-open developers to help us figure out the >> reason? Or, failing that, debug xdg-open in the problematic >> situations to find out what fails there and why? E.g., could it be >> that it fails because stdin/stdout is a PTY? what happens if you bind >> process-connection-type to nil when starting the async subprocess? > > I'm unable to reproduce the problem at all -- all the various ways of > calling xdg-open work fine for me (on this Debian bullseye laptop w/ > Gnome Shell). For me, I get M-! xdg-open /tmp/test.pdf works M-x shell xdg-open /tmp/test.pdf works M-& xdg-open /tmp/test.pdf fails M-x eshell xdg-open /tmp/test.pdf fails The two which fail do not report any error - just now pdf viewer open. I also have no problems with org export menu when I choose export to pdf and open. This was on a Ubuntu 20.10, latest Emacs 27 (27.5.91), mate DE and default shell zsh. -- Tim Cross
Re: [PATCH] ox-md.el export code blocks using grave accents.
I don't think this patch is correct.
There are no precise standards for markdown, but org states in the
manual that the version of markdown it supports is that defined at
http://daringfireball.net/projects/markdown - which uses the indentation
style for code blocks, not the style. Note that there is the github
markdown exporter which does support the style.
One of the problems with markdown is the differing flavours out there.
While may be supported on sites like github and stackoverflow,
other sites only support the indentation style. We therefore need to be
somewhat conservative with respect to introducing changes as while we
may 'fix' things for some sites, we could easily break them for others.
Given there is a package which supports the style code blocks, I
don't think modifying the existing markdown exporter is necessary.
>From your explanation, I suspect what you really need is to use the
github flavoured markdown package available as ox-gfm on MELPA rather
than the default ox-md package in org mode.
Note that I have no particular preference for the markdown style defined
on daringfireball.net and there has been past discussions on this list
regarding what flavour of markdown org should support, so I know there
are varying opinions in this area. My main point is that if we specify
in the manual that we support a particular flavour, then that is the
flavour of markdown we should support. In other words, if we are going
to add features/support for syntax not defined on the daringfireball.net
flavour of markdown, we would need to document what syntax we do support
and consider things like backwards compatibility for any changes introduce.
Rodrigo Morales writes:
> This patch includes the following changes in =ox-md.el=
>
> + =org-md-example-block= now exports code blocks using triple grave
> accents instead of four spaces of indentation. This has been done
> for two main reasons:
>
> 1. To be able to include the language so that Markdown engines can
> syntax highlight the content of code blocks. Syntax highlighting
> can also occur when using indentation in some websites (see
> [[https://meta.stackexchange.com/questions/184108][this]]. However,
> this method doesn't work in all websites (I haven't found
> information about this on Github.). Therefore, using grave accents
> is more generic.
>
> 2. To be able to put the source code and the results of evaluation
> in different code blocks. When using indentation, both the source
> code and the results are shown in the same code block by Markdown
> engines.
>
> + The variable =org-md-lang-export= is now included in order to map
> Org Mode language names to Markdown language names.
>
> The file =mre.org= contains a minimal reproducible example; =mre.md= ,
> the resulting file when exporting using the current version; and
> =mre-patch.md=, the resulting file when exporting with the changes
> of this patch applied.
>
> The patch is shown below.
>
> #+begin_src dash :dir (progn default-directory) :epilogue ":"
> gunzip -c /usr/share/emacs/27.1/lisp/org/ox-md.el.gz > ox-md.el
> diff -u ox-md.el ox-md-patched.el
> #+end_src
>
> #+RESULTS:
> #+begin_example
> --- ox-md.el 2021-01-30 16:49:33.459042367 -0500
> +++ ox-md-patched.el 2021-01-30 16:48:40.232375347 -0500
> @@ -50,6 +50,14 @@
> (const :tag "Use \"atx\" style" atx)
> (const :tag "Use \"Setext\" style" setext)))
>
> +(defcustom org-md-lang-export
> + '(("dash" . "sh"))
> + "Alist mapping languages to the corresponding language names in Markdown."
> + :group 'org-export-md
> + :type '(repeat
> + (cons
> +(string "Org Mode language name")
> +(string "Markdown language name"
>
> Footnotes
>
> @@ -181,10 +189,24 @@
>"Transcode EXAMPLE-BLOCK element into Markdown format.
> CONTENTS is nil. INFO is a plist used as a communication
> channel."
> - (replace-regexp-in-string
> - "^" ""
> - (org-remove-indentation
> -(org-export-format-code-default example-block info
> + (let* (language
> + (org-language
> + (plist-get (car (cdr example-block)) :language))
> + (markdown-language
> + (cdr (assoc org-language org-md-lang-export))) ;
> + (content
> + (org-remove-indentation
> +(org-export-format-code-default example-block info
> +
> +(if markdown-language
> + (setq language markdown-language)
> + (setq language org-language))
> +
> +(setq content (replace-regexp-in-string
> + "\\`" (concat "```" language "\n")
> + content))
> +
> +(replace-regexp-in-string "\\'" "```" content)))
>
> (defun org-md-export-block (export-block contents info)
>"Transcode a EXPORT-BLOCK element from Org to Markdown.
> #+end_example
--
Tim Cross
Re: How to avoid generating the Table of Contents when exporting to markdown?
Rodrigo Morales writes: > When answering questions in Emacs Stack Exchange, I usually write my answer > in Org Mode and then export it to Markdown so that I can copy it to the > answer textbox in Stack Exchange. For this reason, I don't need the > export to contain a Table of Contents because the Markdown content is > not big enough to require it. > > For this reason, I don't want the Table of Contents to be included when > exporting. You can try putting #+OPTIONS: toc:nil in the header of your org file. This is covered in the 'Table of Contents' sub-section of the Exporting section of the org manual. -- Tim Cross
