Thanks for the merge!
On Fri, Mar 15, 2024, at 17:38, Matt wrote:
> Finally had time to commit it.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0e2a9524dc6da8b4d60672e85aba74076baac211
>
> Nice catch and thanks for your contribution!
>
> --
> Matt Trzcinski
> Emacs Org cont
* lisp/ob-shell.el (org-babel-shell-initialize): Override
explicit-shell-file-name in addition to shell-file-name.
When a session with shell source blocks, execution calls `shell',
which checks `explicit-shell-file-name' variable before
`shell-file-name', to determine what shell to run. If the us
at should be OK then. Please see attached.
Thanks,
Aaron
0001-lisp-org-entities.el-Fix-safe-value-predicate-for-or.patch
Description: Binary data
> On Dec 12, 2023, at 21:01, Aaron Madlon-Kay wrote:
>
>> On Dec 12, 2023, at 20:40, Aaron Madlon-Kay wrote:
>>
>> Locally redefining as follows results in the expected behavior:
>
> The previous formulation was not very good. Actually it seems that the
&g
> On Dec 12, 2023, at 20:40, Aaron Madlon-Kay wrote:
>
> Locally redefining as follows results in the expected behavior:
The previous formulation was not very good. Actually it seems that the existing
function is correct except that the list case should be wrapped in (seq …).
(
t)
(_ nil)))
v))
The difference is that the current logic has been supplied as a lambda
to `seq-every-p`.
Thank you,
Aaron
Emacs : GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.1.0, NS
appkit-2487.20 Version 14.1.1 (Build 23B81))
of 2023-11-26
Package: Org mode version 9.6.11 (release_9.6.11 @
/Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)
Hi folks,
It seems there is a bad interaction between org-add-log-setup and
org-with-remote-undo, such that org-agenda-undo does not function
correctly. For example,
1. Enable logging on reschedule, by setting `org-log-reschedule' to
`time'.
2. Reschedule an already-scheduled TODO item throug
hijacker-command-100
With the patch, the above steps correctly insert f and then a newline.
>From 8ae98a51a15bdd4d4c2014e7870ab36afd03562d Mon Sep 17 00:00:00 2001
From: "Aaron L. Zeng"
Date: Mon, 3 Apr 2023 13:46:26 -0400
Subject: [PATCH 1/2] org-table: Refactor away unnecessary vari
Predicates like `org-first-sibling-p' are no use when called
interactively, and should not appear in the M-x prompt.
TINYCHANGE
---
lisp/org.el | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 23cb6012d..20e6ea6d9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@
New patch looks good. Thanks!
On Wed, Feb 8, 2023 at 05:09 Ihor Radchenko wrote:
> "Aaron L. Zeng" writes:
>
> > * org-agenda.el (org--batch-store-agenda-views): Fix treatment of
> > lambda functions used as custom agenda commands.
> > `org-agenda-custom-comm
Thanks Ihor, I sent a new patch with your comment included verbatim, and
also added a ChangeLog entry.
On Tue, Feb 7, 2023 at 12:47 PM Aaron L. Zeng wrote:
> * org-agenda.el (org--batch-store-agenda-views): Fix treatment of
> lambda functions used as custom agenda commands.
> `org-agen
* org-agenda.el (org--batch-store-agenda-views): Fix treatment of
lambda functions used as custom agenda commands.
`org-agenda-custom-commands' entries may specify a custom function
instead of a symbol like `tags-todo'. `org--batch-store-agenda-views'
behaved differently from `org-agenda' when tha
`org-agenda-custom-commands' entries may specify a custom function
instead of a symbol like `tags-todo'. `org--batch-store-agenda-views'
behaved differently from `org-agenda' when that custom function was
defined as a lambda rather than a symbol, incorrectly treating the
lambda form as a list of a
Much obliged :)
On Tue, Jan 24, 2023 at 1:20 PM Ihor Radchenko wrote:
> Aaron Zeng writes:
>
> > Hi Ihor, I just noticed that this patch only fixes one of the lines
> calling
> > `string-pad'. There is another callsite below which needs to be removed.
>
> Oops
Hi Ihor, I just noticed that this patch only fixes one of the lines calling
`string-pad'. There is another callsite below which needs to be removed.
On Tue, Jan 24, 2023 at 11:30 AM Aaron Zeng wrote:
> Thanks for the quick response, Ihor!
>
> On Tue, Jan 24, 2023 at 4:23 AM
Thanks for the quick response, Ihor!
On Tue, Jan 24, 2023 at 4:23 AM Ihor Radchenko wrote:
> "Aaron L. Zeng" writes:
>
> > * org-compat.el (org-string-pad): Add compatibility function
> > `org-string-pad' for `string-pad', introduced in Emacs 28.1.
> &
* org-compat.el (org-string-pad): Add compatibility function
`org-string-pad' for `string-pad', introduced in Emacs 28.1.
* org-agenda.el (org-fix-agenda-info): Use `org-string-pad' rather
than `string-pad'.
Since this is more-or-less just copying string-pad's definition from
subr-x.el, I think t
---
lisp/org-agenda.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 76f71e33e..021d36657 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2124,7 +2124,7 @@ argument to `set-category' for each entry it's called
agains
Thanks Ihor! And, noted for the future.
On Thu, May 26, 2022 at 12:34 AM Ihor Radchenko wrote:
> "Aaron L. Zeng" writes:
>
> > (I'm resubmitting this patch because my previous submission was
> in-reply-to
> > another email which I suspect was ignored.
(I'm resubmitting this patch because my previous submission was in-reply-to
another email which I suspect was ignored. Would love to get this relatively
simple bug fixed. Thanks!)
* lisp/org.el (org-todo-yesterday): Fix an incorrect use of apply when
org-todo-yesterday intends to call org-agenda
* lisp/org.el (org-todo-yesterday): Fix an incorrect use of apply when
org-todo-yesterday intends to call org-agenda-todo-yesterday with the
same interactive arg. Before this change, the command incorrectly set
the todo state of the task to blank when called with C-u C-u C-u in an
agenda buffer (s
0a073f0b0d7b0eb72f41e2edde4e070ca431ff71:
org-todo-yesterday: Fix interactive arg when in agenda buffer
(2022-03-18 23:31:37 -0400)
Aaron L. Zeng (1):
org-todo-yesterday: Fix interactive arg when in agenda buffer
lisp/org.el | 2 +-
1 file changed, 1
On Wed, Nov 17, 2021 at 7:03 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > Here's another on c47b535bb:
> >
> > https://gist.github.com/aaronjensen/348d879f79099c0d9b660bad199f25af
> >
> > I don't recall what I was doing at the time, i
On Sun, Nov 14, 2021 at 3:10 PM Aaron Jensen wrote:
>
> On Sun, Nov 14, 2021 at 3:00 AM Ihor Radchenko wrote:
> >
> > Aaron Jensen writes:
> >
> > > Another one:
> > > https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8
> > >
On Sun, Nov 14, 2021 at 3:00 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > Another one:
> > https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8
> >
> > I don't have the details of what I was doing in the time, sorry.
> >
Another one:
https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8
I don't have the details of what I was doing in the time, sorry.
I'm on: ded97b767 * main origin/main org-element.el: Fix regression
from d3836c1a1
Aaron
On Thu, Nov 4, 2021 at 10:11 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > I got a warning when I did an org-agenda-todo to mark something as done.
> >
> > https://gist.github.com/aaronjensen/163913c0937376c9699eaa71eaa0959a
>
> If I read the backtrace
On Wed, Nov 3, 2021 at 10:30 AM Aaron Jensen wrote:
>
> On Wed, Nov 3, 2021 at 7:43 AM Ihor Radchenko wrote:
> >
> > Aaron Jensen writes:
> >
> > > Here is a backtrace. The package it mentions is my own:
> > > https://github.com/aaronjensen/emacs-orgon
On Wed, Nov 3, 2021 at 7:43 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > Here is a backtrace. The package it mentions is my own:
> > https://github.com/aaronjensen/emacs-orgonomic and
> > https://github.com/Somelauw/evil-org-mode is mentioned too.
>
&g
Here is another that just happened:
https://gist.github.com/aaronjensen/5294a64f243a306b58062113b9306bab
It's scrubbed of all string data, hopefully not over-scrubbed for you.
Aaron
On Mon, Nov 1, 2021 at 8:48 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > On Sat, Oct 30, 2021 at 11:16 PM Aaron Jensen wrote:
> >>
> >> Done, I'll report back.
> >
> > Another one, no trace:
> >
> > Warning (emacs): Em
On Sat, Oct 30, 2021 at 11:16 PM Aaron Jensen wrote:
>
> Done, I'll report back.
Another one, no trace:
Warning (emacs): Emacs reader failed to read data for #:org-element--cache. The error was: "Invalid read syntax:
\"#\", 1, 4670" Disable showing Disable logging
On Sat, Oct 30, 2021 at 10:46 PM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> >> Do you always see "Current command: nil"? If you do, do you have any
> >> minor modes that change text in Org buffers?
> >
> > I don't know, but I&#
On Sat, Oct 30, 2021 at 12:45 PM Aaron Jensen wrote:
>
> On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote:
> >
> > Aaron Jensen writes:
> >
> > > I don't have a consistent repro, but I am seeing this error often. At
> > > different times it
On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > I don't have a consistent repro, but I am seeing this error often. At
> > different times it is in different files and lists different nodes.
>
> Thanks for reporting!
>
>
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
ing is at least functional again.
I'll probably try to learn more about debugging to see if I can pinpoint
the exact spot that's acting up but if anyone sees this again I think the
workaround should do fine.
All good things,
Aaron
On Sat, May 22, 2021 at 8:29 AM Ihor Radchenko wrote:
&g
M-x org-mode or open a new org file after the first one it works
just fine.
Is there perhaps a different set of windows binaries I should be using?
Or is there a way to run a stack trace on the entire emacs session?
It's not running into any actual error so debug isn't yielding anything.
any org file or even if I create a new file ending in .org.Any other ideas on how to get it working? All good things,Aaron
n infinite loop.
Thanks,
Aaron
e-set-variable` to enable
org-enforce-todo-checkbox-dependencies, with the following agenda
file:
* TODO blocked task
- [ ] checkbox
Trying to clock into the task from org-todo-list results in an infinite loop.
Thanks,
Aaron
* ol.el (org-link--open-help): Fix a confusing variable name. No
behavior changes.
TINYCHANGE
---
lisp/ol.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/ol.el b/lisp/ol.el
index 62ea6d2bc..617223cb5 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1325,8 +1325,8 @@ P
On Wed, Feb 17, 2021 at 9:55 AM Aaron Jensen wrote:
>
> The two `shell-command-to-string` invocations during eval are
> extremely slow. Users of Evernote should `org-mac-grab-Evernote-app-p`
> and `org-mac-evernote-path` explicitly.
Hi all,
Any chance of getting this merged in? I
The two `shell-command-to-string` invocations during eval are
extremely slow. Users of Evernote should `org-mac-grab-Evernote-app-p`
and `org-mac-evernote-path` explicitly.
* contrib/lisp/org-mac-link.el (org-mac-grab-Evernote-app-p): Default
to nil
(org-mac-evernote-path): Default to nil and add
On Sun, Jan 10, 2021 at 4:12 PM Kyle Meyer wrote:
> > * lisp/org-refile.el (org-copy): When argument added
>
> Thanks, but this was handled by 248dfcd71 earlier this week.
Ah, excellent!
* lisp/org-refile.el (org-copy): When argument added
---
lisp/org-refile.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 0b44fdfa5..47f22ecc0 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -373,7 +373,7 @@ the *old*
On Mon, Dec 14, 2020 at 5:00 AM Kyle Meyer wrote:
> Thanks. Pushed (57a70d505), tacking on a Reported-by trailer to the
> commit message.
Thanks very much! The fix is working for me.
-Aaron
ng only.
I'm not sure if it should be org-mode's responsibility to resolve the
actual command string, or if it should be done by
`run-ruby-or-pop-to-buffer'. (It kind of seems like the latter?)
Any thoughts?
-Aaron
Brilliant! Thanks very much!
-Aaron
On Sat, Oct 24, 2020 at 20:39 Bastien wrote:
> Hi Aaron,
>
> Aaron Madlon-Kay > writes:
>
> > Using the :ruby header arg.
>
> Applied, thanks!
>
> --
> Bastien
>
Using the :ruby header arg.
* lisp/ob-ruby.el (org-babel-execute:ruby): Locally set
`org-babel-ruby-command' using a header argument.
TINYCHANGE
---
lisp/ob-ruby.el | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
index 669c2eabf..80870c6c0 100644
---
hanks,
Aaron
On Tue, Jan 14, 2020 at 8:20 AM Fraga, Eric wrote:
>
> On Tuesday, 14 Jan 2020 at 07:21, Aaron Jensen wrote:
> > In one of my org files, I will occasionally see src blocks lose their
> > formatting. [...]
> >
> > Is this expected behavior? Is there a way to incre
itself is still visible, the src block will be fontified as
if it were regular text in org. I have org-src-fontify-natively. If I
scroll up so that #+begin_src is in view, it fontifies as expected.
Is this expected behavior? Is there a way to increase the lookback amount?
Thanks,
Aaron
Yes, I still see this with a vanilla config. I tried with [emacs -q] and
the builtin org mode (9.1.9), as well as with 967801.
On Mon, Jun 10, 2019 at 10:43 PM Kyle Meyer wrote:
> Aaron Zeng writes:
>
> > (I'm running org mode from the Spacemacs org layer, which includes
(I'm running org mode from the Spacemacs org layer, which includes the
org-plus-contrib package).
Reproduction:
1. Create a new entry "* TODO Temp"
2. Clock in under that entry
3. Cancel the clock
4. [M-x describe-variable org-clock-current-task] is still set to
"Temp" instead of being nil, which
On November 25, 2018 at 1:08:35 AM, Nicolas Goaziou
(m...@nicolasgoaziou.fr(mailto:m...@nicolasgoaziou.fr)) wrote:
> Hello,
> Applied.
> Fixed.
Thank you for the quick response!
Aaron
Hi all,
Brave is a chromium-based browser, so the existing Chrome code works
with slight modifications.
By the way, I’ve signed FSF papers though
https://orgmode.org/worg/org-contribute.html currently has me listed
in the wrong place.
Best,
Aaron
0001-org-mac-link-Add-support-for-Brave.patch
binding of functions at runtime,
and so it does some specialized things that cl-letf doesnʼt do. This in
turn means that it should be a more robust way of accomplishing the
desired outcome.)
--
Aaron Ecay
. My own opinion is that we can just
document and live with the situation until something much better comes
along. But I also donʼt want to stop you from implementing a small and
reasonable fix if you are motivated to do so. :)
--
Aaron Ecay
Hi Nicolas,
2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:
>
> Aaron Ecay writes:
>
>> Of course, done in c32938b7f. I did not realize how the freeze for 9.2
>> was working.
>
> Thank you.
>
> BTW, I'm considering creating a "next" bra
do-load-languages will not find it (because the file name
does not match). C++ is not a valid choice for the variable AFAICT. The
customize interface makes that clear by not offering it as an option, but
if the variable is customized outside of customize (so to speak...) chaos
reigns...
--
Aaron Ecay
Hi Nicolas,
2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:
>
> Hello,
>
> Aaron Ecay writes:
>
>> Iʼve pushed commit 1643f70d3 to master which documents this behavior.
>
> Thank you. Please have a look at the consistency edits I made to it.
Thanks very
foo-scripts I found it to be quite natural in
my testing. So I hope that we can discuss it (as an optional feature,
certainly) once 9.2 is out.
--
Aaron Ecay
of what is a reasonable non-back-compatible
> change.
Iʼm inclined not to make the change now, but (hopefully remember to)
revisit it when Org 10 is imminent.
Thanks for raising the issue,
--
Aaron Ecay
become visible for editing. It is
modeled after a similar feature in emacs built-in
prettify-symbols-mode.
So, I think that should address your usecase.
Thanks for raising the issue.
--
Aaron Ecay
ox-{hugo,blackfriday}.
And I do not think there are any other shortcomings in org core that are
left outstanding from this discussion.
Thanks again,
--
Aaron Ecay
+ "(\"s\" . \"src\")"
> + "See (info \"(org)org-structure-template-alist\")"
> + ""
> + "The following entries must be updated:"
> + ""
> + "%s"
> + "%s")
> + "\n")
You could use a multiline string literal. IMO itʼs less ugly (but
still ugly...)
--
Aaron Ecay
Hi Kaushal,
2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen:
> That's why I am using (org-element-property :attr_html special-block) in
> the code to get the raw values to #+attr_html.
Iʼm not sure I made myself clear in the previous message. In any case,
this org:
╭
│ #+attr_html: :open
case.
--
Aaron Ecay
crop up for other elements as well, such that it would be
desirable to support it in org core? (This is at least partly me
wondering out loud, no need to specifically answer unless something
particularly occurs to you one way or the other.)
--
Aaron Ecay
pen for details
More summary.
#+end_summary
Many details here.
#+end_details
=
Assuming there are no objections, we could make this tweak to
‘org-html-html5-elements’ in org core. I think “syntactic sugar” like
your original proposal could be implemented as a before-parsing-hook
that transforms th
.
Many details here.
#+end_details
This approach would require a supporing change to be made to the
‘org-html-keyword’ function.
Just food for thought...
--
Aaron Ecay
ead. Then we wouldnʼt have to worry about
the security implications of allowing non-atom values. It seems like a
version of this feature that only worked for atoms would be quite limited
in functionality. In that case, we should probably call the defcustom
above ...apply-unsafe-edit-bindings for the sake of accuracy.
--
Aaron Ecay
t some of this comes as useful advice.
--
Aaron Ecay
c
This silently skips varlist entries that are of the wrong shape, but it
would be possible to make it raise an error as in your version. I like
the pcase version better because itʼs shorter and has fewer nested
conditionals, but itʼs ultimately a matter of taste.
--
Aaron Ecay
kage-archives etc to make the
package-install call above work correctly. Maybe I was being
pessimistic about that, though.
--
Aaron Ecay
wouldnʼt have to
publish org-tempo on Org ELPA, only GNU ELPA. But this (a) doesnʼt help
those who install nightly org as opposed to nightly org-plus-contrib,
and (b) means that org-tempo, unlike other packages in contrib, would
have to be kept copyright-clean...so Iʼm not sure it is a good choice.)
feature request to
the emacs bug tracker, #31383)
--
Aaron Ecay
nge was from a cons of (character, template string) to a
cons of (string, template string). The relevant commit is b56df73.
--
Aaron Ecay
raries personally, so I donʼt know how
well they will work for you.
--
Aaron Ecay
and “C-c / v” for a variable
The template file corresponding to this is located at
$YOUR_EMACS_INSTALL_DIR/etc/srecode/el.srt.
Just as an aside, I have now also learned that emacs also includes
skeleton.el, which is yet a third template expansion library. Sigh.
--
Aaron Ecay
Hi Rasmus,
2018ko maiatzak 5an, Rasmus-ek idatzi zuen:
> I don’t like it, I’m afraid.
Iʼm sorry to hear that.
> It’s a bit nagging.
I wouldnʼt call it nagging. The user presses “ There’s tools to mark thinks as obsolete in Emacs should we need to.
There are tools to mark functions and vari
Variable Definitions").
--
Aaron Ecay
e best place for it eventually would be
org-contrib or GNU ELPA, and not org core. If that is decided now, then
we can include that information in the upgrade message (i.e. that users
who opt in to org-tempo will eventually have to install it specifically).
--
Aaron Ecay
>From 414503d59b2129c
gt; Also, what do you think about :edit-bindings or :edit-locals instead
> of :edit-vars? :var is a completely different thing, and :edit-vars
> may cause confusion, given the similarity of the name.
Agreed. I prefer -bindings, but I suppose itʼs not terribly important:
either of your proposed names is a big improvement.
--
Aaron Ecay
2018ko maiatzak 1an, Göktuğ Kayaalp-ek idatzi zuen:
>
> On 2018-05-01 20:35 +01, Aaron Ecay wrote:
>> Thinking about it some more, lexical binding is not a good case for
>> this feature, since it has to be set not only in the edit buffer, but
>> also when C-c C-c is use
is the major motivating factor, then maybe the above
is enough. My original suggestion was for something like:
#+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val))
...
#+end_src
This would set the variables in the edit buffer in the (hopefully)
obvious way. It is not i
I wouldnʼt see an impediment to
having it be part of org-contrib, though it could also be distributed
via (GNU/M)ELPA; it would be Göktuğʼs choice I guess.
Aaron
PS My view is the lexical-binding case is important enough that this
feature should be included in core, and that core should default to
vel that were quoted in your full message. To be specific,
this would entail (eventually) getting rid of the
org-structure-template-alist variable entirely, as well as the menu now
bound to C-c C-,; the former would be replaced by (AFAIUI) template
files that would be included with org and/or created by
ult
- Show a user warning whenever a “>From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001
From: Aaron Ecay
Date: Tue, 1 May 2018 15:32:36 +0100
Subject: [PATCH] Use minor-mode machinery for org-tempo
* lisp/org-tempo.el (org-tempo-mode):
(org-tempo-global-mode): New minor mo
Y-%m.org")
"* %?\nEntered on %U\n %i\n %a")))
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cb" 'org-iswitchb)
Any suggestions would be greatly appreciated!
Cheers,
Aaron
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
--
it will make maintenance much easier while (as you pointed out) still
leaving alternative solutions for recovering (most of) its
functionality.
--
Aaron Ecay
Hi all,
Does anyone know if it’s possible to create cross-references to sections in
org-mode that contain (or export as) both the section number and the link text?
For example:
* This is heading 1
** This is heading 1.1
* New heading
[[*This is heading 1.1]] # Outputs as 1.1
t the same table? Thanks!
Aaron
On Sun, Mar 19, 2017 at 3:58 PM, Nicolas Goaziou wrote:
> Hello,
>
> Applied. Thank you.
>
> I added TINYCHANGE at the end of the commit message since I don't know
> whether you signed FSF papers or not.
Thank you! I have not yet.
Aaron
This fixes the fontification error discussed here:
http://lists.gnu.org/archive/html/emacs-orgmode/2017-03/msg00423.html
and here:
http://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00280.html
---
lisp/org-src.el | 26 +-
1 file changed, 13 insertions(+), 13 dele
That appeared to fix it for me! Thanks.
>From cdf2c445e46d5691ee82adb1a6ca0bb0ae6bbd1b Mon Sep 17 00:00:00 2001
From: Aaron Jensen
Date: Sun, 19 Mar 2017 12:49:18 -0700
Subject: [PATCH] Reduce scope of inhibit-modification-hooks
This fixes a fontification error that some users were hav
This is in reply to the Fontification error Thomas S. Dye reported on
Feb 13 2017:
http://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00280.html
I was able to bisect this error to the following commit:
f2a5104e45b6f44a08960ae49ba20c124a8fa9d8 is the first bad commit
commit f2a5104e45b6f4
On Sat, Mar 11, 2017 at 7:54 AM, Aaron Jensen wrote:
> On Sat, Mar 11, 2017 at 7:53 AM, Aaron Jensen wrote:
>> $ git clone
>> g...@github.com:aaronjensen/org-mobile-push-breaks-org-agenda-ecm.git
>> ~/.emacs.d.old
>
> Sorry, this line was wrong, it should clo
1 - 100 of 617 matches
Mail list logo
