In Org-mode a task can have one of several process states (e.g. TODO, DONE...). The process state list is configurable and the user may either set a task state directly, or they may cycle over all states using the S-Left and S-Right key combinations.
What I find counter-intuitive, however, is the interaction between state change tracking and the use of the S-Left and S-Right keys. More specifically, when using those keys one may go over several states before settling on the one they need, especially if they type too fast and skip a desired state. Unfortunately, Org-mode will happily log every single one of those state changes, despite the fact that they happened within a few seconds and cannot correspond to what happened with an actual real-life task.
Is there a way to have Org-mode filter the generated log entries, so that those intermediate state changes are not inadvertently logged? E.g. a setting that would merge state changes when they happen in less than X seconds?
To select a TODO state and bypass any logging associated with that, use:
(setq org-treat-S-cursor-todo-selection-as-state-change nil)
in your Emacs configuration file.
Call org-todo with a prefix argument using C-u followed by a number. This avoids the extra window.
From M-x describe-function RET org-todo RET:
With C-u prefix arg, use completion to determine the new state. With
numeric prefix arg, switch to that state. With a double C-u prefix,
switch to the next set of TODO keywords (nextset). With a triple C-u
prefix, circumvent any state blocking. With a numeric prefix arg of 0,
inhibit note taking for the change.
So, using the example from the manual you linked, let's say you had the following workflow states defined:
(setq org-todo-keywords
'((sequence "TODO" "FEEDBACK" "VERIFY" "|" "DONE" "DELEGATED")))
And you had the following in an org file:
* TODO Go Grocery Shopping
You could go immediate from TODO to DONE by typing C-u 4 C-c C-t. The result should look something like:
* DONE Go Grocery Shopping
:LOGBOOK:
- State "DONE" from "TODO" [2014-10-30 Thu 09:20]
:END:
Assuming you have the following in your init.el / .emacs file (which I highly recommend):
(setq org-log-into-drawer t)
Keep in mind if you have multiple workflow states defined (e.g. one for tasks, one for events, etc.), the prefix number goes in order of the keywords. Org-mode doesn't distinguish between different workflow sequences.
Related
I use company-mode a lot on natural language completion with the local dictionary. I am wondering if there is a way to automatically add a whitespace upon completion.
For example, currently when I type abili and select the first candidate ability, my insert point is right after y|. Is there a way that the company-mode can add a space so my insert point is after y |?
I could not find any related information on this but this issue mentioned a space is added after completion in the Eshell mode. Apparently this is exactly what I want.
The issue mentioned the function completion-at-point. Is there a way that I can change or have a function that I can override the current completion mechanism?
Thanks! I’d really appreciate any suggestions.
You could add a hook to company-after-completion-hook that would be called after completion with any of your company backends, eg.
(defun my-company-after-completion-hook (&rest _ignored)
;; this would be called with the completion candidate, so you could
;; modify it to insert spaces based on the candidate
(just-one-space))
;; or setq-local in a mode hook, eg. for text-mode/org-mode or wherever you are
;; completing with dictionary words
(setq company-after-completion-hook #'my-company-after-completion-hook)
If you only wanted to add space after completing with a specific backend you could see if the backend already implements a post-completion action, otherwise you could probably advise it.
I use Emacs org-mode to organise my todo list. Recently I found under each todo item it automatically generates a property drawer containing a key ID and the corresponding value, something like this:
** TODO meeting XXX
SCHEDULED: <2014-07-12 Sat 14:00>
:PROPERTIES:
:ID: 46673B08-F9D9-4966-B70A-A2ADBC2ADE0E
:END:
Entered on [2014-07-08 Tue 20:40]
I have no idea how this property drawer is generated, and I did not have it before. If delete it, next time I start Emacs to read the file, it will come back again. What would I do?
Would you have used MobileOrg? If yes, that's the culprit (and that clutter is something more that keeps me away from using MobileOrg ATM).
Posting your configuration file would definitely help diagnose what's causing this. For some, this is the desired behavior of the org-id package, which is explained in Handling Links in the Org-mode Manual:
The library org-id.el must first be loaded, either through org-customize by enabling org-id in org-modules, or by adding (require 'org-id) in your .emacs.
An init.el / .emacs file that enables this functionality, might for example, include the following:
;; Use global IDs
(require 'org-id)
(setq org-id-link-to-org-use-id t)
;; Update ID file .org-id-locations on startup
(org-id-update-id-locations)
Additionally, you could check your .emacs.d directory to see if there is a .org-id-locations file, which is generated by the org-id package.
To disable this behavior, you should remove all org-id package related code from your configuration files.
It's likely that this behavior occurs every time you use (org-store-link), commonly bound to C-l l. You might also want to check out Assign IDs to every entry in Org-mode
I use M-. to jump to definitions of class/functions. Sometimes there are multiple classes with the same tag, so I need to use C-u M-. to jump to multiple files, hence multiple buffers. Now my question is, how do I go back to the original buffer quickly? I know C-x b, but you need to type in the buffer name, or it just give you by default the last buffer you visited, is there anyway to go further? For example, go to the previous buffer of the last buffer?
I believe that M-. calls find-tag by default. You should be able to go back up the stack of locations with M-* (pop-tag-mark).
From C-h f find-tag:
A marker representing the point when this command is invoked is pushed
onto a ring and may be popped back to with M-*. Contrast this with the
ring of marks gone to by the command.
Icicles multi-command icicle-find-tag, bound to M-. in Icicle mode, combines all of what vanilla Emacs commands M-. (find-tag), M-, (tags-loop-continue), tags-apropos, and list-tags do. And it does more.
You can complete against any tags, cycle (in different orders) among a subset of tags matching an additional pattern, and so on, visiting multiple tags in a single command invocation. You choose the tags you want to visit, in any order --- you need not visit each one in sequence.
You first enter (using RET) a regexp that all tags you are interested in must match (it could be vacuous, to get all tags).
After that, you can type a pattern that a subset of the tags and or their source files must match.
That is, by default you can complete against multi-completion candidates that are composed of the tag itself and its source file name.
You can choose candidates to visit using C-mouse-2 in *Completions* or by cycling among their names using down and up and then using C-RET to visit.
You can return to your original location using M-* (icicle-pop-tag-mark). You can also return to it by just using C-g to finish your M-. invocation.
More information here.
I use winner-mode for this (and other similar situations).
Add (winner-mode 1) to your init file, and then when you wish to return to the window configuration that you were in before jumping to the tags, you just type:
C-c<left> to call winner-undo (repeating as many times as necessary)
If you had visited multiple tags in another buffer, this will get you back to your original buffer (or the previous buffer, at any rate) in a single step, rather than stepping back through the individual tags one by one.
If the tags have taken you through multiple buffers, then you'll need to type C-c<left> once for each buffer (or C-c<left>C-xzzz... if you'd gone on quite a long detour :)
Which setting needs to be done in init.el file, which allows completing the rest of command if one hit M-x and initial letter of the command.
Infact in need something similar as ido-mode for minibuffer too
The ido-mode for the "M-x minifuffer" is called smex (smex use ido).
Available on the main package repos of Emacs. Homepage here
I think you are talking about incremental completion, i.e., having Emacs automatically complete what you type in the minibuffer, without your having to explicitly request completion (e.g., using TAB).
Incremental completion is available in Icicles, as well as Ido and IswitchB. And icomplete-mode shows you completion candidates in a similar way to Ido and IswitchB.
Icicles incremental completion has two aspects:
When buffer *Completions* is displayed and updated, showing you the candidates matching your input -- how soon that happens and what triggers updating
Whether and how much your minibuffer input is expanded (completed) to reflect the set of matching completions
Wrt *Completions* display (#1):
You can use C-# to cycle among the levels (normal, eager, off) at any time.
Normal means that *Completions* is not displayed until you ask for it, but thereafter it is automatically updated as you type/edit your input.
Eager means that *Completions* is displayed as soon as you type something that matches at least two candidates.
(There is also an option to show *Completions* from the outset, before you type anything -- useful as a kind of menu.) You can also specify how long to wait after you type or delete a character before updating *Completions*.
Wrt input expansion (#2):
Icicles is unique in expanding your input to (typically) the longest common match among all completions, even when completion uses apropos matching (that is, regexp or substring -- S-TAB), not just prefix matching (TAB).
There are 4 levels/behaviors for this expansion, plus off (no expansion):
Off -- this is like Ido and IswitchB: completions are shown, but your input is not completed
On request -- expand your input only when requested (TAB or S-TAB)
On request or sole candidate -- on request or when there is only one match
Always for TAB, on request for S-TAB -- TAB expands whenever possible; S-TAB is like previous
Always -- expand input whenever possible
C-" toggles between two of the input-expansion behaviors that you choose (a user option), and C-M-" cycles among all of the behaviors.
Can anyone advise how I can move forward (or back) by n commas in emacs?
I am trying to navigate my way through a CSV file
I am aware I can do something like:
C-u 100 M-f
but being able to do something more reg-exp like specifically on commas would be more accurate
The other thing I tried was combining C-u # and C-s , but that didn't work
It will with a keyboard macro, which you can define interactively.
C-x( -- start recording
C-s,RET -- search for a comma (the RET is important; see below)
C-x) -- stop recording
You can now execute that macro again with C-xe (and then just e for continued single repetitions), or use a prefix argument to repeat it a given number of times:
C-u 100 C-xe
Keyboard macros are tremendously useful, and can be easily bound to keys, or even added to your .emacs file in elisp form if you want to keep one for future use. See the manual for details.
edit:
More seamlessly for ad-hoc macros, you can supply the prefix argument when you stop the recording to get exactly that many repetitions, including the one used to record it:
C-x(C-s,RETC-u 100 C-x)
I was seeing some unexpected behaviour with that sequence before I added the RET to explicitly invoke isearch-exit before stopping recording. It behaved as if it was only recording and repeating the comma key (leading to the comma being inserted many times instead of being searched for many times).
Using edit-last-kbd-macro after recording, I could see there was a quirk when using isearch in a macro, such that the C-x typed when stopping the recording is actually included in the macro definition, which was presumably causing the problem for this particular method of invocation. Similarly with the alternate F3 and F4 bindings (in that case, F4 ends up in the definition). I don't know whether this is a bug or a feature, but apparently it pays to exit the isearch before stopping the macro recording!
p.s. Although the two sets of macro recording bindings aren't identical in all respects, everything here also works with F3 and F4, so for this example you could slightly more concisely use F3C-s,RETC-u 100 F4
With
iy-go-to-char you
can do M-3C-cf, to go to
the third comma.
Use CSV mode which will give you convenient functions to do what you want and more
You could record a macro with C-u C-u M-f or C-u C-u C-f and use that. If it's infrequently used, record it using PF3 and play it back by pressing PF4.