I use repeating tasks in the org-mode agenda for, for example, a daily checklist of things that need to be done. But if I go on vacation, for example, then all the dates are out of date, in which case I have to either mark them each done over and over in the agenda view, or else manually edit the dates in the actual .org file. Is there a "catch up" function that I just don't know about?
Well, if you use the ++1d or .+1d repeater, you'll just have to ack them once. While, by default, with the +1d repeater, you'll see them all 15x times...
Related
Steve Ives provided ALLMEM code to run an edit macro against all members of a PDS, see here: How can I run ISPF Edit Macros in Batch
Some members in my PDS are too large (by default) for edit/view and suffer "Browse substituted" on the line:
Address 'ISPEXEC' 'EDIT DATAID('data1')',
'MEMBER('member1') MACRO('workmac')'
Since browse cannot run edit-macros the MACRO('workmac') bit does not come into play, there is no END command issued to return execution to the loop in ALLMEM, and the overall batch execution stops until I manually hit my PF3.
Is there any way I can force TSO to keep in EDIT mode for these large members?
Is there any way I can force TSO to keep in EDIT mode for these large
members?
Maybe.
ISPF Edit has an LRECL limit. If your members that are too large exceed this there isn't anything much you can do about that. If you want to engage in radical notions like splitting each record in two so they are editable, editing them, then reassembling each record pair back into a single record, that's a separate issue.
But maybe the problem isn't your LRECL, but the number of records. You might be able to do something about that.
You could try increasing the REGION parameter for your batch job in which you are running your ISPF Edit macro. I don't know if your personal ISPF settings matter in an ISPF batch job, but you could type EDITSET in an ISPF Edit session and ensure that the value for "Maximum initial storage allowed for Edit and View" is 0, just in case it matters.
Be advised that this may fix your problem, but it's possible your members are simply too big for ISPF Edit. In that case, you must find an alternate mechanism. Since you already have an edit macro, perhaps you could alter it, substituting your own code for ISPF Edit services, and run that code against your data. Perhaps this is an opportunity to learn the marvelous features of your SORT utility. Or awk. Lots of options.
If it is only certain members then it is not an LRECL issue, but strictly size. As cschneid mentioned you can try and maximize the storage available to Edit. However, if the member is really large then you wold eventually hit a storage limit. Currently Edit or View will switch to Browse in that case. If you are running Batch then this presents a problem as you describe. There is nothing that will keep it in Edit. RC=4 is already a documented return code for Browse being substituted, but if you are in batch then you probably end up in a display loop. One possible solution would be to have your own copy of ISRBROBA in ISPPLIB and have it set .RESP = END in the )INIT or )PROC section so as to force an END if BROWSE gets used. Since it is a batch job it is unlikely you would need the normal version of ISRBROBA. You would just make sure that your PANEL library is concatenated first.
In all the docs I'm reading about org mode it seems that numbered lists will auto number when moving to next list item but it seems that I can't trigger it. So, I'm not understanding how [#50] (to start at 50 instead of 1) works.
Am I just missing some thing about numbered lists?
Assuming that org mode is in fact enabled (either with editing a file with the .org extension, or by manually triggering it with org-mode), you can auto-increment a numbered list by hitting M-<RET> after a list item.
1. First entry (M-<RET>)
2.
Edit: Looking back, seems I may have misunderstood your question. This is how to trigger the autoincrementing of the list items, but are you instead asking how to start at number other than 1?
(Keeping this as an answer because it does provide a solution, at least to the assumed question.)
I do really like key-chord.el but I'd need it to only trigger when I start pressing keystrokes after a short delay during which I didn't do anything elapsed. I'd like to know if it's easy to modify key-chord.el to do that.
Why I want that is simple and I'll try to explain it as easily as I can:
I do want keychords to be assigned to keys that are on my "strong" fingers (no pinky) and that are on my home row (I do touch-type). Hence I'm potentially creating quite a few keychords which may clash with common words / code when I'm typing.
I realized that everytime there's a clash (i.e. keychords kicking in while I didn't want to) it's because I'm in the process of frenziedly modifying the buffer.
Here's an example...
I'm a fast typist so if I'm entering, say, "held", there is never going to be a long delay between when I add the 'e' of "held" and when I then type the 'l'. So in this case it should be "obvious" that I do not want key-chord to kick in when I type 'ld'. However if there's a pause and if 'ld' is an assigned key-chord and then I hit 'ld', then it is very unlikely that I'm writing code / text that would be starting with 'ld'. So in this later case (and because I have assigned 'ld' to a key-chord), I do want it to kick in.
Now don't get me wrong: I'm not sayin this would eliminate every single possible clash in every single case. All I'm saying is that, in my case, this would probably eliminate 99.9% of the (already rare) clashes. The "time lost" should one clash still occur after this change to key-chord would be negligible compared to the amount of time key-chord is making me gain.
The code to key-chord.el is very small so maybe such an addition wouldn't be too hard?
Does anyone have an idea as to how if it would be easy to modify key-chord.el to provide such a feature? (I hope I explained correctly what I want to do)
Here's the code to key-chord.el and half of it is comments:
http://emacswiki.org/emacs/key-chord.el
The Idle Timer mechanism should be able to facilitate this.
C-hig (elisp) Idle Timers RET
I'll leave it to you (or someone else) to figure out the details. Offhand thoughts are:
enable the Key Chord functionality via an idle timer
use post-command-hook to disable it again
That might be all that is needed?
I see two timings at play here
time before the chord (between the letter before the chord and the chord. If short enough, no chord)
time after the chord (if new letter quickly typed, no chord)
The second type of timing is probably more natural, and easy to get used to. If one type the chord, a short timeout before it executes can be accepted. (This is not what you asked for and would not solve the "ld" example. But it could potentially solve the problem with letter combinations that may appear in the beginning of words.)
The first type of timing is probably harder to get used to. When one have completed typing a word and the next thing is to type a chord, I suspect it is not a natural instinct to make a short pause. If one uses the chord often, one is likely to type it quickly, and get annoyed if it is not recognized (and the two chars are inserted into the text instead). What I want to say is, I am not sure a timing before the chord will solve the problem to a satisfactory degree.
As for the implementation of such a timing. The way the state machine in the key-chord-input-method function is currently structured, it would grow exponentially with the number of timers to consider (if I recall correctly). I.e. there would be at least about a dozen new lines of code.
To experiment with the functionality, try phils suggestion in the other answer: a post command that disables chords, and an idle timer that, after a fraction of a second, enables them again. A quick and dirty way to disable and enable chords, without actually changing minor mode, would be to set the input-method-function variable.
Code for test purpose only. It assumes, but does not check, that key-chord-mode version 0.5 is loaded and enabled:
;; Helper functions to be used in timers and hooks
(defun my-enable-chords () (setq input-method-function 'key-chord-input-method))
(defun my-disable-chords () (setq input-method-function nil))
;; Start test
(add-hook 'post-command-hook 'my-disable-chords)
(setq my-timer (run-with-idle-timer 0.3 'repeat 'my-enable-chords))
;; Finish test
(remove-hook 'post-command-hook 'my-disable-chords)
(cancel-timer my-timer)
For the past year and a half, I've maintained a monolithic buffer in Org Mode for my engineering notes with my current employer. Despite containing mostly pointers to other documents, this file has become quite large by human standards (48,290 lines of text), while remaining trivially searchable and editable through programmatic means (read: grep and Org Mode tag search).
One thing bothers me, though. When I perform a tag search using Org Mode 6.33x, Org's sparse tree view retains the folded representation of unmatched trees within the buffer (that is, content preceded by a single asterisk, *). This is generally useful for smaller buffers or those better organized into a single tree with multiple branches. However, this doesn't work especially well for documentation where each new tree is generated chronologically, one for each day, as I've been doing.
.
Before I continue, I'll note that my workaround is inherent in what I've just asked, as are the obvious alterations in my documentation habits with this buffer. However, the following questions remain:
1) Why does Org Mode organize trees in this manner when performing sparse tag searching? The technical details are self-evident, the UX decisions less so.
2) If I wished to correct this issue with a script written in Emacs Lisp, what hooks and commands should I explore in more detail to restructure the document view? Writing overrides for the standard commands (for example, org-match-sparse-tree) is already self-evident.
.
Thank you in advance.
As you already noticed the problem only affects the top level headings. The good thing is that in org-mode you can demote easily all headings with simple keystrokes. This way you can avoid the problem. Also cleaning up afterwards are just some simple keystrokes.
Step-by-step instructions:
Mark the full buffer
Call M-right (for outline-demote)
Input * root\n at the beginning of the file
Now, build up your subtree and do what you want with it.
When done you can remove * root\n at the beginning of the file and promote the headings again with M-left
I have got the impression that you can even leave the overall-heading where it is for your application.
for those who don't know, imenu is a thing in emacs that lets a mode insert one or more menu items into the menu bar. The most common usage is to make a "table of contents" accessible from a drop-down menu, so the user can quickly jump to declarations of functions or classes or sections in a document, etc.
imenu has a couple different ways of working - in the first and more commonly used way, a major mode provides regexps to imenu, and imenu uses those regexps to perform the scan of the buffer and build the index. A major mode sets this up by putting the list of regexps into imenu-generic-expression. The second way is for the major mode to perform its own scan. It can do this by instead setting the variable imenu-create-index-function to the name of a function defined by themode, which returns a list containing the table of contents.
I'm doing the latter - imenu-create-index-function - but sometimes the fn takes a looong time to run, say 3 or 4 seconds or more, which freezes the UI. If I make the operation asynchronous, that would solve that problem.
I know about asynch processes. The scan logic is implemented in elisp. Is it possible to run elisp in an asynch process? If so, how?
Or, is there a way to run regular elisp asynchronously in emacs, without resorting to an asynch process?
I think the way font-lock does it is, it fontifies on idle. It keeps state and fontifies a little at a time, always remembering where it left off, what else needs to be fontified, what has changed since the last fontification run, etc. Is my understanding correct? Maybe I could use this incremental approach .
Recommendations?
To run elisp asynchronously you can use either run-with-idle-timer or run-with-timer. I imagine you'll want the idle version. Check the documentation links for more details.
Note: If the code takes 3 or 4 seconds to run, it'll still take that long (and freeze your Emacs while it runs), so if you can break the work up into small enough chunks that it only takes .5 seconds or so at a time, that might work well.
One package that I use all the time, pabbrev.el, uses idle timers really well - I never notice it running. That might be a good package to examine to see how it breaks up the work (it is scanning all open buffers and building up a word frequency list).
The answers posted by TreyJackson and jeremiahd were valid back in year 2011. Now, in 2018, here is a link to the emacs documentation for asynchronous processes.
You can run elisp in an asynch process by spawning emacs in batch mode as the process, see http://www.emacswiki.org/emacs/BatchMode . Other than that, there's basically nothing as far as I know.
It looks like http://nschum.de/src/emacs/async-eval/ basically wraps the boilerplate necessary to do this. No clue if it's actively maintained or anything though.