Re: Annoyance when resolving clock idle time with emacsclient
On Fri, Oct 9, 2020 at 6:40 PM Samuel Loury wrote: > > I almost always choose 'k' (keep) and it is often not responding after > the > > first or several presses. But as Samuel Loury pointed out, I'll try > > pressing ten times at least, the next time it happens. > > IIRC, pressing 'k', even a lot, did not work. I realized that i might be > linked to the fact that 'k' asks for some minibuffer input and this > input is waited in the other frame. And when emacs is waiting for some > minibuffer input in one frame, there is nothing I could do to get the > control on the other frame.¹ > > What I am suggesting is to press a lot 'i', until org-mode releases its > grasp on the other frame. You notice that it is so when the letter 'i' > gets written in front of you :-). Then, when org-mode let you go, you > can run M-x org-resolve-clocks and you will be able to press 'k' this > time. > > I hope this is clearer this time. > > Good luck :-). > > ¹ Actually, there is one way. Send the SIGUSR2 signal to emacs (pkill > -SIGUSR2 emacs) so that it starts the debugger (in your current focused > frame), then close the debugger and re run manually M-x > org-resolve-clocks. SIGUSR2 would have enabled the debug-on-quit, so > disable it with M-x toggle-debug-on-quit > > Ah, got it. Will also try the SIGUSR2 trick, thanks. Regards,
Re: Annoyance when resolving clock idle time with emacsclient
On Fri, Oct 9, 2020 at 9:35 AM Ihor Radchenko wrote: > > Thanks for the tip, I'll try pressing 10 times the next time it happens > > (which is probably today). > > That sounds really odd. Could it be that there are multiple open > (without ending time) clocks existing in your org files? > > I never have multiple clocks active either, as I only have one "work journal" file and only start one clock for the current day's entry. Regards,
Re: Disambiguate internal links?
On Fri, Sep 4, 2020 at 9:47 PM Bastien wrote: > Hi Budiman, > > Budiman Snowman writes: > > > One way I know is using a unique dedicated target, e.g.: > > > > * topic1 > > See topic [[topic2]]. > > See glossary [[glossary topic2][topic2]]. > > > > * topic2 > > * glossary > > ** <> topic1 > > ** <> topic2 > > > > What are other ways available? > > I don't know other way, but I don't see what's wrong with this one? > > Hi Bastien, Sorry for replying too late (setup a filter on my Gmail account). Nothing wrong actually, except it's a minor visual distraction. So far I've only used a short unique tag like <<201009a>> (for today's date + letter) so it's not a major distraction.
Re: Annoyance when resolving clock idle time with emacsclient
On Thu, Oct 8, 2020 at 10:30 PM Eric S Fraga wrote: > On Thursday, 8 Oct 2020 at 16:54, Samuel Loury wrote: > > Also, another boring behavior of org-resolve-clocks is that I generally > > have to press several times (about ten times) on the "i" key to ignore > > the message. > > Similar with the 'q' key (usually requires 2-3 presses) although not > with 'k' (single press sufficient always). > > I almost always choose 'k' (keep) and it is often not responding after the first or several presses. But as Samuel Loury pointed out, I'll try pressing ten times at least, the next time it happens.
Re: Annoyance when resolving clock idle time with emacsclient
On Thu, Oct 8, 2020 at 9:54 PM Samuel Loury wrote: > Hi, > > Actually, I realized though that even though the client was appearing > frozen, by pressing several times on "i" (ten times also), it eventually > closes the resolve clock stuff and let me play with emacs like nothing > happened. Then, I can run manually M-x org-resolve-clocks in case I > wanted to really resolve the clocks (using k or g or whathever). > > Even if this is an ugly workaround, I Hope that will help :-). > > Thanks for the tip, I'll try pressing 10 times the next time it happens (which is probably today).
Annoyance when resolving clock idle time with emacsclient
I use emacsclient (with Konsole tabs, if that matters). I usually have several emacsclient instances open in different tabs. When I start a clock and then get away long enough, Emacs will prompt me to resolve the idle time in different buffer that has the clock, usually in the first buffer that I get back to. But often I cannot type a response in this buffer, or in the original buffer's tab, so that I have to "killall emacsclient" and reopen all the files/emacsclient instances. Anyone experience the same?
Re: Disambiguate internal links?
On Wed, Jun 3, 2020 at 9:21 PM Diego Zamboni wrote: > I almost always use a CUSTOM_ID property for this, e.g. > > * topic1 > See topic [[#topic2][topic2]]. > See glossary [[#glossary_topic2][topic2]]. > > * topic2 > :PROPERTIES: > :CUSTOM_ID: topic2 > :END: > > * glossary > ** topic1 > :PROPERTIES: > :CUSTOM_ID: glossary_topic2 > :END: > ** topic2 > :PROPERTIES: > :CUSTOM_ID: glossary_topic2 > :END: > > Are there advantages to using CUSTOM_ID instead of dedicated target? I'll stick with dedicated target for now, because it's shorter to type. Regards, BS
Re: agenda-view: match tags: Sorting by number of tags matched?
On Thu, Jun 4, 2020 at 11:31 AM Kyle Meyer wrote:
> Budiman Snowman writes:
>
> > Suppose I have this document:
> >
> > * topic1 :tag1:tag2:tag3:
> > * topic2 :tag1:tag2:tag4:
> > * topic3 :tag1:tag3:tag4:
> > * topic4 :tag2:tag3:tag4:
> > * topic5 :tag1:tag2:
> > * topic6 :tag1:tag4:
> > * topic7 :tag3:tag4:
> > * topic8 :tag1:
> >
> > And I turn on org-agenda m, then search for tag1|tag3|tag4. Emacs will
> then
> > show the results (all entries match) in the above order.
>
> org-agenda-sorting-strategy is the main option that controls sorting in
> the agenda. Going through the values there, I don't see anything
> fitting your description. But there is a user-defined-{up,down} option
> that lets you implement your own logic via org-agenda-cmp-user-defined.
> Here's an example. It's probably brittle and inefficient in a number of
> ways (and maybe completely wrong), but hopefully it gives you something
> to start with.
>
Thanks! I'll play with it later.
> * topic2 :tag1:tag2:tag4:
> > * topic1 :tag1:tag2:tag3:
> > * topic3 :tag1:tag3:tag4:
> > * topic4 :tag2:tag3:tag4:
> > * topic6 :tag1:tag4:
> > * topic5 :tag1:tag2:
> > * topic7 :tag3:tag4:
> > * topic8 :tag1:
>
> Hmm, your example query is "tag1|tag3|tag4", so a few of those lines
> seem off. For example, shouldn't topic 3 be at the top?
Ah yes, I wrote incorrectly, I thought I wrote the query "tag1|tag2|tag4".
You understood my goal perfectly.
Regards,
BS
Disambiguate internal links?
I have this document: * topic1 See topic [[topic2]]. See glossary [[topic2]]. * topic2 * glossary ** topic1 ** topic2 What are ways to disambiguate the internal links? The first link should link to the topic2 first-level entry, while the second link should go to the topic2 entry under glossary. They both have the same title. One way I know is using a unique dedicated target, e.g.: * topic1 See topic [[topic2]]. See glossary [[glossary topic2][topic2]]. * topic2 * glossary ** <> topic1 ** <> topic2 What are other ways available? Regards, BS
agenda-view: match tags: Sorting by number of tags matched?
Suppose I have this document:
* topic1 :tag1:tag2:tag3:
* topic2 :tag1:tag2:tag4:
* topic3 :tag1:tag3:tag4:
* topic4 :tag2:tag3:tag4:
* topic5 :tag1:tag2:
* topic6 :tag1:tag4:
* topic7 :tag3:tag4:
* topic8 :tag1:
And I turn on org-agenda m, then search for tag1|tag3|tag4. Emacs will then
show the results (all entries match) in the above order. Is there a way for
Emacs to show based on the number of tags matched ("sort based on
relevance"), e.g.:
* topic2 :tag1:tag2:tag4:
* topic1 :tag1:tag2:tag3:
* topic3 :tag1:tag3:tag4:
* topic4 :tag2:tag3:tag4:
* topic6 :tag1:tag4:
* topic5 :tag1:tag2:
* topic7 :tag3:tag4:
* topic8 :tag1:
Regards,
BS
