Re: Agenda preserve setting on date change
On Mon, Apr 08, 2024 at 07:31:10PM +, Ihor Radchenko wrote: > Russell Adams writes: > > > I have noticed that when I pull up an agenda view, if I enable/disable > > items (ie: enable logbook, enable inactive timestamps), that if I > > change to a new time period (ie: forward/backward day/week/month/view) > > that I lose some settings. Generally it's the inactive timestamps, > > though logbook stays. > > May you please provide more detailed instructions starting from emacs -Q? I pull up a file in 'emacs -Q'. M-x org-agenda 1 a (restricted to current file, create agenda view). Now viewing the weekly agenda in buffer *Org Agenda*. Press "L" to enable logbook. Press "[" to enable inactive timestamps. I now see the full week with log and timestamps. Press "b" to go back one week. I now see last week's agenda. Logbook mode is still enabled. Inactive timestamps are missing. Pressing "[" will enable inactive timestamps again. If I navigate again, forward or backward in time, or change between daily/weekly/monthly view, timestamps are missing. It appears that the agenda settings in the current view are not reused when refreshing for a new time. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Agenda preserve setting on date change
I have noticed that when I pull up an agenda view, if I enable/disable items (ie: enable logbook, enable inactive timestamps), that if I change to a new time period (ie: forward/backward day/week/month/view) that I lose some settings. Generally it's the inactive timestamps, though logbook stays. Can we consider making agenda keep all settings when regenerating the view when navigating by time? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) (was: Leap-year bug with todo-cycle)
On Fri, Apr 05, 2024 at 06:34:29PM +, Ihor Radchenko wrote: > > In my opinion it should become "2025-02-28 Fri" instead. > > Keeping "end of a month" being end of a month is indeed an alternative > approach in such a situation. Both are possible; we just use the one > that is easier to implement from technical perspective. So the poll is asking: If leap date doesn't exist, round date down instead of up? I think that makes sense, at least it stays the same month. +1 Thanks. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Suggestion: User-contributed use-cases on orgmode.org ?
On Tue, Nov 14, 2023 at 06:14:43PM -0800, David Masterson wrote: > Russell Adams writes: > > > On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: > >> Just a suggestion (or maybe this is already handled?). > >> > >> Was thinking I'd like to see an archive of tagged use-cases for Org that > >> could be searched via tags or regexp. The use-cases should include a > >> description of the problem, a general description of the answer, blocks > >> of elisp (general code) to setup the answer, and how to use the code to > >> do the work of the use-case. In fact, it could be recommended that the > >> use-cases be written in literate programming style (the first use-case > >> would have to provide the recommended example). As such, if written > >> properly in Org, it could (after a once over by maintainers) be exported > >> to HTML for inclusion on orgmode.org. > > > > Have you looked at Worg? > > Yes. and that's a beginning. I'm just wondering if something could be > made to encourage simple use-cases to be uploaded by anyone to provide a > deeper cookbook. Perhaps I'm thinking of a wiki where people could add > their own use cases and comment on other people's use cases, The wiki > would provide structure and search tools for new Org users. That's Worg. It's written in Org via Emacs, and publishes to the web. It does use git, but the codebase is very open. You only have to ask for an account and start writing. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Suggestion: User-contributed use-cases on orgmode.org ?
On Mon, Nov 13, 2023 at 09:09:54PM -0800, David Masterson wrote: > Just a suggestion (or maybe this is already handled?). > > Was thinking I'd like to see an archive of tagged use-cases for Org that > could be searched via tags or regexp. The use-cases should include a > description of the problem, a general description of the answer, blocks > of elisp (general code) to setup the answer, and how to use the code to > do the work of the use-case. In fact, it could be recommended that the > use-cases be written in literate programming style (the first use-case > would have to provide the recommended example). As such, if written > properly in Org, it could (after a once over by maintainers) be exported > to HTML for inclusion on orgmode.org. Have you looked at Worg? ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [FR] STARTUP: hidechecked
On Wed, Nov 08, 2023 at 03:25:33PM +0100, unham...@fsfe.org wrote: > Hi, > > It'd be nice if there was an option to automatically fold list items > that are checked on startup, e.g. The behavior you describe works with headings. Plain lists don't have as many features. Thanks. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: bash source code block: problem after ssh commands
On Wed, Oct 25, 2023 at 01:17:42PM +0200, alain.coch...@unistra.fr wrote: >#+begin_src bash :results output >ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file" >echo "bar" >#+end_src I know that Ihor has already reproduced, but are you using an SSH key to connect, or entering a password? If entering a password, I'd expect there is some mixup. That I defer to Ihor. If you use an SSH key for passwordless access, try adding -n (ie: "ssh -n derp@host mycommand"). The "-n" flag helps prevent the remote command from interfering with your local terminal by redirecting /dev/null as the remote stdin. I have to use this commonly in systems administration, scripts, and tools like Ansible. Thanks. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [BUG] Clocking with inlinetasks
On Wed, Aug 30, 2023 at 08:41:27PM +0200, Ypo wrote: > When clock-in, if there is an inline task above the point, the clock is > set below the END of the inlinetask, instead of in the main headline. Thanks for the report. I think currently that's the expected behavior, because the inline task is considered the current heading. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Wed, Aug 30, 2023 at 05:08:40PM +0200, Russell Adams wrote: > On Wed, Aug 30, 2023 at 04:39:50PM +0200, alain.coch...@unistra.fr wrote: > > Russell Adams writes on Wed 30 Aug 2023 16:31: > > > > > > What would be the equivalent of: > > > > > > > >* head :foo: > > > >*** inlt :bar: > > > >*** END > > > > > > > > where the 'bar' tag could be used in exactly the same way as the 'foo' > > > > tag. > > > > > Please give some examples of "bar used in exactly the same way as > > > foo". > > > > M-x org-agenda m bar > > Is bar used across many headings with inline tasks? Then it may not. That said, I think the question is would any code for interpreting embedded org source blocks be cleaner than the existing inline task code. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Wed, Aug 30, 2023 at 04:39:50PM +0200, alain.coch...@unistra.fr wrote: > Russell Adams writes on Wed 30 Aug 2023 16:31: > > > > What would be the equivalent of: > > > > > >* head :foo: > > >*** inlt :bar: > > >*** END > > > > > > where the 'bar' tag could be used in exactly the same way as the 'foo' > > > tag. > > > Please give some examples of "bar used in exactly the same way as > > foo". > > M-x org-agenda m bar Is bar used across many headings with inline tasks? Then it may not. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Wed, Aug 30, 2023 at 04:06:51PM +0200, alain.coch...@unistra.fr wrote: > Russell Adams writes on Wed 30 Aug 2023 14:36: > > On Wed, Aug 30, 2023 at 01:49:26PM +0200, alain.coch...@unistra.fr wrote: > > > Russell Adams writes on Tue 29 Aug 2023 15:00: > > > > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote: > > > > > Why not just put the TODO heading in a code block with type org? > > > > > > > > > > Then you get all the toys, ignored by the main file. > > > > > > > > If inline tasks are supposed to be Org enabled headings, but > > > > NOT treated like headings in the current file, why not put > > > > them in a src block? > > > > > > > > Doesn't this allow the same functionality without any new syntax > > > > elements, or silly long *'s? > > > > > > Are regular Org tags allowed in this scenario? If not, I'd be > > > miserable. > > > > It's a source block of type Org. That means *everything* that works in > > Org works inside that block. You might open it with C-c C-' to open it > > in an indirect buffer to enable everything. > > Sorry, that's not enough for me to understand. What would be the > equivalent of: > >* head :foo: >*** inlt :bar: >*** END > > where the 'bar' tag could be used in exactly the same way as the 'foo' > tag. Please give some examples of "bar used in exactly the same way as foo". Off the top of my head, I can only think that some agenda views and collapsing to sparse tree may not recognize :bar: because it's inside a source block. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Wed, Aug 30, 2023 at 01:49:26PM +0200, alain.coch...@unistra.fr wrote: > Russell Adams writes on Tue 29 Aug 2023 15:00: > > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote: > > > Why not just put the TODO heading in a code block with type org? > > > > > > Then you get all the toys, ignored by the main file. > > > > If inline tasks are supposed to be Org enabled headings, but NOT > > treated like headings in the current file, why not put them in a src block? > > > > Doesn't this allow the same functionality without any new syntax > > elements, or silly long *'s? > > Are regular Org tags allowed in this scenario? If not, I'd be > miserable. It's a source block of type Org. That means *everything* that works in Org works inside that block. You might open it with C-c C-' to open it in an indirect buffer to enable everything. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote: > Why not just put the TODO heading in a code block with type org? > > Then you get all the toys, ignored by the main file. If inline tasks are supposed to be Org enabled headings, but NOT treated like headings in the current file, why not put them in a src block? Doesn't this allow the same functionality without any new syntax elements, or silly long *'s? == * Things ** TODO stuff [2023-08-07 Mon 20:06] #+begin_src org ,*** DONE This is not a heading CLOSED: [2023-08-29 Tue 14:57] stuff things #+end_src ** DONE stuff2 CLOSED: [2023-08-07 Mon 20:06] [2023-08-07 Mon 20:07] this ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [DISCUSSION] Re-design of inlinetasks
On Sat, Aug 26, 2023 at 05:31:46PM +, Juan Manuel Macías wrote: > Ihor Radchenko writes: > > *** TODO anonsec :tag: > Content that has neither a title nor a section number. > *** END > > and a construction that for the purposes of parceling out the text > behaves like a section. The problem is the LaTeX side. Since there is no > support for anonymous sections in LaTeX (I seem to remember that some > special class like Koma had some command to introduce anonymous breaks, > but I only use the standard classes), I had to define an environment. It > is not inconvenient, since after all what appears in LaTeX is the > typographical result. For the Org side I can use TODO keywords, tags, > deadlines, etc. Why not just put the TODO heading in a code block with type org? Then you get all the toys, ignored by the main file. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Timed lists in org mode
On Fri, Aug 25, 2023 at 01:55:03PM +, Ribeiro, Glauber wrote: > All, > > I often document the running of complex processes such as software installs > by writing down a list with times like this: > > 08:00 – started > 08:05 – prompt about debug data > 08:07 – database update started > … > > and so on. I seem to remember seeing a way to do this in org, where you just > hit “enter” and the next line already gets populated with a time stamp. > However, I haven’t been able to find it. Of course the format doesn’t need to > be exactly that. Just the convenience of automatically adding the timestamp > when I start a new line. > > Does this exist in org? Or did I imagine it? > https://orgmode.org/org.html#Timers M-x org-timer-start C-x C-c - to insert the first line Creates lines like this: - 0:00:17 :: wugga - 0:00:21 :: hi - 0:00:23 :: this is a timer After the first line, you can do M-Enter to create a new list item and the timestamp automatically updates. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote: > > Regressions are not the end of the world. Org does too much and grew > > very fast, which is not sustainable. > > But they should not be taken lightly either. > https://bzg.fr/en/the-software-maintainers-pledge/ I wouldn't recommend taking them lightly, but I think "never" is too strong a word. Org's grown so much and so fast, and has limited maintainer time. If the choice is between keeping Org up to date in Emacs and working, versus a problem feature, then it's appropriate to remove problems for the health of the core. Let's not remove on a whim. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote: > Russell Adams writes: > > >> What do you mean? > > > > I think Markdown has different levels? > > Do you mean # title vs. ## title? https://www.markdownguide.org/basic-syntax look at the alternate syntax where they under line with different symbols. > > Has there ever been a reason to diversify the heading syntax to allow > > levels or changes in visibility? > > > > ** TODO > > > > === TODO Inline item under todo > > > > --- DONE something else? > > > > ### TODO invis to all except interactive editing > > That's even more features. I feel confused about what you are trying to > convey. It is, but it's just brainstorming along the lines of needing an inline task syntax. We have a solid heading syntax, with one or more asterisks followed by keywords and heading metadata. Given we're talking about adding more flags in the metadata, I'm just asking if we should consider alternatives to just asterisks to help indicate differences. An inline task exempt from folding should be eye catching to differentiate it from other headings. Perhaps something other than asterisks is appropriate? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote: > Russell Adams writes: > > >> * [#inline] Inlinetask > >> * [#inline] END > > > > I think the multiline aspect is where the concept breaks down. > > > > "I want a special invisible heading inside the content of a heading, > > that also supports optional multiline contents". Sounds horrible to code. > > It is not. The horrible part is that we rely on some things working > magically without special account for inlinetask existance. Otherwise, > it is just a matter of extra cond. So then, refinement? > > Given limited maintainer time, culling bad features is a fact of life. > > _I_ actively use inlinetasks. And it is not a bad feature by itself. The > current syntax is bad, yes. And the current state with inlinetasks being > optional feature. > > > My recommendation is cut it out, until someone with more time can make > > a rational and compelling case for a clean syntax that isn't a huge > > special case or write a separate module. > > Is there any hurry to delete things? If we still keep a new syntax open > for discussion, I see no reason to remove anything. Certainly no hurry. Just expressing my opinion. You know the code much better than I, I'm just trying to defend maintainer time from extra work. Maybe start a new email thread for a RFC regarding a potential replacement inline task syntax that would be cleaner for the code, parser, and easier to maintain? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:36:39PM +, Ihor Radchenko wrote: > > And that's part of the confusion: inline tasks _look like_ normal > > tasks while behaving differently. > > Yup. That's why I think that we need to make inlinetasks have distinct > syntax. Do we have a concrete summary of individual features that inline tasks have? I'm hearing exempt from folding, and support for drawers/heading items. What else? ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:33:01PM +, Ihor Radchenko wrote: > Russell Adams writes: > > > I hear "we have a bunch of extra complex code for an ill defined > > special case". Org's designed around headings, and this special case > > was a hack to abuse the threshold for heading detection to support a > > nonstandard heading. > > It was a hack to reduce the amount of special cases in the existing > code. > > > Sometimes there are features we just can't support. > > > > Would removing inline tasks in core clean up anything? > > It will. And it will also break some of my workflows :( I think that's unfortunate, but perhaps it would improve the health of the codebase? > > Could we normalize the code if some of the features were enabled in a > > cookie/flag on a heading? > > We would need to put more special cases. Which has pros and cons, > actually. The downside is more special cases. The upside is that most of > inlinetask bugs are originating from the same code handling both > inlinetasks and headings without accounting for their differences. It sounds like the code would be cleaner in a single place using a cookie. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote: > writes: > > >> > >><...> > > > > Ah... it would be nice if Org could "go up one level", > > wouldn't it? > > What do you mean? I think Markdown has different levels? It is interesting to think that Org has only one kind of heading: ** ... Has there ever been a reason to diversify the heading syntax to allow levels or changes in visibility? ** TODO === TODO Inline item under todo --- DONE something else? ### TODO invis to all except interactive editing ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 01:04:10PM +, Ihor Radchenko wrote: > Russell Adams writes: > We might. Adding gazillion of stars is not conceptually different from > adding a spacial cookie. True. Just cleaner. > The only extra thing required is some way to mark inlinetask ending, > because we must be able to continue the containing section below > inlinetask: > > * [#inline] Inlinetask > * [#inline] END I think the multiline aspect is where the concept breaks down. "I want a special invisible heading inside the content of a heading, that also supports optional multiline contents". Sounds horrible to code. > > Shouldn't this be excluded from core and supplied by someone's custom > > plugin if they want this ability? Org-mode should focus on the > > headings and their data, and if you need to hack in some extra syntax > > perhaps Org doesn't need to concern itself. > > Because it will be feature regression. > And it will not be possible with a custom plugin without significant > changes in how all the headline editing commands, agenda, sparse trees, > etc work - they all assume very specific heading syntax. Regressions are not the end of the world. Org does too much and grew very fast, which is not sustainable. There were other mails in this thread that agreed this might be an ill conceived feature hack. Given limited maintainer time, culling bad features is a fact of life. My recommendation is cut it out, until someone with more time can make a rational and compelling case for a clean syntax that isn't a huge special case or write a separate module. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 12:56:01PM +, Ihor Radchenko wrote: > Bastien Guerry writes: > > > Ihor Radchenko writes: > > > >> This will break export and folding. > >> Also, I often simply archive inlinetasks once they are done. The above > >> will archive too much. > > > > I see. So not only inline tasks are ugly syntactic-wise, but they > > also have a specific behavior when exporting. All this pleas for an > > external module, not for something we support in Org's core IMHO. > > I do not think that it would be possible. In order to support > inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to > modify the internals. I see no way around that. > > Too many aspects of Org are designed for one specific heading syntax. > Even modifying inlinetask *... syntax will likely require adding > more special support where things "magically" work for now because > inlinetasks often look the same as headings. I hear "we have a bunch of extra complex code for an ill defined special case". Org's designed around headings, and this special case was a hack to abuse the threshold for heading detection to support a nonstandard heading. Sometimes there are features we just can't support. Would removing inline tasks in core clean up anything? Could we normalize the code if some of the features were enabled in a cookie/flag on a heading? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 12:40:50PM +, Ihor Radchenko wrote: > Bastien Guerry writes: > This will break export and folding. > Also, I often simply archive inlinetasks once they are done. The above > will archive too much. So just to be clear, we want a method to make a heading with all the features of headings, but that isn't a heading or treated like a heading? Isn't the key feature that the inline task is a heading except it is exempt from the folding logic (ie: sparse tree)? Why can't we do this with a flag or cookie in a heading? We already have priority cookies. If the inline task also doesn't impact the tree structure of the parent heading, that's an even taller order. That's where plain lists are OK, they just lack the extra functionality of a heading (ie: drawers). I don't see any solution that isn't really hacky. Shouldn't this be excluded from core and supplied by someone's custom plugin if they want this ability? Org-mode should focus on the headings and their data, and if you need to hack in some extra syntax perhaps Org doesn't need to concern itself. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Thu, Aug 24, 2023 at 11:44:29AM +, Ihor Radchenko wrote: > Bastien Guerry writes: > > >> * TODO Consider explaining more about X > >> > >> > >> <...> > >> > >> Then, I can easily review the manuscript status using sparse tree or > >> agenda view. > > > > I see -- but what is the real benefit of inline tasks here over normal > > tasks? I understand that should not be considered as > > the details for a task, but rather its "target", but inline task does > > not seem to add much here. > > The benefit is that I do not need to search for that "paragraph N" when > I want to work on the task. I simply jump to the task location and can > immediately see the paragraph it refers to. > > Also, pdf export of such inlinetask will nicely mark the TODO item in > the manuscript draft, so that I can print things, and still see what > should be done in that particular location of the manuscript. Interesting. I often will use comments when I need to update things in a document to be exported. * Item Wubba lubba ding dong. # TODO fix this to pig latin Arff!! * Other stuff Doesn't this really come down to a use case for having headings which are excluded from operations like comments are? Could we treat #'s as inline headings? Not sure how that'd handle drawers. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Mon, Aug 14, 2023 at 01:19:07PM +, Fraga, Eric wrote: > I'll chime in regarding inlinetasks: I used to use these *a lot* but I > found that drawers do what I needed in almost all cases very > effectively (for my use cases). Can you give an example? I always hear the meeting notes with a short tasklist example. That plain list checkboxes aren't enough, the extra metadata is desired. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: High CPU with org-set-tags-command in org-capture buffer
On Wed, Aug 16, 2023 at 11:31:10AM -0600, Derek Chen-Becker wrote: > Hi, I recently upgrade to Emacs 29.1 and I also pulled the latest org > (commit cc435cba7), and I just noticed that when I'm in an org capture > buffer and try to execute org-set-tags-command, the CPU goes to 100% and > just seems to stay there (I gave up and hit ctrl-G after a couple of > minutes). The same command works fine outside of a capture buffer. It looks > like a duplicate of what was reported in > https://lists.gnu.org/archive/html/emacs-orgmode/2023-05/msg00402.html. Am > I correct that this is unresolved/unreproducible by others? If so, I'll see > if I can get a minimal repro. Are you running Helm? I think it does a full inventory of the file to find tags to present to you to pick. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
On Tue, Aug 15, 2023 at 03:10:59PM +0100, Timothy wrote: > They are a syntactic abomination. > > If there is any chance of making inlinetasks an extra that is > outside core Org/the Org spec, I think that would be for the > best. Having a 15+ level headlines sometimes transform into a > completely different syntactic element is ... really not nice. I've never used inline for exactly this reason, 15x*'s seems like trying to use an overflow to hide data. Couldn't we use something like headings using ++'s instead of **'s as folded by default? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Wed, Apr 26, 2023 at 04:13:47PM -0500, Corwin Brust wrote: > On Wed, Apr 26, 2023 at 9:31 AM Matt wrote: > > > > FSF associate members have access to a FSF hosted Jitsi instance. I'm an > > FSF associate member and could host it using that if I'm able to make the > > time. > > > > We can make EmacsConf instance of BigBlueButton (BBB) available, as > well. FWIW I had more success with BBB than Jitsi for larger > meetings. I was given an account on https://bbb.emacsverse.org/, and trying to use it today I get a certificate expired error that cannot be ignored. I was hoping to test it to setup a Saturday video session. Any ideas? ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [ANN] org-jami-bot
On Mon, Apr 17, 2023 at 09:22:48PM +0200, Hanno Perrey wrote: > > Dear fellow org-users, > > I have just released two new packages that scratch an old itch of mine: > capturing thoughts, quick notes and URLs while "on the road" with only > my mobile phone around. Messaging myself feels most natural, so that is > what I went with: triggering a capture via GNU Jami, the distributed > private messenger. > > The first package, =jami-bot= provides something of a framework to > handle incoming text and file messages. =org-jami-bot= provides hooks > and functions that extend this to Org mode captures. Any text or file is > being captured, but even simple commands (prefixed with '!') are > possible, for example: Hanno, this is brilliant. I rely heavily on using XMPP notifications with my Emacs/Org setup for appointments. I run a local program for send-xmpp to fire off messages that alert my multiple PC's and my cell phone on my XMPP account. I hadn't considered sending data BACK. That's awesome! How hard would it be to port this to a message agnostic style where other methods could be used? I've used Jami before, but I consider it VOIP software trying to become messenger, where XMPP is messenger trying to become VOIP. I've had battery problems in the past with Jami, but that was back when it was called Ring. I may have to try and adapt this to my workflow. Thanks for sharing! ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: feature request: easy embedding of images
On Sat, Feb 18, 2023 at 04:22:33PM -0800, Alexis Gallagher wrote: > Hello, my fellow org-mode lovers, > > This is a feature request — or failing that, a request for advice on > a settings configuration which could produce this functionality now. Have you looked at org-attach-screenshot? https://github.com/dfeich/org-screenshot It uses org-attach and calls out to take a screenshot. I do the same with some local function's I wrote a while ago. It works very well for me. I run M-x my/org-screenshot, and after 3 seconds it will use Imagemagick's "import" command to allow me to select a region to screenshot and saves it to a filename I prepared. I do this daily, many times each day. > I wish org-mode had the ability to attach images to notes, display > them inline, and have that work well. By “work well” I mean a few > specific things: > > • the image is automatically resized to maintain aspect ratio and > • fit horizontally with a civilized margin, so that I can resize > • my emacs window without the image disappearing or swamping the > • other content. This is Emacs, not Org. Perhaps someone knows how to adjust that. > • you can still scroll the window one line height unit at a time, > • without the entire image being scrolled as if it were one giant > • line, breaking scrolling, as seems to happen on my emacs > • (version 28.x on Linux) Mine jumps too, but again that's Emacs, not Org. > • drag and drop, so I can add the image by dragging it in, for > • instance from a screenshot tool or from an image on a web page. I can't answer that. Drag and drop functions depend on your platform. Does anything else in Emacs use drag and drop? > • sensible defaults for storing the images bundled with notes and > • keeping the two associated, so that I don't subsequently live in > • fear of ever moving my org files I do save all of mine to the same directory as my org file in .org/Filename.org.screenshotMMDDHHMMSS.png. It means I can easily know what files below to my org document. > Why is this valuable, to me at least? I use org to take notes all > day, during meetings, on reading matter, in the development of my > own thoughts. Embedding images would let me collect every kind of > resource I can't reproduce by typing or copy and pasting text — > photos of slides during presentations, photos of whiteboard, key > snippets from websites, handwritten notes and equations, etc.. Of course it's valuable, and already implemented. I think you're asking more about refining how you use it. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
On Sat, Jan 14, 2023 at 12:19:17PM +, Ihor Radchenko wrote: > Russell Adams writes: > > > Doesn't Emacs Calc have timezone conversion functions natively? > > Calc's time zone calculations are hard coded. We should rather rely on > OS library primitives. They have better chances to get updated as > politics changes in some countries. I had no idea. Wouldn't Emacs be updated eventually if timezones change? Doesn't it use the tzdb? I'd rather see Org depend on built in Emacs functions than OS. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
On Sat, Jan 14, 2023 at 11:35:00AM +, Ihor Radchenko wrote: > Russell Adams writes: > > > Can't Org also ready diary formatted timestamps? > > We support diary sexps. > > > Do those include timezones? > > No, AFAIK. sexps may (they are just Elisp functions, anyway). > > > I know they include better repeat information. Maybe we can > > build on that? > > Is it really better? Apart from sexps, diaries support cron-like > repeaters, but more limited. They have repeat with a end date or max iterations. Doesn't Emacs Calc have timezone conversion functions natively? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
On Sat, Jan 14, 2023 at 08:32:30PM +1100, Tim Cross wrote: > If org was to add TZ capabilities to timestamps, the underlying format > would have to be UTC. My previous post where I suggested there was two > 'layers', the underlying storage layer (used for calculations like > duration or comparison etc) and a presentation layer (what the human > sees, which is often in whatever their local TZ is). One of the key issues is that Org timestamps were supposed to be human writable and readable. Computer generated timestamps can easily be long and complex, and potentially hidden under a presentation layer. I have yet to see a proposal that really satisfies both use cases. Writing incomplete timestamps as a human means timestamps in $TZ. Long computer generated timestamps may prefer UTC or to include timezone information (ie: ISO 8601 or RFC 3339). Can't Org also ready diary formatted timestamps? Do those include timezones? I know they include better repeat information. Maybe we can build on that? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Document management system with Org?
On Tue, Nov 08, 2022 at 06:32:32PM +0200, Max Brieiev wrote: > Thank you. This was very useful. > > Seems like attachments will work for me. > > Also seems like I can use org capture templates to record metadata for > different types of documents. > > Now I need to dig in to the Org manual... > Don't plan on using Org to manage the files (ie: folder layout/names), but if you want to take notes on files that works. For instance, for vendor exams I will read whitepapers and course material linking my org file to the original PDF. I use org-noter to let me take notes linked to the document in question! https://github.com/weirdNox/org-noter https://www.youtube.com/watch?v=Un0ZRXTzufo It's worked great for me. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Tue, Nov 08, 2022 at 07:44:21AM +, Ihor Radchenko wrote: > Russell Adams writes: > > > One of my concerns is the format. I used to goto user groups > > frequently, and we could break up into smaller groups working on many > > things. > I am not sure if we even need to worry about multiple rooms. AFAIK, > Emacs meetups generally do not gather more than a dozen of people max. I used to attend the Houston Linux User's Group for a decade, in person. We were hosted in a computer lab, and we'd alternate between having a presentation and a workshop. My point was not everyone wants a presentation. In person user groups used to break up into small groups to solve a problem or check out a neat solution, and people would drift between them. That's making a time and place for everyone to meet, but then do as they like among each other. I'm happy to give a presentation, but would rather encourage a regular meeting which is more of a group workshop. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Mon, Nov 07, 2022 at 12:08:32PM +, Ihor Radchenko wrote: > Russell Adams writes: > > >> For the sake of the talk, it would have to be worked out a bit sooner > >> actually. > >> I’ll most likely be submitting a recording next weekend. > > > > I hadn't intended this to conflict with anything else. I was hoping to > > start a routine meeting, and like I said my time was constrained where > > I hadn't started yet. > > > > Would it be better to wait and schedule something after Emacsconf? > > Sorry, I think made a false impression in my message. > I just thought that Emacsconf could be great opportunity to invite wide > audience to these meetings. But we need to be sure that the meetings are > going to happen---there is no point announcing a meeting that will not > happen. > > There is no need to postpone anything. If you can start regular meetings > earlier, it will be great. One of my concerns is the format. I used to goto user groups frequently, and we could break up into smaller groups working on many things. On the other hand, tools like BBB or Jitsi tend to be best for a presenter and an audience. I'm ok with prepping a presentation and a sample org file or two, and answering questions in a group setting. Does anyone know an open conferencing solution that allows smaller workgroups within a larger unit? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Mon, Nov 07, 2022 at 01:28:29PM +0800, Timothy wrote: > Hi Ihor, > > > To clarify, Timothy’s presentation is going to be in December. > > It would be great if you finalize how committed you can be to this by > > then. Both from technical point of view and from your free time > > availability. > > For the sake of the talk, it would have to be worked out a bit sooner > actually. > I’ll most likely be submitting a recording next weekend. I hadn't intended this to conflict with anything else. I was hoping to start a routine meeting, and like I said my time was constrained where I hadn't started yet. Would it be better to wait and schedule something after Emacsconf? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Sun, Nov 06, 2022 at 03:55:33AM +, Ihor Radchenko wrote: > Russell Adams writes: > > > Would there be any interest in a monthly 1-2 hour long ad-hoc screen > > sharing and video discussion for Org-mode? > There seems to be general interest. > > Do you plan to start the meetups any time soon? > If you do, we may also ask Timothy to announce it during his "This year > in Org" talk at Emacsconf. I've been really busy with work. I got a new Emacs BlueButton account I need to test, and then I'll make an initial presentation on a topic. Perhaps I can schedule one later this month. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [ANN] The 2022 Emacs User Survey is now open!
Completed! On Mon, Oct 24, 2022 at 06:42:35PM +0800, Timothy wrote: > Hi All, > > I’m thrilled to announce that the Emacs User Survey 2022 is now open to > responses. It is my hope that this may help emacs-devel, Emacs package > maintainers, and the wider Emacs community develop a better understanding of > how people experience Emacs on a day-to-day basis. > > <https://emacssurvey.org/> > > The survey will be open from October 24th to November 30th. > > This time there are /no/ non-free Javascript or user-tracking caveats as this > features a bespoke survey framework written from scratch for the Emacs User > Survey to support a pure HTML-forms + CSS approach with server-side rendering > . > > See the [FAQ] for more information on the survey itself. > > It would be fantastic for this to be shared as far and wide as possible, to > get > responses from a large swathe of the community. If you can share this with > Emacs > communities you are a part of, as well as any friends or colleagues that use > Emacs, that would be much appreciated. > > We can look forward to a discussion of the (preliminary) results in EmacsConf: > <https://emacsconf.org/2022/talks/survey/>. > > All the best, > Timothy > > -- > Timothy (‘tecosaur’/‘TEC’), Org mode contributor. > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/tec>. > > > [FAQ] <https://emacssurvey.org/faq.html> -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Fri, Oct 07, 2022 at 09:43:23AM +0800, Ihor Radchenko wrote: > Juan Manuel Macías writes: > > > Great idea. I would like to participate, even if it was just to listen > > :-) But I'm afraid that these months I'm going to have horrible > > schedules. Is it planned to record these meetings? > > Even if there is a recording, where can we publish the recorded videos? Exactly. Recording brings with it extra logistics, which is why I deferred the issue. ;] ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Thu, Oct 06, 2022 at 08:09:44PM +, Juan Manuel Macías wrote: > Russell Adams writes: > > > Would there be any interest in a monthly 1-2 hour long ad-hoc screen > > sharing and video discussion for Org-mode? > > Great idea. I would like to participate, even if it was just to listen > :-) But I'm afraid that these months I'm going to have horrible > schedules. Is it planned to record these meetings? I can't commit to recording initially. I can't run them forever either, but I'm happy to start the ball rolling. Perhaps recording in the future? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Interest in an Org video meetup?
On Thu, Oct 06, 2022 at 05:28:12PM +0200, Marcin Borkowski wrote: > Me too, though it depends on the schedule. What time of day do you plan > for that? >From my original post: >> I'm offering to schedule and moderate the first few events. I'd >> propose a Saturday meeting in the afternoon European time to cover EU >> and NA. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Interest in an Org video meetup?
Would there be any interest in a monthly 1-2 hour long ad-hoc screen sharing and video discussion for Org-mode? I'm offering to schedule and moderate the first few events. I'd propose a Saturday meeting in the afternoon European time to cover EU and NA. I'm considering using Jitsi, or maybe GNU Jami. Topics could include Q, demonstrations of features, interactive troubleshooting, etc. I hadn't considered presentations, but that could be an option too. Comments? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Org and Hyperbole
On Tue, Sep 27, 2022 at 04:06:17PM +0300, Jean Louis wrote: > * Tim Cross [2022-06-21 02:43]: > > > > Russell Adams writes: > > > > > On Mon, Jun 20, 2022 at 02:03:15PM +, Juan Manuel Macías wrote: > > >> I've been intrigued with GNU Hyperbole for a while. I'm reading the > > >> documentation and trying it out a bit. It seems that its button system > > >> is very powerful. But Org links are also powerful (and exportable), and > > >> can be extended outside of Org docs. It seems that hyperbole offers some > > >> cool stuff that Org also has. And other things that are not in Org. I > > >> find some parts a bit confusing. I wonder if anyone is using hyperbole > > >> with Org and can put here some minimal workflow example where both > > >> complement each other in some way. Just in case I'm missing something > > >> useful... > > > > > > Juan, > > > > > > I've often wondered the same thing. I've looked at Hyperbole several > > > times. They have been great at advertising when a new release > > > occurs. Yet I find that I can't really find a useful feature in it > > > that I don't get from Org-mode. > > > > > > Is there some keen feature I'm missing? What's the use case for > > > Hyperbole if you're already an Org-mode user? > > > > > > https://www.adamsinfoserv.com/ > > > > My experiences with it mirror yours. It looked interesting and there > > were some ideas which sounded interesting, but when I came to use it, I > > found little, if anything, which didn't have a close equivalence in org > > mode and many things in org mode which it did not have. > > > > In the end, it came down to asking myself do I really want yet another > > information management framework in my life and the answer was no. I do > > vaguely recall (it was a while ago) there were some ideas I thought > > would be good to add to org mode though. Unfortunately, I cannot recall > > the details now. > > I somehow cannot relate to it, Hyperbole and Org mode are quite > different things. I have Hyperbole all the time here running, no > matter if I use Org mode or what other lightweight markup language. Could you point to some usage of Hyperbole that could help address it's use case? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Sun, Sep 25, 2022 at 11:36:46AM +0800, Ihor Radchenko wrote: > Jean Louis writes: > > > For IRC, there are ways to record history, and I am sure that > > such history may be recorded with referencable hyperlinks. > > > > Look at this example from Guix IRC channel: > > https://logs.guix.gnu.org/ > > AFAIU, this should be supported by the IRC server. Does irc.libera.chat > (where #org-mode channel is hosted) support logging? There is no log today. Also our parent channel #emacs prohibits logging. https://www.emacswiki.org/emacs/EmacsChannelLogging Logging sounds nice until anyone can datamine it. You're welcome to log locally on your client for private use. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Wed, Sep 21, 2022 at 10:59:14AM +0200, Russell Adams wrote: > On Wed, Sep 21, 2022 at 04:05:56PM +0800, Ihor Radchenko wrote: > > Russell Adams writes: > > > > >> I am wondering if we could create a common Org dev matrix room for quick > > >> discussions and then copy the transcript to the relevant ML thread, when > > >> necessary. > > > > > > We have an IRC channel for real time chat. Join in anytime. > > > > The disadvantage of IRC is absence of message history. > > Without history, small-sized channels like I am proposing (dedicated to > > Org mode devs) are not very useful. We live in different time zones and > > countries. > > I disagree. That's why most IRC users stay logged in. > > IRC is most accessible, and if you insist there is a Matrix bridge to > Libera. Let me pose this differently. The #org-mode channel has a large footprint already, though lower utilization than #emacs. There are 230 org users online right now. It would be great to see some dev discussions on IRC, and if we ever get too much traffic, maybe make a #org-mode-dev channel. I'd encourage you to try to use the existing resources first, especially where the user base is. Then split things up later. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Wed, Sep 21, 2022 at 04:05:56PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > >> I am wondering if we could create a common Org dev matrix room for quick > >> discussions and then copy the transcript to the relevant ML thread, when > >> necessary. > > > > We have an IRC channel for real time chat. Join in anytime. > > The disadvantage of IRC is absence of message history. > Without history, small-sized channels like I am proposing (dedicated to > Org mode devs) are not very useful. We live in different time zones and > countries. I disagree. That's why most IRC users stay logged in. IRC is most accessible, and if you insist there is a Matrix bridge to Libera. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Tue, Sep 20, 2022 at 05:22:50PM +0800, Ihor Radchenko wrote: > The problem with the list is that emails often have ~minutes overheads. > It sometimes takes unnecessary extra time to discuss small > clarifications on list. > > I am wondering if we could create a common Org dev matrix room for quick > discussions and then copy the transcript to the relevant ML thread, when > necessary. We have an IRC channel for real time chat. Join in anytime. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
SSL cert expired on orgmode.org
Not sure who is in charge of these, but the orgmode.org SSL cert expired today. Someone brought it up on IRC. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Alternatives to clocking in/out for reporting time
On Sat, Jul 09, 2022 at 12:00:53PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > > I just want to get the agenda items in a programmatic way so I can > > report on them. > > Can you then formulate what exactly you want to achieve? > Do you want to consider only agenda items? All the timestamps in the > matching items or maybe just some? I typically use agenda for the month with logbook view and inactive timestamps enabled. I'd love to iterate over the list of all timestamps from that view. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Alternatives to clocking in/out for reporting time
On Fri, Jul 08, 2022 at 03:02:00PM +0800, Ihor Radchenko wrote: > You may hook into timestamp insertion/todo-state change functions and > accumulate the "time" into headline properties. Hooking on insertion is a bit low level, and sounds like it's only about maintaining state in the currently running Emacs. I just want to get the agenda items in a programmatic way so I can report on them. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Alternatives to clocking in/out for reporting time
On Wed, Jun 29, 2022 at 07:11:10PM -0700, Samuel Wales wrote: > a few things taht are probably all completely obvious or investigated > or irrelevant just in case. just brainstorm. I appreciate that! That's really what I'm asking for is ideas. I don't mind writing a bit of code, but I'm not sure where to start. > do you have everything relevant in the same subtrees? i.e. not > wanting granular, can you search upward for a dominating entry kind of > like git searching upward for the .git dir or so? property drawer > could control what's a dominating entry. you probably thoguht of this > or of having whatever categories as tags or categories in entries > though. in any case that would clock. you could even have clocking > clock into that no matter wher eyou are via some timer in principle. > just a brainstorm. you said dynamic som perhaps there is no > dominating entry for each category though. The core issue is I want to report on total time as an aggregate, not on time per task. Clock reporting gives me precise time accounting for a specific task. I want to fill whole hours with whatever tasks happened at those times chronologically. > org-time-stamp-rounding-minutes and org-clock-rounding-minutes . i > presume you don't find them relevant. I saw that. Interesting they don't appear to change the result, they modify the input when you record the time by rounding. > reminder: inactive ts in the clocked notation is usualy treated > separately by org [i.e. not hte same type of ts] from bare ia. I had considered perhaps converting inactive timestamps into clocking records. Unfortunately I think the core issue remains in aggregating by task, not by time. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Alternatives to clocking in/out for reporting time
On Thu, Jun 30, 2022 at 07:26:20AM +1000, Tim Cross wrote: > > The point is that I'm not worried about accounting time by task, > > instead I'm aggregating tasks into accounting by whole hours. > > > > I'm looking at org-element, and it appears I'd have to do my own > > agenda style scan of the whole tree to find items to classify by > > hour. While I'm somewhat proficient at elisp, that sounds like a steep > > wall to climb. > > > > Is there an iterative way to review items in an agenda view so I can > > do the math to produce a report? > > > > Russell, > > I don't have an answer for your specific problem. However, I was > wondering if you looked at the options to configure the built-in time > clocking and report table? I've looked at it several times, and it just doesn't fit the bill. Sorry. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Alternatives to clocking in/out for reporting time
I make extensive use of timestamps for billing (timesheet) purposes. I'm looking to automate this more, and I find the existing clocking system inadequate. I'm hoping someone can point me in the right direction. Today I have log mode enabled so that each time I close a TODO item, it records the date and time it was closed. At regular intervals while working I add inactive timestamps to my notes. I've mapped that to a single key, so it's quite fast. If I switch tasks, have an update, made progress I want to note to myself, or leave and return I add an inactive timestamp. I have well over 1000 inactive timestamps in my current file. Later I can open my agenda view on the working file, choose my timespan (week or month), enable log mode to show when items were closed, and then enable inactive timestamps to view all of the timestamps. This itemizes all the events organized by time into a timeline. It's fairly straightforward from that timeline to count my hours based on the record of where I spent my time. It is unfortunately a very manual process. I find Org's clocking to be too detailed, and that it doesn't play well with dynamically organized hierarchies of notes. I frequently create and close subtasks, or switch parts of the tree. Clocking each one is too much overhead, and too granular. I don't need to provide down to the minute reports of each item. It also doesn't appear to allow rounding of values, so I still have to adjust the results. What I envision is a way to count items in the agenda view to produce a time report. Counting any inactive timestamp as 15 minutes, where if a half hour or more is logged I round up to bill the hour. Closed TODO items should count toward billing that whole hour. Clearly this should be customized. The point is that I'm not worried about accounting time by task, instead I'm aggregating tasks into accounting by whole hours. I'm looking at org-element, and it appears I'd have to do my own agenda style scan of the whole tree to find items to classify by hour. While I'm somewhat proficient at elisp, that sounds like a steep wall to climb. Is there an iterative way to review items in an agenda view so I can do the math to produce a report? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Org and Hyperbole
On Mon, Jun 20, 2022 at 05:26:30PM +0200, Russell Adams wrote: > Is there some keen feature I'm missing? What's the use case for > Hyperbole if you're already an Org-mode user? Watching the replies, I've noticed it all seems to come back to hyperlinking / hot button support across Emacs modes. Almost sounds like Apple's Hypercard is evoked in the responses. I rarely use Org's own links, much less links between documents so maybe I'm not the target audience. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Org and Hyperbole
On Mon, Jun 20, 2022 at 02:03:15PM +, Juan Manuel Macías wrote: > I've been intrigued with GNU Hyperbole for a while. I'm reading the > documentation and trying it out a bit. It seems that its button system > is very powerful. But Org links are also powerful (and exportable), and > can be extended outside of Org docs. It seems that hyperbole offers some > cool stuff that Org also has. And other things that are not in Org. I > find some parts a bit confusing. I wonder if anyone is using hyperbole > with Org and can put here some minimal workflow example where both > complement each other in some way. Just in case I'm missing something > useful... Juan, I've often wondered the same thing. I've looked at Hyperbole several times. They have been great at advertising when a new release occurs. Yet I find that I can't really find a useful feature in it that I don't get from Org-mode. Is there some keen feature I'm missing? What's the use case for Hyperbole if you're already an Org-mode user? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Regarding arbitrary Org blocks
On Thu, May 12, 2022 at 06:19:35PM +0800, Ihor Radchenko wrote: > > Some recent change instead now says "No special environment to edit > > here". How can I get back that behavior? > > I am unable to get the described behaviour even using Org 8.2.10. Could > you elaborate what you mean by "used to"? Which Org version? It's been quite some time. I've been using Org for years and I don't keep it up to date. I can't identify when it changed, only that my muscle memory started throwing errors. ;] To be fair, I think I only moved to v9 this year. So I may have learned this in versions before v8. > > Could I add some minor mode to say text-mode with auto-fill-mode and > > aspell somewhere when opening those blocks? > > Not currently, unless you advice org-edit-special. Though we might add > something like org-edit-special-hook (similar to org-ctrl-c-ctrl-c-hook) > if others are also interested in this functionality. That's the kind of configuration I was referring to. It'd be fine to me to add items to match the tags I use. On the other hand, perhaps it would be useful to have a fallback behavior to use the current org-mode settings in a popup buffer for a block that has no mode associated with it? ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Regarding arbitrary Org blocks
On Wed, May 11, 2022 at 02:39:28PM -0700, Greg Minshall wrote: > Russell, the behavior you describe, that used to work, sounds reasonable > to me. otoh, in case you haven't discovered =narrow-to-region= and > friends, (which i only recently did), that might also give you some of > what you want. cheers, Greg Check out org-tree-to-indirect-buffer ;] ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Regarding arbitrary Org blocks
On Wed, May 11, 2022 at 09:23:27PM +0300, Daniel Fleischer wrote: > Russell Adams [2022-05-11 Wed 18:14] wrote: > > > Could I add some minor mode to say text-mode with auto-fill-mode and > > aspell somewhere when opening those blocks? > > Hi! If you're editing text why do you need a special buffer? You can > edit them in the orgmode buffer and enjoy all its textual features. First up, it's because it used to work and now it doesn't. ;] Second it can be very useful to work on a sub-buffer, or indirect buffer for some content. Why shouldn't I be able to edit the contents of that block inside an indirect buffer where my beginning-of-buffer, end-of-buffer, word wrap, or global find and replace are constrained to that block of text? This works for example blocks, but no longer for verse and quote blocks. These are native Org block types and not my fanciful made up ones. Why should the popup work for example blocks, but not the others? That borders on a bug, where my question was considered as a configuration question. Finally when you edit in the popup buffer, the results are indented which makes the document more legible. Regular text tools do that inconsistently. > The special buffer is for major modes which are not orgmode such as > programming languages or latex which use different > completions/highlighting/minor-modes and editing them in orgmode is > a hassle. I think what I am using were once called "special blocks". You're referring to source blocks. They have many more features but are outside the question. https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html Thanks. ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Regarding arbitrary Org blocks
I used to insert arbitrary blocks like: #+BEGIN_IMPORTANT yadda yadda #+END_IMPORTANT in my documents, and when I hit C-c ' to edit them it would give me a basic buffer and I could edit the plain text within. Some recent change instead now says "No special environment to edit here". How can I get back that behavior? I'm really just editing text blocks for Latex export, and the source block type triggers some latex formatting. It's not source code language, just plain text. Could I add some minor mode to say text-mode with auto-fill-mode and aspell somewhere when opening those blocks? Thanks. ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [Bug] Date span failure in agenda w/o day of week in timestamp?
On Tue, Apr 26, 2022 at 08:17:23PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > >> > <2022-04-28 21:00>--<2022-04-29 02:00> > >> > > > > Is that technically a valid timestamp, meaning that it should be > > recognized? Or is it just Gnus outputting a bad timestamp and I should > > go try to adjust it? > > It is valid. You can check it by calling M-: (org-element-context) at > timestamp. Our parser does recognise your example as: > > (timestamp > (:type active-range :raw-value "<2022-04-28 21:00>--<2022-04-29 02:00>" > :year-start 2022 :month-start 4 :day-start 28 :hour-start 21 :minute-start 0 > :year-end 2022 :month-end 4 :day-end 29 :hour-end 2 :minute-end 0 :begin 293 > :end 331 :post-blank 0)) > > You can see that the end date is recognised correctly. What do you recommend as the next step? -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [Bug] Date span failure in agenda w/o day of week in timestamp?
On Tue, Apr 26, 2022 at 05:43:48PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > > -- > > * Fails w/o DOW, end time at 2100 not 0200 > > > > <2022-04-28 21:00>--<2022-04-29 02:00> > > Confirmed. > > The problem is that org-ts-regexp1 does not match "2022-04-29 02:00". I > am not sure why. org-ts-regexp1 looks like it should match the above > case. Maybe something to do with greedy/non-greedy regexp matching, but > its just a guess. Is that technically a valid timestamp, meaning that it should be recognized? Or is it just Gnus outputting a bad timestamp and I should go try to adjust it? ------ Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
[Bug] Date span failure in agenda w/o day of week in timestamp?
Consider this sample file: -- * Test with day of week <2022-04-25 Mon 15:00>--<2022-04-26 Tue 02:00> * Fails w/o DOW, end time at 2100 not 0200 <2022-04-28 21:00>--<2022-04-29 02:00> -- Results in this agenda: -- Week-agenda (W17): Monday 25 April 2022 W17 8:00.. 10:00.. 12:00.. 14:00.. 14:31.. now - - - - - - - - - - - - - - - - - - - - - - - - - testdate: 15:00.. (1/2): Test with day of week 16:00.. 18:00.. 20:00.. Tuesday26 April 2022 testdate:2:00.. (2/2): Test with day of week Wednesday 27 April 2022 Thursday 28 April 2022 testdate: 21:00.. (1/2): Fails w/o DOW, end time at 2100 not 0200 Friday 29 April 2022 testdate: 21:00.. (2/2): Fails w/o DOW, end time at 2100 not 0200 Saturday 30 April 2022 Sunday 1 May 2022 -- So if the DOW is omitted from the end date, then it defaults to 24 hours? I discovered this using gnus-icalendar to import ical invites. Gnus appears to omit the DOW when creating the timestamp. I thought DOW was optional in timestamps? Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/) GNU Emacs 28.1 (build 2, amd64-portbld-freebsd13.0, X toolkit, cairo version 1.17.4, Xaw3d scroll bars) ---------- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: Question About Low Level Issues To Fix
Samuel, On Wed, Mar 16, 2022 at 01:07:48PM -0400, Samuel Banya wrote: > On a related note, I took a look at what's present, but was kind of > lost in terms of what to necessarily fix. > > I saw the general TODO list present, but wasn't sure if there are > any low level issues that should be looked at. > > Or should I primarily focus on what's been reported directly on the > Source Hut repo itself? Have you tried starting at https://updates.orgmode.org/#bugs Also: https://orgmode.org/worg/org-contribute.html I believe the main git is on GNU Savannah, however many of the devs use Sourcehut. ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: bug-tracker: How to response/subscribe to a bug-thread
On Wed, Mar 09, 2022 at 04:46:25PM +, c.bu...@posteo.jp wrote: > Hello, > I still try to become warm with the bug-tracking-system you are using. > > There is a known bug that is also tracked on the "dashboard" > (https://updates.orgmode.org/) as "Inconsistent handling of id: links to > other file during publish". > https://list.orgmode.org/12368452.sVpYeFqCzH@pluto/ > > I was not subscribed to the list when this thread comes up. So I have no > mail here I can reply-to. I can I answer to that thread? On that list page, the footer says you can either download an mbox archive of the messages and reply inside your mail client, and it provides a link where you can use a in-reply-to and subject header which CC's the list. * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link mailto:inkbottle007%40gmail.com?In-Reply-To=%3C12368452.sVpYeFqCzH@pluto%3ECc=emacs-orgmode%40gnu.orgSubject=Re%3A%20Internal%20link%20broken%20when%20publishing%20%28was%20org-id%20with%20ox-html%29 > Side question: I can I monitor that thread/bug without being subscribed > to the list? The "dashboard" seems not to have any subscribe, monitor or > feed mechanism. The "Atom" feed (https://list.orgmode.org/new.atom) is > only for complete list not for one thread. The best way is to subscribe to the list. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Communication problems and possible problems with the website
On Fri, Feb 25, 2022 at 02:24:53PM +, c.bu...@posteo.jp wrote: > Dear Ihor > > Am 25.02.2022 15:18 schrieb Ihor Radchenko: > > Org has no official GitHub page. This is partially a requirement from > > Free Software Foundation: > > https://www.gnu.org/prep/standards/standards.html#References > > I totally and absolute support that FSF requirement. > > In that case I would say org-mode does violate that requirement because > there is a GitHub and a PayPal link on the landing page. Those are links to supporting our maintainers. Not a project repo. > And on the Worg page (which is "official" from the new users point > of view) there is also a GitHub link. It does not matter that there > is not code on GitHub and that this is only for > sponsoring/donations. You have the link and the logo so you > "promote" that stuff that the FSF do not want you to promote. I think that's a bit hazy, as they are services and not software. The standards specify not to promote non-free software. While I don't like Github at all, in this context it's only for the sponsorship solution. That's a service like Paypal. I'm not sure what a clear answer is here. I don't like having any mention of Github and non-free services myself, but I respect that we need to support the maintainers and that may require using common services. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Communication problems and possible problems with the website
On Fri, Feb 25, 2022 at 12:48:17PM +, c.bu...@posteo.jp wrote: > Am 25.02.2022 13:30 schrieb Ihor Radchenko: > > If you think that the current wording is confusing, please point out > > which parts. We are pretty much blind here on the potential issues for > > the newcomers (for obvious reason - we are too familiar with Org). > > Pointing to the confusing parts would help a lot. > > The text in the buffer after M-x org-submit-bugreport says in the first > line "You are about to submit a bug report to the Org mailing list". > This does not explain how this is done. As a (very fresh not Emacs > familiar) user I wouldn't assume that I have to setup my Emacs as a mail > client in that case. I would assume that there is some magic in behind. > ;) > > Just write something like "Make sure your Emacs is setup to send emails > or copy and paste the resulting buffer into an Email client of your > choice." Pardon. M-x report-emacs-bug opens a side panel which clearly states you can copy the message content out for another email program. Perhaps we should update the information popup in org-submit-bugreport. Can you recommend some additional explaination? > >> It is unclear where the repositories for the source code and the code > > But the front-page and the Install are not the place where I would > expect infos like that. Repos are for contributers not for users. Are they? Many Emacs users pull direct from repos, which is why it's front and center on the main orgmode site. I think the difference here is between users and developers, where in Emacs many users are developers and use tools like Git daily. > In contribute the git thing is explained in "Details on how to submit > patches" but there is a repo url missing. I think we should consider adding the repo to the top of contribute as well. Good idea. > btw: I would suggest to create links or mirror repos on your GitHub > page. This could be done in Worg. > > Do you recall the urls where you tried to search for the source code? > > I searched behind the GitHub link (right top corner of the website) > first. > I searched around on savannah but still have problems with the > interface; which is another topic. > > The point is that the users have to search (e.g. DuckDuckGo) because the > links to the repo or to description that there is no public repo are not > at the usual (compared to most of the other FOSS projects) places. I agree this is rather confusing. I think maybe we should consider creating a comprehensive list of repos on Worg. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Communication problems and possible problems with the website
On Fri, Feb 25, 2022 at 12:38:24PM +, c.bu...@posteo.jp wrote: > Am 25.02.2022 13:25 schrieb Russell Adams: > > On Fri, Feb 25, 2022 at 11:29:38AM +, c.bu...@posteo.jp wrote: > >> This site does not make clear how to submit bug reports. It even does > > I was looking here: https://orgmode.org/worg/org-contribute.html > Especially the section "Ways to contribute" -> "Ways that do not involve > programming" -> "Send bug reports" > There is not described _how_ to do this. That is the point. This may just be an unfortunate lack of alignment between the community Worg and the main site. Again, on the main site there is a prominent Contribute button and it shows how to send a report. We're open to suggestions how to make them integrate better. > From my point of view this is unusual to. But this just should made > clear to the users. I wasted time searching the repo. Just write > "The repo is not publicly available". ;) Because orgmode is FOSS > everyone (new to it) would expect a source repo. I expect the software product to have a repo. I don't always expect a repo for their public facing site. Some sites don't use source tools to publish, and their public facing site will be access controlled to prevent defacement. On the other hand, Org does have a repo and Ihor appears to be requesting TEC to add a link to the page. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Communication problems and possible problems with the website
Just to start, honest critical feedback is just fine. Thank you for not being negative. ;] On Fri, Feb 25, 2022 at 11:29:38AM +, c.bu...@posteo.jp wrote: > This website has a lot of deadlinks. > https://orgmode.org/worg/exporters/ox-overview.html Worg is community written and maintained. I've personally done deadlock scans before, but I'm sure it needs to be done again. Care to volunteer? > This website > https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html > at the end in sub-section "Further reading" points to the mailinglist > but only to the archive > (http://lists.gnu.org/archive/html/emacs-orgmode/) not to the > list-subscription site > (https://lists.gnu.org/mailman/listinfo/emacs-orgmode). > And on the archive site there is no link to the subscription site. Reading implies reading the list archive, not posting. It's unfortunate that the archive doesn't link back to the main list. I'm not sure that's configurable. I've fixed it so that it links to the Worg page about the mailing list. I hope that increases the clarity. > This site does not make clear how to submit bug reports. It even does > not make clear that the "way" is unusual (not web-based bug-trackers > like bugreport or github). It simply says "Submit a bug report" but does > not how. I think the important point and information for the users is > that "Bug reports are done via E-Mail" to the mailinglist with > manipulating the headers or using Emacs itself. Where would this belong? On the main Org page? On Worg? It's documented under "feedback" in the manual. All Emacs bug reports are to mailing lists. That is the usual. On the main org-mode site the first major point under "Contribute" is how to submit a bug report. > Search more around I found out that I have to submit bugreports from > inside Emacs via M-x org-something > Make clear that I have to setup Emacs for sending emails in that case. > In my case I am not able to submit regular bug-reports because I do not > manipulate my headers and my Emacs is not setup for emails. M-x org-submit-bug-report Emacs doesn't have to be setup for email, you can simply copy the message into your mail client to send. It tells you that inside Emacs when you create the report. This is the same as M-x submit-emacs-bug. Again the first point under Orgmode.org's Contribute button is bug reporting. > It is unclear where the repositories for the source code and the code of > the website are. If I had found them I would have created a PR/patch for > 2. Which site? https://orgmode.org/ is administered by Org maintainers. I'm not sure where that repo is, and it's not publicly writable. Suggesting edits for that site is certainly appropriate on this mailing list. https://orgmode.org/worg/ is community written, and the git repository is on the main page of both orgmode.org and Worg: https://git.sr.ht/~bzg/worg You can follow the directions below to request access to contribute to Worg: https://orgmode.org/worg/worg-about.html -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Read only org view mode
On Mon, Jan 24, 2022 at 11:40:05AM +, Neil Jerram wrote: > On Mon, 24 Jan 2022, 11:14 Russell Adams, wrote: > > > Why not just do an ASCII export to a temporary read only buffer for > > viewing? > > Do you mean that you're agreeing with the concept, but finding the > implementation unnecessarily complicated? I'm not being negative about the concept. I'm asking if the poster had considered using the built-in tools before creating another new library. I did a short look at the site and the assertion "view org with less markup", and that was my first impression. I had two thoughts. The first was if the markup is a problem and you want a read only view, why not use the built in ascii export to a buffer and view that buffer? I just hit C-c C-e t A and M-x read-only-mode and was able to navigate my ascii org file as a read only buffer. Second thought was that Org's syntax was supposed to minimize the markup so it didn't negatively impact reading. Maybe the poster is identifying a pain point we should be aware of as a community, ie: that too much markup makes it hard to read. My impression is only property drawers and source blocks are potentially visually loud compared to the other markup. Timestamps are pretty minimal and links already only show a descriptive text instead of the full [[]] syntax. ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Read only org view mode
ty)) >(goto-char (point-min)) >(while (re-search-forward "^[ \t]*#\\+PROPERTY:.*$" nil t) > (put-text-property > (1- (match-beginning 0)) (1+ (match-end 0)) 'invisible > visibility)) > > (defun org-view--update-stars (visibility) > "Update invisible property to VISIBILITY for markers in the current buffer." > (org-with-wide-buffer >(save-excursion > (goto-char (point-min)) > (with-silent-modifications >(while (re-search-forward org-view-stars-re nil t) > (put-text-property > (match-beginning 0) (match-end 0) 'invisible visibility)) > > (defun org-view--update-credentials (visibility) > "Set invisible property to VISIBILITY for export settings." > (org-with-wide-buffer >(save-excursion > (with-silent-modifications >(goto-char (point-min)) >(while (re-search-forward org-view-credentials-re nil t) > (put-text-property > (match-beginning 0) (match-end 0) 'invisible visibility) > (when org-view-center-credentials >(org-view--center-in-window visibility))) >(goto-char (point-min)) > > (defun org-view--center-in-window (center) > "Center a line in a window pixel wise." > (save-excursion > (goto-char (line-beginning-position)) > (let ((end (line-end-position)) > (beg (line-beginning-position))) > (if center > (let* ((line (buffer-substring beg end)) > (length (/ (string-pixel-width line) 2))) > (put-text-property > beg (1+ beg) 'display `(space :align-to (- center (,length) > (remove-text-properties beg (1+ beg) '(display nil)) > > ;;;###autoload > (define-minor-mode org-view-hide-tags-mode > "Hide/show tags in org-headings." > :global nil :lighter " org-htm" > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (org-view--update-tags org-view-hide-tags-mode)) > > ;;;###autoload > (define-minor-mode org-view-hide-stars-mode > "Hide/show leading stars in org-headings." > :global nil :lighter " org-hsm" > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (org-view--update-stars org-view-hide-stars-mode)) > > ;;;###autoload > (define-minor-mode org-view-hide-keywords-mode > "Hide/show leading stars in org-headings." > :global nil :lighter " org-hkm" > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (org-view--update-keywords org-view-hide-stars-mode)) > > ;;;###autoload > (define-minor-mode org-view-hide-properties-mode > "Hide/show properties and property drawers." > :global nil :lighter " org-hpm" > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (org-view--update-properties org-view-hide-properties-mode)) > > ;;;###autoload > (define-minor-mode org-view-pretty-credentials-mode > "Prettify credentials in org-buffers." > :global nil :lighter " org-pcm" > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (org-view--update-credentials org-view-pretty-credentials-mode)) > > (defun org-view-quit () > (interactive) > (org-view-mode -1) > (message "org-view mode disabled in current buffer")) > > (defvar-keymap org-view-mode-map > :doc "Keymap for ‘ORG-view-mode’" > "c" #'org-view-quit > "C" #'org-view-quit > "e" #'org-view-quit > "E" #'org-view-quit > "q" #'org-view-quit > "Q" #'org-view-quit) > > ;;;###autoload > (define-minor-mode org-view-mode > "Hide/show babel source code blocks on demand." > :global nil :lighter " org-view" :keymap org-view-mode-map > (unless (derived-mode-p 'org-mode) > (error "Not in org-mode")) > (cond (org-view-mode > (org-view-hide-tags-mode org-view-mode) > (org-view-hide-stars-mode org-view-mode) > (org-view-hide-keywords-mode org-view-mode) > (org-view-hide-properties-mode org-view-mode) > (org-view-pretty-credentials-mode org-view-mode) > (when org-view-diminish-mode >(dolist (mode '(org-view-hide-tags-mode >org-view-hide-stars-mode >org-view-hide-keywords-mode >org-view-hide-properties-mode >org-view-pretty-credentials-mode)) > (let ((mode-str (cdr (assq mode minor-mode-alist >(setcar mode-str "" > (view-mode +1)) > (t (view-mode -1) >(org-view-hide-tags-mode -1) >(org-view-hide-stars-mode -1) >(org-view-hide-keywords-mode -1) >(org-view-hide-properties-mode -1) >(org-view-pretty-credentials-mode -1 > > (provide 'org-view-mode) > > ;;; org-view-mode.el ends here -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Thu, Dec 09, 2021 at 10:46:34AM +, Eric S Fraga wrote: > Org v8 in particular was a major step forward but broke many of my > org files. I know we're beating a dead horse, but can you clarify. Did Org break your Org editing experience in Emacs for your Org files, or did this change just break some of the finer formatting details of your exported Org file? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Wed, Dec 08, 2021 at 08:22:31PM +0100, Dr. Arne Babenhauserheide wrote: > > - Anything outside of basic Org syntax, tables and source blocks I do > >directly in latex. Images are a good example. I will use latex code > >for the image, sizing, orientation, etc instead of relying on Org's > >extended syntax for image links, caption, and attributes. > > > As a result my publishing has been pretty consistent for customer > > documents. I also only update my Org between projects. ;] > > If I had needed a stronger argument for more backwards compatibility, > this list of habits is it. That should not be required to keep your > org-mode documents working. I think this may be a problem regarding expectations. I expect Org to be great at handling it's own format, and to give me the editing experience within Emacs that I have come to expect. That Org can also be used to export to other formats is both a blessing and a curse. Org can only do high level constructs in the languages it exports to, and really should only be expected to do just that. It's a paper thin macro or template over a much more complicated document language. Org's lightweight markup has had things bolted onto it repeatedly for years. Typically issues have resulted in changes in the export engine defaults (ie: html moving to using css), and not Org itself changing the editing experience in Emacs. > Org-mode is not just a library, it keeps user-data. It should really not > be volatile¹. Org's format isn't volatile. You could view those anytime in Org and see what you expect to see. The issue you are having is that an old document may not export perfectly over time. What if Org didn't diverge, the underlying format did? > If I can’t trust org-mode to keep working but have to check the > documents every time I come back to them — and might have to spend hours > fixing them — then it not suitable for writing, as much as that would > pain me (because it would cast into doubt most of my decisions around > writing of the past decade). You can absolutely trust Org to open, view, and edit it's own files even decades old. It's plain text, so there's no risk in experiencing a permanent loss of data. The exporting is the difference in expectations. Org's lightweight markup is quite simple, and the documents it produces should be as well. This is much like the original HTML specification. Look how complicated it is to write HTML now with CSS and Javascript emulating mundane functions after decades of bolt on "standards". If I had a document which had a highly sensitive output format which had to remain perfect over decades, I would argue that perhaps Org wasn't the correct markup to write it in. Much like plain text vs original simple HTML, vs Latex. Text was plain and simple, with little formatting. Durable and ugly at times, but always legible. The original HTML had more markup required, but it was hyperlinks and some simple fonts and formats. Prettier, variable fonts, colors, pictures. Latex can make pixel perfect PDFs with multiple medias and professional results, however it has a very specific format and this may be poor for writing in dynamically. HTML required decades of tweaks to become "pixel perfect", and HTML a decade old rarely renders properly in a "modern" browser. At some point with each of these languages, the formatting became more important than the content. I write all my customer documentation in Org, with custom Latex templates. I've only had to make major changes once, I think between v8 and v9. Yes, my old documents won't export identically without the changes. The likelihood they still export is high, and 100% that I can view and edit them correctly in Org. It's only the polished result which could degrade. I may have to tweak them to make them export the same way again, but I expect they can without too much effort. I'm OK with that. > Please do not make org-mode volatile.¹ I think our maintainers have done an excellent job of minimizing the impact of any changes. However when changes are needed, I trust their judgement to have good reason to make a change and document it thoroughly. However I only export Org to be backwardly compatible with itself, not the languages it makes exports to. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Wed, Dec 08, 2021 at 05:16:20PM +0100, Dr. Arne Babenhauserheide wrote: > > Tim Cross writes: > > > Backwards compatibility is important and changes should never be done > > lightly. However, that doesn't mean they don't occur (we have already > > had breaking changes, so old org files are likely to have issues > > already). Backwards compatibility can also become a burden and > > I already spent several hours fixing old presentations, because of org > format changes, so I want to put in a strong vote for backwards > compatibility. I agree completely. Luckily org-lint provides great insights into changes. Reading the release notes between major versions is a good idea. I have found that anytime I've had a problem it was well documented in the release notes, and that I simply neglected to read them. > If you have 1400 slides of lectures, all carefully laid out to convey > information as best as possible, and you realize a few days before the > lecture when you want to update them that the layout is broken, because > of some minor change in interpretation of empty headlines in org-beamer > export so you have to go over each slide individually to make sure that > nothing is cut off and no layout is broken — and check the compile to > latex many times until the layout is working again — that is a huge > cost. I don't see this as much different from the issues encountered with compiling code with libraries. During development you have to freeze libraries you're working against. After an update, you'll have to check again. I've had this come up in my professional documents on occasion, and I've developed habits to help. For instance: - Every file gets an export header template and all settings are done there. - Exported documents must never depend on variables in my init.el. All variables must be stored as file local variables if they required customization against Org defaults. - I run org-lint first if I suspect a problem. - I pay latex experts to make my templates so I don't have to. - Anything outside of basic Org syntax, tables and source blocks I do directly in latex. Images are a good example. I will use latex code for the image, sizing, orientation, etc instead of relying on Org's extended syntax for image links, caption, and attributes. As a result my publishing has been pretty consistent for customer documents. I also only update my Org between projects. ;] ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Tue, Dec 07, 2021 at 02:47:28AM +0800, Timothy wrote: > I have a few comments on your comments :) To my esteemed colleague, I have a few comments for your comments on my comments. ;] > > How many syntax documents are we supposed to maintain outside of the working > > implementation in Emacs and the manual? > > Just the one. I have some ideas on this that need to be written up, but I see > this more as polishing our syntax specification such that it’s is more > approachable for someone interested in supporting Org. IMO this leads to a > syntax document which is just better, period. I'm all for the idea of tightening up documentation to make Org a more polished product. The issue is when the justification for that effort is interoperability with tools outside Emacs. > > Discussions are often fruitful for all involved and shouldn’t be a > > problem when conducted in a respectful manner. Expect critical > > opinions at times, but we should keep it civil. > > Indeed. I do find myself wishing that some discussions stayed more on-topic > though… My goal is to remind everyone that maintainer and coder time is a scarce resource, and I'm very protective of asking them to commit to anything. An indirect commitment can still feel like a commitment, even if it's only implied by popular opinion and not agreed to. As a free program with free and plain text results, anyone can code anything they want to work with it. Asking Org volunteers to do something outside the scope of Emacs should be critically examined before we can justify asking for volunteer time. That doesn't mean topics shouldn't be discussed, that discussion is the process of critical examination. There's also plenty of room for "fluff", but not flame. For instance, Karl clearly spent a lot of time on his proposal. I thought he was trying to clearly articulate issues from the recent discussions regarding interoperability. I appreciate his efforts even when I don't agree with every conclusion (I vote "Orgish"!). I wish I knew enough about the underlying code to make an informed opinion so I have abstained from on commenting on the details. I don't have to agree or disagree with every point, I'm just watching the debate and trying to place some gentle reminders in the discussion to keep it civil and remember our volunteers are just that, volunteers. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Sun, Dec 05, 2021 at 03:35:39PM +0800, Ihor Radchenko wrote: > Dear Fellow Orgers, > > The recent spike of discussions following Karl's presentation in > Emacsconf 2021 revealed a lot of controversy among Org and Emacs > enthusiasts. Yet, Karl named a number of very real problems surrounding > Org mode usage outside Emacs. On a lighter note, I preferred the format be named "Orgish". ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Mon, Dec 06, 2021 at 07:25:02PM +0100, M. ‘quintus’ Gülker wrote: > > We started with an interoperability topic and now we are discussing > whether the intent is to take away software freedom from Emacs org > users. I cannot help but to find this connection far-fetched. Nobody > is suggesting to hamper org-mode-in-emacs' further development. All > that was asked was if there is interest in someone outside of > org-mode-in-emacs writing up “compatibility levels” for the org > markup. These kind of issues snowball because we are also indirectly asking for our coders and maintainers to consider those external tools while continuing to support Org. How many syntax documents are we supposed to maintain outside of the working implementation in Emacs and the manual? The topic of software freedom comes up because by definition, other tools are outside of Emacs and may be non-free. It's important to consider, but isn't a reason to not discuss features. The key is our volunteers should not be required to code features for non-free tools outside of Emacs. An implied support requirement to preserve interoperability with external tools is a large commitment, and could also run into the non-free software issue. Expect people to have strong opinions about these matters. > ... not be banned from discussion on this mailing list. I don't think banning topics is appropriate. I think we were reminded that this is an Emacs list and FSF software ethics apply. Any official stance Org maintainers take would have to be in line with that moral code. Discussions are often fruitful for all involved and shouldn't be a problem when conducted in a respectful manner. Expect critical opinions at times, but we should keep it civil. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Mon, Dec 06, 2021 at 09:59:42AM -0800, Tom Gillespie wrote: > I think it is a major strategic mistake to exclude discussions > about interoperability from this list. I don't think discussion on the list (or irc) is a problem. It's all on topic if it's related to Org-mode. As you said, users and developers share the mailing list. Just understand as an Emacs mode, it's Emacs oriented and Emacs is the priority. The truth is Org doesn't work outside Emacs. The issue is when non-Emacs enhancements or feature requests are made to the maintainers and coders. I don't think anyone is hostile to interoperability, but hostile to additional workload. I've watched Org since shortly after it's creation snowball features nonstop until it burned out coders. I feel like every power user with a new edge case feature wants it added to the Org core, and that's just not sustainable. That's why I'm very cautious about advocating for new features, or potential burdens external interoperability may place on our volunteers. > I follow this list, I keep the community up to date with my work, > I have no idea where to look for other Org related dicussions, IRC. #org-mode on Libera. > Whether a certain portion of the Org community likes it or not, > there is another portion for whom Org syntax already has a life > beyond Org mode (e.g. academic papers and computation notebook > style workflows). Ideally written with Emacs, and the source blocks processed by Emacs. I can't imagine any of the data science source blocks working in any environment outside Emacs today. If other programs try to replicate Org's features that's fine in the spirit of open source, but what support do we owe their implementations? At what point does their project impose a maintenance burden on our volunteers? That's what we need to be careful of. Perhaps it's worth noting the clear distinction between Org's plain text format and the Org experience inside Emacs. I think that the plain text format in it's simplest forms may be interpreted by external tools (ie: README.org on Github is HTML formatted). I don't expect any tools outside of Emacs to provide the Org editing experience. > The plain text nature of Org syntax and the freedom that it enables > also means freedom from Emacs. Empowering users to own and control > their own data to use with their own tools is the whole point. The > fact that this means that it works outside Emacs is a critical > feature for many data preservation use cases. Certainly Org is future proof because it's plain text. There's a big difference between future proofed and openly legible versus programming two way interoperability between Emacs and an external tool. Just ask any synchronization tool. ;] In summary, don't assume hostility to interoperability. Please respect the limited time of our coders and maintainers, and the additional burdens on them that may be implied by supporting external programs. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Org-syntax: Intra-word markup
On Sat, Dec 04, 2021 at 10:51:47AM +1100, Tim Cross wrote: > > Tom Gillespie writes: > > > I don't mean to be a wet blanket... I'd like to be a wet blanket. > +infinity! > > Please, please can we stop trying to satisfy every edge case or extend > the markup to satisfy every possible scenario. +infinity^2 I've often thought Org needs to hit the brakes and stop adding features, or cut out features that have a high support/maintenance cost. We need to respect our maintainers' time. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Org-syntax: Intra-word markup
On Sat, Dec 04, 2021 at 10:01:15PM +0700, Max Nikulin wrote: > On 04/12/2021 06:51, Tim Cross wrote: > > > > Please, please can we stop trying to satisfy every edge case or extend > > the markup to satisfy every possible scenario. > > It is ridiculous to throw away a nice tool and start to struggle with > another bunch of problems when a small missed feature is really required. I think this is a problem of expectations. I don't export Org to export perfect documents in every language. I expect Org to make a simple subset of features available consistently. With HTML or Latex you can create those words, and you can insert that code into your Org document. Why does the Org syntax need to be further extended to support this? Part of the reason Org is a nice tool is that it is simple, and we should be cautious trying to make it any more complex. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
On Sun, Dec 05, 2021 at 06:59:20PM +, Juan Manuel Macías wrote: > Frustration every time I want to recommend Org to many of my friends > and colleagues, who don't even use Emacs. I think this is the core of every interoperability argument: "Why do we have to use Emacs to use Org?" It's called Emacs Org-mode for a reason. Org-mode doesn't work outside of Emacs. I've often told users that it's worth learning enough Emacs to use Org, and have successfully moved several non-power users over to Emacs. They know enough to consistently open their files, edit Org, and quit. That's enough. They complain it's "ugly" compared to "modern" GUI tools, but they can't deny the utility. > I came to Org been an Emacs user already, so I was reasonably familiar > with Emacs and Elisp, although what I used most was AUCTeX (and Markdown > for my docs). I'd have a hard time convincing users in Mordor to use a plain text format, much less Org without Emacs. > On the other hand, Org as a lightweight markup language is only > a tiny part of Org. I don't think Org is better or worse as a markup > language than Markdown, asciidoc or other similar formats. What makes Org dramatically different is the editing experience in Emacs. Collapsing the outline, filtering on metadata, exports, agenda, etc. Those are Emacs features, not specific to the actual markup format. My impression is we already have stretched our resources thin trying to maintain Org. Pushing to provide compatibility with non-Emacs tools seems a poor use of their time, and rude to ask of them. If non-Emacs users and coders want to use Org formatted files, they are free to spend their time customizing their tools to make it work. If the Org project owes anything to anyone, it's a consistent experience for the users who have used Org for years. Not changes to satisfy potential users or follow trendy fads. My experience has been that Org's markup is so simple and could be summarized in a few lines. Anything more complex enters the territory of Emacs only features (ie: drawers. exports, view control, source blocks, reporting). Those are unlikely to be portable, so we're back to "use Emacs". ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [QUESTION] How to generate org-agenda view for clocked tasks and logs etc which are sorted by timestamps?
On Thu, Nov 04, 2021 at 12:16:19PM +0800, stardiviner wrote: > How to use elisp code to generate an org-agenda view for clocked tasks and > logs etc which are sorted by timestamps? I want to view my daily done tasks > and attach them as part of diary (maybe use org source block elisp code to > generate output?) > > So how to setup `org-agenda-custom-commands` to archive this purpose? I routinely export my agenda to HTML with logbook mode enabled and inactive timestamps. This shows a complete timeline of my actions. I save timestamps on changing TODO to DONE, use active timestamps for appointments, and I constantly add inactive timestamps while taking notes. I use this to justify billing to clients. I open the agenda, v m to make a monthly view, L for logbook, ] to enable inactive timestamps, and then C-x C-w to save. You may be able to just use elisp to trigger these actions. I don't do it often enough to automate it. I love being able to flatten my tree of notes into a timeline this way. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Clarify bug report requirements wrt mailing list subscription
On Wed, Oct 20, 2021 at 08:33:42PM -0300, Carlos Pita wrote: > I find the instructions about bug reporting in [1] lacking a heads-up > that subscription to the mailing list is a (soft?) prerequisite. It's > true that it links to [2] which states: > > You can subscribe to the list from this web page. If you are not a > member of the mailing list, your mail will be passed to the list > after a moderator has approved Subscription is not a prerequisite to sending your message to the mailing list. If you do not subscribe, your message will wait for moderation. There is no guarantee that your message will pass moderation quickly, it could be many days because we have only volunteer moderators. Once your address has passed moderation, if you aren't already a subscriber, you will be added to a list of authorized senders so you don't have to wait in moderation again. Either way it's true that the mailing list has some reasonable protections against spam. I'm sorry if that's caused you some frustration, but we're all just volunteers with limited time. I find the Org list policy to be very liberal. I am on other mailing lists where subscription is mandatory to send any message, and unauthorized senders are ignored completely. > but also it's true [3] states: > > The Org mailing list is a members only mailing list to prevent > spam. Membership is freely available and only requires that you > subscribe to the list and confirm your email address. > > Moreover, that it seemingly is a soft requirement implies that I'm not > getting any feedback for some time about the status of my report. Indeed. Spam protections can cause problems. However, what are your expectations regarding a response for a bug report? Specifically are you referring to the time until your report shows up on the list archive, or the issue itself is addressed? I agree we should try to effectively communicate what you should expect when posting a bug report the first time, and how quickly your report can reach the list. (ie: instantly if you subscribe, or expect delays in moderation) As to how fast the bug can be confirmed or addressed, there are no guarantees. > What do you think of: > > - Adding some brief mention to subscription in [1]. I've updated the Worg page, it should be pushed out soon. > - Resolve the apparent contradiction about subscription being a > prerequisite or not between [2] and [3]. I've updated [3] as well, pending next update. > [1] https://orgmode.org/worg/org-issues.html > > [2] https://orgmode.org/org.html#Feedback > > [3] https://orgmode.org/worg/org-mailing-list.html -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Useful package? Compat.el
On Mon, Oct 11, 2021 at 06:36:50PM +0800, Timothy wrote: > I’ve recently come across an interesting looking library available on ELPA, > <https://git.sr.ht/~pkal/compat>. I’m thinking in future this could allow us > to > both use newer features and also support older versions of Emacs, e.g. > > Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and > newer with compat.el. That's interesting, using a library to wrap new Emacs functionality and implement a common replacement instead of custom work-arounds in local code. Do you have any examples of where this could shorten code in Org? I believe it's a tall order to add a dependency, but if it eliminates large chunks of backward compatibility code then maybe that's something to consider. Thanks. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: orgmode.org setup
On Wed, Sep 29, 2021 at 10:18:02PM +0200, Bastien wrote: > https://orgmode.org/worg/ is populated by .org pages from the Worg > repo after each push: https://git.sr.ht/~bzg/worg > > Worg is maintained by Krupal and Corwin Brust. Anyone is welcome to > contribute: https://orgmode.org/worg/worg-about.html I had commit access to Worg previously, and wanted to confirm I can use it again. I've ensured I have an account on sr.ht, but where can you request access? https://git.sr.ht/~bzg/worg shows only summary, tree, log, and refs even though I'm logged in. What's the correct way for myself and others to request access? Thanks. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Disabling paredit in export buffers?
On Sat, May 15, 2021 at 11:59:23PM +0800, Timothy wrote: > Russell Adams writes: > > > I'm enabling paredit globally for all prog-modes, and it breaks HTML > > export. I'm trying to find a way to disable paredit in all Org export > > temporary buffers. Any suggestions? > > Have you tried this since > https://code.orgmode.org/bzg/org-mode/commit/ec6d1df9bc8967e1db14bbd3c90828c71a6a8e0e > ? Issues like what you mention were exactly the motivation behind your > commit. No, I'm not up to date. But I might patch that in. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Disabling paredit in export buffers?
On Sat, May 15, 2021 at 04:47:02PM +0200, Nicolas Goaziou wrote: > >> > I'm enabling paredit globally for all prog-modes, and it breaks HTML > >> > export. > >> > >> I'm not sure to understand how it breaks the HTML export, can you > >> share a reproducible recipe? > > > > It appears that because I set paredit to be enabled by prod-mode-hook, > > HTML buffers have paredit enabled. > > > > If I then try to do an export to HTML, it aborts immediately with a > > message "Unmatched parenthesis". That's paredit interfering with Org > > inserting text in the temporary buffer. > > Could you show the backtrace? I fail to see when prog-mode-hook is > called. I wish. I tried turning on debug-on-error, and couldn't get any results. When I cleared prod-mode-hook, I could export again. How should I create a backtrace for you? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Disabling paredit in export buffers?
On Sat, May 15, 2021 at 11:04:56AM +0200, Bastien wrote: > > I'm enabling paredit globally for all prog-modes, and it breaks HTML > > export. > > I'm not sure to understand how it breaks the HTML export, can you > share a reproducible recipe? It appears that because I set paredit to be enabled by prod-mode-hook, HTML buffers have paredit enabled. If I then try to do an export to HTML, it aborts immediately with a message "Unmatched parenthesis". That's paredit interfering with Org inserting text in the temporary buffer. If I remove paredit from my prog-mode-hook, Org export works fine. I was trying to find a way to set a hook to disable paredit during Org export in the temporary buffers. I'd like to keep paredit enabled during my HTML editing though. I just didn't see a export create buffer hook. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Disabling paredit in export buffers?
I'm enabling paredit globally for all prog-modes, and it breaks HTML export. I'm trying to find a way to disable paredit in all Org export temporary buffers. Any suggestions? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: The fate of ditaa.jar (9.4.5.)
On Wed, May 12, 2021 at 11:41:48AM +0200, Dr. Arne Babenhauserheide wrote: > I have Java, but not ditaa, because Java is packaged in my distribution > and ditaa is not. My build pipelines use ditaa as shipped with > org-mode. My opinion is that Org has integration for many external tools, but doesn't ship them. I don't think Org should be shipping anything that isn't Org's own code due to maintainer overhead, potential legal/license issues, and inconsistency across tools. We don't ship Latex distributions or gnuplot either. > So unbundling ditaa breaks my documents when updating org-mode. The same > for everyone else who used a standard ditaa-setup with org-mode. I think it's a reasonable request to make of an end user that if you want to use Org's integration with the tool, you ensure the tool is installed first. If your Linux distribution doesn't provide a package for ditaa, file a bug report or a feature request with them. Alternatively you can install it yourself as it's just one .jar file. Perhaps Org should show a better error message if ditaa isn't found. > Ask the other way round: What is the benefit of removing ditaa from org? > If you want to force most current org-ditaa users to unbreak their setup > after update, there should be a significant tangible benefit. Org's codebase is always undergoing change and right now there's a significant cleanup effort going on to separate contrib out of core. I expect removing ditaa was part of that. I defer here to the wisdom of the maintainers that there is benefit to reorganizing the code base, even if it's just to simplify their job as maintainers. I respect that it's causing you some personal inconvenience, however it's not a major breakage. It should be simple to resolve by installing locally. ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: The fate of ditaa.jar (9.4.5.)
On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote: > I pulled the latest master and noticed that contrib has been moved into > a separate repository. I also cloned this contrib repository, but can > not find the file > > scripts/ditaa.jar > > in the repo. In fact, there is no directory scripts in the repo. I actually never considered this might be packaged with Org. I always thought I had to install it separately, like my Latex distribution or PlantUML. ---------- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Checkboxes in headings - opinions wanted
Arthur, Could you just use unicode checkbox symbols instead of TODO and DONE? https://kdr2.com/tech/emacs/1405-orgmode-checkbox-unicode.html That ought to be just a string, and need no patch. On Mon, May 03, 2021 at 09:00:40AM +0200, Arthur Miller wrote: > > Last night I have been playing with a minor mode to enable a checkbox in > a heading, or rather to fake a checkbox. To be honest, it was a 10 > minute job. Took me way moare time to figure out avialable key > combination to use (which I didn't found). > > In general, enable mode and use S+up/down to toggle a checkbox. A > heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or > [x] before a heading. It means a [ ] can be placed somewhere after the > leading stars, whitespaces ignored. > > This has nothing todo with my previous hacks of todo keywords. This one > does not uses todo states at all so it can be used with todo states. > > It is just a small prototype. I will use something else than > replace-string later on. > > Just wonder if the approach is sane. > > There is also a repo on gh for interested one: > > https://github.com/amno1/org-heading-checkbox ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Programmatically set TODO labels per file?
On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: > > Hi all, > > I have a simple question, but I wasn't able to find answer on the web, > so finally I'll try my luck here. > > I know I can setq org-todo-keywords with a list '((sequence "TODO" > DONE")), as an example. But what variable is used for per-file keywords? > Once that are set with #+TODO: ... line? > > I guess when org mode parses a file when starting up the mode, it has to > parse that line into some var, where do I find it? > > Thanks in advance! > > Best regards > /a > https://orgmode.org/manual/Per_002dfile-keywords.html ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: On the protection of emails in the archives
Guillaume On Thu, Apr 08, 2021 at 10:29:00AM +0200, Guillaume MULLER wrote: > Hi all, > > I recently sent an email on this mailing list (see > https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/ > ) Yes you did, and the official archive is here where the list is hosted. https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00184.html > Since then, I'm receiving spams on the email address I used to send the > message. Welcome to the tragedy of the commons known as the Internet. > Would it be possible to configure the archive to obfuscate / hide the email > addresses inorder to protect its users? We do. The GNU mailing list archive that hosts the mailing list does. I can't say regarding the other. Maybe someone else can check it. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Idea for handling timezones
On Sat, Apr 03, 2021 at 02:23:34PM +0300, Greg Minshall wrote: > > #+TIMEZONE: America/Toronto > > > > at the start of their org file, and they moved to Shanghai, all the > > timestamp in > > the org file is converted using something equivalent to I think what you're saying here is that timestamps without timezone information should have a default timezone. I'd suggest there is a global default setting (ie: init file), and allow a buffer local override. Essentially all timestamps that don't specify a timezone should fall back to the local TZ, unless there's a buffer override. I'd be in favor of revisiting the idea of putting timezone information into the timestamp. I know it's a deep change, but this is a kind of incremental growth we should expect to a core feature. I frequently fight this issue myself with meetings across timezones. I would not suggest using UTC. I believe one of the reasons timestamps didn't include TZ information was to keep them short and human legible. Solutions with overlays to change a timestamp reduce the usefulness of the plain text reading of Org (ie: less, grep, etc). Storing timestamps with UTC is really a shortcut for the computer, not the user. I was just reading about Emacs' parse-time-string function, and Emacs already has TZ conversion built in to many of the time functions. It seems to me that we could fall back to the Emacs parser if needed. https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Parsing.html Today's timestamps are in the form of "-MM-DD Day HH:MM". I've often wondered that the day name is in there, other than for human legibility. Given timestamps are always wrapped in <> or [], for active and inactive timestamps accordingly, parsing for a new element at the end by time zone name doesn't sound so bad. Staying with user friendly, I think time zone names would be more useful than delta syntax from UTC. [2021-04-03 Sat 16:56 CEST] doesn't sound too bad, given the timezones aren't expected to be in every timestamp. I really think that the key issue making adoption difficult will be all the tooling reading these, not the timestamps themselves. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Where has the manual on one html page gone?
On Sun, Mar 21, 2021 at 09:54:48AM +0100, Christine Köhn wrote: > Here's why I prefer the one page manual: > > I can search it easily. Sometimes I do not find what I'm looking for > where I would expect it to be. Also, searching is convenient way to find > out if something *is not* in the manual. > > I'm used to reading and searching in a browser. Searching and saving are both effective use cases. > I agree that it's not efficient to download a whole manual but I guess > that's what caching is for? Anyway, I thought about switching to > accessing the manual offline but I haven't gotten to it yet. I disagree. With transparent gzip compression its a few hundred K, less than all the Javascript libraries that load when you open most popular websites. You are also less likely to reopen it repeatedly or reload it. Perhaps the main link can goto a sectioned manual, but I'd like to see a link to the one page manual preserved. ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: contact management in emacs
On Sat, Feb 27, 2021 at 12:08:04PM +0100, Alan Schmitt wrote: > Hello, > > This may be slightly off-topic for the list, but as I’m considering > org-contacts for my question, I hope it will be of interest here. > > I would like to migrate my contact management to emacs, as I’m already > using it for email. My requirements are the following ones: > - address completion in emacs email clients (I currently use notmuch) > - support for multiple email addresses and custom fields > - creation of org links to contacts > - export to vcard format for synchronization to my mobile phone (using > vdirsyncer) > - keep the data under version control > > I have looked at two tools, which almost seem fit for the job. > - ebdb does most of this, with the exception of vcard export (it seems > to be worked on, https://github.com/girzel/ebdb/issues/60), and I’m not > sure using version control on an sqlite file is a good idea. > - org-contacts also seem to have all the required features, including > vcard export (and if not sufficient there is > https://github.com/novoid/org-contacts2vcard). I was worried it was > unmaintained when looking at the copyright line, but I see in > https://code.orgmode.org/bzg/org-mode/commits/master/contrib/lisp/org-contacts.el > that there are recent commits to the file. > > Do you manage your contacts in emacs? And if so, what tools or workflow > do you recommend? The only reason I don't use BBDB is I want to use Org to allow me to maintain notes about contacts (ie: CRM). Yes, I get that I could have a CRM file and link in BBDB contacts, but that feels like adding layers. The stumbling point for me has been exporting to my mobile phone. I'm fine with a one way sync from my BBDB/Org solution to the phone, but I feel like I never found a good option. Please share what you find works for you. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Source Block header arguments
On Thu, Feb 18, 2021 at 07:10:52PM +0800, Timothy wrote: > > Hi Russel, > > Russell Adams writes: > > > I know I can easily create templates for frequently used code blocks. > > > > My question is, is there a completion or in-place documentation for > > valid header arguments to code blocks? The options are rather buried > > in the manual. > > As it so happens, I have had the exact same annoyance. > > My solution was using snippets, you can see the details by looking at: > + https://tecosaur.github.io/emacs-config/config.html#snippet-helpers > + https://tecosaur.github.io/emacs-config/config.html#snippets-org-mode That is interesting. That's kind of what I was thinking could already be implemented without my knowing. ;] Maybe we need to buff the block insertion code? ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Source Block header arguments
On Thu, Feb 18, 2021 at 11:08:32AM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > > I know I can easily create templates for frequently used code blocks. > > > > My question is, is there a completion or in-place documentation for > > valid header arguments to code blocks? The options are rather buried > > in the manual. > > I use helm-info-org for this. I have helm, and never saw this. Good tip! ------ Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
