Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Sławomir Grochowski writes: > Philip Kaludercic writes: >> I have pushed the changes to master. > > Thank you Philip for your help. It works. > > But there is one more small thing. > A message that is displayed in the minibuffer. > It contains two pieces of information: > > (1) command name > Right now it's hardcoded. > We need to change the it from `help-quick-toggle' to > `org-columns-help-quick-toggle'. > How to do it? > Add another variable like `help-quick-use-map'? > Maybe 'help-quick-command-name'? Instead of using substitute-command-keys, we could just use this-command, but that assumes that help-quick can always be toggled by the command that invokes it. > (2) keybinding to the command name > Just to modify message string. Add '\\'. > To use other keymap. > Change is in the diff below. I don't see how this would work in general, at the very least it breaks the regular usage. Furthermore, I am not convinced we have to change anything here, since C-h C-q (the default binding for `help-quick-toggle') should also hide the buffer if one uses your command, or am I mistaken? > > diff --git a/lisp/help.el b/lisp/help.el > index d4e39f04e53..35412b9d2fe 100644 > --- a/lisp/help.el > +++ b/lisp/help.el > @@ -263,7 +263,9 @@ help-quick >;; ... and shrink it immediately. >(fit-window-to-buffer)) > (message > - (substitute-command-keys "Toggle display of quick-help buffer using > \\[help-quick-toggle]." > + (substitute-command-keys "Toggle display of quick-help buffer > using\\ \\[org-columns-help-quick-toggle]." > + > + > > (defun help-quick-toggle () > "Toggle display of a window showing popular commands and their bindings. > -- > > 2.30.2 > > > Regards, -- Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Philip Kaludercic writes: > Sławomir Grochowski writes: > >> Thank you Philip for the explanation and preparing the code snippet. >> >> So what are the next steps? >> Can you merge your patch? > > If this is everything, I can push the change. But I'll test it first. I have pushed the changes to master. -- Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Philip Kaludercic writes: > Sławomir Grochowski writes: > >> Thank you Philip for the explanation and preparing the code snippet. >> >> So what are the next steps? >> Can you merge your patch? > > If this is everything, I can push the change. But I'll test it first. I tried out using your `org-columns-help-quick-sections' variable, but it seems that `where-is' didn't find all the commands you wanted: --8<---cut here---start->8--- Move column & rowAdd & delete columnEdit column Edit values View Misc. M- move column left M-S- add column < narrow e edit value c show content C-c C-o open link M- move column right M-S- delete column > widen a edit allowed value o show overview g redo s attributes n next allowed value v show value q quit p previous allowed value C-c C-c toggle checkbox or quit C-c C-t change TODO state --8<---cut here---end--->8--- (some of the descriptions are pretty long, are they not?) Are commands like `org-columns-move-up' part of the next release of Org? I am using whatever is currently on master. -- Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Sławomir Grochowski writes:
> Thank you Philip for the explanation and preparing the code snippet.
>
> So what are the next steps?
> Can you merge your patch?
If this is everything, I can push the change. But I'll test it first.
--
Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Sławomir Grochowski writes: > Philip Kaludercic writes: > >> We could add a `help-quick-use-map' variable and bind it to `global-map' >> by default. You can then re-bind it in your command. > > I'm sorry, but I don't quite understand it. Just this here: diff --git a/lisp/help.el b/lisp/help.el index 1ef46e394f3..5700f10fdc8 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -175,6 +175,9 @@ help-quick-sections COMMAND is the symbol of a command and DESCRIPTION is its short description, 10 to 15 char5acters at most.") +(defvar help-quick-use-map global-map + "Keymap that `help-quick' should use to lookup bindings.") + (declare-function prop-match-value "text-property-search" (match)) ;; Inspired by a mg fork (https://github.com/troglobit/mg) @@ -193,7 +196,7 @@ help-quick (let ((max-key-len 0) (max-cmd-len 0) keys) (dolist (ent (reverse (cdr section))) (catch 'skip - (let* ((bind (where-is-internal (car ent) nil t)) + (let* ((bind (where-is-internal (car ent) help-quick-use-map t)) (key (if bind (propertize (key-description bind) You would then only have to rebind `help-quick-use-map' in your custom command. > It seems to me that the simplest way is to add a parameter to the > function, like this: > > (defun help-quick ( keymap) > > Because it will not change the behavior for previous calls to this > function. And it will allow to pass specific keymap, not need to pass > and search in whole global-map. > > What do you think? Eli said that we shouldn't change the signature of public functions, so I don't think that this is an option. -- Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Sławomir Grochowski writes:
> chad writes:
>
>> If you don't mind me asking:
>
> Thank you for sharing your views.
>
>> What are your high-level goals and immediate needs for changing
>> help-quick?
>
> I want to reuse quick-help for functionality in org-mode - column view
> package. See first email in this thread - there is even a screenshot.
>
>> It looks like you may be trying to have multiple
>> simultaneous quick-help buffers active at once?
>
> Philip Kaludercic writes:
>
>> Is there a reason not to re-use the same buffer? I am not sure if we
>> need multiple quick-help buffer to co-exist at the same time.
>
> Yes you are right. There is no need to create multiple quick-help
> buffers.
>
>> The idea here was that some other function could rebind
>> `help-quick-sections' dynamically. That way you avoid the redundant
>> arguments (which would all have to be documented).
>
> Is this really a good practice?
It certainly is practice.
> Relying on global variables instead of passing variables as a parameters?
A lot of Emacs Lisp code uses dynamic scope. Examples include
`default-directory' or a lot of search functionality.
> I tried like this:
>
> +(defun org-columns-help-quick-toggle ()
> + (interactive)
> + (let ((help-quick-sections org-columns-help-quick-sections))
> +(help-quick-toggle)))
>
> So passing a 'sections' data works.
> But it doesn't read keymaps from `org-columns-map'.
> Because as I understand it read keymaps available only in the created buffer
> "*Quick Help*" not from the buffer with org-colview.
>
> This is the line from function: `help-quick' where it happens:
> + (let* ((bind (where-is-internal (car ent) nil t))
> Signature:
> (where-is-internal DEFINITION KEYMAP FIRSTONLY NOINDIRECT NO-REMAP)
>
> So previously I was passing a keymap `org-columns-map' to function
> 'where-is-internal'.
>
> Eli Zaretskii writes:
>> In any case, we cannot change the signature of help-quick, since it's a
>> public function.
>
> If I can't modify the function `help-quick' how can I make it work?
We could add a `help-quick-use-map' variable and bind it to `global-map'
by default. You can then re-bind it in your command.
> I'm attaching the whole patch:
>
> From dcc5172c87f9f7acfc9ab3a72f7de8b363a05447 Mon Sep 17 00:00:00 2001
> From: Slawomir Grochowski
> Date: Sun, 7 Apr 2024 01:13:27 +0200
> Subject: [PATCH] lisp/org-colview.el: add help-quick sections for org-colview
>
> ---
> lisp/org-colview.el | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/lisp/org-colview.el b/lisp/org-colview.el
> index d71c84a76..547f50df8 100644
> --- a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -169,6 +169,7 @@ See `org-columns-summary-types' for details.")
>(org-cycle-overview)
>(org-cycle-content))
>
> +(org-defkey org-columns-map "?"#'org-columns-help-quick-toggle)
> (org-defkey org-columns-map "c"#'org-columns-content)
> (org-defkey org-columns-map "o"#'org-overview)
> (org-defkey org-columns-map "e"#'org-columns-edit-value)
> @@ -231,6 +232,46 @@ See `org-columns-summary-types' for details.")
> "--"
> ["Quit" org-columns-quit t]))
>
> +(defvar org-columns-help-quick-sections
> + '(("Move"
> + (org-columns-move-up . "up")
> + (org-columns-move-down . "down")
> + (org-columns-move-cursor-left . "left")
> + (org-columns-move-cursor-right . "right"))
> +("Move column & row"
> + (org-columns-move-row-up . "move row up")
> + (org-columns-move-row-down . "move row down")
> + (org-columns-move-left . "move column left")
> + (org-columns-move-right . "move column right"))
> +("Add & delete column"
> + (org-columns-new . "add column")
> + (org-columns-delete . "delete column"))
> +("Edit column"
> + (org-columns-narrow . "narrow")
> + (org-columns-widen . "widen")
> + (org-columns-edit-attributes . "attributes"))
> +("Edit values"
> + (org-columns-edit-value . "edit value")
> + (org-columns-edit-allowed . "edit allowed value")
> + (org-columns-next-allowed-value . "next allowed value")
> + (org-columns-previous-allowed-value . "previous allowed value")
> + (org-columns-toggle-or-columns-quit . "toggle checkbox or quit")
> + (org-col
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
t; > (defun help-quit () >"Just exit from the Help command's command loop." > -- > 2.30.2 > > > > JD Smith writes: > >> Also recall we had a discussion in bug#68236 >> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg00124.html> >> about expanding quick-help to include mode-local >> personalized binding shortcuts (with org as a particular target of interest). > > Thank you for the link I haven't seen that topic. > > Regards, -- Philip Kaludercic on icterid
Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]
Ihor Radchenko writes:
> Philip Kaludercic writes:
>
>>> Thanks for reporting!
>>> Does the error persist if you upgrade Org mode to the latest 9.6.20
>>> version? If yes, what about the development version?
>>
>> Sorry, I cannot really reproduce the bug in any reliable way.
>
> Even if you cannot reproduce reliably, it is not a problem. Org mode has
> a way to enable recording diagnostics info (via
> org-element--cache-self-verify). But that only makes sense if we know
> for sure that the bug is present on the latest development version of
> Org mode.
>
> So, I just need to know if you keep seeing problems after upgrading to
> the latest main.
>
> If you have no time or interest diagnosing the bug and the warnings keep
> appearing, you may disable cache in your config by customizing
> org-element-use-cache.
The issue is rather, I don't see the warning at all anymore ("cannot
reproduce reliably" in the sense of might randomly occur at some point
again).
--
Philip Kaludercic on peregrine
Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]
Ihor Radchenko writes: > Philip Kaludercic writes: > >> This just popped up in my *Warnings* buffer: >> >> --8<---cut here---start->8--- >> ⛔ Warning (org-element-cache): org-element--cache: Org parser error >> in .links.org::29638. Resetting. >> The error was: (wrong-type-argument integer-or-marker-p nil) >> ... >> I was editing a file through occur over TRAMP, but otherwise I don't >> think anything special was going on. > > Thanks for reporting! > Does the error persist if you upgrade Org mode to the latest 9.6.20 > version? If yes, what about the development version? Sorry, I cannot really reproduce the bug in any reliable way. -- Philip Kaludercic on peregrine
[BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete
org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export
org-link-doi-export)
("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207"
["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("mailto" :follow
#[514 "\301\300\302Q\"\207"
["mailto" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("https" :follow
#[514 "\301\300\302Q\"\207"
["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("http" :follow
#[514 "\301\300\302Q\"\207"
["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("ftp" :follow
#[514 "\301\300\302Q\"\207"
["ftp" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("help" :follow org-link--open-help :store
org-link--store-help)
("file" :complete org-link-complete-file)
("elisp" :follow org-link--open-elisp))
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-pre-tangle-hook '(save-buffer)
org-highlight-latex-and-related '(native latex entities)
org-export-before-parsing-hook '(org-attach-expand-links)
org-link-shell-confirm-function 'yes-or-no-p
org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-link-elisp-confirm-function 'yes-or-no-p
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-function #[514 "\207" [] 3
("/home/phi/Source/emacs/lisp/org/ox-odt.elc" . 16675)]
)
--
Philip Kaludercic on peregrine
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
Ihor Radchenko writes: > Stefan Kangas writes: > >> Adam Porter writes: >> >>> Since transient.el is part of Emacs now, these kinds of menus should >>> probably be implemented with it. >> >> IIUC, this is not a menu, but a reminder of key bindings that are usable >> in that context. Other keybindings here are self-inserting keys, which >> are equally useful, and they wouldn't be available in a transient. The point of quick-help is to provide a persistent buffer with useful bindings, comparable to what Nano does OOTB. > I am wondering how quick-help, transient, and which-key (AFAIU, it is to > be included into the core soon-ish) play together. > > transient provides a specific way to define the displayed layout, among > other things. At the same time, quick-help provides an alternative > (undocumented) way to define the layout. And which-key uses pre-defined > layout. One critical difference between which-key and transient compared to quick-help, is that the latter has nothing to do with prefix maps, but (by default) just presents global bindings, and is as such closer to a curated version of `describe-bindings' (sort of like how `shortdocs' is a curated version of `apropos-functions'). > I am wondering if transient style to define how various options in the > menu/help buffer/which-key buffer can be unified. -- Philip Kaludercic
Re: Htmlize support, maintenance, and Org mode
Ihor Radchenko writes: > Philip Kaludercic writes: > >>> We might consider extending engrave-faces to cover all the htmlize >>> features. >> >> Perhaps I missed something, but is there an issue with the built-in >> `htmlfontify'? > > Org uses htmlize historically. > Nicolas once tried to port htmlize support into htmlfontify [1], but it > did not go well [2]. > > [1] https://list.orgmode.org/orgmode/874lnw5rfi@nicolasgoaziou.fr/ > [2] https://list.orgmode.org/orgmode/874ldzovv4@nicolasgoaziou.fr/ How come you infer that it didn't go that well? It just seems incomplete? > As for engrave-faces, it is working for both LaTeX and HTML export. Would that have the same issue has htmlize, that it copies the colours from the currently active theme, causing issues when exporting a website while a dark-theme is enabled?
Re: Htmlize support, maintenance, and Org mode
Ihor Radchenko writes: > Jonas Bernoulli writes: > >> `htmlize' is currently maintained at https://github.com/hniksic/emacs-htmlize >> but its maintainer hasn't been responding to any issues and pull-requests >> for quite some time now and seems to be inactive on Github altogether. > > Hmm... Org has built-in htmlize support and I did not know that it is > not maintained actively. > > Note that Timothy wrote https://github.com/tecosaur/engrave-faces that > provides similar functionality but not just for HTML. > > We might consider extending engrave-faces to cover all the htmlize > features. Perhaps I missed something, but is there an issue with the built-in `htmlfontify'?
Re: org-mode for package documentation
Ihor Radchenko writes: > Payas Relekar writes: > >> IIRC, Richard Stallman said he'd be amenable to it, _provided that_ Org >> fulfilled all the requisite functionality from Texinfo. > > Correct. We need to add more flexible markup. The idea was to add > something similar to special blocks, but inline. Currently, ox-texinfo > is approaching the extended markup with macros. See doc/doc-setup.org. > >> Ihor (org maintainer) was also receptive, but I don't remember if/how >> much progress happened towards the goal. > > We discussed possible syntax of inline custom markup to be added. See > https://orgmode.org/list/87bkqx4jyg.fsf@localhost Someone is to go ahead > and try to implement it. It might be me in future, but I am prioritizing > working on some other new features in Org for now. My general question is what advantage this would provide over just using TeXinfo in the first place, if the required complexity of the markup has to be the same as for TeXinfo in the first place?
Re: org-mode for package documentation
Björn Bidar writes: > Philip Kaludercic writes: > >> Christopher Dimech writes: >> >>> Dear Compeers, >>> >>> Some months ago there had been a discussion about using org-mode >>> to produce package documentation. Which would allow the use of >>> Latex3 (e.g. use of colour, floating images). >> >> Where/when did this happen? Could you provide a few pointers? > > I don't know exactly but when use-package was merged into Emacs there > were discussions if keeping the documentation in org-mode format is > fine. > > From what I understood it is possible. Using org-mode to generate TeXinfo manuals is already possible, due to the ox-texinfo backend, but I haven't been personally that satisfied with the quality of the output, due to the lack of (easy) support for the fine distinctions in markup that texinfo provides. That is why the use-package documentation had to be translated from org-mode to texinfo, which was part of the reason the process of merging took so long.
Re: org-mode for package documentation
Christopher Dimech writes: > Dear Compeers, > > Some months ago there had been a discussion about using org-mode > to produce package documentation. Which would allow the use of > Latex3 (e.g. use of colour, floating images). Where/when did this happen? Could you provide a few pointers? > What is the current status for that? > > Christopher
Re: About org-mode-tests and CI
Bastien writes: > Thanks Simon for bringing this up! > > Our first need is to have someone volunteering for maintaining our > current test infrastructure - Christian is helping with this right > now but cannot afford to become the maintainer right now. > > Philip, is this something you would consider? I am sorry, I know too little about Org and use it too superficially to be of much use here. > If so, that'd be very helpful. Let me know your SourceHut username > and I'll give you access to https://git.sr.ht/~bzg/org-mode-tests/ > > I am a paid user on SourceHut and I'm happy pulling org-mode-tests > from the orgmode.org server to build from the latest repo manifests. > > Once we solve this maintenance issue, we might consider evolving > the tests so that they use Guix instead of Debian if it provides a > real benefit for our needs. > > In the meantime, this test infrastructure has already proven very > useful IMHO. > > Thanks,
Re: About org-mode-tests and CI
Simon Tournier writes: > Hi, > > Recently, Bastien told me about using GNU Guix for some tests of Org. > Neat! Then, Bastien pointed this org-mode-tests [1] effort. > > Unrelated, Philip provides Guix recipes [2] for various old Emacs > versions. I cannot find the discussion right now, but I should point out that for the intent of testing, if the code depends on any external packages, it will also be necessary to provide packages for every version so that the compiled byte code, to avoid byte-code incompatibility. Maybe https://yhetil.org/guix-devel/87y21n3x99@posteo.net/ could be of use? > Org and Guix are part of the GNU system. Therefore, we could imagine to > bridge instead of relying on Debian. :-) > > Moreover, what would be another advantage? Run the exact same > computational environment from locally to SourceHut builds. > > Two directions: > > 1. The SourceHut image of Guix [3] could be used but – and maybe I am > missing a point since I am not an expert about SourceHut CI – the state > (revision) of this image is not controlled and thus it requires > something like: > > image: guix > tasks: > - guix: | > guix pull -C project/path/to/channels.scm > > Well, I do not know how SourceHut is caching but somehow the .yml > configuration leads to always the same computational environment > (image), in which “make test” is run. Therefore, the CI could spend > more time in computing again and again this fixed state than running the > Org test suite. :-) This is also what I intend to do one day (in my case for Compat), but I can imagine that if a substitute server existed with all the old versions of Emacs, then that could be pinged for tests and that would make testing a lot faster. I believe that a number of packages on MELPA and GitHub use Nix to the same effect. But perhaps the SourceHut CI integration with Guix just requires more work? I can't say, because I am neither a SourceHut CI nor a Guix export :/ > 2. Using [2], it appears to me almost straightforward to build > beforehand a Docker pack containing all the requirements; say emacs@26, > curl, gcc-toolchain, git, etc. And this Docker pack would be built > using GNU Guix, > > guix pack -f docker -m manifest.scm > > where the file manifest.scm lists all the requirements. Using adequate > option as --save-provenance, this Docker pack can be inspectable [4] and > it could be stored to any Docker registery. > > Hence, the line, > > image: debian/oldstable > > or some images as, > > image: ubuntu/focal > repositories: > emacs: http://ppa.launchpad.net/kelleyk/emacs/ubuntu focal main > 3FF0E01EEAAFC9CD > > would be replaced by some images produced by “guix pack -f docker” > stored to some Docker registery. > > > All in all, I forked the project [1] but the SourceHuts build (CI) > requires some fee, right? Well, let me know how we could test this > approach of using Guix as base for running Org test suite. > > (The maintenance of such can be part of the story too. ;-)) > > > Last, without putting the cart before the horse, I think this work could > be a kind of preliminary proof-of-concept for testing Emacs packages > (ELPA, MELPA, etc.). > > Cheers, > simon > > 1: https://git.sr.ht/~bzg/org-mode-tests > 2: https://git.sr.ht/~pkal/guix-emacs-historical > 3: https://man.sr.ht/~dhruvin/builds.sr.ht-guix-cookbook/ > 4: https://hpc.guix.info/blog/2021/10/when-docker-images-become-fixed-point/
Some feature requests/questions
Hi, I was wondering if someone could help me out to solve these annoyances I have been having with Org: 1. Most things I would like to clock are related to Emacs, but I often forget to check my agenda first, clock in, then clock out. Is there some way I can automatically manage clocking when I enter a directory/kill the last buffer? 2. Capturing is configured by describing what keys should do via `org-capture-templates'. Is there some way to use bookmark-like strings and completing-read? 3. Related to the previous point, is there a way to configure capture templates /in/ org files? That would make it easier to dynamically add notes, without having to do so centrally, in my configuration file. 4. Limiting until when events may repeat, without having to duplicate timestamps manually (or via `org-clone-subtree-with-time-shift'). Better yet being able to do so for an entire subtree/file, and have the property inherit itself. All of these issues I have encountered by trying to use Org for the last few years at University, managing courses, notes, assignment due dates, appointments, etc. The friction that these issues cause often have me become sloppy after a while, which defeats the entire purpose. I have little experience with the Org codebase, but would be interested in helping to implement these features, in so far they don't just exist and I haven't found out about them. -- Philip Kaludercic
Re: Fixing the automatic generation of Tex info node names
Ihor Radchenko writes: > Philip Kaludercic writes: > >> For some reason ox-texinfo removes periods from node names. It seems >> this is not necessary as info can render these files without any issues, >> and in certain cases not intended (e.g. I had a node named "Emacs 28.1" >> and it was abbreviated to "Emacs 281"). > > According to > https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Node-Line-Requirements > >>> Unfortunately, you cannot reliably use periods, commas, or colons >>> within a node name; these can confuse the Info reader. Also, a node >>> name may not start with a left parenthesis preceding a right >>> parenthesis, as in (not)allowed, since this syntax is used to specify >>> an external manual. (Perhaps these limitations will be removed some >>> day.) > > Not that we cannot work around this, but we need something different > than the proposed patch. Would you happen to know what the issue is? As I said, the documents appear to render just as expected in my case, but it might just be due to the version or because I didn't hit some specific edge-case. > Best, > Ihor -- Philip Kaludercic
Fixing the automatic generation of Tex info node names
For some reason ox-texinfo removes periods from node names. It seems this is not necessary as info can render these files without any issues, and in certain cases not intended (e.g. I had a node named "Emacs 28.1" and it was abbreviated to "Emacs 281"). This patch should resolve the issue: >From f9a8d9738cb118939a8307bf13f63ec5950bd59b Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Tue, 19 Apr 2022 12:17:40 +0200 Subject: [PATCH] ox-texinfo: Allow for periods in node names * ox-texinfo.el (org-texinfo--sanitize-node): Don't remove periods from node names. --- lisp/ox-texinfo.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el index a01bb268c..3a2c4791b 100644 --- a/lisp/ox-texinfo.el +++ b/lisp/ox-texinfo.el @@ -555,7 +555,7 @@ periods, commas and colons." (replace-regexp-in-string "[ \t]+" " " (replace-regexp-in-string - "[:,.]" "" + "[:,]" "" (replace-regexp-in-string "\\`(\\(.*?)\\)" "[\\1" title) (defun org-texinfo--sanitize-title (title info) -- 2.30.2 -- Philip Kaludercic
Re: [ANN] EmacsConf 2021 Call for Proposals
quil...@riseup.net writes: > What a great call for papers. If it was created using Emacs, it would > be great to have a talk or a howto for how it was made. It seems to me like it is just an org-mode document, converted to plain text using one of the built-in exporters. > Congratulations > for the organizers for making this a free software event and not just an > event with free software. -- Philip Kaludercic
