Hi Stefan,
Stefan Monnier writes:
> The patch below gets rid of the old `defadvice`, replacing it with
> `advice-add`.
Applied in the main branch as 6d73cd34a, thanks a lot!
--
Bastien
Hello,
I am having an odd behavior with org-return. I use hard indents, and I have
set 'org-adapt-indentation' to t in my .emacs file. However, I have noticed
that sometimes when I press RET under a heading, instead of getting an
indent to match the indentation of the heading after the *'s, point
On 19 Dec 2021, Ihor Radchenko wrote:
Karl Fogel writes:
Should we just remove `org-truely-invisible-p'? Or at least
correct the spelling of its name ("truely" should be "truly")?
I feel slightly reluctant about removal. If nothing, this
function can
be a reminder about visible-mode and
> thank you. just an idle question. is it common/desirable for built
> in packages to use advice instead of hooks and such?
Desirable? no.
Common? kinda, yes, sadly.
It's usually good to look at the existing advice as "requests for hooks".
I haven't spent the energy to look at them this way,
thank you. just an idle question. is it common/desirable for built
in packages to use advice instead of hooks and such?
also, merely as a plea from a user, i hope defadvice will stick around
for all that user and non-built-in and abandoned code.
On 3/31/22, Stefan Monnier wrote:
> The patch
Max Nikulin writes:
> New calling convention for `encode-time' exists since emacs-27.1, so it is
> incompatible with yet supported emacs-26. It is unfortunate that sources in
> Org
> and in Emacs repository diverged, but I am unsure if it reasonable to
> introduce
> a new compatibility
The patch below gets rid of the old `defadvice`, replacing it with `advice-add`.
It also includes some FIXMEs about things I found along the way which
look suspicious (they're not directly related to the patch, tho, nor
are they affected by it AFAICT).
Stefan
2022-03-31 Stefan Monnier
On Thu, Mar 31, 2022 at 11:27 AM Max Nikulin wrote:
> >> Emphasis and bold markers may appear in plain text export. Behavior of
> >> styles is
> >> not uniform in respect to adding (unbreakable?) space before citation.
> >
> > Sorry; not following here again. Isn't the space before a
Confirmed
Emacs copy of Org changed the way of calling `encode-time' as a result
interpretation of last nils returned by `org-parse-string' altered from
ignored to "no DST".
Kyle, be aware of the conflict with `org-time-string-to-time' when you
will port emacs commit
>
> Ubuntu-20.04 LTS has emacs-26.3, so...
>
> Could you, please, try
>
> (encode-time '(0 0 23 29 3 2022 nil -1 nil))
> ^^^
Thanks. Using -1 as DST argument indeed fixes it.
However, while testing that, I've realized that I made a mistake in the
bug report.
> Ignacio Casso writes:
I can't reproduce this bug in Emacs 27.2.
>>> I'm on orgmode 9.4.6, with emacs 28.0.50.
Verified: This is fixed in the latest orgmode version (problem is gone in
9.5.2). It now clocks into different things without forgetting the rest of the
action after leaving the
On 29/03/2022 23:14, Bruce D'Arcus wrote:
On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote:
So it is not more general. Switching CSL style means necessity to update
styles in each citations (unless it is possible to specify global or
per-cite mapping).
Not really. Arguably the most
On 29/03/2022 20:09, Ignacio Casso wrote:
Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example:
1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3
2022 nil nil nil).
2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520)
in Emacs 27, but
13 matches
Mail list logo
