Re: [Orgmode] Re: org-link-mode ...
n.b. org-link-minor-mode exists, works, and i find it useful. i think it could use updating, but it is indispensible. btw i have not tried embark yet. i wonder if it could do something similar, or maybe it doesn't fontify. meanwhile, for years now i'm finding that i am wanting a new link-like anchor-like feature that would also be a minor mode for non-org and org. a little similar to org-link-minor-mode in usage. it is a very simple feature that is sort of a tiny subset of what id markers can do [those are extensible syntax thunks that use org ids in org and non-org]. i want to be able to place ===link thunks=== anywhere, such as elisp or shell comments, and have features for listing all of them that exist in my common directories [shell, elisp, org] like a better lgrep with wgrep, navigating from one to the next, fontification, completion, etc. so for example, i could put ===refactor whatever=== on a few things in various files, and navigate among them. they kind of indicate a topic or allow gathering together things that are related. have to try embark sometime to see if it can do things like that. On 8/18/09, Bastien wrote: > "Eric Schulte" writes: > >> Not sure if this is apropos to this conversation, but I've been thinking >> for some time that it would be useful to have a minor mode which would >> activate org-style links in non-org files. For example if an org link >> in the comment section of a source-code document could be highlighted >> and activated so that the C-c C-o keybinding can be used to follow said >> link. -- Eric > > Now I understand. Maybe someone can grab some code from Org and try to > write a minimal implementation of this. > > -- > Bastien > > > ___ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function
Esteban Ordóñez writes: > Hello Doctor. > >> That said: C-c C-t or M-x outline-hide-body > > C-c C-t > is org-todo, not outline-hide-body. I guess I customized that … > Thanks for the clarification. Glad to :-) Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function
Hello Doctor. > That said: C-c C-t or M-x outline-hide-body C-c C-t is org-todo, not outline-hide-body. Thanks for the clarification.
Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function
Philipp Kiefer writes: > Thanks, Eric, I am aware of customization options. > > My suggestion was aimed at improving the out-of-the-box experience of (new) > Org users by extending the usefulness of 'org-cycle' by > folding the subtree at point from anywhere inside it that is not itself a > parent item rather than doing nothing at all in those positions. > I've used two flavours of dedicated outlining software for many years and > both have easy shortcuts to fold the current subtree from > any position - it is a frequently used action. Do I understand you correctly that you mean tab should cycle visibility in this case? * headline some text CURSOR IS HERE - a list For me tab is useful as it is, because it indents whatever I am writing right now. That could be a list-item or a source-block or a verse. Org is not just for outlining but also for full-blown writing, and that would be disrupted if tab were to fold the entry away that I’m currently writing in. That said: C-c C-t or M-x outline-hide-body Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
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
org-mode for package documentation
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). What is the current status for that? Christopher
Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))
Ihor, I do not like lengthy emacs commands and make functions to generate them. I think, it is better to move such code to a script. A proof of concept is attached, however it is rather rough draft ./epm.el -Q --epm-dir $(emacs_pkgdir)/emacs-%e install compat ./epm.el -Q -L ~/src/compat install compat or export EPMDIR="$HOME/.cache/epm/emacs-%e" ./epm.el install compat to just abort compilation due to absent dependency ./epm.el missing compat On 20/04/2023 16:27, Ihor Radchenko wrote: Max Nikulin writes: Sure. And you will have such option (EFLAGS). By the way, accordingly to (info "(make) Command Variables") or (info "(standards) Command Variables") "Variables for Specifying Commands" https://www.gnu.org/prep/standards/html_node/Command-Variables.html it should be EMACSFLAGS rather than EFLAGS. In my opinion, ideally there should be 3 options for dependency management: 1. Completely disabled. If load from default paths failed than it is a fatal error. I have no problem with this approach when using system packages. However, it is almost guaranteed that compat.el is absent in global load-path as long as compat.el is not built-in. I see that installation attempt is not performed when packages are available. However form my point of view it is normal when compilation fails when dependency are not provided. It works so for decades for applications that use make. To be precise, usually I expect detection of missed libraries from configure scrips, but in some cases they are missed. Maybe such experience was formed when access to network was limited. For me it is quite natural that make does try to pull dependencies (at least by default) and it is my responsibility to ensure availability of necessary libraries. 2. Use specified directory outside of Org tree (~/.emacs.d/elpa by default) or any other directory that you named pkgdir. Only dedicated target may clean this directory. This is mostly an equivalent of -L switch. No, -L is for source directories of package (e.g. git repositories). I mean namely alternative `package-user-dir', but not managed by make. I do not like the idea of using ~/.emacs.d/elpa default. It is fragile if this default ever changes. I still consider it as a reasonable default for a user having just one emacs version who is going to build and run org. Both steps may use the same package directory. A developer who switches between various emacs versions may have set of packages for each emacs version. 3. Install packages to Org source/build directory. You decided to make 3 the default variant. I believe, it should be activated by a variable, e.g. AUTODEP = 1 in local.mk or from command line "make compile AUTODEP=1 It is now activated by EPACKAGES being non-empty. And it is non-empty by default because it defines list of build dependencies, not whether they should be managed by make. I think, it is better to require an additional command make autoloads make fetch-dependencies make compile Maybe. Then, also make doc and make install? In general "make install" may be executed by root while "make all" is a task for regular user. "make doc" is an optional step, so I do not see any problem. Ideally it might be make fetch-dependencies # or specify package directory # or load path in local.mk make all followed by optional doc or install And make repro, I have not justified my point of view to make repro yet. I do not like that versions of dependencies are ignored. I have noticed `package-install-from-buffer'. Perhaps it can be used to generate a stub package (e.g. org-build-deps) with Package-Requires line obtained from org.el. The only purpose of this package is to pull dependencies. It is just an idea, I have not tried such approach. This sounds fragile. I see no reason to go this far and using so complex approach. My idea is to ensure that *required* version is installed, not some stale one. I have not tried such approach though. Subject: [PATCH 3/7] Use compat.el library instead of ad-hoc compatibility function set * mk/default.mk (EPACKAGES): Demand compat library during compile time. when I asked for more granular commits I expected this change in Subject: [PATCH 2/7] org-compat: Enable compat.el To separate adding dependency and replacing org-compat functions to compat. For me, PATCH 3/7 grouping is more reasonable. So, I disagree. Splitting EPACKAGES modification would create transient commit with non-working Org. I just do not like that a single line change in default.mk (modification of build process) is buried in a large patch (changes of the code). My idea was that -EPACKAGES ?= +EPACKAGES ?= compat should be in the same commit as -;; Package-Requires: ((emacs "26.1")) +;; Package-Requires: ((emacs "26.1") (compat "29.1.4.1")) Currently patch 2 requires compat, but it is provided till patch 3. Despite in commit 2 the package does not do anything useful, I
Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function
Thanks, Eric, I am aware of customization options. My suggestion was aimed at improving the out-of-the-box experience of (new) Org users by extending the usefulness of 'org-cycle' by folding the subtree at point from anywhere inside it that is not itself a parent item rather than doing nothing at all in those positions. I've used two flavours of dedicated outlining software for many years and both have easy shortcuts to fold the current subtree from any position - it is a frequently used action. Fraga, Eric schrieb am Fr., 28. Apr. 2023, 11:45: > Hi Philipp, > > On Friday, 28 Apr 2023 at 10:49, Philipp Kiefer wrote: > > Well, it could simplify things a good deal further if, on issuing the > > command when point is *not* on a parent heading, (non-global) > > org-cycle would instead fold the subtree that point is in, i. e. do > > 'outline-up-heading' and 'hide-subtree' on the parent heading. > > You could always bind TAB to your own command that does this. As an > illustration, I have TAB bound to my own function that invokes > completion instead unless I'm on an org heading! > > --8<---cut here---start->8--- > (defun esf/complete-or-indent () > (interactive) > (cond >;; ((eq 'message-mode major-mode) >;; (message-tab)) >((and (eq 'message-mode major-mode) > (message-point-in-header-p) > (looking-back "^\\(To\\|B?[Cc]c\\): *.*" > (line-beginning-position))) > (if (looking-back " ") > (progn > (message "try inserting alias abbrev") > (insert (symbol-value (intern-soft (completing-read "Expand > alias: " mail-abbrevs nil t) mail-abbrevs > (progn > (message "try eudc") > (eudc-expand-try-all >((eq 'message-mode major-mode) > (completion-at-point)) >((org-table-p) > (org-cycle)) >((looking-back "[ \t\n]") > (if (eq 'org-mode major-mode) > (if (looking-back "^\\(\\*+ \\| *|\\)[^\\n]*") ;a heading or > table line > (org-cycle) > (indent-for-tab-command) > ) > (indent-for-tab-command)) > ) >(t > ;;(consult-company) > (completion-at-point) > ))) > --8<---cut here---end--->8--- > > You could use a similar (and much simpler) approach to get what you > want. > > HTH, > eric > > -- > : Eric S Fraga, with org release_9.6.4-335-ge065b5 in Emacs 30.0.50
Dealing with inter-org links vs #+include
Hi, I want what may be two conflicting things: - Produce a monolithic HTML export of an main org file that #+include:'s other org files. - Have links in the other org files that are valid both when the monolith is exported to HTML and when visiting the individual org files in Emacs. Below is a simple test. The "main.org" includes "a.org" and "b.org". The "b.org" has two types of links. The link: [[A][A by headline only]] is valid in the HTML export of "main.org" but it is not valid for Emacs visiting b.org (C-c C-o gives "No match - create this as a new heading?"). And then vice versa for the link: [[file:a.org::*A][A by file with headline]] I can follow that link in Emacs but it renders to an with "a.html#MissingReference". And export fails outright if I do not include #+options: broken-links:t Is there a way I can have my cake and eat it too? That is, how can I make a link between "sub" org files that can be followed by Emacs and also that produces a valid HTML link when the main.org is exported? Thanks! -Brett. $ ls *.org a.org b.org main.org $ for n in *.org echo "=== $n ===" cat $n end === a.org === * A This is A. === b.org === * B This is B. Links: - [[file:a.org::*A][A by file with headline]]. - [[A][A by headline only]]. === main.org === #+title: Main #+options: broken-links:t * Main This is main. * Includes #+include: a.org #+include: b.org * Links - A :: [[file:a.org]] - B :: [[file:b.org]] signature.asc Description: PGP signature
Re: [ANN] lisp/ob-tangle-sync.el
Ruijie Yu writes: > Thanks. Can you make a full patch from the current main branch to your > changes, with a commit message and so on? This would help reviewers to > look at the full picture of what are modified. Take a look at the > manpage git-format-patch(1) if you aren't sure how to do it. I'm at the moment patching the =org-babel-tangle= function, to act appropriately to the =:tangle-sync = requests. It's harder than I thought, because the way the function currently works is to populate a temporary buffer with source block contents and then to overwrite the destination tangle file, i.e. it is unaware of the tangled files contents during processing. This is efficient, but works anathema to syncing changes in the opposite direction, i.e. when a block requests =:tangle-sync import=. I'm currently doing a small rewrite of the function that populates a list of comments in the tangled file (restricted to stemming from the source org file), and then either populates this temporary buffer with the org mode source block contents or with the already tangled contents (when "import" is given for that block). I will submit a full patch with these changes (with properly detailed commit messages) from the main branch in the next few days.
Re: [ANN] lisp/ob-tangle-sync.el
Mehmet Tekman writes: > Ruijie Yu writes: > >> Great idea! Some inline comments below. >> >> You only need to say #'expand-file-name instead of the quoted lambda. >> Also, you need to set the variable, otherwise the variable >> `org-babel-tangle-sync-files' is undefined. >> >> What I have in mind is this: >>:set (lambda (var val) (set var (mapcar #'expand-file-name val))) >> >> Here you don't have to use `progn' because it is implied from >> `save-excursion'. >> > > Thanks! I've made your changes, and I've also incorporated John > Wiegley's comments about using "import" instead of "pull" as a > tangle-sync action word (small diff attached). > > I've also written up my changes in the ~etc/ORG-NEWS~ and > targeted my custom variable for the 9.7 release (diff attached). Thanks. Can you make a full patch from the current main branch to your changes, with a commit message and so on? This would help reviewers to look at the full picture of what are modified. Take a look at the manpage git-format-patch(1) if you aren't sure how to do it. For the commit message, take a look at https://orgmode.org/worg/org-contribute.html#commit-messages for inspirations. >> Is there possibility to have a local minor mode (without introducing too >> much code changes)? > > I initially tried it this way, but the problem is that an org > source block buffer might be in sync-mode, but it's > corresponding tangle file might not be, making any changes > asymmetric. > > Another issue is in order to see the changes in the tangled file, > the tangle buffer needs to be reverted (with user prompt) which > then switches off the sync-mode for that buffer on reload. > > One way around this (and it's something I implemented 3 years ago in > my messy org-tanglesync[0] MELPA code) is to set an explicit list of > "sync files", and then for Emacs to parse every =:tangle= header in a > given file when loaded (via =org-src-mode-hook=) to create an alist of > config files and their associated tangled files[1], such as > =((file1.conf . (tanglefile1.txt tanglefile2.txt etc)))=. Then, for > example, when ~tanglefile1.txt~ is loaded, Emacs knows that it should > load the sync-mode too. > > This approach works reasonably well when the "sync files" list is > mandatory, but it's also prone to errors if a sync file is edited and > the alist of config files isn't updated, and the user would also lose > the flexibility of having ~ob-tangle-sync~ function everywhere. > > I think a global minor mode is really elegant in this regard and I > wish I knew about it 3 years ago! Thanks for explaining this. Yes, this sounds like a lot of work with probably insufficient audience, so I'd wait for more use cases to come up before thinking about local minor modes. -- Best, RY [Please note that this mail might go to spam due to some misconfiguration in my mail server -- still investigating.]
Re: Suggestion to increase usefulness of TAB key / 'org-cycle' function
Hi Philipp, On Friday, 28 Apr 2023 at 10:49, Philipp Kiefer wrote: > Well, it could simplify things a good deal further if, on issuing the > command when point is *not* on a parent heading, (non-global) > org-cycle would instead fold the subtree that point is in, i. e. do > 'outline-up-heading' and 'hide-subtree' on the parent heading. You could always bind TAB to your own command that does this. As an illustration, I have TAB bound to my own function that invokes completion instead unless I'm on an org heading! --8<---cut here---start->8--- (defun esf/complete-or-indent () (interactive) (cond ;; ((eq 'message-mode major-mode) ;; (message-tab)) ((and (eq 'message-mode major-mode) (message-point-in-header-p) (looking-back "^\\(To\\|B?[Cc]c\\): *.*" (line-beginning-position))) (if (looking-back " ") (progn (message "try inserting alias abbrev") (insert (symbol-value (intern-soft (completing-read "Expand alias: " mail-abbrevs nil t) mail-abbrevs (progn (message "try eudc") (eudc-expand-try-all ((eq 'message-mode major-mode) (completion-at-point)) ((org-table-p) (org-cycle)) ((looking-back "[ \t\n]") (if (eq 'org-mode major-mode) (if (looking-back "^\\(\\*+ \\| *|\\)[^\\n]*") ;a heading or table line (org-cycle) (indent-for-tab-command) ) (indent-for-tab-command)) ) (t ;;(consult-company) (completion-at-point) ))) --8<---cut here---end--->8--- You could use a similar (and much simpler) approach to get what you want. HTH, eric -- : Eric S Fraga, with org release_9.6.4-335-ge065b5 in Emacs 30.0.50
Suggestion to increase usefulness of TAB key / 'org-cycle' function
To quote from the Org Manual: "Org greatly simplifies the use of outlines by compressing the entire show and hide functionalities into a single command, org-cycle, which is bound to the TAB key." Well, it could simplify things a good deal further if, on issuing the command when point is *not* on a parent heading, (non-global) org-cycle would instead fold the subtree that point is in, i. e. do 'outline-up-heading' and 'hide-subtree' on the parent heading. This would make collapsing subtrees a lot easier and quicker as it could be done from any non-parent position inside a tree. It is very noticeable when collapsing multiple adjacent trees in succession. Currently, hitting TAB when not on a parent heading merely returns an 'EMPTY ENTRY' message - not useful at all. 'Outline-up-heading' (C-c C-u) has to be called manually each time before hitting TAB to achieve what the user is most likely attempting to do anyway. Personally, I doubt this change in behaviour would break much for users, unless one were to assume that there is a lot of Elisp code out there that relies on 'org-cycle' doing nothing in such cases, incurring the 'EMPTY ENTRY' reprimand to boot, rather than first checking whether point is on a parent heading. I don't see any drawbacks when 'org-cycle' is used interactively.
