.html#copyright>?
>
Oh, I had completed the process on 2023-05-03, after my previous patch.
But yeah, I never told you. :)
Best,
Tim
prewarning (org-get-wdays
> > s
> > + (wdays (min max-wdays (org-get-wdays s
>
> warning-days
>
> > - (suppress-delay
> > + (max-ddays
>
> max-deadline-warning-days
>
Done.
Tim
From 145b2526882264985d497ee0940
Added a test.
> Please do not remove arguments from the public functions. This may
> break
> code outside Org mode.
>
Hm, sure, I assumed it's okay for this niche thing. Can we deprecate
the argument somehow?
Best,
Tim
From b886446be8ea02f38d9be6cccf6899d6de396d06 Mon Sep 17 00:00:
or delay period, but never extend it.
Best,
Tim
From 5db0ac7115b86a12d1a2106eb54b07d339f69ed6 Mon Sep 17 00:00:00 2001
From: Tim Ruffing
Date: Tue, 13 Feb 2024 10:57:29 +0100
Subject: [PATCH] org-agenda: Make sure skipping warning/delay days never
increases their number
* lisp/org-agenda.el (org-agen
---[end snip]---
But, when obsoleting `org-capture-bookmark', this problem is solved
anyhow: Bookmark creation can be fully controlled using the plist
variable (and only there).
So, I vote for obsoleting `org-capture-bookmark'.
Thanks again for your help!
Best regards,
Tim.
---[end snip]---
But, when obsoleting `org-capture-bookmark', this problem is solved
anyhow: Bookmark creation can be fully controlled using the plist
variable (and only there).
So, I vote for obsoleting `org-capture-bookmark'.
Thanks again for your help!
Best regards,
Tim.
it
superfluous, as the same behavior can be achieved by removing the
:last-capture keyword from the plist? (Note, moreover, that currently
the :last-capture-marker bookmark is created even in case
`org-capture-bookmark' is set to nil, see `org-refile'.)
Best regards,
Tim.
the documentation reads like users having had an is-
sue ("my Python code does not produce (correct) results")
and then someone feeling the need to document the solution
right then and there. IMNSHO this leads to documentation
that is not very usable for the general audience.
Tim
formatting.) In the end, this
works very nicely.
Thanks!
Tim
the add-hook call, but in the interactive capture buffer is
nil again (and no message is printed in *Messages*).
How can I evaluate Lisp code after all prompts have been
answered?
TIA,
Tim
(*1) I would prefer not doing this, as in this case I
could not see the result prior to finalizing.
s so that they are evaluated in sequence, being able
to refer to the output of previous commands? Are there any
obvious collections of examples that I missed?
TIA,
Tim
On Fri, Jun 23, 2023 at 6:53 AM Ihor Radchenko wrote:
> Tim Visher writes:
>
> > I've attached a small follow up `worg` patch to hopefully clarify the
> > changelog section of the commit message going forward for other
> > contributors.
>
> Thanks!
> Applied, on
On Thu, Jun 22, 2023 at 6:13 AM Ihor Radchenko wrote:
> Tim Visher writes:
>
> > Will do! I've attached a prospective patch file but I'm not sure I follow
> > what you mean by 'add all the necessary changelog entries to the final
> > commit
> > message'. Lookin
On Wed, Jun 21, 2023 at 11:54 AM Ihor Radchenko wrote:
> Tim Visher writes:
>
> >> Also, may you update the docstring of `org-capture-templates'
> >
> >
> > Good catch! This has been done in patch 0004 now. Look good?
>
> Yup.
>
>> &q
On Wed, Jun 21, 2023 at 6:29 AM Ihor Radchenko wrote:
> Tim Visher writes:
>
> > I've now created patches for updating the manual and NEWS file. Let me
> know
> > how they look!
>
> Thanks! The patches look good, and the commit messages look excellent.
>
٩( ᐛ )و
On Fri, May 12, 2023 at 12:32 PM Ihor Radchenko wrote:
> Tim Visher writes:
>
> > I think this should likely involve an update to the manual but I don't
> want
> > to bother doing that unless the basic approach is approved.
>
> LGTM.
>
Sorry this took me foreve
Hi Everyone,
I think this should likely involve an update to the manual but I don't want
to bother doing that unless the basic approach is approved.
-
>From eccc3f8f805c38b1de55fc8ad60c67a87e2feea4 Mon Sep 17 00:00:00 2001
From: Tim Visher
Date: Fri, 12 May 2023 11:32:21 -0400
Subj
On Fri, May 12, 2023 at 8:05 AM Ihor Radchenko wrote:
> Tim Visher writes:
> > Can `org-capture` templates be made to result in a sub-heading of the
> > current heading?
>
> Just use target `here' (as symbol).
>
Thanks for the suggestion, Ihor.
Do you have an example
On Thu, May 11, 2023 at 9:05 AM Tim Visher wrote:
> On Thu, May 11, 2023 at 8:42 AM Tim Visher wrote:
>
>> On Wed, May 10, 2023 at 5:04 PM Tim Visher wrote:
>>
>>> Can `org-capture` templates be made to result in a sub-heading of the
>>> current heading?
&g
On Thu, May 11, 2023 at 8:42 AM Tim Visher wrote:
> On Wed, May 10, 2023 at 5:04 PM Tim Visher wrote:
>
>> Can `org-capture` templates be made to result in a sub-heading of the
>> current heading?
>>
>> So
>>
>> ```
>> * This Week
>&
On Wed, May 10, 2023 at 5:04 PM Tim Visher wrote:
> Can `org-capture` templates be made to result in a sub-heading of the
> current heading?
>
> So
>
> ```
> * This Week
> ** TODO A TODO Item
>
>[2023-05-05 Fri 10:47]
>
>A description
> ```
>
]
A description
*** [2023-05-10 Wed 17:02]
[2023-05-10 Wed 17:02]
```
I have a tendency to make these items for longer running tasks that I want
to keep a journal on. The visibility cycling makes it easier to see my
progress over time.
Thanks in advance!
-- Tim Visher
sers to have customized.
Tim
With the Org file:
| #+BEGIN_SRC python :results silent :exports results
| test = '1'
| with open('test-a.log', 'w') as f:
| f.write(f'Test {test}a\n')
| with open('test-b.log', 'w') as f:
| f.write(f'Test {test}b\n')
| #+END_SRC
| Test, part A:
| #+INCLUDE: "test-a.log"
git send-email properly...
Tim
On Fri, 2023-03-10 at 19:32 +0700, Max Nikulin wrote:
> On 10/03/2023 18:48, Ihor Radchenko wrote:
> > Tim Ruffing writes:
> >
> > > * org-agenda.el (org-prepare-agenda): Don't reset
> > > `org-todo-keywords-for-agenda' when org-a
-todo-keywords-for-agenda and
(org-done-keywords-for-agenda) are not nil.
Best,
Tim
On Fri, 2023-03-10 at 11:48 +, Ihor Radchenko wrote:
> Tim Ruffing writes:
>
> > * org-agenda.el (org-prepare-agenda): Don't reset
> > `org-todo-keywords-for-agenda' when org-agenda-mul
y, and "++" is relative to the
default date. That's exactly what's promised
in https://orgmode.org/manual/The-date_002ftime-prompt.html and also in
the `org-read-date` doctring. (And I think it makes sense.)
Best,
Tim
* org-agenda.el (org-prepare-agenda): Don't reset
`org-todo-keywords-for-agenda' when org-agenda-multi.
Fixes a bug with TODO keywords that came to light in org-modern,
see https://github.com/minad/org-modern/issues/26.
This is very similar to cd2d138883a55cad48394a3f473da8b973a99a5e,
which
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> On 27/12/2022 16:47, Ihor Radchenko wrote:
>>> Can you then try to test using Emacs 28?
>>> The main question if whether this has been fixed in newer Emacs releases
>>> or it is also something to do with OS environment.
>>
>> I see quite the
Ihor Radchenko writes:
> Tim Cross writes:
>
>>> Either I understand you wrong, or you don't know what you are
>>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>>> points in time, thus it /is/ ambiguous. If you use disambiguating
>>&
writes:
> [[PGP Signed Part:Undecided]]
> On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
>> * Ihor Radchenko [2023-01-31 16:46]:
>> > Specifying just @Europe/Berlin is ambiguous around the daylight savings
>> > transition.
>>
>> Sorry, I cannot see practical example why is it
Andreas Röhler writes:
> Hi,
>
> when taking notes in plain org-mode, run into trouble for instance with this
> scala-snippet:
>
> def scalaFiles =
> for {
> file <- filesHere
> if file.getName.endsWith(".scala")
> } yield file
>
> With cursor on lesser-than sign, get a
Ihor Radchenko writes:
> Greg Minshall writes:
>
>> just a thought/reminder. there are "semantics" and "encoding". a spec
>> like ISO-8601 specifies both. the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2.
Jean Louis writes:
> * Tim Cross [2023-01-29 23:38]:
>> Saying that an offset is a fixed value is very different from saying
>> that a time zone has a fixed offset. I think this is where your
>> confusion is coming from.
>
> I said neither of those. I never said tha
Jean Louis writes:
> * Tim Cross [2023-01-28 00:15]:
>> >
>> >> What kinds of representations would a calendar system capable of
>> >> handling timezones require?
>> >>
>> >> • Instant (fixed)
>> >> • This is referring t
"Thomas S. Dye" writes:
> No, I don't think you've missed anything significant. Thanks very much for
> your patience
> during a discussion that was interesting for me. I learned quite a bit from
> you and the
> other contributors to the thread and look forward now to learning how Org
> mode
Jean Louis writes:
> * Sterling Hooten [2023-01-27 09:06]:
>> Offset
>> Constant duration difference between times of two time scales
>> (ISO). i.e., a quantity to combine with a time scale to produce
>> a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
>>
Ihor Radchenko writes:
> First of all, thanks for the detailed suggestion!
> I will need more time to look through the provided links and think about
> the ideas.
>
> I will provide one important consideration you missed in the below comment.
>
> Sterling Hooten writes:
>
>> What format and
Bastien Guerry writes:
> Hi Ihor,
>
> Ihor Radchenko writes:
>
>> I have recently been contacted by the current compat.el maintainer
>> asking if we are willing to adapt compat.el in Org.
>
> Very nice!
>
>> WDYT?
>
> As long as we keep our promise in terms of backward compatibility with
>
Ihor Radchenko writes:
> Tim Cross writes:
>
>> 3. There is no requirement to install non-free software to use
>> ob-sql.el. The software is fully functional using a free RDMS like
>> postgres.
>
> Yes, but there is requirement to install in order to use ob-sql.
Ihor Radchenko writes:
> Tim Cross writes:
>
>> to be very clear, ob-sql is not adding any NEW interface to any external
>> program. It is just using the Emacs built-in SQL library (Elisp), which
>> has been part of Emacs for a long time (I was using it in late 90s to
Richard Stallman writes:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > Would someone please tell me more
Max Nikulin writes:
> On 22/01/2023 14:48, Tim Cross wrote:
>> Timestamp for a log
>> record I would probably want or one of the
>> variants because the most common way I use those types of timestamp is
>> in diagnosing problems and comparing revords from various loca
I just wanted to provide some additional information which RMS may find
informative.
Under the hood, ob-sql.el is using the built-in Emacs sql.el library. It
is this library which provides the 'support' for various SQL database
engines. That support has been part of the sql library since it was
Max Nikulin writes:
> On 22/01/2023 04:29, Tim Cross wrote:
>> Max Nikulin writes:
>>> - UTC is a recommendation for planning when participants are scattered over
>>> multiple
>>> timezones.
>>> - You admit that some timestamps in your files
Max Nikulin writes:
> On 21/01/2023 06:38, Tim Cross wrote:
>> - Use UTC for meetings which are not face-to-face and which involve
>>people form different time zones.
>
> I agree with you that it should considered as first option by whose who are
> planning an
> e
t when it's taken from an existing timestamp.
A similar issue when capturing has been reported and fixed here:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg00056.html
(Please include me in CC for now, I haven't subscribed to mailing
list.)
Best,
Tim
PS: Thanks for org-mode. It has my changed my life.
"Thomas S. Dye" writes:
> Aloha Max,
>
> Max Nikulin writes:
>
>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>> Max Nikulin writes:
>>> Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before
>>> the
>>> conference takes place,
>>> then everyone who participates in the
Max Nikulin writes:
> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to distinguish the
>> case where the times need to be adjusted and local tz when they don't
>> won't work a a mechanism that can be used to allow org to handle
Max Nikulin writes:
> On 20/01/2023 15:11, Tim Cross wrote:
>> Max Nikulin writes:
>>
>>> Tim, I am trying to say that any meeting either face to face or on-line may
>>> be associated
>>> with arbitrary primary timezone.
>> and what you are
Daryl Manning writes:
> Perhaps a leading question (leading to outrage =p ), but does anybody even
> use those anymore?
>
> I don't believe I've used them at all in 5 years of using org-mode (and if I
> did it was most likely because of
> some arcane older feature which required them).
>
>
"Thomas S. Dye" writes:
> Aloha Max,
>
> Max Nikulin writes:
>
>> On 20/01/2023 03:09, Tim Cross wrote:
>>> To reiterate for the last time, there are 2 clear and different use
>>> cases for timestamps associated with meetings.
>>> 1. A mee
Max Nikulin writes:
> On 20/01/2023 12:39, Tim Cross wrote:
>> No, I disagree with that statement. That is old thinking based when
>> meetings meant face to face meetings. Only meeting which have a specific
>> location can have a time zone and even then, it isn't really the
Max Nikulin writes:
> On 20/01/2023 03:09, Tim Cross wrote:
>> To reiterate for the last time, there are 2 clear and different use
>> cases for timestamps associated with meetings.
>> 1. A meeting timestamp for a meeting where all the participants are in
>> t
"Thomas S. Dye" writes:
> Aloha Tim,
>
> Tim Cross writes:
>
>> "Thomas S. Dye" writes:
>>
>>> Aloha Tim,
>>>
>>>> UTC is a time zone - just one where offset is +
>>>
>>> UTC is absolute time.
"Thomas S. Dye" writes:
> Aloha Tim,
>
>> UTC is a time zone - just one where offset is +
>
> UTC is absolute time. It lacks the spatial component that defines a time
> zone.
>
Really? I would have thought the prime meridian was the spacial
component for
Jean Louis writes:
> * Tim Cross [2023-01-19 10:48]:
>> You completely misunderstood the specific issue being discussed. You
>> clearly have not been following this specific point being discussed and
>> your long reply just confuses matters rather than helps.
>>
Jean Louis writes:
> * Tim Cross [2023-01-19 00:31]:
>> The problem is with meeting 2 and the assumption there is a definitive
>> timezone for the meeting.
>>
>> Consider this scenario. I have a meeting with two other people. We are
>> all in differe
Ihor Radchenko writes:
> Jean Louis writes:
>
>> ...
>> Should be part of C library to observe those things.
>
> Sure. My previous proposals are all relying on `encode-time' which uses
> time.h from system libraries and utilizing TZDB that is taking care
> about all this insanity.
>
> We,
Ihor Radchenko writes:
> Tim Cross writes:
>
>>> Does it sound good enough?
>>
>> No, I'm afraid not. How does org distinguish between meeting 1 and
>> meeting 2? IN meeting one, when the timezone transitions in/out of
>> daylight savings, nothing
Ihor Radchenko writes:
> Tim Cross writes:
>
>>> Could you please elaborate here?
>>
>> I have some meetings scheduled in my org files which show up in the
>> agenda.
>>
>> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
Ihor Radchenko writes:
> Daniel Kraus writes:
>
>> Tim Cross writes:
>>
>>> I think you run a high risk of running into GNU policy issues wrt
>>> licensing and free software support given this is a cleint for an AWS
>>> only database.
>&g
Ihor Radchenko writes:
> Tim Cross writes:
>
>> It also seems that the solution will need some mechanism (possibly on a
>> per time stamp basis) for the user to specify what should happen when
>> either the time zone has a daylight savings transition, when the
>>
Daryl Manning writes:
> I'd argue that setting a specific datestamp and time for DST would mean that
> you expected to meet at that
> specific time and date as per DST. If the clocks changed you'd be out of luck
> (that's where I'd argue you'd
> use a non-specified timezone for a meeting that
Ihor Radchenko writes:
> Daniel Kraus writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
Ihor Radchenko writes:
> Tom Gillespie writes:
>
>
>> I will note that this doesn't address the issue of syntax for
>> historical and future dates. For historical dates those almost always
>> require significant additional metadata to compensate for things like
>> the julian/gregorian calendar
Daryl Manning writes:
> I think timezone you're in should be declared globally, surely? And then
> defined in the timestamp?
>
Do you mean globally as in at the OS level or globally in org mode. If
the latter, I disagree. The OS has this information and there is no need
for org to repeat it
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Unfortunately, the common abbreviated forms like EST, AEST etc are
>> inconsistent here. Some places will have a standard and a daylight
>> savings type i.e. AEST and AEDT, while others will have just AEST. TO
>>
Max Nikulin writes:
> On 15/01/2023 03:30, Tim Cross wrote:
>> The UTC time stays the same, but the
>> meeting time for me changes twice per year (moving forward/backward an
>> hour).
>
> Meeting time remains the same expressed as local time (15:00), but alternates
George Mauer writes:
> I had a need the other day to execute some typescript in an org document. Now
> I know that there's an
> ob-typescript package but that doesn't quite work the way I want and expects
> typescript to be installed
> globally (which runs into a variety of versioning issues).
Ihor Radchenko writes:
> to...@tuxteam.de writes:
>
>>> ... Having an
>>> ability to specify time zones manually will already cater needs for a
>>> number of users.
>>
>> Definitely. But the time stamp (with time zone) in itself doesn't
>> carry enough context to actually decide that. It's even
to...@tuxteam.de writes:
> [[PGP Signed Part:Undecided]]
> On Sat, Jan 14, 2023 at 03:05:22PM +, Ihor Radchenko wrote:
>> writes:
>>
>> > Now there's still enough work for the applications to do: presentation,
>> > parsing, disambiguation, if necessary asking the user for help. Someone
>> >
Max Nikulin writes:
> On 14/01/2023 20:50, Tim Cross wrote:
>> I"m sorry, but I don't follow. The UTC time is the only time whihc is
>> not affected by daylight savings transitions, so is the only stable
>> metric. All the others are relative to that time but can chan
Max Nikulin writes:
> On 14/01/2023 20:08, Jean Louis wrote:
>> * Max Nikulin [2023-01-14 10:14]:
>>> Let's assume <2023-01-15 Sun 09:00 +1>
>>>
>>> It may be suitable for timestamps in the past, but future is more tricky.
>>> There is no problem if you are going to watch Lunar eclipse. However
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Daryl mentioned elsewhere in this thread that how hard this feature
>> would be depends largely on the available libraries for elisp with
>> respect to working with date/time values. Sadly, the available elisp
>
Max Nikulin writes:
> On 14/01/2023 16:32, Tim Cross wrote:
>> If org was to add TZ capabilities to timestamps, the underlying format
>> would have to be UTC.
> ...
>> can change based on various criteria, including political whims
>> (e.g. Australia eastern D
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I agree this would be a great feature to add. However, after having
>> looked at it in some detail, I realise that not only is it not a trivial
>> task, it is actually a very large and complex task and will require
Max Nikulin writes:
> On 14/01/2023 02:06, Jean Louis wrote:
>> This is good for review as related to PostgreSQL database:
>
> I agree that PostgreSQL is an example of good implementation of time-related
> calculations.
>
>>
Daryl Manning writes:
> Following on from thread at https://www.reddit.com/r/orgmode/comments/zrppqw/
>
> [First off, I just wanted to say thank you to everyone that works on
> org-mode. It is a wonder.]
>
> While I realize a few kicks at this can may have been taken, I wanted to
>
Ypo writes:
> Hi
>
> Orgmode is sometimes desperately slow on my PC:
>
> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100 Mhz
>
> (RAM)4,00 GB
>
> I am running Windows 10, everything I use works OK, but Orgmode.
>
> Do you think that if I install a Linux OS, Orgmode would run fast? Any OS
Leo Butler writes:
> On Fri, Jan 06 2023, Tim Cross wrote:
>
>> alain.coch...@unistra.fr writes:
>>
>>> Tim Cross writes on Thu 5 Jan 2023 09:43:
>>>
>>> > As a simple example, try increasing the font size and see what
>>> > happe
alain.coch...@unistra.fr writes:
> Tim Cross writes on Thu 5 Jan 2023 09:43:
>
> > As a simple example, try increasing the font size and see what
> > happens to the menus. Keep in mind that some users require a very
> > large font (for example, I use a 26 or 28 pt fo
alain.coch...@unistra.fr writes:
> Bastien Guerry writes on Wed 4 Jan 2023 11:21:
>
> > Strong +1 on working on Worg's styling.
> >
> > The task may be daunting, but we can also tackle it incrementally.
> >
> > >From memory, orgmode.org/worg is visited by ~30k persons each month,
> >
writes:
> My current solution is to convert ~code~ to code and
> =verbatim= to verbatim.
>
> In that case the user can decide himself how to render them. In my
> default CSS I would render the ~code~ in monospace with a light gray
> background (different from the whole page background) and
writes:
> Hi,
>
> in org you can have inline verbatim and code text elements like this.
>
> Example with =verbatim= and ~code~.
>
> I would like to understand what "verbatim" really means. What is the
> semantic behind it? What content should go in there?
>
>
> I'm aware of the separation
Ihor Radchenko writes:
> Tim Cross writes:
>
>> First step is to get a working local copy so that I have something to
>> work with. AFter that and a bit of exploring, I should have a better
>> understanding and idea how to go forward.
>
> Hi Tim,
>
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>> P.S. Considering intense discussion around the topic, what about
>> reverting my commit from the release? We can then re-consider the whole
>> design and apply something more elaborate later.
>
> I now reverted the discussed commit.
>
Ihor Radchenko writes:
> As Max proposed, it may be a good idea to extend the concept of org-lint
> to export.
>
> We may unify the LaTeX errors, some errors/warnings potentially signalled
> by export backend, and maybe some warnings from org-lint during the
> export process. These errors can
Max Nikulin writes:
> On 22/12/2022 19:34, Ruijie Yu wrote:
>> One possible approach to this is to have all org-persist related
>> temporary directories into an overall "$TMPDIR/org-persist" directory.
>
> Predictable name in a "world" writable directory generally is not a good
> idea.
Ihor Radchenko writes:
> "Fraga, Eric" writes:
>
>> for some reason, I am now getting many (tens) directories of the form
>> org-persist-NN in /tmp. These seem to include an index file and a
>> cache type sub-directory structure. Why are these there and does
>> anything clean them up?
Karthik Chikmagalur writes:
> Hi,
>
> I'm trying to work on the main branch of Org, with the intent of creating a
> patch.
> However, I need to continue using Org 9.5 for everyday work in a separate
> Emacs session as
> I can't have things breaking. Is there a recommended way to run two
>
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Based on the information in section 17.13, how do I configure my Emacs
>> so that
>>
>> 1. All the code in the files I wrote just runs and doesn't bother me with
>> annoying execute questions.
>>
&g
Timothy writes:
> Hi Max,
>
>> Notice emacs-25.1 in the elpa package description:
>
> Yea, I’m pretty sure this is just an oversight. This should be bumped to 26.
>
Yep, that would be my assumption as well. Support is for the two
previous releases i.e. 27.x and 26.x.
Tom Gillespie writes:
> Treating src blocks missing a lang as paragraphs is
> incorrect because according to the syntax spec they
> are syntactically still blocks (greater or lesser depending
> on your inclinations).
>
> I think the general principle we want to follow here is
> that a block
Sharon Kimble writes:
> I unfortunately upgraded this morning to emacs-30.0.50, and since then I
> can't get into my usual emacs of 29.0.50.
>
> When I'm loading emacs-29.0.50 from /usr/local/bin/ it is consistently
> failing to load
> saying "Symbol's function definition is void:
Jean Louis writes:
> * Ihor Radchenko [2022-12-17 12:59]:
>> The error looks like you attempted to run `org-heading-components' in
>> non-Org buffer. `org-heading-components' behaviour in non-Org buffers is
>> undefined.
>
> OK I can change it for my personal use, however, consider that
>
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I do wonder if it would be a good idea to try and document when org will
>> evaluate code in org files. This would include not just babel block
>> evaluation, but also elisp evaluation in table formulas, block header
&
Max Nikulin writes:
> On 15/12/2022 19:25, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> I would consider reverting the commit causing user prompt for every
>>> variable.
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply
Max Nikulin writes:
> On 15/12/2022 16:31, Ihor Radchenko wrote:
>> The actual parser does allow empty lang in src blocks, setting :lang
>> element property to nil. Should we stop doing this and treat such src
>> blocks as paragraphs? Or should we allow empty lang and instead adapt
>> the
Anthony Carrico writes:
> I'm trying to remember what the old keybinding was before it got switched to
> 'C-c C-,'...
IIRC there wasn't one.
Previously, a completely different system was used for adding these
templates and it was bound to < (or was it >, I cannot remember).
The problem
1 - 100 of 1113 matches
Mail list logo
