Re: Provide org-insert-subitem
Hi Dmitrii, Dmitrii Korobeinikov writes: > In short: > org-insert-heading -> org-insert-subheading > org-insert-todo-heading -> org-insert-todo-subheading > org-insert-item -> ? > > Maybe should provide org-insert-subitem for consistency? `org-insert-subheading' and `org-insert-todo-subheading' are not used anywhere in Org's code. Do you them? How? I'm more inclined to delete these commands since they have no binding than to add an `org-insert-subitem'. Hitting then seems swift and handy enough. WDYT? -- Bastien
Re: Bug: Custom TODO fields not rendered when preceded by priority [9.1.14 (9.1.14-9-g131531-elpaplus @ /Users/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/)]
Hi Michael, Michael Dickens writes: > You could argue that this is expected behavior and the priority > should go after the to-do state, but IMO it should work either way > because it can still be unambiguously parsed. Org sets a few syntactic rules, the position of the priority cookie right _after_ the TODO keyword is one of them which we don't want to change, as it makes it easier for everyone to read Org files. Well, because a different syntax can be unambiguously parsed does not mean we should use this different syntax. Best, -- Bastien
Re: Bug Report: Broken Link in Worg
Hi Joshua, Joshua Meyers writes: > In this page (https://orgmode.org/worg/org-gtd-etc.html) the link to > the "very instructive post by Pete Phillips" now directs to the > defunct gmane.org. I think I tracked down the post it is supposed to > link to, so I don't want others to have to do this work again: https: > //lists.gnu.org/archive/html/emacs-orgmode/2007-12/msg00281.html Fixed, thanks! As Nick said, worg is editable, see https://orgmode.org/worg/worg-git.html There are a few other broken links like this one, every contribution helps. Best, -- Bastien
Re: org-superstar-mode: A re-imagining of org-bullets with new features
D writes: > Here is the link to the new project: > https://github.com/dw-github-mirror/org-superstar-mode/ Nice, thanks for sharing! Don't hesitate to mention it in https://orgmode.org/worg/ See https://orgmode.org/worg/worg-git.html Thanks, -- Bastien
Re: org table integrity
Jude DaShiell writes: > Does a way exist in orgmode to fix a column so that it only stores time > stamps? Nope, sorry. -- Bastien
org table integrity
Does a way exist in orgmode to fix a column so that it only stores time stamps? A table I'm using has two columns that could this kind of error protection and two that should contain text. --
Re: customizing Org for legibility
Good points Jack - I was going to post something similar. There are many who use terminal mode for all sorts of reasons which may not be obvious and which is not just sys admin work. For example, people who like to use tmux or do pair programming (or paired writing, such as for co-authoring of papers, presentations etc). Spacemacs has been growing in popularity for this as well. My concern here is that we are very much moving into aesthetics and personal taste. I'm largely with Jack in that I prefer fixed width fonts. While I agree that variable pitch can make some text look better, I find the additional complication this brings wrt formatting and consistent presentation outweighs the small visual improvements. For similar reasons, I never use visual-line-mode. I'm not saying we should not have 'mixed' fonts. However, we do need to ensure this is optional and that it is thoroughly tested - for example, many people have customised Agenda views. There has been discussion around how variable pitch can work, but these tend to focus on the 'default' agenda. It is important to be mindful of such assumptions in order to recognise where changes will need to be implemented as options you can select rather than defaults you must disable. It has been some years since I have done anything with Emacs' customize interface and in particular, custom-face settings, but from memory, it allowed you to set defaults for both GUI and text based consoles, so it should be possible to do things in a way which work for both environments. Jack Kamm writes: >> One thing I don't understand: It seems that GUI and terminal modes are >> completely different. Rather than constrain GUI defaults to terminal >> limitations, it makes sense to gracefully degrade them when a terminal >> is detected. I assume that terminal users don't care about variable >> pitch. They're likely doing sysadmin, with little or no prose >> interaction. > > Personally, I run emacs in daemon mode, and often have both GUI and > terminal emacsclients connected to the same session. So I like to have > settings that work well in both. > > I agree terminal users typically won't want variable pitch, but disagree > that they are generally doing sysadmin -- I know users who use org-mode > for their notes, but prefer to use emacs in the terminal. > > Speaking to my own preferences -- I prefer fixed-width for editing text, > whether it's prose or code. For example, if I execute a command to move > the cursor down 10 lines, I like to know where my cursor is going to end > up. Fixed-width also works better for certain editing commands, such as > rectangle commands. > > I am not sure what the majority preference is here, but it would be > interesting to know, and also how it distributes across old-timers and > newcomers. Ideally, it should be easy to accommodate all preferences, > with a small amount of configuration and easily discoverable > documentation. -- Tim Cross
org-superstar-mode: A re-imagining of org-bullets with new features
Hi, thank you two for your encouragement! Here is the link to the new project: https://github.com/dw-github-mirror/org-superstar-mode/ Fair warning though, I am still in the process of debugging. Cheers, D.
Re: [RFC] C-c C-c in agenda
fwiw i /think/ most of the rest of emacs makes c-c c-c complete/send/do stuff with entered or modified text, while c-c c-k cancels. but we are not talking about cancelling edits so c-c c-k wouldn't be quite right either. i just know newcomers will want something. what is best idk.
Re: customizing Org for legibility [agenda category column]
[continuing from previous email and changing email header per bastien's request to have separate threads/conversations per suggestion.] another useful change imo would be to allow categories to have their own faces, selectable by regexp (so "^m-.*" could be yellow). similar to tags and todo kw. then you could tell them apart without things like having to use the < command. in the agenda, currently (i think) they use the same face as the whole line in the agenda.
Re: Command to edit the heading?
Hi Dmitrii, Dmitrii Korobeinikov writes: > There is the org-set-tags for tags, but is there anything for the > title (org-set-heading/title)? > Would be nice to have. When would it be more useful than editing the headline directly? >From an agenda view? -- Bastien
Re: [BUG] Tags misalign while editing heading
Hi Dmitrii, Dmitrii Korobeinikov writes: > Oh, I forgot about the "-Q"... Anyway, I figured the behavior is > present with evil-mode. > > Here's is how to launch a clean evil environment: > > $ git clone https://github.com/emacs-evil/evil > $ cd evil > $ make emacs > > Should I file a bug in the evil tracker? Yes, probably. Thanks for the follow-up if any, -- Bastien
Re: A new, "org-bullets"-like minor mode
Hi D., Would it be appropriate to share the link here? I think it would be > great to get feedback before trying to get it on melpa. > I would love to give it a try! I use org-bullets currently, and your new features sound quite interesting :) --Diego
Re: customizing Org for legibility [agenda]
hi d, On 2/1/20, Diego Zamboni wrote: > I think you can configure most faces as you wish. For this, I have found > the key "C-u C-x =" (which run what-cursor-position with the DETAILED > argument enabled) very useful - among other things, it shows the face which > is applied at the point under the cursor. Based on that, you can know which > face you need to customize. For example, when running it on an agenda > header line, I see the following: what i mean by header line is not the whole line in the agenda, but the stuff that is after the stars in the headline in the outline, which appears on the right in the agenda. faces for the /whole line/ in the agenda are indeed settable. but that is not what i am referring to. /most/ of the columns in the whole agenda line must be fixed pitch, because they have to line up. so currently everything is fixed pitch. if you set the whole line to variable, nothing will line up. the header on the right, however, can be variable. that is what i am proposing [can't code it]. [niggle: depending on your tag column setting, there might be issues with tags, but those issues also obtain in the outline. which you have set to variable, then fix tags by setting them to 0. this can also be done in the agenda, so it is not unique to agenda.] [niggle: todo kw has a variable that iirc controls whether that is to be a column, so that should be settable also. for myself i would choose variable as i don't need todo kw in a column, but some might want them fixed so they can be in a column.] > also, i would remove the second column, which seems not to do anything. this appears to be hardcoded. dunno what its purpose is. >> >> also, i removed colons from some columns in the agenda and think it >> looks better. also i aligned all items. also, i made bare active >> tses use a leader. also i made everything more compact except >> categories which i widened. also, i removed [xd.] in leaders. >> > > I would be interested to learn how to make these customizations. i did most of them by setting the user leader variables. org-agenda-deadline-leader etc. bare active was a trivial fix to a string in the org code. i just searched for it and got lucky. i can send the patch. this also allowed aligning those with everything else. i cannot sign with fsf and don't know if contributions accumulate. another possible change is ... bastien wanted separate email headers so i will suggest in one. cheers -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
Re: A new, "org-bullets"-like minor mode
D writes: > On 01.02.20 21:32, Marco Wahl wrote: >> AFAICS org-bullets is released under GPL3. Doesn't this mean that you >> can use org-bullets as a base for further development if you leave the >> license intact and also keep the original authors next to your name? > > That is correct, I just don't mean to come off as rude making a still > rather derivative mode like that without trying to get the guy's > blessing. I am likely overthinking the matter. I see and I think that's fine that you want to contact the original author first. > Would it be appropriate to share the link here? I think it would be > great to get feedback before trying to get it on melpa. I would say yes, but it's just me. For sure there is no guarantee for feedback. But there is some potential since at least some people playing with Org hang out on this list. Best regards, -- Marco
Re: A few changes to test in master
Hi Axel, Axel Kielhorn writes: > I now get: > > Error running timer: (invalid-function (ov (first (overlays-in > (point) (1+ (point)) [10 times] That was due to the use of `if-let' - this should be fixed now. Thanks, -- Bastien
Re: A new, "org-bullets"-like minor mode
On 01.02.20 21:32, Marco Wahl wrote: > AFAICS org-bullets is released under GPL3. Doesn't this mean that you > can use org-bullets as a base for further development if you leave the > license intact and also keep the original authors next to your name? That is correct, I just don't mean to come off as rude making a still rather derivative mode like that without trying to get the guy's blessing. I am likely overthinking the matter. Would it be appropriate to share the link here? I think it would be great to get feedback before trying to get it on melpa. Cheers, D.
Re: customizing Org for legibility
> Ok, I see what you're saying. You're proposing to have TODO states and
> other tags on the left of the heading title in fixed pitch, and the
> heading title in variable pitch. In my current setup the whole heading
> is fixed in Agenda and variable in normal buffers. I agree it would be
> good to have mixed-pitch headings.
>
This is doable for the TODO states already using the org-todo-keyword-faces
variable, which can contain full font attribute lists, like this:
(org-todo-keyword-faces
'(("TODO" . (:foreground "DarkOrchid1" :inherit fixed-pitch))
("INBOX". "cyan"))
--Diego
Re: customizing Org for legibility
HI Bob, In my testing, all font-related settings get ignored when running in terminal mode, except for the colors. --Diego On Sat, Feb 1, 2020 at 9:12 PM Bob Newell wrote: > Aloha everyone, > > > I agree terminal users typically won't want variable pitch, but disagree > > that they are generally doing sysadmin -- I know users who use org-mode > > for their notes, but prefer to use emacs in the terminal. > > I have a Very Big Use Case here: on my Android devices I run > Termux, which runs nearly everything perfectly but only in > terminal mode. I run Emacs/org-mode this way on my Android > tablet all the time when out of the house or traveling. > > The mixed pitch idea has great merit, don't get me wrong, and > would be a very nice thing indeed on my native Linux > devices. But I'd hope there would be no "unintended > consequences" for terminal users. > > -- > Bob Newell > Honolulu, Hawai`i > - Via Gnus/BBDB/Org/Emacs/Linux > >
Re: customizing Org for legibility
Hi Samuel,
> i get the sense spacemacs has brought a lot of new users to emacs. i
> don't use it but i have comments on your interesting and welcome
> beauty tips.
>
This is definitely the case. I also don't use Spacemacs, but know a few
people who got started thanks to it. I even have a friend who was a
devoted vim user, and now swears by Spacemacs, particularly thanks to
org-mode and magit :)
this is really impressive. does it have a fill column?
>
Yes, there is (I don't use it):
https://github.com/joostkremers/visual-fill-column
i would be over the moon if you could make headers in the agenda
> variable pitch. not only would it look better and be consistent with
> the outline, but it would conserve space.
>
I think you can configure most faces as you wish. For this, I have found
the key "C-u C-x =" (which run what-cursor-position with the DETAILED
argument enabled) very useful - among other things, it shows the face which
is applied at the point under the cursor. Based on that, you can know which
face you need to customize. For example, when running it on an agenda
header line, I see the following:
There are text properties here:
day 737456
face org-agenda-date-today
By customizing this face to inherit from "variable-pitch", I was able to
make those lines display in variable pitch font.
also, i would remove the second column, which seems not to do anything.
>
> also, i removed colons from some columns in the agenda and think it
> looks better. also i aligned all items. also, i made bare active
> tses use a leader. also i made everything more compact except
> categories which i widened. also, i removed [xd.] in leaders.
>
I would be interested to learn how to make these customizations. I have
only recently been getting into agenda mode, so I have not customized much
yet,
curious what the brackets mean in
>("PROPOSAL" . "orange")
>("[PROPOSAL]" . "orange")
>
Nothing special - only that I sometimes use TAG in my headers, and others I
use [TAG], depending on how I think it looks better at the time :) This way
it gets colorized correctly no matter what.
what does reformatting a buffer change?
>
I guess you are referring to the zz/org-reformat-buffer in my config? I got
this from the mailing list, although I can't remember who posted it (sorry
to the author! there goes my intention to always attribute things). It
basically redoes all the spacing and indentation in the buffer. I run it
every once in a while to uniformize things.
could tags be fixed to stay at a column by counting pixels?
>
I have not found a way to make that happen. The misalignment was bothering
me, so in the end this is what I do:
- In =variable-pitch= mode, the default right-alignment for headline tags
doesn't work, and results in the tags being misaligned (as it uses
character positions to do the alignment). This setting positions the tags
right after the last character of the headline, so at least they are more
consistent.
#+begin_src emacs-lisp :tangle no :noweb-ref org-mode-custom-vars
(org-tags-column 0)
#+end_src
> thank you for the tips.
>
Glad you found them useful!
Cheers,
--Diego
Re: A new, "org-bullets"-like minor mode
D writes: > However, since the mode still contains code snippets from org-bullets, I > have tried to contact the original author (sabof) of the package in the > hopes of getting an official approval before making the thing public. > The problem with /that/ however is that the author has been inactive for > several years now, with the package being maintained by Jonas Bernoulli, > who I did not yet contact. AFAICS org-bullets is released under GPL3. Doesn't this mean that you can use org-bullets as a base for further development if you leave the license intact and also keep the original authors next to your name? Best regards, -- Marco
Re: [RFC] C-c C-c in agenda
Samuel Wales writes:
> i think it can be confusing to new users to have column mode
> accidentally activated. what are the things they will try to get out
> of it? maybe worth considering all the panic commands they'd try, and
> either deactivate or message what to do to deactivate?
Indeed. Ease the breakout from column view was the main motivation for
the binding.
> if c-c c-c is being weighed, maybe consider it as one of those things
> to possibly tip the balance? i do not use column mode (drawers are
> slow, too disorrganized to make a contact list with it), so cannot
> say.
>
> some things they might try are: q, c-c c-c, c-c c-k, esc esc esc, c-g,
> undo, whatever they tried last, c-u on whatever they tried last,
> revert, kill buffer, ? as a speed command, look at mode line, skim the
> manual [for what?], c-z, whatever vim does, spacemacs?.
The inspiration for the C-c C-c to quit column view was the removal of
highlightings hanging around from a sparse tree with those keys C-c C-c.
BTW C-c C-c is also a way out of the macro editing buffer. { M-x
kmacro-edit-macro }
> similar for things like outline search view and org agenda restriction
> lock, but in my experience, those are less commonly accidentally
> activated.
I also think so for restriction lock.
Ciao,
--
Marco
Re: [RFC] C-c C-c in agenda
Hi Adam, Adam Porter writes: >> For some days now C-c C-c disables column view in Org files. This helps >> me a bit and never got in my way. And I thought it would be quite >> natural and consistent to use this binding for the agenda too. >> >> What do you think about all that? > > Hi Marco, > > I've always had the impression that the "C-c C-c" binding was intended > to do the most obviously useful or natural action in the current > context. For example, in a capture or log buffer, it completes the > capture. With point on a #+ line, it resets buffer properties > accordingly. > > I don't use column view very often, so I may be biased, but anyway: in > the general context of an Agenda buffer, I don't feel like enabling or > disabling column view is the most obviously useful or natural thing to > do, so "C-c C-c" doesn't seem like an appropriate binding to me. Yes, it might not be 100% natural. But as Samuel pointed out accidentially turned on column view can be a trap in particular for new users. And C-c C-c often is a way out not only in Org mode. And also recall Bastien's observation that C-c C-c already all the time quit column view when triggered on a line in column view state. Best regards, -- Marco
Re: customizing Org for legibility
Aloha everyone, > I agree terminal users typically won't want variable pitch, but disagree > that they are generally doing sysadmin -- I know users who use org-mode > for their notes, but prefer to use emacs in the terminal. I have a Very Big Use Case here: on my Android devices I run Termux, which runs nearly everything perfectly but only in terminal mode. I run Emacs/org-mode this way on my Android tablet all the time when out of the house or traveling. The mixed pitch idea has great merit, don't get me wrong, and would be a very nice thing indeed on my native Linux devices. But I'd hope there would be no "unintended consequences" for terminal users. -- Bob Newell Honolulu, Hawai`i - Via Gnus/BBDB/Org/Emacs/Linux
Re: [RFC] Document level property drawer
>> Sebastian Miele writes: >>> I would like to be able to make a clear distinction between properties >>> that are visible by default and properties that are not. Maybe it would >>> be possible to allow some #+.. syntax following headings for subtree >>> properties that are visible by default. A requirement could be made that >>> such property specifications always have to be followed by a property >>> drawer, even if that is empty. Then everything #+.. that is before the >>> property drawer would belong to the heading/subtree, and everything #+.. >>> that follows the drawer would be treated as it is until now. >>> >>> Please tell me if I missed something and Org is already capable of >>> something like that. If not, are there others who would like >>> visible-by-default property specifications for headings/subtrees in >>> addition to invisible-by-default property specifications in drawers, >>> too? >> >> I don't think Org is capable of this out of the box right now. Further >> I don't feel the need for a visible-by-default property, but that's just >> me. > > After a few more months of living without that feature I must say that I > basically live perfectly well without that, too. I just do not define > source block header args in property drawers. It gets a bit verbose at > times. But not to the degree of being painful. Sounds good to me. >>> Finally, I would like to state an opinion: If there is >>> visible-by-default (by #+..) and invisible-by-default (by drawers) >>> syntax for headings/subtrees, including level 0, it may be viable to >>> require them to be disjoint for each heading/subtree. Most probably it >>> would be good practice, anyway. And the precedence question raised >>> previously in this thread would be eliminated. >> >> I may not feel the need for the visible/invisible-by-default properties >> but actually I like the idea of #+ properties parallel to the property >> drawers as visible by default properties. But since the #+ properties >> may appear anywhere in the Org file and affect the whole file it would >> be difficult or even impossible to give them reliable meaning for >> subtrees AFAICS. > > In the meantime I had a look into worg/dev/org-syntax.org. From the > document: "Property drawers are a special type of drawer containing > properties attached to a headline. They are located right after a > headline and its planning information." Thanks for the quote. > So, currently, #+ properties may not appear between a heading and a > property drawer. At least not without turning the property drawer into a > non-special drawer. So, in principle, it would be possible to change the > syntax of Org to allow #+ properties between headings and (possibly > empty) property drawers in order to denote visible-by-default > properties attached to a heading. Sounds true AFAICS. > Moreover, this change probably would introduce very little to no > backwards incompatibility. With the change it would not be possible to > turn property drawers into non-special drawers by putting a #+ property > before them. Now it is possible to sort of uncomment property drawers by > putting #+ properties before them. This "feature" probably is hardly > used, if at all. I also think this is very corner case-y. All in all I think your idea is good. But the masses did not scream for that change so I think your idea is something for a wishlist to wait for further discussion. Best regards, -- Marco
Re: A few changes to test in master
> Am 01.02.2020 um 17:39 schrieb Bastien : > > Hi Axel, > > Axel Kielhorn writes: > >> There is another issue when a column is reduced in width by C-C TAB. >> The header line still has the original width, thus the columns are >> not aligned. > > Ah, I know understand - this should be fixed too, thanks. With Org mode version 9.3.2 (release_9.3.2-182-g4d5731 ...) I now get: Error running timer: (invalid-function (ov (first (overlays-in (point) (1+ (point)) [10 times] Greetings Axel
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Bastien writes: > Future maintainers may of course interpret the recommendations of > the FSF differently, but that's mine for now. Of course, sir.
Re: Format of Effort estimates should be mentioned in its Info node
Hi Kisaragi Hiu, > Done; I haven't done the copyright assignment paperwork with FSF, but > I guess it's fine since this is under the 15 line limit? Yes, thanks a lot. I've applied your commits to th master branch. I just added the TINYCHANGE cookie in the commit messages. > I copied a few examples from org-duration.el, which is what actually > defines the format (org-refresh-effort-estimates). I also corrected > the docstring of org-effort-property, as the format does actually > allow for values like "10min" or "6h". (I was under the impression > that "10m" didn't work because it didn't show up when I asked the > agenda to filter to < 60 minutes; it's actually working just fine > since that means 10 months.) Thanks again! -- Bastien
Re: Format of Effort estimates should be mentioned in its Info node
Done; I haven't done the copyright assignment paperwork with FSF, but I guess
it's fine since this is under the 15 line limit?
I copied a few examples from org-duration.el, which is what actually defines
the format (org-refresh-effort-estimates). I also corrected the docstring of
org-effort-property, as the format does actually allow for values like "10min"
or "6h". (I was under the impression that "10m" didn't work because it didn't
show up when I asked the agenda to filter to < 60 minutes; it's actually
working just fine since that means 10 months.)
2020年2月1日 17:24 差出し人： b...@gnu.org:
> Hi Kisaragi Hiu,
>
> Kisaragi Hiu writes:
>
>> Currently, the Info node about effort estimates does not mention what
>> format should it be written in. This causes confusion, as a user might
>> assume that it's the same format as schedulers (10m, 6h, etc.) like I
>> did.
>>
>> Simply mentioning "Effort estimates need to have the format H:MM"
>> (copied from the docstring or org-effort-property, the only*
>> description of the format I could find) in the Info node would be
>> enough.
>>
>
> Yes. Can you submit a patch against doc/org-manual.org?
>
> Thanks!
>
> --
> Bastien
>
>From 558ad170a05bb9aaf43e246918cea44d8f8da783 Mon Sep 17 00:00:00 2001
From: Kisaragi Hiu
Date: Sun, 2 Feb 2020 00:04:23 +0800
Subject: [PATCH 1/2] org-manual.org: Mention the format of effort estimates
* doc/org-manual.org (Effort Estimates): Mention the format of effort
estimates.
---
doc/org-manual.org | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ce4fedb55..70a654647 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6899,9 +6899,14 @@ to produce offers with quotations of the estimated work effort, you
may want to assign effort estimates to entries. If you are also
clocking your work, you may later want to compare the planned effort
with the actual working time, a great way to improve planning
-estimates. Effort estimates are stored in a special property
-=EFFORT=. You can set the effort for an entry with the following
-commands:
+estimates.
+
+Effort estimates are stored in a special property =EFFORT=. Multiple
+formats are supported, such as =3:12=, =1:23:45=, or =1d3h5min=; see
+the file =org-duration.el= for more detailed information about the
+format.
+
+You can set the effort for an entry with the following commands:
- {{{kbd(C-c C-x e)}}} (~org-set-effort~) ::
--
2.25.0
>From e7e7a3205ae6da51a696f45d7afee5f8b98bddac Mon Sep 17 00:00:00 2001
From: Kisaragi Hiu
Date: Sun, 2 Feb 2020 00:08:10 +0800
Subject: [PATCH 2/2] org.el: Correct docstring
* lisp/org.el (org-effort-property): Correct docstring, as the
previous description of the format was inaccurate.
---
lisp/org.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 3605460f3..ba34ee38e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -565,7 +565,8 @@ An entry can be toggled between COMMENT and normal with
(defconst org-effort-property "Effort"
"The property that is being used to keep track of effort estimates.
-Effort estimates given in this property need to have the format H:MM.")
+Effort estimates given in this property need to be in the format
+defined in org-duration.el.")
Timestamp
--
2.25.0
Re: A few changes to test in master
Hi Axel, Axel Kielhorn writes: > There is another issue when a column is reduced in width by C-C TAB. > The header line still has the original width, thus the columns are > not aligned. Ah, I know understand - this should be fixed too, thanks. -- Bastien
Re: customizing Org for legibility
> One thing I don't understand: It seems that GUI and terminal modes are > completely different. Rather than constrain GUI defaults to terminal > limitations, it makes sense to gracefully degrade them when a terminal > is detected. I assume that terminal users don't care about variable > pitch. They're likely doing sysadmin, with little or no prose > interaction. Personally, I run emacs in daemon mode, and often have both GUI and terminal emacsclients connected to the same session. So I like to have settings that work well in both. I agree terminal users typically won't want variable pitch, but disagree that they are generally doing sysadmin -- I know users who use org-mode for their notes, but prefer to use emacs in the terminal. Speaking to my own preferences -- I prefer fixed-width for editing text, whether it's prose or code. For example, if I execute a command to move the cursor down 10 lines, I like to know where my cursor is going to end up. Fixed-width also works better for certain editing commands, such as rectangle commands. I am not sure what the majority preference is here, but it would be interesting to know, and also how it distributes across old-timers and newcomers. Ideally, it should be easy to accommodate all preferences, with a small amount of configuration and easily discoverable documentation.
A new, "org-bullets"-like minor mode
Hi, in the past two weeks I have been working on a new org minor mode based on org-bullets. Much like org-bullets-mode, the new mode (dubbed "org-superstar-mode" for the time being) visually replaces headline stars with UTF8 bullets. However, while I took the code of org-bullets as an initial template, I have largely rewritten the code base for lots of additional features, including: * The ability to fully customize the look of plain list items as well. * Contextual sensitivity (meaning lists and headings are recognized semantically, so org-superstar-mode ignores false positives in for example SRC blocks) * level-dependent fontification for bullets * The ability to customize the look of leading stars, while respecting org-hide-leading-stars. However, since the mode still contains code snippets from org-bullets, I have tried to contact the original author (sabof) of the package in the hopes of getting an official approval before making the thing public. The problem with /that/ however is that the author has been inactive for several years now, with the package being maintained by Jonas Bernoulli, who I did not yet contact. So, before going any further, I wanted to first ask whether there is any community interest in such a package. As an addendum, an excerpt from the description of the yet-to-be package: ;; This package is heavily influenced by (and uses snippets from) the ;; popular package "org-bullets", created by sabof. It was made with ;; the goal of inheriting features the author liked about org-bullets ;; while being able to introduce compatibility-breaking changes to it. ;; It is largely rewritten, to the point of almost no function being ;; identical to it's org-bullets counterpart.
Re: equal syntax highlighting for publishing code blocks to html and pdf
Bastien writes: >> Frequently I publish org-mode documents containing source code blocks >> to html (htmlize) and pdf (minted). I would like to see the same >> colors in both export types. But >> I cannot figure out, what’s the best way to achieve this. >> >> Has anyone solved this problem? Are there any hints? On casual inspection, HTML export seems to derive the colors from the way Emacs has fontified the buffer. It appears to insert the colors literally, which I guess it has to if it’s going to base them on face properties. > If you find a solution, please mention it here, others may be > interested. I think there are two plausible ways forward. If you like the colors used by minted, you can try changing the faces in Emacs to match them. If you like the colors used by Emacs, you can change the colors used by minted to match. Minted appears to use pygments, so you could create your own style[1] and then use that style in your documents[2]. My own approach to printed output[3] doesn’t use minted yet, so I haven’t actually tried to do any of these things :-) Be seeing you, norm [1] https://pygments.org/docs/styles/ [2] https://tex.stackexchange.com/questions/218556/style-pygments-at-pythontex [3] https://so.nwalsh.com/2020/01/05-latex -- Norman Tovey-Walsh | The fact that an opinion has been https://nwalsh.com/ | widely held is no evidence | whatever that it is not utterly | absurd; indeed in view of the | silliness of the majority of | mankind, a widespread belief is | more likely to be foolish than | sensible.--Bertrand Russell signature.asc Description: PGP signature
Re: A few changes to test in master
Hi Bastien, > Hi Axel, > > thanks for testing the feature and reporting these issues. > > I pushed a fix on master - can you confirm it solves your issues? It does, thanks for the quick response. There is another issue when a column is reduced in width by C-C TAB. The header line still has the original width, thus the columns are not aligned. Greetings Axel
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hi Nicolas, Nicolas Goaziou writes: > Bastien writes: > >> My point is that distinguishing trivial vs. non-trivial parts of a >> change may be subject to interpretation. When in doubt, I recommend >> staying on the safe side of not accepting a change that is more than >> 15 lines of "maybe-significant" changes. > > AFACT, there was no doubt involved when I said "15 lines of non-trivial > code". I'm sure there was no doubt on your side, but as the one responsible for the consistency of copyright assignment for Org-mode, my attention is necessarily triggered when I see a change of >20 lines marked as "tiny change". I fully trust your judgement. I am not arguing that *this* change required Dan to sign the papers. I'm saying that in general, I would rather avoid relying on the evaluation of the "triviality" of the locs and incite contributors to sign the papers. > If your point (I didn't get it actually) is "interpretation is hard, > let's not interpret anything and count everything as significant", well, > I think this is not a good way to look at the problem. But that's fine, > as long as it suits you. My point is this: the inconveniency of *systematically* requesting copyright assignment from the contributor when its contribution is more than 15 lines (significant *or not*) is a small inconveniency compared to the one of having to check carefully whether every >15 lines change is significant or not. And since is it a good outcome to have more people signing the FSF papers, I recommend requesting contributors to sign the copyright assignment for every >15 lines contributions (significant or not). Future maintainers may of course interpret the recommendations of the FSF differently, but that's mine for now. Thanks, -- Bastien
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Bastien writes: > My point is that distinguishing trivial vs. non-trivial parts of a > change may be subject to interpretation. When in doubt, I recommend > staying on the safe side of not accepting a change that is more than > 15 lines of "maybe-significant" changes. AFACT, there was no doubt involved when I said "15 lines of non-trivial code". > Yes, in this case there is no new idea, but this is irrelevant to the > discussion, I thought we had a discussion about it recently, but my memories may be brittle. > since ideas cannot be copyrighted anyway. I knew I shouldn't have used this word. Fair enough. Replace it with "process", or whatever has a copyright meaning. > Well, I hope I clarified my point, which is to stay on safe side of > asking contributors to sign the FSF papers when the importance of the > change can be subject to intepretation. If your point (I didn't get it actually) is "interpretation is hard, let's not interpret anything and count everything as significant", well, I think this is not a good way to look at the problem. But that's fine, as long as it suits you. Regards,
Re: org-mode functional programming library
Hello, "Dwarshuis, Nathan J" writes: > I recently authored an package called "om.el" which is a functional > org-mode API akin to dash.el primarily using org-element. Briefly, it > provides a library of (mostly) pure functions that manipulate the > parse tree generated by org-element.el, and uses this to either edit > or query the buffer with all the advantages of functional programming > (eg lack of side effects, referential transparency, easier testing, > etc). The github repo for om.el is here: > https://github.com/ndwarshuis/om.el. > > I'm posting to the mailing list a) for general feedback on this > package and b) because I am wondering if this would be a good package > to include with org-mode itself rather than in another repository such > as MELPA. The code for om.el is tightly integrated with org-element.el > and it might make sense for development between these to be closely > intertwined. Thank you for this thorough work. Note that code going into Org proper cannot rely on external libraries, e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not in its current form. Is it possible to write it without these libraries, and without re-inventing the wheel? Note that, at some point, Org will support "seq.el", i.e., when we drop support for Emacs 24. Skimming through your code, I read a lot of griefs against Element library (inconvenient, unfortunate, buggy, inconsistent... I stopped there). I agree on most points, of course. Though, there are a few cases where you seem to miss the point. Also, the way you handle plain lists is not how it is done in Org. Anyway, it could be beneficial for both Org and your library to discuss the points above and improve the parser. WDYT? I didn't check, but how do you alter the buffer when applying changes to the parse tree? Is it optimized, e.g., only changed lines are replaced? Or are you deleting the whole thing and replacing it with the interpreted stuff? Note that Org has hardly ever access to the full parse-tree, because parsing a whole buffer is too slow. So, because of these limitations, I wonder if your library can be used efficiently to alter the buffer. Regards, -- Nicolas Goaziou
Re: equal syntax highlighting for publishing code blocks to html and pdf
My guess is you have two options: 1. Customize the colors in minted to match what is on your screen. I am pretty sure that code in html looks very much like what is on your screen. This might be an entry point to customizing minted style. https://tex.stackexchange.com/questions/131456/customize-comment-color-in-minted-style 2. Customize the faces emacs uses for syntax highlighting to match the look in minted. either way, I don't see a simple way to have a common theme between them, and they will probably always have some minor differences. It might be easier to hack a new exporter for src blocks that turns the htmlized code into latex markup perhaps. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, Feb 1, 2020 at 4:28 AM Bastien wrote: > Hi Johannes, > > Johannes Brauer writes: > > > Frequently I publish org-mode documents containing source code blocks > > to html (htmlize) and pdf (minted). I would like to see the same > > colors in both export types. But > > I cannot figure out, what’s the best way to achieve this. > > > > Has anyone solved this problem? Are there any hints? > > I don't know how to do this and I guess it's difficult. > > If you find a solution, please mention it here, others may be > interested. > > Thanks! > > -- > Bastien > >
Re: a wide column problem
Jude DaShiell writes: > I think the best that's now possible with orgmode is something like the > following. You can use M-RET in the cell to wrap the line - but when exporting, each line will be exported independantly, so this is limited. -- Bastien
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hi Nicolas, I think it is worth spending a little time discussing this to ensure that everyone is aligned on the same understanding, otherwise we may have to spend more time later, discussing it over and over for other cases. Nicolas Goaziou writes: > So, I stand on my ground: there is a "non-trivial" part to take into > consideration when counting locs. Yes, you are right. My point is that distinguishing trivial vs. non-trivial parts of a change may be subject to interpretation. When in doubt, I recommend staying on the safe side of not accepting a change that is more than 15 lines of "maybe-significant" changes. In general, the more FSF-signed contributors there are, the less time maintainers spend on deciding whether changes are significant or not. Also, signed contributors are more likely to contribute again, so I recommend inciting contributors to sign. I am glad we already have more than 200 signed contributors, that's a great achievement :) > I would go even further: when you transform a string regexp into a rx > regexp, there is no line to count, because there is no new idea to > copyright in the first place. This is a trivial change. Yes, in this case there is no new idea, but this is irrelevant to the discussion, since ideas cannot be copyrighted anyway. Copyright is about the expression of ideas, and code is also all about this, hence the difficulty, sometimes, to interpret "significant". > Anyway, I think arguing here is just wasting our time. Well, I hope I clarified my point, which is to stay on safe side of asking contributors to sign the FSF papers when the importance of the change can be subject to intepretation. Thanks, -- Bastien
Re: A few changes to test in master
Hi Axel, thanks for testing the feature and reporting these issues. I pushed a fix on master - can you confirm it solves your issues? -- Bastien
re: a wide column problem
I think the best that's now possible with orgmode is something like the following. I'll just need to be careful entering text into the work column since the users of this table haven't even got emacs on their computers let alone orgmode. #+STARTUP align | arrived| staff | work | left | |+-+---+| || | <40> || | [2020-01-28 Tue 09:08] | Daedon and Doug | watch Doug laundry dishes | [2020-01-28 Tue 13:08] | || | trash removal containers recovery || | [2020-01-29 Wed 20:30] | umuaru | brought food | [2020-01-29 Wed 20:45] | | [2020-01-30 Thu 13:00] | alex| fixed drains brought lunch and black bags | [2020-01-30 Thu 14:00] | || | put light cover on over stove || || | || --
re: wide column problem
The table should have a 40 character line wrap limit in the work column and would look like this: | arrived| staff | work | left | |+-+-+| | [2020-01-28 Tue 09:08] | Daedon and Doug | watch Doug laundry dishes | [2020-01-28 Tue 13:08] | || | trash removal containers recovery || | [2020-01-29 Wed 20:30] | umuaru | brought food | [2020-01-29 Wed 20:45] | | [2020-01-30 Thu 13:00] | alex| fixed drains brought lunch and black bags | [2020-01-30 Thu 14:00] | || | put light cover on over stove || || | || I had to use ex to insert lines with field delimiters in the table then cut and paste text to have gone in the second line of the first and third records. --
Re: Displaying remote images
Hello, Jack Kamm writes: > Thank you for reviewing my patch. I'm attaching an updated patch in > response to your review. Applied. Thank you. I also simplified the allowed symbols for the new variable a bit, and added a docstring for the internal function. Regards, -- Nicolas Goaziou
Re: a wide column problem
I only wrote text in a column and haven't tried anything for that column yet. I searched through info org and came close to stuff that looked like it might work but only came close according to the documentation. I've never done anything like this with org-mode before so figured it might be a good idea to ask here first. On Sat, 1 Feb 2020, Bastien wrote: > Date: Sat, 1 Feb 2020 03:55:38 > From: Bastien > To: Jude DaShiell > Cc: emacs-orgmode@gnu.org > Subject: Re: a wide column problem > > Hi Jude, > > Jude DaShiell writes: > > > For a table with a wide column can org-mode use a width on the column as > > well as word wrap? > > What did you try? Can you show how it should look like? > > --
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hello, Bastien writes: > Nicolas Goaziou writes: > >> TINYCHANGE is only about the number of non-trivial lines of code in >> your patch (15 or so). > > I would not say "non-trivial lines" of code. > > The change should be less *than 15 lines or so* to be accepted. > > I may be wrong, but this is how I read this: > https://www.gnu.org/prep/maintain/maintain.html I disagree. As stated in this page, only lines of code significant copyright-wise count. Commenting a line of code, changing indentation (e.g., when you wrap a `let') do not count. You cannot copyright an indentation change. Nor a symbol renaming (this example is even given in the page above). Also, applying the same change multiple times may count /at most/ once. So, I stand on my ground: there is a "non-trivial" part to take into consideration when counting locs. I would go even further: when you transform a string regexp into a rx regexp, there is no line to count, because there is no new idea to copyright in the first place. This is a trivial change. Anyway, I think arguing here is just wasting our time. Regards, -- Nicolas Goaziou
Re: A few changes to test in master
> Am 31.01.2020 um 12:26 schrieb Bastien : > > Dear all, > > I would like to highlight three changes from master that need to be > carefully tested before Org 9.4 can be released: > > - M-x org-table-electric-header-mode RET will display the first row > of the table at point in the header line when the first row is not > visible anymore. This sounds great! It works fine when I activate Display Line Numbers Mode. Without that I get: Org-Table-Header-Line mode enabled in current buffer Error running timer: (void-variable display-line-numbers-mode) [3 times] but no header line. When I enable Display Line Numbers Mode Activate org-table-header-line-mode And disable Display Line Numbers Mode it keeps on working but I still get lots of (void-variable display-line-numbers-mode) warnings. I’m using Emacs 26.3 on MacOS 10.13 with the scimax customization. Org mode version 9.3.2 (release_9.3.2-175-gf70490 ...) Greetings Axel
Re: customizing Org for legibility
Hi Texas, > I aim to popularize Spacemacs as a personal info manager. Next task is > the Org configuration layer. thanks for doing so. > As preparation, I wrote a post critiquing Org's out-of-the-box > legibility. some ideas might be useful - thanks again. Can you take ideas one by one and send an email to the list for each improvement you sugggest? That will make it easier for everyone to contribute to what feature or new default is discussed, based on the subject line of your emails. Thanks in advance, -- Bastien
Re: [BUG] Infinite loop in org-agenda-show-new-time
Hi Andrew, Andrew Hyatt writes: > I've been having this same issue - the issue is quite reproducible > for me, and it has been for years. I just finally grew tired of the > issue and decided to investigate it, and yes, the issue is > org-agenda-show-new-time. > > I also have invisible entries in the org buffer, and the call to > org-move-to-column apparently will move several lines forward, which > causes us to process the same lines over and over. > > Wrapping the call to org-move-to-column with a let setting the > buffer-invisibility-spec to nil does fix the issue. this problem is from... 2013! https://lists.gnu.org/archive/html/emacs-orgmode/2013-08/msg00218.html Is there anything we still need to fix in this area? If so, can you send it as a patch against current maint branch? Thanks, -- Bastien
Re: C-c C-c to close the buffer in *Org Src ...* buffers
On 2020-01-31, at 12:14, Fraga, Eric wrote: > On Friday, 31 Jan 2020 at 12:03, Bastien wrote: >> Hi all, >> >> I'd like to make an equivalent to in Org Src buffers >> so that hitting will close the buffer, which seems natural. > > It does seem natural and generally support this idea. > > However, it could potentially cause me a minor annoyance: I often (in > manuals and other forms of dissemination) use org src blocks (i.e. src > blocks with org code) and I would expect C-c C-c to do whatever it would > normally do in an org file (e.g. add tag) while editing that > block. Would the normal C-c C-c behaviour take precedence? > > If not, this is a very minor issue so I'm sure I would adjust! A similar issue was the reason I stopped using C-c C-c to add tags in favor of C-c C-q: I wanted to add tags while capturing notes. What I'm saying is that maybe C-c C-c tries to be too clever, and it may be better not to rely on it too much. Just my 2 cents, -- Marcin Borkowski http://mbork.pl
Re: equal syntax highlighting for publishing code blocks to html and pdf
Hi Johannes, Johannes Brauer writes: > Frequently I publish org-mode documents containing source code blocks > to html (htmlize) and pdf (minted). I would like to see the same > colors in both export types. But > I cannot figure out, what’s the best way to achieve this. > > Has anyone solved this problem? Are there any hints? I don't know how to do this and I guess it's difficult. If you find a solution, please mention it here, others may be interested. Thanks! -- Bastien
Re: Format of Effort estimates should be mentioned in its Info node
Hi Kisaragi Hiu, Kisaragi Hiu writes: > Currently, the Info node about effort estimates does not mention what > format should it be written in. This causes confusion, as a user might > assume that it's the same format as schedulers (10m, 6h, etc.) like I > did. > > Simply mentioning "Effort estimates need to have the format H:MM" > (copied from the docstring or org-effort-property, the only* > description of the format I could find) in the Info node would be > enough. Yes. Can you submit a patch against doc/org-manual.org? Thanks! -- Bastien
Re: [PATCH] Fix `org-babel-detangle' handling of false positives
Hi Kevin, this looks good. The patch is significant enough that we need you to sign the FSF copyright assignment papers. Here is the form: https://code.orgmode.org/bzg/org-mode/raw/master/request-assign-future.txt Once you're done with this, we can push your commit. Should you contribute more, we can give you push access. Some comments below: Foley writes: > This patch fixes the way `org-babel-detangle' handles false positive > matches for links. Without the patch it tries to use match data that > may not be present in a false positive. I've also included a regression > test. > > This is my first contribution to Org Mode or Emacs and my first patch > by mailing list so please let me know if I've overlooked anything. > > Also note I have not assigned copyright to FSF at this time, however I > believe this change should be small enough to not require it. > > Kevin Foley > > From 82e2d108536101c5a5ff9f8a0009051e5a308a3a Mon Sep 17 00:00:00 2001 > From: "Kevin J. Foley" > Date: Tue, 28 Jan 2020 17:51:29 -0500 > Subject: [PATCH] Fix `org-babel-detangle' handling of false positives > > * lisp/ob-tangle.el (org-babel-detangle): Handle false positive > matches of `org-link-bracket-re' ^ There should be a "." at the end of sentences in changelog entries. > * testing/examples/babel.el: New file for babel detangle false > positive test ^ Same here. > * testing/examples/babel.org (detangle): Add detangle/false positive > example ^ And here. > * testing/lisp/test-ob-tangle.el (ob-tangle/detangle-false-positive): > Add test for detangle false positive ^ And here. > TINYCHANGE Well, there are more than 15 lines of changes. Signing the FSF papers will allow you to submit more changes later. Thanks! -- Bastien
Re: Bug: org-mks case insensitive search breaks org-capture-templates groups [9.3.1 (release_9.3.1-108-gebf8b3 @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]
Hi, thanks for the report. I applied the patch under your name as a TINYCHANGE. Best, -- Bastien
Re: a wide column problem
Hi Jude, Jude DaShiell writes: > For a table with a wide column can org-mode use a width on the column as > well as word wrap? What did you try? Can you show how it should look like? -- Bastien
Re: A few changes to test in master
Samuel Wales writes: > org-table-header-line-mode? That's indeed better - I pushed the change. Thanks to both of you! -- Bastien
Re: C-c C-c to close the buffer in *Org Src ...* buffers
Thanks Charles, Matt and Eric for your feedback. I'd rather stick to the current keybindings for now, let's resist the temptation to supercharge `C-c C-c'. -- Bastien
Re: Delay all occurences for a heading scheduled with repeater not work.
Hi, h...@protonmail.com writes: > In https://orgmode.org/manual/Deadlines-and-Scheduling.html# > Deadlines-and-Scheduling > > It says: > "If you want to delay the display of this task in the agenda, use > ‘SCHEDULED: <2004-12-25 Sat -2d>’: the task is still scheduled on the > 25th but will appear two days later. In case the task contains a > repeater, the delay is considered to affect all occurrences; if you > want the delay to only affect the first scheduled occurrence of the > task, use ‘--2d’ instead." > > With headings below: > * delay in scheduled with repeater > ** TODO delay all occurences >SCHEDULED: <2020-01-30 Thu -1d +2d> > ** TODO delay only the first occurence >SCHEDULED: <2020-01-30 Thu --1d +2d> > > Both headings display in today's agenda (today is <2020-01-31>). > Which is correct. > > Then both display in agenda of <2020-02-01>. > Which is not correct for 'delay all occurences'. > It should display in agenda of <2020-02-02>. > > Please help check if this should be fixed. Yes, this should be fixed and this is now fixed in the maint branch, it will be part of the next bugfix (if any) or major release. This was quite tricky to solve, please test it carefully. Thanks, -- Bastien
