Re: (✿╹◡╹) there are always ways to go - Re: Sad tweet
I think he is the creator of the magit package. May 24, 2021 23:02:56 Jean Louis : > * Ypo [2021-05-24 00:30]: >> I've read this: >> >> "Contributing to Emacs is so frustrating. It's not worth it for minor things >> and if I cannot get some experience and confidence with minor things, then I >> likely won't ever make major contributions." >> https://twitter.com/magit_emacs/status/1396536686570610697?s=19 > > Alright, but no need for desperation. There is a way forward. > > Make your own package, see (info "(elisp) Packaging") > > As when you make your own package you are extending Emacs. > > Then apply the package to be included in GNU ELPA: > https://elpa.gnu.org on emacs-de...@gnu.org mailing list. > > That way you are contributing to GNU Emacs. > > Your package can improve some functions and thus get kudos from other > users. > > Then it becomes so much easier to point out to your improvements and > propose them to mainstream Emacs or Org mode. > > -- > Jean > > Take action in Free Software Foundation campaigns: > https://www.fsf.org/campaigns > > Sign an open letter in support of Richard M. Stallman > https://stallmansupport.org/
Re: misaligned tab and spaces in src block
Michael Dauer writes: > Hi, > > #+begin_src elisp :results output > (aaa > bbb ( > #x09#x09#x09ccc)) > ccc > #+end_src > looks like this in the editor > (aaa > bbb ( > ccc)) > ccc > > Line 1-3 were indented automatically by pressing Tab. In line 4 I inserted 6 > spaces manually. This is what I would expect to find in line 3 too. But at my > surprise there are 3 tab chars in line 3. Line 2 was indented automatically > with 1 space. > > 1. So why is line 3 indented with 3 tabs instead of 6 spaces? > 2. How can I prevent this? > 3. Why does a tab have a width between 1 and 2 spaces? > 4. How can I prevent this misalignment? > >I don't understand what org-block face has fixed-pitch. > > Org mode version 9.4.6 (9.4.6-gcf30f7 > (setq-default tab-width 2) > (setq org-src-fontify-natively t > org-src-window-setup 'current-window > org-src-strip-leading-and-trailing-blank-lines t > org-src-preserve-indentation t > org-src-tab-acts-natively t) > Are you editing the source block using org-edit-special (C-c ,)? If not, then you are not editing the source block with the correct syntax for elisp and this will throw out auto formatting. Your example block is invalid elisp code which is #+begin_src elisp :results output (aaa bbb ( #x09#x09#x09ccc)) ccc #+end_src but I don't see how you can get any output as it is not valid elisp. It is not clear to me what you are trying to do. You have 3 tab characters (#x09), so don't see why you would expect them to be spaces? If what you want is for hitting tab to insert only spaces, have a look at the variable indent-tab-mode. You can, for example, do (setq-default indent-tab-mode nil) to force use of spaces instead of tabs. However, be careful about doing this globally if you also want to contribute to projects where tabs are used as this will cause havoc with diffs and git. You can also set this on a per language (via mode hooks) or per project (via local variables). To get a better feel for how language modes align code etc, you really need to make sure the code you are trying to align is syntactically valid and you are using the correct coding style for the language. -- Tim Cross
Re: Empty headline titles unsupported: Bug?
Sebastian Miele writes: > Sebastian Miele writes: >> #+BEGIN_EXAMPLE >> ,* A >> ,* :B: >> ,* C >> #+END_EXAMPLE >> >> org-element-parse-buffer and org-match-sparse-tree make the second >> headline have title ":B:" and no tags. > > Currently org-syntax.org says that "TITLE can be made of any character > but a new line. Though, it will match after every other part have been > matched." This does not reflect the currently effective behavior that > "* :t:" is a headline with title ":t:" and no tags. Can you describe what should happen in a parser grammar (ie. BNF)? If not, I would tend toward rethinking the structure of the Org file so that it can be described in a grammar. Having a good grammar for Org files will promote it's acceptance beyond Emacs. -- David Masterson
Re: Quick help when pressing '?' in an agenda view?
* Nathaniel W Griswold [2021-05-24 15:08]: > I noticed that org-agenda-mode stands out in that '?' is not bound > to open some kind of help by default. Org agenda is unique in this, > it is the first out of many views i have used that did not have '?' > bound to open some kind of help. Seems to be convention in pretty > much anything builtin to emacs or added by third party that takes > over a buffer and interacts with the user. Some examples of builtin > are dired, list-buffers, ibuffer, list-bookmarks. You are right, that screen, but I find the Org export screen similar, is such static menu that just expects keybindings and nothing else. It is also in its meaning misrepresented as it is not just "agenda", the menu serves to search all of the Org files by any queries, not just for queries representing online planning. It gives difficulties to inspect itself by using standard Emacs keybindings like C-h k It would be good that Org agenda menu is displayed in Org buffer, but it is not... Example display: (define-derived-mode rcd-org-agenda-mode org-mode "RCD Org Agenda Mode" "Org Agenda in Org Mode") (define-key rcd-org-agenda-mode-map (kbd "q") 'quit-window) (define-key rcd-org-agenda-mode-map (kbd "m") 'org-tags-view) (defun rcd-org-agenda () "The RCD Org Agenda" (interactive) (let ((buffer-name "░▒▓▆▅▃▂▁ ORG AGENDA ▁▂▃▅▆▓▒░")) (switch-to-buffer (get-buffer-create buffer-name)) (setq header-line-format (concat buffer-name " ➜ finish with `q'")) (setq org-link-elisp-confirm-function nil) (read-only-mode 0) (erase-buffer) (insert buffer-name "\n") (center-line) (rcd-org-agenda-mode) (insert " 1. [[elisp:(org-agenda-list)][Org Agenda List]] - Display the agenda for current day or week. 2. [[elisp:(org-todo-list)][Org TODO List]] - Display the global TODO list. 3. [[elisp:(org-todo-list)][Org TODO List]] - Display the global todo list, select only entries with a specific TODO keyword (the user gets a prompt). 4. [[elisp:(org-tags-view)][Org Tags View]] - Display headlines with tags matching a condition (the user is prompted for the condition). ") (goto-char 0) (use-local-map rcd-org-agenda-mode-map))) > There hasn't been much discussion on the list about this, There was > brief discussion on the list about 'h' here: > https://orgmode.org/list/87v9b6qn23@gmail.com/. Maybe most > people don't really care about this. Do other people ever use '?' or > was that just me because i came from the vim world? It was something > that stood out to me when i first started using org-mode, so i > thought i would present it to the list as feedback data. I do use, that is not consistent with other Emacs key-style menus. The way to go is to adapt it for yourself. You need not use Org Agenda menu, it is anyway a menu that tries to do anything and everything. You may invoke specific function yourself or bind it to a key, such as `M-x org-agenda-list' > I didn't realize for a while that "C-h m" opens describe-mode by > default, and describe-mode is kinda what i wanted for my problems. I > had been opening the org info manual, taking a couple steps to > navigate to 'Agenda Commands', and referencing that. I then > bookmarked it because i was doing it so much. Maybe i was being > stupid but i was new to stuff and i think the '?' is intended for > people who are getting started and it would have helped me out > there. You are totally right, I find those design problems too including in the Org export mode. Each of the modes can be simply constructed as a non-blocking Org buffer that simply works both with keys and hyperlinks or mouse. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/
(✿╹◡╹) there are always ways to go - Re: Sad tweet
* Ypo [2021-05-24 00:30]: > I've read this: > > "Contributing to Emacs is so frustrating. It's not worth it for minor things > and if I cannot get some experience and confidence with minor things, then I > likely won't ever make major contributions." > https://twitter.com/magit_emacs/status/1396536686570610697?s=19 Alright, but no need for desperation. There is a way forward. Make your own package, see (info "(elisp) Packaging") As when you make your own package you are extending Emacs. Then apply the package to be included in GNU ELPA: https://elpa.gnu.org on emacs-de...@gnu.org mailing list. That way you are contributing to GNU Emacs. Your package can improve some functions and thus get kudos from other users. Then it becomes so much easier to point out to your improvements and propose them to mainstream Emacs or Org mode. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
On Mon, 24 May 2021 at 13:34, Bhavin Gandhi wrote: Yes, I have attached an updated patch. Looks good to me. Thank you! We are indeed aligned. The only additional thing I discovered was the reason `org-refile--get-location' works despite having double slashes. That was new for me. Great! Thanks for clearing that up too. Best, Gustavo.
BUG: eval macros not working anymore
at least not compatible with before.
Probably caused by commit 8abdbbee395f284f2262a89187d662eaf40080b1.
originally correct macro ("macroA" . "(eval
do-something-dynamically-at-macro-expansion)")
How should this be achieved now? (functionp "any-string") is nil
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
On Sun, 23 May 2021 at 23:53, Timothy wrote:
>
> Hi Bhavin! Great to see you on the mailing list :)
>
> Thank you so much for looking at the bugs, investigating one, /and/
> working out a fix. That's absolutely fantastic of you!
Thank you for a welcoming message! :)
On Mon, 24 May 2021 at 00:28, Gustavo Barros wrote:
>
> The patch looks good to me, and corresponds to my analysis of the
> problem and suggested fix. I have only one minor nitpick: you could go
> with a simple `let' there, instead of a `let*', since we only have one
> let-bound variable there anyway.
Yes, I have attached an updated patch.
> > [...] it has other details as well.
>
> As far as I could see, we are very much aligned on the problem and fix.
> But perhaps I'm missing something, could you elaborate on that?
We are indeed aligned. The only additional thing I discovered was
the reason `org-refile--get-location' works despite having double
slashes. That was new for me.
Just experimenting with Woof!
X-Woof-Patch: confirmed
From e069c35ff6011a7f9efe372e675a0bc43ba1fa80 Mon Sep 17 00:00:00 2001
From: Bhavin Gandhi
Date: Sun, 23 May 2021 23:07:13 +0530
Subject: [PATCH] org-refile: Fix double slashes in the refile targets
* org-refile.el (org-refile-get-location): When we generate the `tbl'
variable, we add extra slash depending on the value of
`org-refile-use-outline-path'. This patch updates some locations which
add another extra slash assuming the target did not have it.
`org-refile--get-location' does lookup for entries with and without
slash, so it was not causing any issues before. It works as it is now
as well.
Thanks to Gustavo Barros for a very detailed bug report.
TINYCHANGE
---
lisp/org-refile.el | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index bffad0a81..678759e10 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -649,20 +649,18 @@ this function appends the default value from
(setq old-hist org-refile-history)
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
- (or cdef (concat (car org-refile-history) extra
+ (or cdef (car org-refile-history
(if (setq pa (org-refile--get-location answ tbl))
- (let* ((last-refile-loc (car org-refile-history))
- (last-refile-loc-path (concat last-refile-loc extra)))
+ (let ((last-refile-loc (car org-refile-history)))
(org-refile-check-position pa)
(when (or (not org-refile-history)
(not (eq old-hist org-refile-history))
- (not (equal (car pa) last-refile-loc-path)))
+ (not (equal (car pa) last-refile-loc)))
(setq org-refile-history
(cons (car pa) (if (assoc last-refile-loc tbl)
org-refile-history
(cdr org-refile-history
- (when (or (equal last-refile-loc-path (nth 1 org-refile-history))
- (equal last-refile-loc (nth 1 org-refile-history)))
+ (when (equal last-refile-loc (nth 1 org-refile-history))
(pop org-refile-history)))
pa)
(if (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
--
2.31.1
misaligned tab and spaces in src block
Hi, #+begin_src elisp :results output (aaa bbb ( #x09#x09#x09ccc)) ccc #+end_src looks like this in the editor (aaa bbb ( ccc)) ccc Line 1-3 were indented automatically by pressing Tab. In line 4 I inserted 6 spaces manually. This is what I would expect to find in line 3 too. But at my surprise there are 3 tab chars in line 3. Line 2 was indented automatically with 1 space. 1. So why is line 3 indented with 3 tabs instead of 6 spaces? 2. How can I prevent this? 3. Why does a tab have a width between 1 and 2 spaces? 4. How can I prevent this misalignment? org-block face has fixed-pitch. Org mode version 9.4.6 (9.4.6-gcf30f7 (setq-default tab-width 2) (setq org-src-fontify-natively t org-src-window-setup 'current-window org-src-strip-leading-and-trailing-blank-lines t org-src-preserve-indentation t org-src-tab-acts-natively t) Thanks, Michael
Problem inserting meeting in agenda using "pm" time indicators
Hello all,
In the past, I have been able to insert new entries in the diary file
using am/pm times, e.g. "2pm-3pm An entry", using "i d" in the agenda
view.
When I try this now, with org up to date from git, I get this backtrace:
,
| Debugger entered--Lisp error: (error "Invalid duration format: \"3pm\"")
| error("Invalid duration format: %S" "3pm")
| org-duration-to-minutes("3pm")
| org-agenda-format-item(nil "2pm-3pm testing" nil nil nil t)
| org-agenda-add-entry-to-org-agenda-diary-file(day "2pm-3pm testing" (6 28
2021))
| org-agenda-diary-entry-in-org-file()
| org-agenda-diary-entry()
| funcall-interactively(org-agenda-diary-entry)
| command-execute(org-agenda-diary-entry)
`
If I represent the times using 24 hour clock, e.g. 14:00-15:00, it works
fine.
I know that there has been some ongoing discussion on durations etc. on
the list but I've not been tracking this. Is what I want to do no
longer allowed? I've looked at the ORG-NEWS file but did not see
anything.
Thank you,
eric
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-542-gf72a65
Re: sort “on-the-fly” in org-agenda-view
Sorry for the late reply. You can press M-up / M-down to manually sort agenda items once the agenda view is open. It's just a convenient way to do minor adjustments. No files are actually changed. On Mon, Apr 19, 2021 at 12:55 PM Ben Sima wrote: > Heh, I just found myself wanting to do this. I often use C-c ^ to sort > subtrees by creation date, and I wanted to do that with my global TODO > list just now, but couldn't figure out how. > > So, imo there is at least a small need for this feature. >
Re: reevaluating org-x11idle-exists-p with new org-clock-x11idle-program-name
Julien Cubizolles writes: > I'm using a custom python program to display x11 idle time. I've set > org-clock-x11idle-program-name accordingly but org-x11idle-exists-p is > still nil. I'm guessing it's defvar'ed in org-clock.el before > org-clock-x11idle-program-name is set. Evaluating the defvar of > org-x11idle-exists-p afterwards indeed sets it to t. > > I could do (setq org-x11idle-exists-p t) but there must be a better way > to handle the definition of a new org-clock-x11idle-program-name. How are you setting org-clock-x11idle-program-name? In your init file or via custom? Looking at the code, I would expect that provided org-clock-x11idle-program-name is set before you load org-clock.el, it should 'just work'. I think your right in your assumption it is not set before org-clock.el is loaded. The question is why is org-clock.el being loaded before you have set the program name? There are a few possible reasons, depending on whether your setting the program name with a setq in your init file, setting it via custom and whether you have altered when custom settings are loaded or where in your init file you load org. I would probably just put a (setq org-clock-x11idele-program-name ...) early in your init file to ensure it is set before org is loaded and all should then work. -- Tim Cross
Org-capture %K "Link to the currently clocked task" link with id?
> > On May 19, 2021, at 8:26 AM, Nathaniel W Griswold > wrote: > > Looking at the source (org-capture.el), it appears org-capture doesn't allow > you to make a permalink for "Link to the currently clocked task", or %K in > your template. > > I use (org-id-link-to-org-use-id t) because i like to be able to still follow > links after i archive stuff. I want that behavior here so i want the link to > an `id:` link instead of a `file:/path/to/file` link. Would a patch for this be welcome? Does anyone have any suggestions or ideas? I was thinking it should just respect current value of `org-id-link-to-org-use-id` but maybe there should be something more specific? Thanks! Nate
[PATCH] ox-latex.el: add LaTeX attributes to quote block
Hi all,
The `quote' block is exported to LaTeX as a `quote' environment.
However, standard LaTeX classes have two environments for quotes:
`quote' and `quotation', with certain format differences: it is often
said that `quotation' is intended for longer quotes with several
paragraphs and applies a first line indent to each paragraph. In
addition there are several very popular packages that offer more
environments and features for quoting, for example `quoting' or
`csquotes', which includes a set of quote environments and very powerful
options. Even some languages as Spanish option for Babel have their own
quoting environment. Given all this variety, I think it would be nice to
offer the user at least a couple of LaTeX attributes to choose:
`:environment' (by default the environment would remain `quote') and
`:options'. I attach a possible patch for it (if the patch sounds good,
I can add the documentation for the new features).
An example with a quote in German:
#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote
Best regards,
Juan Manuel
>From 1164c3066f0ea7e639382b01c5da2d7b5b46efb8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Mon, 24 May 2021 13:19:01 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el: add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
lisp/ox-latex.el | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..3704267c9 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+(:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' environment."
+ :group 'org-export-latex
+ :version "24.4"
+ :package-version '(Org . "8.0")
+ :type 'string)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,9 +2903,17 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let* ((env (org-export-read-attribute :attr_latex quote-block :environment))
+ (opt (org-export-read-attribute :attr_latex quote-block :options))
+ (current-env (if env env org-latex-default-quote-environment))
+ (current-opt (if opt opt "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ current-env
+ current-opt
+ contents
+ current-env)
+ info)))
Radio Target
--
2.26.0
Quick help when pressing '?' in an agenda view?
I noticed that org-agenda-mode stands out in that '?' is not bound to open some kind of help by default. Org agenda is unique in this, it is the first out of many views i have used that did not have '?' bound to open some kind of help. Seems to be convention in pretty much anything builtin to emacs or added by third party that takes over a buffer and interacts with the user. Some examples of builtin are dired, list-buffers, ibuffer, list-bookmarks. '?' is currently default `org-agenda-show-the-flagging-note`, i haven't used that quite yet. There hasn't been much discussion on the list about this, There was brief discussion on the list about 'h' here: https://orgmode.org/list/87v9b6qn23@gmail.com/. Maybe most people don't really care about this. Do other people ever use '?' or was that just me because i came from the vim world? It was something that stood out to me when i first started using org-mode, so i thought i would present it to the list as feedback data. I didn't realize for a while that "C-h m" opens describe-mode by default, and describe-mode is kinda what i wanted for my problems. I had been opening the org info manual, taking a couple steps to navigate to 'Agenda Commands', and referencing that. I then bookmarked it because i was doing it so much. Maybe i was being stupid but i was new to stuff and i think the '?' is intended for people who are getting started and it would have helped me out there. Anyway, just some thoughts. Thank you, everyone. Great work on the software. Nate
Re: Empty headline titles unsupported: Bug?
Ihor Radchenko writes: > Either way is fine while it is consistent. I just tried to test some > edge cases with existing org-element code: > > * TODO COMMENT :tag: > > org-element-at-point returns :raw-value "". > > * TODO :tag: > > :raw-value ":tag:" Concerning tags, it is the expected behavior according to org-syntax.org: "If the first word appearing in the title is “COMMENT”, the headline will be considered as “commented”." So the headline * TODO COMMENT :tag: is a headline with title "COMMENT" and tag "tag". The headline is not empty. However, according to org-element-api.org, the :raw-value should be "COMMENT". But this raises another question: In my opinion the apparently effective behavior of org-element (make the headline :commentedp, but do not actually include "COMMENT" in the title) is preferable. So I would prefer to change the spec (org-syntax.org) to reflect that.
Re: Empty headline titles unsupported: Bug?
Sebastian Miele writes: > #+BEGIN_EXAMPLE > ,* A > ,* :B: > ,* C > #+END_EXAMPLE > > org-element-parse-buffer and org-match-sparse-tree make the second > headline have title ":B:" and no tags. Currently org-syntax.org says that "TITLE can be made of any character but a new line. Though, it will match after every other part have been matched." This does not reflect the currently effective behavior that "* :t:" is a headline with title ":t:" and no tags.
Re: Empty headline titles unsupported: Bug?
Nicolas Goaziou writes: > You cannot distinguish the following two cases: > > * :mytag: > * :myheadline: In my opinion, the cleanest solution would be to allow not only tags specifications of one or more tags, but also the tags specification ":" of zero tags in the headline. Then in * :t: * :t: : the former would be a headline with empty title and tag "t", and the latter would be a headline with title ":t:" and not tags.
Re: declaring :var in a property drawer
Eric, > I would suggest it is intentional: setting a header property means it > applies to *all* src blocks. thanks. but, in this case, all source blocks are being tangled to the same file. which, for many (most?) languages (but not elisp), means the variable is going to be defined (and re-defined) at (the particular language's version of) global scope. which seems mostly redundant. that was what i was wondering about. cheers, Greg
Re: declaring :var in a property drawer
On Sunday, 23 May 2021 at 17:25, Greg Minshall wrote: > hi. i noticed the following behavior, and am curious if it is > intentional. I would suggest it is intentional: setting a header property means it applies to *all* src blocks. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd
reevaluating org-x11idle-exists-p with new org-clock-x11idle-program-name
I'm using a custom python program to display x11 idle time. I've set org-clock-x11idle-program-name accordingly but org-x11idle-exists-p is still nil. I'm guessing it's defvar'ed in org-clock.el before org-clock-x11idle-program-name is set. Evaluating the defvar of org-x11idle-exists-p afterwards indeed sets it to t. I could do (setq org-x11idle-exists-p t) but there must be a better way to handle the definition of a new org-clock-x11idle-program-name. -- Julien Cubizolles
Re: Sad tweet
(Took the liberty of CC'ing Jonas to make sure he can correct any mischaracterization, and to show our support, such as it is) band...@gnu.org writes: > Ypo writes: > >> I've read this: >> >> "Contributing to Emacs is so frustrating. It's not worth it for minor >> things and if I cannot get some experience and confidence with minor >> things, then I likely won't ever make major contributions." >> https://twitter.com/magit_emacs/status/1396536686570610697?s=19 > > Do you know if there is any more context around that? Did Jonas mention > any specific pain points around contributing to Emacs and/or concrete > things that he thinks could be improved? Last time I'd seen him post on > emacs-devel it seemed like things were going fairly smoothly with his > work on adding transient to Emacs(?). Given the timing, I'd hazard that this stems from bug#48592 (plus a few more past attempts that Jonas deems similarly fruitless, I assume). FWIW, to bounce off Amin's reply: Jonas, the patience you demonstrated in order to get transient in Emacs core was nothing short of saintly, and I for one am grateful for your perseverance. I understand how Emacs's development process can feel frustrating, especially in Jonas's position as maintainer of a popular package like Magit: 1. on the one hand, each and every attempt at contributing is met with varying degrees of skepticism and defiance, on the premise that you might e.g. break other people's code, disrupt other people's workflow… 2. on the other hand, upstream sometimes adds major features which impact your package, and you wake up to lots of disgruntled users expecting you to fix something you never saw coming; cf. :extend t, the tentative binding for C-x g… I don't necessarily view 1 nor 2 as inherently problematic: for 1, we're lucky to have maintainers looking out for breakage, although the line between "healthy conservatism" and "clinical sclerosis" is blurry; for 2, users of the development branch or the latest release should expect some measure of breakage in third-party packages. As a user, watching from the sidelines, the process "works": third-party additions slowly make their way upstream after some review and a generous coating of backward-compatibility/accessibility changes; on the flip side, bleeding-edge users warn third-party maintainers of upcoming changes which can then be amended before they make it into a release. Even so, as a third-party maintainer, I assume the combination of 1 and 2 feels like a "power imbalance": one party makes the other's life consistently harder. So, once more with feeling: thank you Jonas for your patience and your perserverance Disclaimer: I'm very much just a user, whose free time is mostly gobbled up catching up with the mailing lists. This reply is my interpretation of what I observe and may not be representative of anybody else's feelings on the subject.
