Re: [PATCH] Re: the comment environment does not work for checkboxes
Uwe Brauer writes: >> Uwe Brauer writes: > > Thanks for the patch (this is against the latest master I presume?) >> Thanks for the heads-up! >> Comment blocks are not supposed to contain Org markup, and thus it indeed >> makes sense to support them in org-edit-special and in structure >> templates. > >> See the attached patch. > > I test and report back: BTW > > 1. The feature I require can only be achieved by using a «src» block >not a comment block. A bit contra intuitive I say I am sorry, but I am not familiar with the feature you are referring to. Either way, both src and comment blocks are supposed to contain arbitrary non-parseable text, which should not contribute to the statistics? calculations. > 2. Suppose I once mark a lot of headings and add a src block (which >add the required «,» to the *, how do I later get rid of the src >block *and* the «,» AFAIK, you cannot. At least, not using an existing command. What you can instead do is open C-c ' window, copy the unescaped text, exit the window, remove the block, and yank the unescaped text. Best, Ihor
Re: [PATCH]: ox-latex: omit empty date
em...@vergauwen.me writes: > The updated (and still untested) patch is attached to this mail. Well. The patch is simple enough to not worry too much about checking. And the tests are passing. Applied onto main via a753d0dd2. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a753d0dd26018a951fe21548ae6b513594b570a8 Also, we have a record that you have the FSF copyright assignment. Is it still the case? If you have, you do not need to put TINYCHANGE cookie. Best, Ihor
Re: [PATCH] Re: the comment environment does not work for checkboxes
> Uwe Brauer writes: Thanks for the patch (this is against the latest master I presume?) > Thanks for the heads-up! > Comment blocks are not supposed to contain Org markup, and thus it indeed > makes sense to support them in org-edit-special and in structure > templates. > See the attached patch. I test and report back: BTW 1. The feature I require can only be achieved by using a «src» block not a comment block. A bit contra intuitive I say 2. Suppose I once mark a lot of headings and add a src block (which add the required «,» to the *, how do I later get rid of the src block *and* the «,» Uwe smime.p7s Description: S/MIME cryptographic signature
[PATCH] Re: the comment environment does not work for checkboxes
Uwe Brauer writes: > Thanks, a couple of remarks > > 1. It does not work! I Presume you mean «C-c '» no «C-c C-'»? Well >this is bound to is edit special > ... > > Comments block are not listed and as I said it seems not to work, if > what you say is the correct syntax, then there is a bug, since > > 1. when I mark the region, > > 2. Run org-insert-structure-template, > > 3. Select comment, it should then lead to Thanks for the heads-up! Comment blocks are not supposed to contain Org markup, and thus it indeed makes sense to support them in org-edit-special and in structure templates. See the attached patch. Best, Ihor >From 4913df3f84b6d1d0fc5cc0f613dca42abe47821d Mon Sep 17 00:00:00 2001 Message-Id: <4913df3f84b6d1d0fc5cc0f613dca42abe47821d.1659158779.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 30 Jul 2022 13:24:10 +0800 Subject: [PATCH] Support interactive editing of comment blocks * lisp/org-src.el (org-edit-comment-block): New command to edit comment block elements. The command auto-escapes Org markup inside. (org-src--contents-area): * lisp/org.el (org-insert-structure-template): (org-edit-special): Support comment blocks. * etc/ORG-NEWS (Interactive commands now support escaping text inside comment blocks): (New command ~org-edit-comment-block~ to edit comment block at point): Document the new features. See https://orgmode.org/list/87y1wc3ruw@mat.ucm.es --- etc/ORG-NEWS| 19 ++- lisp/org-src.el | 25 - lisp/org.el | 5 - 3 files changed, 46 insertions(+), 3 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 478fcf95c..0bc3fa638 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -141,6 +141,14 @@ discouraged when working with Org files. ** New features +*** Interactive commands now support escaping text inside comment blocks + +~org-edit-special~ and ~org-insert-structure-template~ now handle +comment blocks. + +See [[*New command ~org-edit-comment-block~ to edit comment block at +point]]. + *** New customization option =org-property-separators= A new alist variable to control how properties are combined. @@ -253,6 +261,16 @@ instance, includes all available items in the printed bibliography. ** New functions and changes in function arguments +*** New command ~org-edit-comment-block~ to edit comment block at point + +As the contents of comments blocks is not parsed as Org markup, the +headlines and keywords inside should be escaped, similar to src +blocks, example blocks, and export blocks. This in inconvenient to do +manually and ~org-edit-special~ is usually advised to edit text in +such kind of blocks. + +Now, comment block editing is also supported via this new function. + *** New function ~org-element-cache-map~ for quick mapping across Org elements When element cache is enabled, the new function provides the best @@ -266,7 +284,6 @@ to ~org-element--cache-map-statistics~ and ~org-element--cache-map-statistics-threshold~. ~org-scan-tags~ and tag views in agenda utilise the new function. - *** New function ~org-element-at-point-no-context~ This function is like ~org-element-at-point~, but it does not try to diff --git a/lisp/org-src.el b/lisp/org-src.el index b7e0af50e..0249af60b 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -384,7 +384,7 @@ (defun org-src--contents-area (datum) (let ((beg (org-element-property :contents-begin datum)) (end (org-element-property :contents-end datum))) (list beg end (buffer-substring-no-properties beg end - ((memq type '(example-block export-block src-block)) + ((memq type '(example-block export-block src-block comment-block)) (list (progn (goto-char (org-element-property :post-affiliated datum)) (line-beginning-position 2)) (progn (goto-char (org-element-property :end datum)) @@ -1161,6 +1161,29 @@ (defun org-edit-export-block () (lambda () (org-escape-code-in-region (point-min) (point-max) t)) +(defun org-edit-comment-block () + "Edit comment block at point. +\\ +A new buffer is created and the block is copied into it, and the +buffer is switched into Org mode. + +When done, exit with `\\[org-edit-src-exit]'. The edited text \ +will then replace the area in the Org mode buffer. + +Throw an error when not at a comment block." + (interactive) + (let ((element (org-element-at-point))) +(unless (and (eq (org-element-type element) 'comment-block) + (org-src--on-datum-p element)) + (user-error "Not in a comment block")) +(org-src--edit-element + element + (org-src--construct-edit-buffer-name (buffer-name) "org") + 'org-mode + (lambda () (org-escape-code-in-region (point-min) (point-max))) + (org-unescape-code-in-string (org-element-property :value element))) +t)) + (defun org-edit-src-code ( code edit-buffer-name) "Edit the source or example block at point. \\ diff --git a/lisp/org.el b/lisp/org.el index
[SOLVED: src not comment] (was: the comment environment does not work for checkboxes)
>>> "AB" == Arne Babenhauserheide writes: > Uwe Brauer writes: >> #+BEGIN_COMMENT >> WAIT Computer >> :PROPERTIES: >> :Nr: 4 >> :Comp1:[X] >> :Comp2:[X] >> :END: >> #+END_COMMENT >> Does not. Any idea why? > In a block, you must escape * as ,* — open the environment with C-c C-' > and save it the same way, then it escapes them for you. Your recommendation works if I use a *src* block not a *comment* #+begin_src ,** Computer :PROPERTIES: :Nr: 4 :Comp1:[X] :Comp2:[X] :END: #+end_src Is ignored! I found that contra intuitive. BTW how to get rid of the block? Just deleting #+begin_src and #+end_src Does not help since «*» would still carry the «,» I could run a query-replace, but this seems cumbersome! regards -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ob-tangle.el: fix ‘:comments noweb’ double linking
Hraban Luyat writes: > This is my first org-mode patch, all comments welcome :). I signed a > copyright assignment to the FSF 2021-07-12. Thanks for the contribution! Bastien, could you please check the FSF records? The patch looks good in general. Few minor comments below. > * lisp/ob-tangle.el: Refactor the double implementation to a single > helper function. This avoids the double link wrapping. > * testing/lisp/test-ob-tangle.el: Add unit tests. > > Babel tangle allows inserting comments at the tangled site which link > back to the source in the org file. This linking was implemented > twice, to handle separate cases, but when using ‘:comments noweb’ it > ended up going through both codepaths. This resulted in doubly wrapped > links. Please use double space " " between sentences. See https://orgmode.org/worg/org-contribute.html#commit-messages > +(defun org-babel-tangle--unbracketed-link (params) > + "Get a raw link to the src block at point, without brackets. > + > +The PARAMS are the 3rd element of the info for the same src block. > +" No newline at the end of the docstring, please. See D.6 Tips for Documentation Strings in Elisp manual: • Do not start or end a documentation string with whitespace. > + (let* (;; The created link is transient. Using ID is not necessary, > + ;; but could have side-effects if used. An ID property may > + ;; be added to existing entries thus creatin unexpected file > + ;; modifications. Can as well fix the "creatin" typo here. > + (org-id-link-to-org-use-id nil) > + (l (org-no-properties (org-store-link nil))) > + (bare (and (string-match org-link-bracket-re l) > +(match-string 1 l For safety, please wrap the matching into save-match-data. This is often annoying when calling some random function unexpectedly changes match-data. > +(ert-deftest ob-tangle/comment-noweb-relative () > + "Test :comments noweb tangling with relative file paths" > +(ert-deftest ob-tangle/comment-noweb-absolute () > + "Test :comments noweb tangling with absolute file path" Full stop at the end of sentence, please. Best, Ihor
[PATCH] Re: [BUG] org-colview tests fail in Emacs 29 because of wrong org-colview's assumptions about current-column [9.5.4 (release_9.5.4-626-g45f9d8.dirty @ /home/yantar92/.emacs.d/straight/build/o
Ihor Radchenko writes: > On Emacs 29, make test will fail on both bugfix and main: > > 5 unexpected results: >FAILED test-org-colview/columns-move-left >FAILED test-org-colview/columns-move-right >FAILED test-org-colview/columns-new >FAILED test-org-colview/columns-next-allowed-value >FAILED test-org-colview/columns-update I am attaching a tentative fix. Also, note that `current-column' is used, for example, in org-element list parser. If users use some kind of weird font-lock that replaces indentation in Org lists, our parser may become faulty. Similarly, `current-column' is being used in few more places across Org. I am not yet fixing such possible issues, but it would be helpful if someone comments on the considered possibilities. Best, Ihor >From 8f56cf22ff1727542a237a2ed39d48eca1479414 Mon Sep 17 00:00:00 2001 Message-Id: <8f56cf22ff1727542a237a2ed39d48eca1479414.1659154264.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 30 Jul 2022 12:07:14 +0800 Subject: [PATCH] org-colview: Do not rely on `current-column' ignoring display properties * lisp/org-macs.el (org-current-text-column): New macro calculating current column without accounting display text properties. * lisp/org-colview.el (org-columns-check-computed): (org-columns-next-allowed-value): (org-columns-new): (org-columns-delete): (org-columns-edit-attributes): (org-columns-widen): (org-columns-move-right): (org-columns-move-left): (org-columns-update): Use the new macro when calculating point position in the column view table overlay. Do _not_ use the new macro when we want to get the visual column position of the point. Fixes "test-org-colview/" failures on Emacs 29 after Emacs commit 4243747b1b8c3b7e3463822804b32e83febe2878: ;; Fix 'current-column' in the presence of display strings ;; * src/indent.c (check_display_width): Support calculation of width ;; of 'display' properties whose values are strings. This fixes the ;; value returned by 'current-column' when display strings are ;; present between BOL and point. (Bug#53795) See https://orgmode.org/list/CACnOyijQc7BDDtrYQb+=vogwkpwaymu7o4qsvgpsu6scgwi...@mail.gmail.com --- lisp/org-colview.el | 25 + lisp/org-macs.el| 5 + 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 13643101b..2829678f5 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -557,7 +557,7 @@ (defun org-columns-quit () (defun org-columns-check-computed () "Throw an error if current column value is computed." - (let ((spec (nth (current-column) org-columns-current-fmt-compiled))) + (let ((spec (nth (org-current-text-column) org-columns-current-fmt-compiled))) (and (nth 3 spec) (assoc spec (get-text-property (line-beginning-position) 'org-summaries)) @@ -713,7 +713,8 @@ (defun org-columns-next-allowed-value ( previous nth) an integer, select that value." (interactive) (org-columns-check-computed) - (let* ((column (current-column)) + (let* ((column (org-current-text-column)) + (visible-column (current-column)) (key (get-char-property (point) 'org-columns-key)) (value (get-char-property (point) 'org-columns-value)) (pom (or (get-text-property (line-beginning-position) 'org-hd-marker) @@ -763,7 +764,7 @@ (defun org-columns-next-allowed-value ( previous nth) ;; the right place on the current line. (let ((org-columns-inhibit-recalculation)) (org-columns-redo)) (org-columns-update key) - (org-move-to-column column)) + (org-move-to-column visible-column)) (defun org-colview-construct-allowed-dates (s) "Construct a list of three dates around the date in S. @@ -925,14 +926,14 @@ (defun org-columns-new ( spec attributes) (if spec (progn (setcar spec (car new)) (setcdr spec (cdr new))) - (push new (nthcdr (current-column) org-columns-current-fmt-compiled))) + (push new (nthcdr (org-current-text-column) org-columns-current-fmt-compiled))) (org-columns-store-format) (org-columns-redo))) (defun org-columns-delete () "Delete the column at point from columns view." (interactive) - (let ((spec (nth (current-column) org-columns-current-fmt-compiled))) + (let ((spec (nth (org-current-text-column) org-columns-current-fmt-compiled))) (when (y-or-n-p (format "Are you sure you want to remove column %S? " (nth 1 spec))) (setq org-columns-current-fmt-compiled @@ -942,18 +943,18 @@ (defun org-columns-delete () ;; updating it may prove counter-intuitive. See comments in ;; `org-columns-move-right' for details. (let ((org-columns-inhibit-recalculation t)) (org-columns-redo)) - (when (>= (current-column) (length org-columns-current-fmt-compiled)) + (when (>= (org-current-text-column) (length org-columns-current-fmt-compiled)) (backward-char) (defun org-columns-edit-attributes () "Edit the attributes of the current
Re: [PATCH v2] Add new entity \-- serving as markup separator/escape symbol
my deep apologies for the typo in john's name. i meant of course John
Kitchin -- jkitchin. i refer to his new style link syntax and his
proof of concept for cl style keyword args. i still owe you email
replies.
On 7/29/22, Samuel Wales wrote:
> i am not in a position to judge \-- but i like the idea of not having
> zws be used, and expect you have thought it out.
>
>
> just an idea: something approximately like this might work, or
> something like john kitchen's poc implementation of it might. this is
> called extensible syntax. one of the goals of es is to reduce the
> proliferation of org syntax and other stuff.
>
> es was proposed long ago, but i was unable to sufficiently follow up
> for unrelated reasons. i have lots of replies and lots of further
> work on it but that's neither here nor there in this case.
>
> [other stuff includes but is not limited to increase reusability and
> reliability of code to implement things you want to do with syntax
> such as whether to show it, add a subfeature, export it variantly in
> different exporters, escape it, quote it, pretty-print it, etc.; allow
> user to do this so org is not burdened by it; etc. terms to look up
> in the mailing list archives include extensible syntax, parsing risk,
> and id markers.]
>
> $[emphasis :position beg :type bold :display "*"]bold text$[emphasis
> :position end :type bold :display "*"]
>
> alternatively:
>
> $()...
>
> other than the basics, such as sexp, i do NOT care about the details
> of the $[] low level syntax in general OR the arglist details in this
> particular case. those can change according to consensus or
> implementation needs etc. instead, it is getting the concept across
> that matters to me. one key thing about es is that when we want a new
> feature, we do not need new org syntax for that new feature. OR for
> new subfeatures. we just do something like this:
>
> $[extended-timestamp :whatever yes :displays-as interval]
>
> or whatever. this has nothing to do with bold emphasis. it is an
> unrelated feature, using the same outer syntax. another completely
> unrelated feature i'd strongly like, for emacs in general, is id
> markers. that too can be done with this syntax.
>
> it looks verbose to 3rd party tools but is parseable by them. this
> example displays as * to the user. parseable as lisp sexp data using
> lisp tools. it is meant to be vaguely reminiscent of a cl function
> call while still not likely to occur naturally.
>
> it would of course not be typed by the user directly but by some
> completion thing.
>
> i am not doing well so i am unlikely to be able to respond much or at
> all to queries. please take it easy on me if this rubs you the wrong
> way. it is just an idea and it does not have to be the answer.
>
> merely saying that once implemented, could solve this problem and ALSO
> later problems. in fact, we discussed coloring of text using this
> syntax. although with various understandings of it. that's kinda
> similar to emphasis.
>
> On 7/29/22, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
> The good point in your patch is that \- is still work as shy hyphen
> (that, by the way, may be used in some cases instead of zero width
> space: *intra*\-word). On the other hand I have managed to find a case
> when your approach is not ideal:
>
> *\--scratch\--*
>
>
> -scratch
Well. I think that it is impossible to use the same escape construct to
both force emphasis and escape it.
>>>
>>> Let's articulate the problem as follows: when some characters ("*". "/".
>>> etc.) besides used literally are overloaded with 2 additional roles that
>>> are start emphasis group and terminate emphasis group, in addition to
>>> lightweight markup heuristics, it is necessary to provide a way to
>>> disambiguate which of 3 roles is associated with particular character.
>>>
>>> "Activate" and "deactivate" characters or entities for emphasis markers
>>> are alternative and perhaps not so clear terms have used before.
>>>
>>> The advantage of zero width space is that "[:space:]" is part of
>>> PREMATCH and POSTMATCH (outer) regexps in
>>> `org-emphasis-regexp-components' and "[:space:]" is forbidden at the
>>> inner borders of emphasized span of text. The latter is mostly
>>> meaningful, however I am unsure if bold space has the same width as
>>> regular one, and space in fixed width font is certainly distinct.
>>>
>>> The problem with the "\--" entity is that it is not handled properly at
>>> the start of emphasis region. It neither disables emphasis nor parsed as
>>> complete entity, instead it becomes combination of "\-" shy hyphen and
>>> literal "-".
>>>
>>> Unsure if it can be solved consistently. Possible ways:
>>> - It addition to space-like (in respect to current regexp) entity add
>>> another one that acts as a part of word, but like "\--" stripped from
>>> output. Likely it should be accompanied by more changes in the parser
Re: Org links and Flatpak firefox
Ken Mankoff writes: > >> Out of curiosity, what is the reason why you are avoiding firefox as a >> snap package? > > I'm not 100 % sure why but I don't like snap. Maybe because it pollutes the > home folder. I > read up on snap vs flatpak vs AppImage and flatpak seemed to get the best > reviews, so I've > gone with that one. > There has been a real issue with startup times for snap based firefox. While there have been some improvements very recently, the snap version is still significantly slower to start than the flatpak version (on my system, it was taking over 25 seconds! This is on a 20 core i7 with 32Gb RAM and SSD). I recently switched from Ubuntu (which favours snap) to Fedora (which favours flatpak). However, when I was on Ubuntu, I actually replaced the snap version with the deb version (this is still possible, but people don't necessarily know that) because it was so much faster to start. I think the deb/rpm based versions are still the fastest, but flatpak opens firefox within just a couple of seconds on the same hardware where snap took 25.
Re: Serving .org files for worg (was: Re: Library of babel help)
Max Nikulin writes:
> On 01/07/2022 04:48, Tim Cross wrote:
>> 1. Just using the .org as the suffix of the url instead of the .html did
>> not work for me using two different browser. However, it did work for
>> ihor, so either I did something wrong or there is something in my setup
>> which is preventing that from working. Need to investigate further.
>> However, that is not my main issue.
>
> Tim, have you managed to achieve any progress with either nginx or with
> settings of your
> browsers?
>
> I have tried some variants of desktop environments with almost default
> setting without
> issues similar to yours.
>
> Org files are fetched to the Downloads folder without additional user actions
> (besides
> Firefox-91). It is not always obvious at first glance. With default settings:
> - Chromium displays a bar at the bottom of the window.
> - Firefox-102 (Ubuntu and Gnome, Arch and KDE) opens transient popup window.
> In
> Ububntu-22.04 firefox and chromium are installed as snap packages.
> - Firefox-91 (Debian, Xfce) displays more traditional popup window to confirm
> download
> (somehow it guesses that it is an org-mode file even for
> application/octet-stream
> MIME-type).
>
> If I change MIME type then Chromium displays internally both text/plain and
> text/x-org,
> Firefox asks for an external application for text/x-org while text/plain is
> displayed in
> the browser tab.
>
> The following snippet should be added to nginx configuration to assign MIME
> type for .org
> files:
>
> types {
> # Chromium opens text/x-org in the browser tab,
> # Firefox downloads files and offers to open in some other
> application.
> # text/x-org org;
> text/plain org;
> }
>
> See http://nginx.org/en/docs/http/ngx_http_core_module.html#types
> It is assumed that default mime.types is included somewhere.
Yes, I do have it working in my local dev environment. I have also made
some progress with improvements with both the nginx and worg layout, but
it isn't ready for 'prime time' yet. My testing with different browsers
did show variation across browsers and this is something I would like to
avoid. I also have come to a similar conclusion to you and think it is
about setting a mime handler for org files in nginx.
Unfortunately, during this whole process, I had a major hardware failure
and have had to re-build my whole system. One of the things I did have
on my TODO list was to migrate from using Ubuntu to Fedora and while I
was going to do that later, given that I had to restore from backups
onto a new system, I decided to make the switch now.
While immensely happy with Fedora and pleased to be free of some of the
stuff I didn't like with current Ubuntu, it has been 20 years since I've
run a RH based distro, so there has been some learning curve to deal
with which has slowed down my progress with worg (especially getting up
to speed with SELinux, dnf and flatpak). However, it is progressing and
I hope to have something for everyone to look at sooner rather than
later.
I have now become a member of the SourceHut community and I think it
should be possible to deploy a dev/uat version of the new worg site to
their pages site. This should provide a relatively easy way for everyone
who is interested to have a look at the changes I'm making. I'm also
hoping this will also provide a workable 'dev' site for the main worg
repository so that anyone with the correct permissions can make changes,
deploy to the dev site to verify nothing is broken and then push it to
the production site. My hope is this will make people more relaxed and
confident in contributing while also ensuring a good user experience for
worg users. I still have a bit of work to do getting to grips wiht the
sh tools and understanding how they can help. There is definitely some
good stuff here, but there are still some rough edges you have to work
with and some different concepts/approaches I'm not yet familiar with.
The good news is that I think all the necessary prerequisite stuff is
now working well and I can focus on the specifics of worg and the
various moving parts which make up orgmode.org!
Re: Something has happened such that I can't export to latex
Sharon Kimble writes: > [[PGP Signed Part:Undecided]] > Ihor Radchenko writes: > >> Sharon Kimble writes: >> >>> But, I'm unable to 'make autoloads' in the git version because its >>> trying to connect to /usr/share/emacs and looking for something >>> there which isn't there and just ends up deleting org-loaddefs, and the >>> only way that >>> I can get round it is by restoring git/org-mode from backup. >>> >>> Can you advise please as to how I can surmount that obstacle? >> >> I am not sure. make autoloads should have nothing to do with >> /usr/share/emacs >> >> What exactly happens when you run make autoloads? >> >> Best, >> Ihor > > Morning all. > > = > foo$ git pull > From https://git.savannah.gnu.org/git/emacs/org-mode >5be0c709b3..d37c0ee5fa main -> origin/main > Updating 5be0c709b3..d37c0ee5fa > Fast-forward > lisp/org.el | 2 +- > lisp/ox-latex.el | 7 +-- > mk/org-fixup.el | 2 +- > 3 files changed, 7 insertions(+), 4 deletions(-) > > foo$ make autoloads > make -C lisp autoloads > make[1]: Entering directory '/home/boudiccas/git/org-mode/lisp' > rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc > org-install.elc > org-version: 9.5.4 (release_9.5.4-684-gd37c0e) > Warning: Lisp directory '/usr/local/share/emacs/29.0.50/lisp': No such file > or directory > Cannot open load file: No such file or directory, loadup.el > make[1]: *** [Makefile:72: org-version.el] Error 255 > make[1]: Leaving directory '/home/boudiccas/git/org-mode/lisp' > make: *** [mk/targets.mk:133: autoloads] Error 2 > = > > Does this help please? > After you do a pull from git, I think you should always do a make clean before trying anything else. The error is referencing a file which has nothing to do with org, so I suspect something is wrong with your local environment. I would also try git clean -dxf in the root of the org git tree just to ensure there are no files there which don't belong. Follow that with make clean and make.
Re: [PATCH v2] Add new entity \-- serving as markup separator/escape symbol
i am not in a position to judge \-- but i like the idea of not having
zws be used, and expect you have thought it out.
just an idea: something approximately like this might work, or
something like john kitchen's poc implementation of it might. this is
called extensible syntax. one of the goals of es is to reduce the
proliferation of org syntax and other stuff.
es was proposed long ago, but i was unable to sufficiently follow up
for unrelated reasons. i have lots of replies and lots of further
work on it but that's neither here nor there in this case.
[other stuff includes but is not limited to increase reusability and
reliability of code to implement things you want to do with syntax
such as whether to show it, add a subfeature, export it variantly in
different exporters, escape it, quote it, pretty-print it, etc.; allow
user to do this so org is not burdened by it; etc. terms to look up
in the mailing list archives include extensible syntax, parsing risk,
and id markers.]
$[emphasis :position beg :type bold :display "*"]bold text$[emphasis
:position end :type bold :display "*"]
alternatively:
$()...
other than the basics, such as sexp, i do NOT care about the details
of the $[] low level syntax in general OR the arglist details in this
particular case. those can change according to consensus or
implementation needs etc. instead, it is getting the concept across
that matters to me. one key thing about es is that when we want a new
feature, we do not need new org syntax for that new feature. OR for
new subfeatures. we just do something like this:
$[extended-timestamp :whatever yes :displays-as interval]
or whatever. this has nothing to do with bold emphasis. it is an
unrelated feature, using the same outer syntax. another completely
unrelated feature i'd strongly like, for emacs in general, is id
markers. that too can be done with this syntax.
it looks verbose to 3rd party tools but is parseable by them. this
example displays as * to the user. parseable as lisp sexp data using
lisp tools. it is meant to be vaguely reminiscent of a cl function
call while still not likely to occur naturally.
it would of course not be typed by the user directly but by some
completion thing.
i am not doing well so i am unlikely to be able to respond much or at
all to queries. please take it easy on me if this rubs you the wrong
way. it is just an idea and it does not have to be the answer.
merely saying that once implemented, could solve this problem and ALSO
later problems. in fact, we discussed coloring of text using this
syntax. although with various understandings of it. that's kinda
similar to emphasis.
On 7/29/22, Ihor Radchenko wrote:
> Max Nikulin writes:
>
The good point in your patch is that \- is still work as shy hyphen
(that, by the way, may be used in some cases instead of zero width
space: *intra*\-word). On the other hand I have managed to find a case
when your approach is not ideal:
*\--scratch\--*
-scratch
>>>
>>> Well. I think that it is impossible to use the same escape construct to
>>> both force emphasis and escape it.
>>
>> Let's articulate the problem as follows: when some characters ("*". "/".
>> etc.) besides used literally are overloaded with 2 additional roles that
>> are start emphasis group and terminate emphasis group, in addition to
>> lightweight markup heuristics, it is necessary to provide a way to
>> disambiguate which of 3 roles is associated with particular character.
>>
>> "Activate" and "deactivate" characters or entities for emphasis markers
>> are alternative and perhaps not so clear terms have used before.
>>
>> The advantage of zero width space is that "[:space:]" is part of
>> PREMATCH and POSTMATCH (outer) regexps in
>> `org-emphasis-regexp-components' and "[:space:]" is forbidden at the
>> inner borders of emphasized span of text. The latter is mostly
>> meaningful, however I am unsure if bold space has the same width as
>> regular one, and space in fixed width font is certainly distinct.
>>
>> The problem with the "\--" entity is that it is not handled properly at
>> the start of emphasis region. It neither disables emphasis nor parsed as
>> complete entity, instead it becomes combination of "\-" shy hyphen and
>> literal "-".
>>
>> Unsure if it can be solved consistently. Possible ways:
>> - It addition to space-like (in respect to current regexp) entity add
>> another one that acts as a part of word, but like "\--" stripped from
>> output. Likely it should be accompanied by more changes in the parser
>> and regexps.
>> - Provide some new explicit syntax for literal character, start of
>> emphasis group, end of emphasis group.
>
> The fact that \-- was not parsed in your example is because entities
> cannot be directly followed by a letter (see 12.4 Special Symbols).
>
> You need
>
> *\--{}scratch\--*
>
> Concerning the 3 listed roles of the *_/+ markup, I propose to simplify
> the problem
Re: [PATCH] oc-csl: Add support for sub-bibliographies
Dear All, On Fri, 29 Jul 2022 at 03:32, Ihor Radchenko wrote: > This is an important point. I think that we should describe this gotcha > in the "Bibliography printing". oc-basic and oc-csl just print the list > of bibliography entries, while oc-bibtex/oc-natbib/oc-biblatex insert a > separate section. It is a very important information and users should be > aware of it. I agree, so I've attached a new version in which a sentence is added about this difference in behaviour. Also, this is kind of annoying - this way mixing oc-bibtex > and oc-basic for LaTeX and non-LaTeX export gets awkward. Yes, in the long run we might want to unify the behaviour of the processors in this respect. OTOH changing "basic" and "csl" to automatically print a heading would be a breaking change, e.g., AFAIK, ox-hugo currently adds a heading on its own when org-cite is used for bibliography printing with the "csl" processor. best wishes, András > Best, > Ihor From b765d8bd65ece076041b8c280c0a7f076a376338 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= Date: Thu, 28 Jul 2022 22:50:26 +0200 Subject: [PATCH] * doc/org-manual.org: Document "PRINT_BIBLIOGRAPHY" options --- doc/org-manual.org | 63 +- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 596ab3723..9ec49c14e 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -16818,11 +16818,72 @@ conformant to the Harvard style and the specification of the Wolkers-Kluwer publisher; since it relies on the ~bibtex~ processor of your LaTeX installation, it won't export to anything but PDF. +** Bibliography printing + The =PRINT_BIBLIOGRAPHY= keyword specifies where the bibliography -should print. +should be printed (note the colon): : #+print_bibliography: +The bibliography printed by the LaTeX-based export processors +"bibtex", "natbib" and "biblatex" has a chapter or section heading by +default, while the "basic" and "csl" processors print the list of +bibliography entries without a heading. + +A document may contain more than one =PRINT_BIBLIOGRAPHY= keywords. +Each of the keywords will trigger printing the bibliography. + +The keywords can be used with or without additional options. Options +can be used, for example, to print only entries that belong to a +certain category or to control formatting. The set of supported +=PRINT_BIBLIOGRAPHY= options and their interpretation varies between +the different citation export processors. Some export processors do +not support passing options. + +*** Bibliography options in the "biblatex" and "csl" export processors + +The "biblatex" and "csl" export processors support bibliography +options through a property list attached to the =PRINT_BIBLIOGRAPHY= +keyword. For example, + +: #print_bibliography: :keyword algebra :type book + +Values including spaces must be surrounded with double quotes. If you +need to use a key multiple times, you can separate its values with +commas, but without any space in-between: + +: #print_bibliography: :keyword "algebraic logic" :nottype article,book + +The "biblatex" export processor accepts all options supported by +BibLaTeX's ~\printbibliography~ command, while the "csl" processor +accepts the following ones: + +- =:keyword = :: Print only entries whose + keyword field contains all given keywords. + +- =:notkeyword = :: Print only entries whose + keyword field does not contain any of the given keywords. + +- =:type = :: Print only entries whose type is + ==. Entry type is the BibTeX/BibLaTeX entry type if this + information is available (the entry was read from a BibTeX/BibLaTeX + bibliography) and the CSL entry type otherwise. + +- =:nottype = :: Print only entries whose + type is not among the given entry types. Entry type is determined + as in the case of =:type=. + +- =:csltype = :: Print only entries whose CSL entry type + (possibly based on a conversion from BibTeX/BibLaTeX to CSL) is + ==. + +- =:notcsltype = :: Print only entries whose + CSL entry type (possibly based on a conversion from BibTeX/BibLaTeX + to CSL) is not among the listed entry types. + +- =:filter = :: Print only entries for which the given + Emacs Lisp predicate returns a non-~nil~ value. + * Working with Source Code :PROPERTIES: :DESCRIPTION: Export, evaluate, and tangle code blocks. -- 2.25.1
Re: [PATCH]: ox-latex: omit empty date
Hi Ihor,
sorry for not testing my code!
My test halted on the main branch with the message: Warning (python):
Your `python-shell-interpreter' doesn't seem to support readline, yet
`python-shell-completion-native-enable' was t and "python" is not part
of the `python-shell-completion-native-disabled-interpreters' list.
Native completions have been disabled locally.
Shell native completion is disabled, using fallback
and I was not in the mood to fix this small problem with my python
installation.
The updated (and still untested) patch is attached to this mail.
Kind regards,
Bob
Jul 29, 2022, 15:31 by yanta...@gmail.com:
> emacs--- via "General discussions about Org-mode."
> writes:
>
>> From 120e4ca11f021fa2d7e7abf57187c2db71942302 Mon Sep 17 00:00:00 2001
>> From: Bob Vergauwen
>> Date: Fri, 29 Jul 2022 14:28:21 +0200
>> Subject: [PATCH] lisp/ox-latex: Omit empty date
>>
>> * lisp/ox-latex.el: (org-latex-template): When no date is provided or
>> the export option date is nil, the empty '\date{}' string is no
>> longer included in the exported latex document.
>>
>> The default behaviour for ox-latex was to include an empty date line as
>> '\date{}'. This empty date line can affect more complex latex templates
>> when the date is for example set by the template on compilation, or when
>> the date command is overwritten entirely. In this new patch, the date
>> line is omitted from the exported document.
>>
>
> Thanks! This looks reasonable.
>
>> (let ((date (and (plist-get info :with-date) (org-export-get-date info
>> - (format "\\date{%s}\n" (org-export-data date info)))
>> + (cond date
>> + (format "\\date{%s}\n" (org-export-data date info
>>
>
> This will give compilation error. Did you mean (when date ...)?
>
> Best,
> Ihor
>
0001-lisp-ox-latex-Omit-empty-date.patch
Description: Binary data
Re: the comment environment does not work for checkboxes
>>> "AB" == Arne Babenhauserheide writes: > Uwe Brauer writes: >> #+BEGIN_COMMENT >> WAIT Computer >> :PROPERTIES: >> :Nr: 4 >> :Comp1:[X] >> :Comp2:[X] >> :END: >> #+END_COMMENT >> Does not. Any idea why? > In a block, you must escape * as ,* — open the environment with C-c C-' > and save it the same way, then it escapes them for you. Thanks, a couple of remarks 1. It does not work! I Presume you mean «C-c '» no «C-c C-'»? Well this is bound to is edit special , | C-c ' runs the command org-edit-special (found in org-mode-map), which | is an interactive compiled Lisp function in ‘org.el’. | | It is bound to H-e, C-c ', C-c C-l, | ,. | | (org-edit-special ARG) | | Call a special editor for the element at point. | When at a table, call the formula editor with ‘org-table-edit-formulas’. | When in a source code block, call ‘org-edit-src-code’. | When in a fixed-width region, call ‘org-edit-fixed-width-region’. | When in an export block, call ‘org-edit-export-block’. | When in a LaTeX environment, call ‘org-edit-latex-environment’. | When at an INCLUDE, SETUPFILE or BIBLIOGRAPHY keyword, visit the included file. | When at a footnote reference, call ‘org-edit-footnote-reference’. | When at a planning line call, ‘org-deadline’ and/or ‘org-schedule’. | When at an active timestamp, call ‘org-time-stamp’. | When at an inactive timestamp, call ‘org-time-stamp-inactive’. | On a link, call ‘ffap’ to visit the link at point. | Otherwise, return a user error. ` Comments block are not listed and as I said it seems not to work, if what you say is the correct syntax, then there is a bug, since 1. when I mark the region, 2. Run org-insert-structure-template, 3. Select comment, it should then lead to #+BEGIN_COMMENT , WAIT Computer :PROPERTIES: :Nr: 4 :Comp1:[X] :Comp2:[X] :END: #+END_COMMENT Automatically, but it does *not*. So I am a bit puzzled. Uwe > Best wishes, > Arne -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH]: ox-latex: omit empty date
emacs--- via "General discussions about Org-mode."
writes:
> From 120e4ca11f021fa2d7e7abf57187c2db71942302 Mon Sep 17 00:00:00 2001
> From: Bob Vergauwen
> Date: Fri, 29 Jul 2022 14:28:21 +0200
> Subject: [PATCH] lisp/ox-latex: Omit empty date
>
> * lisp/ox-latex.el: (org-latex-template): When no date is provided or
> the export option date is nil, the empty '\date{}' string is no
> longer included in the exported latex document.
>
> The default behaviour for ox-latex was to include an empty date line as
> '\date{}'. This empty date line can affect more complex latex templates
> when the date is for example set by the template on compilation, or when
> the date command is overwritten entirely. In this new patch, the date
> line is omitted from the exported document.
Thanks! This looks reasonable.
> (let ((date (and (plist-get info :with-date) (org-export-get-date
> info
> - (format "\\date{%s}\n" (org-export-data date info)))
> + (cond date
> + (format "\\date{%s}\n" (org-export-data date info
This will give compilation error. Did you mean (when date ...)?
Best,
Ihor
Re: Something has happened such that I can't export to latex
Sharon Kimble writes: > foo$ git pull > - From https://git.savannah.gnu.org/git/emacs/org-mode >5be0c709b3..d37c0ee5fa main -> origin/main > Updating 5be0c709b3..d37c0ee5fa > Fast-forward > lisp/org.el | 2 +- > lisp/ox-latex.el | 7 +-- > mk/org-fixup.el | 2 +- > 3 files changed, 7 insertions(+), 4 deletions(-) > > foo$ make autoloads Considering that you have a questionable local.mk, I suggested trying cloning the Org repo from scratch. Just in case. If that does not work, I suspect that you have some peculiar Emacs installation. The error you are getting appears like Emacs compilation wrongly set the environment somehow. It is the first time I am seeing such a strange error. Best, Ihor
Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point
Tom Gillespie writes: > Here's a patch to fix the follow behavior for ol-man links so > that the ::SEARCH functionality will actually work. Best! > Tom > From 2c3e3b994fd7b47a6e91d147d2b1f08cd97a1908 Mon Sep 17 00:00:00 2001 > From: Tom Gillespie > Date: Thu, 28 Jul 2022 23:33:22 -0700 > Subject: [PATCH] * lisp/ol-man.el (org-man-open): Set window point not buffer > point Thanks for the contribution! > When passed man:path::SEARCH org-man-open tries to use search-forward > to jump to the location of e.g. a heading. Prior to this fix it only > used search-forward, which will not change the point of the cursor in > the window, meaning that even if there is a match it will not appear. Please check out https://orgmode.org/worg/org-contribute.html#commit-messages for our conventions about commit messages. > Use sleep-for as a horrible hack to work around the fact that the man > command runs in the background with no way to synchronize back. This is indeed a horrible hack. What about `accept-process-output'? Best, Ihor
Re: Serving .org files for worg (was: Re: Library of babel help)
On 01/07/2022 04:48, Tim Cross wrote:
1. Just using the .org as the suffix of the url instead of the .html did
not work for me using two different browser. However, it did work for
ihor, so either I did something wrong or there is something in my setup
which is preventing that from working. Need to investigate further.
However, that is not my main issue.
Tim, have you managed to achieve any progress with either nginx or with
settings of your browsers?
I have tried some variants of desktop environments with almost default
setting without issues similar to yours.
Org files are fetched to the Downloads folder without additional user
actions (besides Firefox-91). It is not always obvious at first glance.
With default settings:
- Chromium displays a bar at the bottom of the window.
- Firefox-102 (Ubuntu and Gnome, Arch and KDE) opens transient popup
window. In Ububntu-22.04 firefox and chromium are installed as snap
packages.
- Firefox-91 (Debian, Xfce) displays more traditional popup window to
confirm download (somehow it guesses that it is an org-mode file even
for application/octet-stream MIME-type).
If I change MIME type then Chromium displays internally both text/plain
and text/x-org, Firefox asks for an external application for text/x-org
while text/plain is displayed in the browser tab.
The following snippet should be added to nginx configuration to assign
MIME type for .org files:
types {
# Chromium opens text/x-org in the browser tab,
# Firefox downloads files and offers to open in some other
application.
# text/x-org org;
text/plain org;
}
See http://nginx.org/en/docs/http/ngx_http_core_module.html#types
It is assumed that default mime.types is included somewhere.
Re: [PATCH v2] org-test: Run all ol tests on make test
Max Nikulin writes: > I have decided that I prefer to have org-test common prefix even though > it causes discrepancy test-ol.el file vs. test-org-link/... cases. > From 725369323a1a3303820c2c92b116e8238b895bac Mon Sep 17 00:00:00 2001 > From: Max Nikulin > Date: Thu, 28 Jul 2022 22:08:57 +0700 > Subject: [PATCH] test-ol: Rename cases to match the default selector Thanks! Applied onto main via 20274454c after removing a tangling ")" in the commit message. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=20274454c6821b8194ba600d54c4d8ee996946c0 Best, Ihor
Re: [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
Ignacio Casso writes: Sorry for the late reply. > I'm not sure what is the expected behaviour of the COMMENT keyword for > TODOs and the agenda, since I only found it in the "Exporting" section > of the manual, but I find the following behaviour inconsistent: > > - Tasks with a COMMENT keyword or under a heading with a COMMENT keyword > do not appear in the agenda. I'm not sure if this is a feature or just > happens because there is a step involving exporting when the agenda is > constructed, but it seems reasonable to me and I use the COMMENT > keyword for this sometimes. Also, code blocks inside COMMENT subtrees are not considered during code block execution with noweb. > - Tasks with a COMMENT keyword or under a heading with a COMMENT keyword > DO matter when computing dependencies between tasks, when > org-enforce-todo-dependencies is 't' or there is a 'ORDERED' > property. > > These two points seem inconsistent to me, since the first leads me to > believe that tasks under commented subtrees are as if they did not > exist, but in the second we see that's not true. Am I interpreting the > COMMENT keyword wrong? There is indeed an inconsistency here. > P.D: Just when I was going to send this I tried to investigate it a > little bit more to not waste anyone's time, and I found the variable > 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that > if it is set to 'nil' it would not be inconsistent to me anymore, but I > still think that the default behaviour is inconsistent, or at least > unintituive for newcomers, and that maybe a corresponding variable like > 'org-dependencies-skip-comment-trees' might be needed. This makes sense. The new variable should default to the old behaviour - we do not want to break existing Org files relying on it. Patches are welcome! Best, Ihor
Re: [PATCH v8] ol.el: add description format parameter to org-link-parameters
On 25/07/2022 18:55, Hugo Heagren wrote:
In any case, we cannot, unfortunately, use map-do here and should
probably fall back to the previous version with cl-loop.
You're right, this is strange. Oh well, I've moved back to the version
of the macro which used `cl-loop' in the current patch. Nothing else
is changed. All the tests pass for me.
Hugo, almost certainly you are tired by so many iterations, but I still
can not approve your patch. It is again Emacs-26 and likely the last
`should' form with (org-link-parameters nil). I hope, you have not lost
motivation yet and you will fix this test failure.
Test test-ol/insert-link-insert-description backtrace:
signal(error ("rx form ‘or’ requires at least 1 args"))
apply(signal (error ("rx form ‘or’ requires at least 1 args")))
(setq value-7590 (apply fn-7588 args-7589))
(unwind-protect (setq value-7590 (apply fn-7588 args-7589)) (setq fo
(if (unwind-protect (setq value-7590 (apply fn-7588 args-7589)) (set
(let (form-description-7592) (if (unwind-protect (setq value-7590 (a
(let ((value-7590 (quote ert-form-evaluation-aborted-7591))) (let (f
(let* ((fn-7588 (function null)) (args-7589 (condition-case err (let
(closure (t) nil (let* ((fn-7563 (function string=)) (args-7564 (con
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name test-ol/insert-link-insert-descriptio
ert-run-or-rerun-test(#s(ert--stats :selector "test-ol/" :tests [#s(
ert-run-tests("test-ol/" #f(compiled-function (event-type even
ert-run-tests-batch("test-ol/")
ert-run-tests-batch-and-exit("test-ol/")
(let ((org-id-track-globally t) (org-test-selector (if org-test-sele
org-test-run-batch-tests("test-ol/")
eval((org-test-run-batch-tests org-test-select-re))
command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
command-line()
normal-top-level()
Test test-ol/insert-link-insert-description condition:
(error "rx form ‘or’ requires at least 1 args")
FAILED 5/13 test-ol/insert-link-insert-description
[PATCH]: ox-latex: omit empty date
Dear list,
In the attachment you can find a patch which omits an empty \date{} line in
a latex document when the option to include the date is set to nil or when
no date is provided. This empty date line can cause problems is certain
use cases.
Kind regads,
Bob
0001-lisp-ox-latex-Omit-empty-date.patch
Description: Binary data
Re: Something has happened such that I can't export to latex
> On Fri, 29 Jul 2022 13:24:46 +0100, Sharon Kimble > said: >> What does your local.mk contain? I donʼt think the default org >> makefile references loadup.el anywhere. >> Sharon> Does this help? Its been a very long time since I looked at it, and I don't think that I changed anything in it then. Hmm, that doesnʼt reference loadup.el at all, which is normally passed to temacs during the Emacs build process, not when running emacs itself. Can you try removing the ʼ@ʼ from the start of the lines in the recipe for $(LISPI) in lisp/Makefile and re-running the make? If that contains loadup we need to figure out why. Robert --
Re: Something has happened such that I can't export to latex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert Pluim writes: >> On Fri, 29 Jul 2022 09:48:09 +0100, Sharon Kimble >> said: > > Sharon> Morning all. > > Sharon> = > Sharon> foo$ git pull > Sharon> From https://git.savannah.gnu.org/git/emacs/org-mode > Sharon>5be0c709b3..d37c0ee5fa main -> origin/main > Sharon> Updating 5be0c709b3..d37c0ee5fa > Sharon> Fast-forward > Sharon> lisp/org.el | 2 +- > Sharon> lisp/ox-latex.el | 7 +-- > Sharon> mk/org-fixup.el | 2 +- > Sharon> 3 files changed, 7 insertions(+), 4 deletions(-) > > Sharon> foo$ make autoloads > Sharon> make -C lisp autoloads > Sharon> make[1]: Entering directory '/home/boudiccas/git/org-mode/lisp' > Sharon> rm -f org-version.el org-loaddefs.el org-version.elc > org-loaddefs.elc org-install.elc > Sharon> org-version: 9.5.4 (release_9.5.4-684-gd37c0e) > Sharon> Warning: Lisp directory '/usr/local/share/emacs/29.0.50/lisp': No > such file or directory > Sharon> Cannot open load file: No such file or directory, loadup.el > Sharon> make[1]: *** [Makefile:72: org-version.el] Error 255 > Sharon> make[1]: Leaving directory '/home/boudiccas/git/org-mode/lisp' > Sharon> make: *** [mk/targets.mk:133: autoloads] Error 2 > Sharon> = > > What does your local.mk contain? I donʼt think the default org > makefile references loadup.el anywhere. > Thanks for replying Robert. = # Remove "oldorg:" to switch to "all" as the default target. # Change "oldorg:" to an existing target to make that target the default, # or define your own target here to become the default target. oldorg: # do what the old Makefile did by default. ##-- ## CHECK AND ADAPT THE FOLLOWING DEFINITIONS ##-- # Name of your emacs binary EMACS = emacs # Where local software is found prefix = /usr/local/share # Where local lisp files go. lispdir= $(prefix)/emacs/site-lisp/org # Where local data files go. datadir = $(prefix)/emacs/etc/org # Where info files go. infodir = $(prefix)/info # Define if you only need info documentation, the default includes html and pdf #ORG_MAKE_DOC = info # html pdf # Define which git branch to switch to during update. Does not switch # the branch when undefined. GIT_BRANCH = # Where to create temporary files for the testsuite # respect TMPDIR if it is already defined in the environment TMPDIR ?= /tmp testdir = $(TMPDIR)/tmp-orgtest # Configuration for testing # add options before standard load-path BTEST_PRE = # add options after standard load path BTEST_POST = # -L /ert # needed for Emacs23, Emacs24 has ert built in # -L /ess # needed for running R tests # -L /htmlize # need at least version 1.34 for source code formatting BTEST_OB_LANGUAGES = awk C fortran maxima lilypond octave perl python # R # requires ESS to be installed and configured # ruby # requires inf-ruby to be installed and configured # extra packages to require for testing BTEST_EXTRA = # ess-site # load ESS for R tests # See default.mk for further configuration options. = Does this help? Its been a very long time since I looked at it, and I don't think that I changed anything in it then. Thanks Sharon. - -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk DrugFacts = https://www.drugfacts.org.uk Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4 -BEGIN PGP SIGNATURE- iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLj0Y4dHGJvdWRpY2Nh c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1v3YQ//YZIRrIqIZjSdW9pe SuTFsgZDYJD2w6M0+3sT2qiFrtN1PdeNvDZXshbVMEHX3ozyMB5GA0ioctAtiiD0 ohUID7oeZCwxBf/qMadRQ66vxiliw86AHdk0vEH72HdOFb0EPTD4ggUlIdYg8Agm pHyG62ZKA6yEgwamnfd5gtxQtI+L4dqr3UbvoqBXgh4RBgvXX8OianrRDZHMgVp7 HwbTLEmeOFYuc8De+bzgLSkMrHBUzOFxtCmeFmIAraJ8KnJ5d0wUJBZOl1H0zhLH UigeVK7WEJar8pjpSmEttyNYYo8ibJYe6wJZgtKtLHxDWhlG/HFCww3vLDu15tyl iqpEWzqNhgL1cPYguDwRyIPi1s/s0ox6q2h5sXhCNHWsUVXq+x9WDYtBKM9P29Zk y/0uh7qfUd3B783AOUPQ5YKPtzJBVqYZ1jFDwKI/GNDMPsKPiATJHTTSkU0ZVmEX lpOrvvSNqd97+MBZE3xQ80HgnprN2/a4jS6sWr6hS7tcmmzrnFIABhiFZrDyKw5G Sn0WzV+FtcScdlqvDneSL7Lte7xtYRXJc0RuRQDT33bTK9nNpcYNZKePwUww5rkx n/21K1v59u1hTSTxkjva8Qie5pT/rXNBcRi8xqdu8nxtjFawjrGdoqwbsJ+vpM7D 8tW/OqkNALB16c9ybCH3TIbcJFw= =Ut1g -END PGP SIGNATURE-
Re: Something has happened such that I can't export to latex
> On Fri, 29 Jul 2022 09:48:09 +0100, Sharon Kimble > said: Sharon> Morning all. Sharon> = Sharon> foo$ git pull Sharon> From https://git.savannah.gnu.org/git/emacs/org-mode Sharon>5be0c709b3..d37c0ee5fa main -> origin/main Sharon> Updating 5be0c709b3..d37c0ee5fa Sharon> Fast-forward Sharon> lisp/org.el | 2 +- Sharon> lisp/ox-latex.el | 7 +-- Sharon> mk/org-fixup.el | 2 +- Sharon> 3 files changed, 7 insertions(+), 4 deletions(-) Sharon> foo$ make autoloads Sharon> make -C lisp autoloads Sharon> make[1]: Entering directory '/home/boudiccas/git/org-mode/lisp' Sharon> rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc org-install.elc Sharon> org-version: 9.5.4 (release_9.5.4-684-gd37c0e) Sharon> Warning: Lisp directory '/usr/local/share/emacs/29.0.50/lisp': No such file or directory Sharon> Cannot open load file: No such file or directory, loadup.el Sharon> make[1]: *** [Makefile:72: org-version.el] Error 255 Sharon> make[1]: Leaving directory '/home/boudiccas/git/org-mode/lisp' Sharon> make: *** [mk/targets.mk:133: autoloads] Error 2 Sharon> = What does your local.mk contain? I donʼt think the default org makefile references loadup.el anywhere. Robert --
[PATCH v2] Add new entity \-- serving as markup separator/escape symbol
Max Nikulin writes:
>>> The good point in your patch is that \- is still work as shy hyphen
>>> (that, by the way, may be used in some cases instead of zero width
>>> space: *intra*\-word). On the other hand I have managed to find a case
>>> when your approach is not ideal:
>>>
>>> *\--scratch\--*
>>>
>>>
>>> -scratch
>>
>> Well. I think that it is impossible to use the same escape construct to
>> both force emphasis and escape it.
>
> Let's articulate the problem as follows: when some characters ("*". "/".
> etc.) besides used literally are overloaded with 2 additional roles that
> are start emphasis group and terminate emphasis group, in addition to
> lightweight markup heuristics, it is necessary to provide a way to
> disambiguate which of 3 roles is associated with particular character.
>
> "Activate" and "deactivate" characters or entities for emphasis markers
> are alternative and perhaps not so clear terms have used before.
>
> The advantage of zero width space is that "[:space:]" is part of
> PREMATCH and POSTMATCH (outer) regexps in
> `org-emphasis-regexp-components' and "[:space:]" is forbidden at the
> inner borders of emphasized span of text. The latter is mostly
> meaningful, however I am unsure if bold space has the same width as
> regular one, and space in fixed width font is certainly distinct.
>
> The problem with the "\--" entity is that it is not handled properly at
> the start of emphasis region. It neither disables emphasis nor parsed as
> complete entity, instead it becomes combination of "\-" shy hyphen and
> literal "-".
>
> Unsure if it can be solved consistently. Possible ways:
> - It addition to space-like (in respect to current regexp) entity add
> another one that acts as a part of word, but like "\--" stripped from
> output. Likely it should be accompanied by more changes in the parser
> and regexps.
> - Provide some new explicit syntax for literal character, start of
> emphasis group, end of emphasis group.
The fact that \-- was not parsed in your example is because entities
cannot be directly followed by a letter (see 12.4 Special Symbols).
You need
*\--{}scratch\--*
Concerning the 3 listed roles of the *_/+ markup, I propose to simplify
the problem a bit and not try to make \-- serve as a proper escape symbol.
Instead, we can document the already existing quoting entities:
("slash" "/" nil "/" "/" "/" "/")
("plus" "+" nil "+" "+" "+" "+")
("under" "\\_" nil "_" "_" "_" "_")
("equal" "=" nil "=" "=" "=" "=")
("star" "\\star" t "*" "*" "*" "⋆")
Then, your example should better be written as
\star{}scratch\star
\-- may better work between markup, not inside.
> Concerning zero width space workaround, I may be wrong, but Nicolas
> might consider using U+200B zero width space as the escape character for
> itself: single one is filtered out during export, double zero width
> space becomes single character. (I do not like this kind of "white
> space" programming language".)
This is too complex, IMHO.
If desired, we can again go the entity road and introduce
\zws entity.
Note that we already have
("nbsp" "~" nil "" " " " " " ")
("ensp" "\\hspace*{.5em}" nil "" " " " " " ")
("emsp" "\\hspace*{1em}" nil "" " " " " " ")
("thinsp" "\\hspace*{.2em}" nil "" " " " " " ")
Generally, it is a good idea to advertise entities in the manual.
Zero-width space is not only limited, it is impossible to use, e.g. in
tables when you want to quote "|". The only solution is using \vert or
\vbar entity.
> Another question is whether U+2060 word
> joiner (or some other character) should be added either as alternative
> to zero width space or to allow =verbatim= fixed width text
> surrounded by fixed width spaces.
This particular example is tricky.
If we put escape symbol _inside_ the verbatim, it is never possible to
know if the user intents to use that symbol literally or not.
But non-space before/after opening/closing markup char is hard-coded and
changing it is fragile.
Instead of using some kind of "escape" symbol here, I suggest turning to
the idea about inline special blocks. We can introduce a more verbose
markup that will allow spaces inside at the beginning/end of the
contents.
https://orgmode.org/list/87a6b8pbhg@posteo.net
Manuel Macías [ML:Org mode] (2022) About 'inline special blocks'
Instead of using the tricky *bold text*, we may allow _*{bold text}*_ or
something similar, with _name{...}name_ being inline special block.
Best,
Ihor
Re: Something has happened such that I can't export to latex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ihor Radchenko writes: > Sharon Kimble writes: > >> But, I'm unable to 'make autoloads' in the git version because its >> trying to connect to /usr/share/emacs and looking for something >> there which isn't there and just ends up deleting org-loaddefs, and the >> only way that >> I can get round it is by restoring git/org-mode from backup. >> >> Can you advise please as to how I can surmount that obstacle? > > I am not sure. make autoloads should have nothing to do with > /usr/share/emacs > > What exactly happens when you run make autoloads? > > Best, > Ihor Morning all. = foo$ git pull - From https://git.savannah.gnu.org/git/emacs/org-mode 5be0c709b3..d37c0ee5fa main -> origin/main Updating 5be0c709b3..d37c0ee5fa Fast-forward lisp/org.el | 2 +- lisp/ox-latex.el | 7 +-- mk/org-fixup.el | 2 +- 3 files changed, 7 insertions(+), 4 deletions(-) foo$ make autoloads make -C lisp autoloads make[1]: Entering directory '/home/boudiccas/git/org-mode/lisp' rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc org-install.elc org-version: 9.5.4 (release_9.5.4-684-gd37c0e) Warning: Lisp directory '/usr/local/share/emacs/29.0.50/lisp': No such file or directory Cannot open load file: No such file or directory, loadup.el make[1]: *** [Makefile:72: org-version.el] Error 255 make[1]: Leaving directory '/home/boudiccas/git/org-mode/lisp' make: *** [mk/targets.mk:133: autoloads] Error 2 = Does this help please? Thanks Sharon. - -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk DrugFacts = https://www.drugfacts.org.uk Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4 -BEGIN PGP SIGNATURE- iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLjnskdHGJvdWRpY2Nh c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1u8LQ/6AyONH3DgnIBaCgHb hX64gc4AmydhXDLCRHt5rAE3zBhgEUXtXOWaKmNIDaeLyiBcuqwPic5VEINrRVGF Rb8VVEaShQTbF93w8N+m5QaGwbYabJ+3Iw7bcO8kmq1kxKIW+P812R1fHQyVdWeC dq8EHbdZWoF2M2zROgVZxl6Vg8r+tBfk6vl9EZOjvUNrAeLKnMkZjJy9xgdCCJdE Qt49rHnIVqSgfUMhOpDK6VFPx28ogC6627m+H2KMggXffKo/93W10EqxB2HEFPrd UFrm0FW3U66AxwiZzpj1Zpe6KmRjl1FbgBsYoLIj+qG9QaQl07/0J8ltejN4V6m0 14r6VtGq+llafu+HMNBimyGmHlFKgh/cUwbjPns88aoxl/pZImTr8rlrfJKGuRSV LNuQL0jiEbBvzO1G4lnOhYhbV3JzJaTZoigeZDffPgWRaRdsXE1/b9Vu3EMfYv7W IMjrifgc5tD5r1GdhYSoQZg85bO+WjoauRv7+J3xzNVW4CWea5OrDQWAs3r1TfoW vuikoGTIRkFVi2LujEFhmcl6ic97MYDth7DSIIZcjGplpeKDrJCYirpsNgjyrTJA 8B5MUWHfX9Jf5lgXZGOaNJ4tR0YA9O5OQXkk/xt2gUx7PaxlFA4GdcS6/cRecoAf Lq/t3zewIk/oU4aPo83PorMoOMY= =S0sG -END PGP SIGNATURE-
Re: @string abbreviation in bib file not honored in (basic) org-cite
On Thu, 28 Jul 2022, at 14:12, Ihor Radchenko wrote: > Did you manage to get the copyright form from FSF? > They are supposed to respond within 5 working days. Yeah, I have the form. I signed it and scanned it, just haven't sent it off yet... -- Joost Kremers Life has its moments
Re: the comment environment does not work for checkboxes
Uwe Brauer writes: > #+BEGIN_COMMENT > WAIT Computer > :PROPERTIES: > :Nr: 4 > :Comp1:[X] > :Comp2:[X] > :END: > #+END_COMMENT > Does not. Any idea why? In a block, you must escape * as ,* — open the environment with C-c C-' and save it the same way, then it escapes them for you. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH v7] ol.el: add description format parameter to org-link-parameters
Hi Ihor and Hugo, Ihor Radchenko writes: > Bastien, can you please confirm that Hugo is listed in the FSF > records Yes I do! > and then add him to the contributors.org? Done. -- Bastien
[PATCH] ol-man.el (org-man-open): Set window point not buffer point
Here's a patch to fix the follow behavior for ol-man links so that the ::SEARCH functionality will actually work. Best! Tom From 2c3e3b994fd7b47a6e91d147d2b1f08cd97a1908 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] * lisp/ol-man.el (org-man-open): Set window point not buffer point When passed man:path::SEARCH org-man-open tries to use search-forward to jump to the location of e.g. a heading. Prior to this fix it only used search-forward, which will not change the point of the cursor in the window, meaning that even if there is a match it will not appear. Use sleep-for as a horrible hack to work around the fact that the man command runs in the background with no way to synchronize back. --- lisp/ol-man.el | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/lisp/ol-man.el b/lisp/ol-man.el index aa22964c5..5843cd5f6 100644 --- a/lisp/ol-man.el +++ b/lisp/ol-man.el @@ -43,12 +43,20 @@ If PATH contains extra ::STRING which will use `occur' to search matched strings in man buffer." (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) (let* ((command (match-string 1 path)) - (search (match-string 2 path))) -(funcall org-man-command command) + (search (match-string 2 path)) + (buffer (funcall org-man-command command))) (when search - (with-current-buffer (concat "*Man " command "*") - (goto-char (point-min)) - (search-forward search) + (with-current-buffer buffer +(goto-char (point-min)) +(unless (search-forward search nil t) + (sleep-for 0.75) ; async, can't block, no callback + (goto-char (point-min)) + (search-forward search)) +(previous-line) +(let ((point (point))) + (let ((window (get-buffer-window buffer))) +(set-window-point window point) +(set-window-start window point))) (defun org-man-store-link () "Store a link to a README file." -- 2.35.1
