Previously, links which end in a closing brackets got a non-breaking
space appended via a separate advice to `org-link-make-string`.
However, this did not work well with the other advice that removes
statistics cookies from links, mostly because I messed up the order in
which the advices were applied. To remedy this, the advice to remove
statistics cookies now also adds a non-breaking spaces as described
above.
When a headline ends on a closing bracket, Org adds an escape character
to the link text to distinguish the end of the link from the link
description. This escape character is a zero-width space, which is
counted for Org table alignment as one character, but the link itself is
displayed shorter, because the zero-width character is displayed as a
single pixel by emacs.
To work around this issue until the upstream fix is released, let's add
a final non-breaking space to those link descriptions to avoid the need
for the zero-width escape characters.
I found that opening this output on the right side to be annoying, so
let's switch try the bottom side window instead. This also works with
having an eshell buffer open at the same time, resulting in a nice reuse
of the right space of eshell windows that is usually empty.
With vertico, using the default `yank-pop` is nice enough. Furthermore,
yanking with helm does not update the current candidate selection when
in a minibuffer prompt (like for `find-file` or `org-insert-link`),
sometimes leading to confusion.
With `common-lisp-indent-function`, the indentation of `while` was not
correct – oops.
This change will break some current indentations, though. Stay tuned.
This is to have this extra blank line after refiling.
This reintroduces 76c8717, and reverts f064bf9 and 8ed64b7. The issue
with too many blank lines at some items may reappear.
I access bookmarks far more often than the list of local important
files, so let's skip the usual `C-o` hazzle and have bookmarks right
under point when available.
This is more reasonable than inserting a link to the current location of
point, which can be quite arbitrary (at least in my workflow). When a
link to the item at point is needed, it should be inserted manually.
This change is experimental and might be reverted.
Idea: we don't want to see those items until the deadline warning date
is due anyway. Drawback: those items are not shown even when jumping to
the specific date (or past it), so planning ahread get's a bit more
complicated.
Those cookies are correct when the link is inserted, but subsequently
gets updated (usually to `[0/0]`) when the statistics cookie is updated
in the Org item where the link is placed — removing any meaning from
this cookie. It's thus better to not have it at all, I think.
`org-capture-fill-template` unconditionally adds a final newline to each
template. This caused extra empty lines with the old templates when
nothing is inserted at point (`%?`), because in this case empty lines
before and after point were present, with nothing in between.
Those extra empty lines are gone now, and point is positioned after the
final non-blank character. When extra empty lines are needed, they have
to be inserted manually.
This is to better be able to identify those empty lines and keep the
notes tidy.
The new value for org-cycle-separator-lines` is the current default
value.
Inspired by the `use-package` documentation, but the other places where
`add-hook` is called this simplification does not seem to be appropriate
from my point of view (missing `-hook` suffix, better readability when
calling `add-hook` directly).
This seems to be slow, causing proced to take more time updating a
buffer than waiting the one second until the next update – resulting in
an unresponsive proced buffer.
Note: I am not sure whether this setting is correct, as `(not
on-windows)` will not be evaluated when `use-package` calls
`custom-theme-set-variables`. However, I think it will be evaluated
eventually, and that should be all that's needed.
It's nice to be able to collapse plain lists easily, as I have some
quite large ones. The comment advises to be careful with certain
situations yields strange results, though, which is why this setting is
deemed experimental for the time being.
Using orderless by default get's in the way of “usual” code completion
and shell completion, where prefix completion is the expected
behavior (for me). So let's try to use basic completion first, and try
to rely on orderless completion to kick in as soon as spaces are
involved (which should not happen for shell and code completion).
The completion colors should also help to see whether we are still using
basic completion or orderless completion. Let's try this for now.
Since `counsel-switch-buffer` has been replaced by the plain
`switch-to-buffer`, recently used files are not shown there anymore, so
let's make `recentf` easier to access.
NB: `consult` also provides a function akin to `counsel-switch-buffer`,
so maybe this keybinding will not be that relevant anymore in the
future.
Using ivy for completing in regions somehow has problems in eshell, so
let's not do it. The main use-case for using ivy in region completion
is for ledger, so maybe it can only be activated there?
This mostly reverts commit 615b285f74.
The default completion style is now to use orderless by default, but
certain categories can benefit from additional completions (e.g., file
and partial-completion).
It's quite hard to determine the appropriate completion categories,
though. Does Org have a dedicated one?
The reason is that while filtering Org headlines, sometimes one of the
other completion styles matches, hiding other possible matches that
would have been found by the `orderless` style. This can happen when
spaces are included in Org headlines (which is usually the case) and
those spaces match the search pattern. In this case, the position of
point is also relevant, which is not something I want.
It would be better to know which completion category is use in this case
and override the completion style for this only, but so far I haven't
found it. Continue looking …
This may change back in the future.
The ivy configuration is kept on purpose, in particular because some
counsel functions are still in use. Maybe those can be also be replaced
later on, maybe with helm functions? Not quite sure whether this is a
good idea, though.
This is mostly to speed up agenda generation, in particular the main
agenda view. It turns out that filtering out SCHEDULED items is
expensive, but in tags views there is no variable to exclude scheduled
items – as for todo and tags-todo views. Thus, SCHEDULED items must be
removed with a corresponding search pattern, which is slow.
`hydra-org-clock` thus only hosts keybindings for clock-related
commands, while the new `hydra-org-jump` is for jumping to Org items in
various ways. Feels cleaner to me this way.
This is an experimental setting to increase usage of completion
functionaly in my workflow. It's not clear yet whether I will find this
disturbing, though.
No need to conditionally enable it in main initialization function when
it can be done directly directly after loading `org-roam`. This keeps
the configuration of the package local, i.e. syntactically together.
It's annoying that `org-agenda-redo-all` always jumps back to today, so let's
try to avoid this by not having it bound anymore. I am usually completely
satisfied with `org-agenda-redo` anyway.
This never worked anyway, I would probably have had to define the source
globally for adaptive sorting to work, or something like that. However, I am
usually happying with the interactive narrowing of the candidates, so let's get
rid of adaptive sorting for now.
Get rid of some helm sources I usually don't use, to speed up function
execution. Indeed, on Windows 11, if this function takes too long, the Emacs
frame will loose its focus, which is super annoying!
`org-return-indent` is obsolete since 9.4, one should use `org-return` with
`indent` set to `t` instead – and I am not sure whether it will work if I rebind
`org-return` to some interactive lambda form. So let's try to not indentent
automatically anymore, maybe this is good enough?
This is instead of repeating the path again and again in the code. It's cleaner
this way, also easier to spot mistakes (see the now fixed definition for
`abbrev-file-name' …).
This is supposed to inhibit this warning:
```
Warning: Eager macro-expansion skipped due to cycle:
… => (load "db-utils.el") => (macroexpand-all (defalias 'db/sync-magit-repos-from-projectile …)) => (macroexpand (eval-when-compile …)) => (load "db-utils.el")
```
It should make calling this function also more robust.
Also updated the implementation to be more “dash-y”.
This is required by the regular expression in `org-agenda-show-clocking-issues`,
without this space, no consistency checking is done.
Also indent all other agenda views, for consistency.
Usually, when searching for important documents vie `db/helm-shortcuts`, I
forget to include the universal argument, abort the current search and repeat
it. This is annoying. Since listing documents is fast enough, including them
by default should alleviate this issue.
When retrieving the list of documents is too slow and should be disabled
interactively, providing a universal argument excludes this listing now.
Accidentally touching keys while having an active region happens far too often
to me, so let's keep things safe for now. Deleting an active via C-w is easy
enough when needed.
Used proced quite often lately, because it offers a nice process overview on
Windows without having to leave Emacs.
Default taken from [lw's blog][1], nice post!
`proced-enable-color-flag` will only be available from Emacs 29 on, but let's
included it nevertheless to be “future proof”.
[1]: https://laurencewarne.github.io/emacs/programming/2022/12/26/exploring-proced.html
When logging in via TRAMP and sudo, the root password is transmitted
automatically. This does not feel right to me, so let's not enable
`auth-source-pass` for now.
Displaying the current filters in the mode line alone often goes unnoticed for
me, so I need a more direct display. Let's add it to the first structural
header.
Do not delete shell side windows when deleting other windows and do not make
them selectable by default (although `ace-windows` does not seem to respect this
setting).
This should inhibit their windows from being split by `display-buffer` to
display normal buffers, but during early testing also magit buffers went to this
side window. This configuration may thus not be final yet.
Mostly moving functions around and updating page headers. Also removed some
obsolete functions, see updated command list for `db-org` use-package
declaration.
`org-ql-search.ql` contains the definitions for Org QL dynamic blocks but is not
automatically loaded by `org-ql.el`. Since I am using Org QL dynamic blocks
extensively, let's load this library explicitly when `org-ql.el` is activated.
Note that this implicitly reverts 939b1e882a,
which changed the use-package declaration from `org-ql-search` to `org-ql`
proper. So this commit was wrong after all (and the state before that commit
was right), but having a use-package declaration for `org-ql` instead of some of
its sublibraries seems to be clearer to me.
For this, `org-export-use-babel` has to be non-nil. To still inhibit source
block evaluation on export (both for performance and for security reasons), set
`:eval` to `never-export` by default.
Two configuration changes have been made:
- Removed `require-final-newline`, which originally had been set to nil; this is
not necessary (I think), because this is a buffer-local variable that is
usually set by the respective major mode when necessary; the default value is
nil anyway.
- Activate `minibuffer-depth-indicate-mode` by default, to signify the depth of
recursive minibuffer edits when they happen.
Remove some more redundant or obsolete (or even wrong) package declarations.
Also move some package declarations from the core configuration to more
specialized sections; this is not completely done yet, however.
When following links in the help buffer, inhibiting reuse of the current buffer
pops up a new one, but still updates the current buffer with the followed link.
The result is having two buffers with the same content, usually side by side.
Only the value for `completions-detailed` is non-default, the rest has only been
included for reference's sake.
Note that these configurations currently do not effect, as ivy and counsel do
not honor them.
Remove the separates “Fixes” section and inline its content to other
configuration sections. Fuse “Core Configuration” and “Basic Builtin Packages”
sections as those had always been similar anyway.
I am not sure yet whether I want to move configuration for files.el into a
separate use-package declaration, but maybe it's cleaner this way and easier to
find via imenu?
Text edited in this mode is usually meant for Redmine Wiki pages and the like,
and line-wrapping there is then done by the browser. Manually inserted line
breaks only disrupt here.
The problem seems to be the dynamically scoped variable `org-time-was-given`,
which is used by `org-read-date` to decided whether an hh:mm part is present.
The variable `org-time-was-given` is set by `org-read-date-analyze`, but only
when it's (globally) bound, which it is not on startup (since it's only declared
via `defvar`). Manually setting the variable to nil binds the variable and
everything seems to work nicely.
use case: GOALs may just be tagged with :HOLD: but do not have to have the HOLD
keyword; in this case, they should also appear in this agenda view, since they
will not be shown in the stuck agenda view anymore (among others).
Turns out `org-store-link` actually returns something and other code (e.g.,
`org-capture`) depends on this. Fix this, and on the way also recognize the
special case where `org-store-link` does not update `org-stored-links`.
This way the original function definition is left intact and can be found via
the help buffer.
The manual overwrite of `org-ql--link-regexp` has been left as it is, as it's a
`cl-defun` definition and I am not quite sure how turn this into an ELisp around
advice without breaking things.
The manual fix for `enriched-decode-display-prop` has also been left untouched,
maybe this should be an around advice as well?
From my point of view, this makes it clearer that the functions thus defined are
not meant to be used anywhere else.
Some one-time `advice-add` calls are still there, though, mostly because the
associated functions would be too long to inline them directly into their
present locations.
When adding a link to an item via `org-store-link`, and the link is not known
yet, the links is always put at the beginning of the list of currently known
links, as stored in `org-stored-links`. This allows to conveniently insert this
link via `org-insert-link` by just choosing the first element of the list, which
is selected by default.
However, when the link to the requested item is already present in
`org-stored-links`, the link is not pushed to the beginning of
`org-stored-links` by `org-store-link`, but kept where it is. When calling
`org-insert-link` to insert a link to the item, manual selection of the correct
link is required, which is annoying and unnecessarily interrupting the current
workflow. Even worse, when overlooking the notification that the link is
already stored, one will assume that the link to the requested item is at the
top of `org-stored-links` (which is isn't), subsequently inserting false links
when blindly calling `org-insert-link`. (Yes, this has happend to me …)
This patch fixes this issue by ensuring that links to items (regardless whether
they have already been known or not) are always put at the front of the
`org-stored-links`. This patch also removes the rarely used
`db/org-clear-stored-links` function, whose purpose was to provide some kind of
workaround, but turned out not to be convenient enough to actually be
used (because it also removed potentially useful links when clearing the cache).
The original version of `grep-read-files` includes file names in its default
values, giving an irritating completion candidate list when used with ivy.
Changed this to just let `completing-read` do the completion itself.
This is supposed to be the dual to DEADLINE, and shall someday release the
SCHEDULED property from its semantics to not display things before a certain
date (then the SCHEDULED property can be solely used to mean that things should
be done on a specific date).
However, the NOT_BEFORE property needs some more consistency checks, as
otherwise items that have a NOT_BEFORE property that's too far in the future may
be overlooked. Is this something for the monthly review?
Always use property matches for this, as it's more direct to me to understand
what the actual search criteria are (even if these are a bit slower). Also use
`<today>` instead of `<now>` to ignore the time part and always fall back to
00:00 time; this should avoid intra-day changes of whether an item appears on a
list or not.
