Re: ts-down sorts between deadline-down and scheduled-down

[Samuel Wales]

actually:

ts-down
deadline-down
scheduled-down

results in output:

scheduled-down
deadlie-down
ts-down


On 6/19/23, Samuel Wales  wrote:
> if i put ts-down before deadline-down and scheduled-down, it shows up
> after deadline and before scheduled.
>
> ((agenda habit-down time-up tsia-down ts-down deadline-down
> scheduled-down category-up user-defined-up)
>  (todo category-up user-defined-up)
>  (tags category-up user-defined-up)
>  (search category-up user-defined-up))
>
> what i expect is before deadline.
>
> i am getting this in vanilla bugfix and main with my .emacs [canot do
> ecm atm].  vanilla 9.4 maint works correctly.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

ts-down sorts between deadline-down and scheduled-down

[Samuel Wales]

if i put ts-down before deadline-down and scheduled-down, it shows up
after deadline and before scheduled.

((agenda habit-down time-up tsia-down ts-down deadline-down
scheduled-down category-up user-defined-up)
 (todo category-up user-defined-up)
 (tags category-up user-defined-up)
 (search category-up user-defined-up))

what i expect is before deadline.

i am getting this in vanilla bugfix and main with my .emacs [canot do
ecm atm].  vanilla 9.4 maint works correctly.

How to tell `org-html-link' to create a link with some HTML class?

[Marcin Borkowski]

Dear Orgers,

as I mentioned some time ago, I'm writing a custom exporter (actually,
a very thin wrapper around the HTML exporter).  I'd like `org-html-link'
to add some class to the links it generates.  Is that possible?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: batch breaks bugfix

[Samuel Wales]

i don't do anything with visibility.  make test seems ok in bugfix.
but perhaps it does not generate a comprehensive agenda, in which case
maybe --batch would cause the bug.

what i am going to try to do is just remove --batch and lower the
frame and try to get bugfix to work like main.  this is more like
normal use.  but it would be good to know what the problem is with
--batch.


On 6/19/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> the bug occurs in recent bugfix, but not recent main, so perhaps we
>> could say that it is fixed in main but that the fix has not been
>> applied to bugfix?  [if only the fix were known.]
>
> Maybe.
>
>> does org testing use --batch?
>
> Yup.
> If you have time and interest, it would be useful if you can integrate
> your regression tests with Org's test suite.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Is this proper time format?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I used C-c C-a to attach my patch to the message for you.  I was looking
>> for the reverse to pull your patch out.  When I read the message, the
>> patch was inlined, so I wasn't seeing any buttons(?) to pull it out with
>> and the Mime command didn't seem to do anything, so I thought I was
>> looking in the wrong.  The patch showed in diff-mode.
>
> It may depend on what you are using to view the patch.  In notmuch,
> there is `notmuch-show-save-part' and `notmuch-save-attachments'.  In
> Gnus, there is `notmuch-show-save-part'.

Hmm.  I think notmuch is non-standard.  I was using gnus.

-- 
David Masterson

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Ihor Radchenko writes:


What about the following approach:

When converting from org-src buffer back to Org,

1. We do not touch the original indentation, except minimal common
indentation of the whole src code, respecting the src mode value of
`indent-tabs-mode'.
2. Minimal common indentation is treated according to
`org-src-preserve-indentation'.
3. `org-src-preserve-indentation', when in effect, will add extra
indentation of #+begin indentation + `org-src-preserve-indentation',
now honouring `indent-tabs-mode' in Org buffer.

When converting from Org to org-src buffer,

1. When `org-src-preserve-indentation' is in effect, remove the common
`org-src-preserve-indentation' + #+begin indentation from the body.


You've mixed up =org-src-preserve-indentation= and
=org-edit-src-content-indentation= so I may misunderstand. But I guess
what you propose amounts to

 1. When =org-src-preserve-indentation= is =t=, do not touch
indentation one way or the other (same as now).
 2. Otherwise, do what we do now, but for the common indentation in
the org buffer, use the org value of =indent-tabs-mode=, and for
the rest of the indentation, use the native value of
=indent-tabs-mode=. In this case, instead of trying to read this
value, we might as well just blindly add the common indentation,
to every non empty line.




... "- Item $abc\n  efg$"

Shouldn't newlines be removed completely before editing the body here?
Just like what we do for inline src blocks. See `org-babel--normalize-body'.


I was not aware of how we treated inline src blocks, but I don't think
so. LaTeX fragments, in particular $$…$$ fragments, can have
significant (for the user) newlines.


May you provide an example?
AFAIK, LaTeX usually treats newlines as whitespace, same with " ".


When I say significant, I don't mean for compilation. When editing an
array of equations for example, one might want to keep one equation
per line in the buffer.


--
Sébastien Miquel

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> I do not mind falling back to ":memory:" when :db is not specified, but
> we should display a warning to notify the users. Maybe not as a warning
> every time src block is executed, but at least via org-lint.
>
> Rudolf, WDYT?

I am not a fan of making the use of in-memory databases into a "smell",
as per Org Lint, because it would communicate to the user that "this is
a potential issue that you should probably fix".  I think that is not
true, given that SQLite defaults to in-memory for interactive use. It is
common and useful.  Showing a warning has the same problem.

Now, showing a message, such as "Using in-memory database", could do,
but it would feel like spam.  The SQLite shell prints "Connected to a
transient in-memory database" exactly once, not on every (re-)query.
Perhaps there is a precedent somewhere in Org Babel, and we could do
something similar?

Rudy
-- 
"Music is the mathematics of the sense, mathematics is the music of the reason."
-- James Joseph Sylvester, 1814-1897

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Ihor Radchenko]

Sébastien Miquel  writes:

> Ihor Radchenko writes:
>> I feel that we will be getting various edge cases like the original
>> report and like the one I made up above if we keep trying to convert
>> tabs/spaces. Just retaining the original code indentation will be much
>> more robust, IMHO.
>
> Python code being broken with the default configuration is
> problematic, and fixing that seems worth the downsides (the
> indentation in an org file will now partially depend on the
> =indent-tabs-mode= settings of other modes, which cannot be set using
> buffer local variables).

What about the following approach:

When converting from org-src buffer back to Org,

1. We do not touch the original indentation, except minimal common
   indentation of the whole src code, respecting the src mode value of
   `indent-tabs-mode'.
2. Minimal common indentation is treated according to
   `org-src-preserve-indentation'.
3. `org-src-preserve-indentation', when in effect, will add extra
   indentation of #+begin indentation + `org-src-preserve-indentation',
   now honouring `indent-tabs-mode' in Org buffer.

When converting from Org to org-src buffer,

1. When `org-src-preserve-indentation' is in effect, remove the common
   `org-src-preserve-indentation' + #+begin indentation from the body.

>>> ... "- Item $abc\n  efg$"
>> Shouldn't newlines be removed completely before editing the body here?
>> Just like what we do for inline src blocks. See `org-babel--normalize-body'.
>
> I was not aware of how we treated inline src blocks, but I don't think
> so. LaTeX fragments, in particular $$…$$ fragments, can have
> significant (for the user) newlines.

May you provide an example?
AFAIK, LaTeX usually treats newlines as whitespace, same with " ".

>>>2. Renaming of =preserve-blank-line=, for clarity.
>> My concern is for `newline-and-indent'. Current line is _previous_  line
>> in such scenario, not the newly inserted line.
>
> The way =newline-and-indent= works, I think, is that a newline is
> inserted, then =org-indent-line= is called, which preindents the line
> to the common org indentation, then calls =TAB= in a native edit
> buffer that does the rest of the indentation. The "current" line I
> refer to in the code is the new line (the "current" line is the one
> from which the native edit was called).

I think I stumbled upon related problem in my testing, but can no longer
reproduce. Your explanation indeed makes sense for my example.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: batch breaks bugfix

[Ihor Radchenko]

Samuel Wales  writes:

> the bug occurs in recent bugfix, but not recent main, so perhaps we
> could say that it is fixed in main but that the fix has not been
> applied to bugfix?  [if only the fix were known.]

Maybe.

> does org testing use --batch?

Yup.
If you have time and interest, it would be useful if you can integrate
your regression tests with Org's test suite.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Ihor Radchenko writes:

I feel that we will be getting various edge cases like the original
report and like the one I made up above if we keep trying to convert
tabs/spaces. Just retaining the original code indentation will be much
more robust, IMHO.


Python code being broken with the default configuration is
problematic, and fixing that seems worth the downsides (the
indentation in an org file will now partially depend on the
=indent-tabs-mode= settings of other modes, which cannot be set using
buffer local variables).


   - =preserve-fl= is an isolated issue, and only concerns LaTeX
 fragments. I will attach a test with the issue it solves with
 multiline LaTeX fragments. I think LaTeX fragments are particular
 because in the org buffer they do not need to start at the
 beginning of a line.
... "- Item $abc\n  efg$"

Shouldn't newlines be removed completely before editing the body here?
Just like what we do for inline src blocks. See `org-babel--normalize-body'.


I was not aware of how we treated inline src blocks, but I don't think
so. LaTeX fragments, in particular $$…$$ fragments, can have
significant (for the user) newlines.


Here are three patches attached.
   1. Two tests : about editing LaTeX fragments, and preserving empty
  lines.

LGTM.


   2. Renaming of =preserve-blank-line=, for clarity.

My concern is for `newline-and-indent'. Current line is _previous_  line
in such scenario, not the newly inserted line.


The way =newline-and-indent= works, I think, is that a newline is
inserted, then =org-indent-line= is called, which preindents the line
to the common org indentation, then calls =TAB= in a native edit
buffer that does the rest of the indentation. The "current" line I
refer to in the code is the new line (the "current" line is the one
from which the native edit was called).

--
Sébastien Miquel