When cleaning up hard indentation, I found my source blocks remaining indented.
The way that org-do-remove-indentation is sensitive to invisible text.
This occurs for source blocks whenever using org-modern-mode, where it
makes the source blocks align left.
By swapping out the arithmetic and expr
I wrote up a small addition to the unfill package, which is very
convenient for switching hard newlines out in favor of tools like
visual-line-mode and adaptive-wrap.
The command unfilled every list and paragraph in the entire buffer. PR is here:
https://github.com/purcell/unfill/pull/11#pullrequ
Hi,
I'd like to request a new ESS feature that will allow to choose which
session is created by ESS when no session is yet associated with a
buffer.
Currently, `ess-request-a-process' unconditionally re-uses an existing
ESS process with appropriate `ess-dialect', even when such process is
not con
Jack Kamm writes:
>> ---
>> etc/ORG-NEWS | 11 +++
>> lisp/ob-R.el | 20 ++--
>> lisp/ob-julia.el | 16 +---
>> 3 files changed, 26 insertions(+), 21 deletions(-)
>
> Not sure if you are doing this in a separate commit, but you also need
> to make the
Psionic K writes:
> When cleaning up hard indentation, I found my source blocks remaining
> indented.
>
> The way that org-do-remove-indentation is sensitive to invisible text.
> This occurs for source blocks whenever using org-modern-mode, where it
> makes the source blocks align left.
Thanks
Psionic K writes:
> I wrote up a small addition to the unfill package, which is very
> convenient for switching hard newlines out in favor of tools like
> visual-line-mode and adaptive-wrap.
>
> The command unfilled every list and paragraph in the entire buffer. PR is
> here:
> https://github.c
> From: Ihor Radchenko
> Cc: emacs-orgmode@gnu.org, Eli Zaretskii ,
> 65...@debbugs.gnu.org, Max Nikulin , i...@whxvd.name
> Date: Tue, 09 Jan 2024 22:33:58 +
>
> Stefan Monnier writes:
>
> >> Although, I am still interested to pursue feature request to allow
> >> customizing `kill-whole-l
Eli Zaretskii writes:
>> Eli told me in the past that Org mode should not remap keys.
>> See the discussion branch starting at
>> https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/
>
> I said that remapping widely-used keys to commands that behave
> significantly differently places a non-tr
> From: Ihor Radchenko
> Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org,
> maniku...@gmail.com, i...@whxvd.name
> Date: Wed, 10 Jan 2024 13:05:19 +
>
> Eli Zaretskii writes:
>
> > I said that remapping widely-used keys to commands that behave
> > significantly d
> Would you also be able to create a reproducer, so that we can replicate
the problem and write a test?
Yeah, I just have to make some indentation text invisible. Where
should such a test live? Where is your documentation on running a
test?
> It looks like you did not send the patch with git se
> You may instead just run
No. That will have to be run manually on every element and every line
of every list. I suppose let's just not talk about it further and
I'll submit a patch so there's no confusion.
On Wed, Jan 10, 2024 at 9:31 PM Ihor Radchenko wrote:
>
> Psionic K writes:
>
> > I w
This is the org-fill-buffer command, done generically for people who want
to fill or unfill the entire buffer, as is required when alternating
between hard newline filling and visual line mode filling.
See attached patch for docstring and commit message.
From 706d5d71cdf1ed2528664bdaf714aad6bd15af
Psionic K writes:
>> Would you also be able to create a reproducer, so that we can replicate
> the problem and write a test?
>
> Yeah, I just have to make some indentation text invisible. Where
> should such a test live? Where is your documentation on running a
> test?
The tests live in tests/
Psionic K writes:
>> You may instead just run
>> (let ((fill-column most-positive-fixnum)) (fill-region (point-min)
>> (point-max)))
> No. That will have to be run manually on every element and every line
> of every list. I suppose let's just not talk about it further and
> I'll submit a patch
Juan Manuel Macías writes:
>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.
For the rec
If I run fill-region on a buffer, there's a lot of errors where the
lack of element awareness means filling is attempted on text that does
not fill properly, such as property drawers, keywords, and even
src-blocks without newline separations. The result requires way too
much cleanup.
It is critic
>> I said that remapping widely-used keys to commands that behave
>> significantly differently places a non-trivial burden on users,
>> especially on those who use the remapping mode relatively rarely.
>
> Sure. From which I concluded that Org mode should avoid remapping
I don't think that's what
[ CCing emacs-devel ]
Psionic K writes:
> If I run fill-region on a buffer, there's a lot of errors where the
> lack of element awareness means filling is attempted on text that does
> not fill properly, such as property drawers, keywords, and even
> src-blocks without newline separations. The
> From: Stefan Monnier
> Cc: Eli Zaretskii , emacs-orgmode@gnu.org,
> 65...@debbugs.gnu.org, maniku...@gmail.com, i...@whxvd.name
> Date: Wed, 10 Jan 2024 11:26:08 -0500
>
> >> I said that remapping widely-used keys to commands that behave
> >> significantly differently places a non-trivial
I have the below set in my init file:
---
(setq org-agenda-deadline-faces
'((1.01 . org-agenda-deadline-past)
(1.0 . org-agenda-deadline-today)
(0.9 . org-agenda-deadline-tomorrow)
(0.7 . org-agenda-deadline-soon)
(0.0 . org-agenda-deadline-upcoming)))
---
But the faces are n
Mark Kerr writes:
> I have the below set in my init file:
> ---
> (setq org-agenda-deadline-faces
> '((1.01 . org-agenda-deadline-past)
> (1.0 . org-agenda-deadline-today)
> (0.9 . org-agenda-deadline-tomorrow)
> (0.7 . org-agenda-deadline-soon)
> (0.0 . org-agenda-deadline-
Mark Kerr writes:
>> > Invalid face reference: org-agenda-deadline-today [6 times]
>> > Invalid face reference: org-agenda-deadline-past [19 times]
>> > ---
>>
>> These two faces have nothing to do with Org mode. Org mode simply does
>> not define such faces and never did (I cannot find these fac
"Sparapani, Rodney" writes:
> Hi Ihor:
>
> Do you have a patch? I’m not an org-mode user so I can’t test this myself.
> Thanks
Well. I am not exactly ESS user, so I wanted to get a general feedback
first before trying anything blindly.
I think I can demonstrate the problem we are facing withou
[ Adding org-mode mailing list back to CC.
Please use "Reply All" or "Wide reply" to
keep the discussion public ]
Mark Kerr writes:
>> Faces that you reference from org-agenda-deadline-faces should exist and
>> should be valid faces. However, it does not look like your
>> `org-agenda-deadlin
"Sparapani, Rodney" writes:
> I see. But, I assume that you meant…
> 8. Observe that the line still goes to "session1"
Yup.
> I usually launch another emacs for “session2”.
> There’s probably a way to do this manually,
> but, I take your point. However, if you are a
> non-user, then why do yo
Ihor Radchenko writes:
> The attached patch makes Org throw an error in such scenario.
This is a great feature (and it deserves a test, given it protects from
data loss). For what is worth, I remember making this error at least
twice in the past year. (Git saved me in both cases, fortunately.)
"Richard M. Heiberger" writes:
> This idiscussion s reminding me of the following ESS functions
>
> ess-request-a-process M-x ... RET
>Ask for a process, and make it the current ESS process.
AFAIK, this is the function deciding whether to run a new ESS process or
re-use the existing
Hi folks,
I have the 'org-use-extra-keys' customization enabled to avoid reaching
for the arrow keys, but the variable needs to be set before loading Org,
which makes literate configuration a bit more complex.
Other Emacs commands have alternative keys bound by default, which makes
me wonder, why
i lost track of all the visual fill stuff vs. emacs native filling vs.
org filling vs. filladapt back before visual filling was able to fill
with both a fill column and a reasonably smart fill prefix reliably.
is that possible now?
also, if a new command is to be introduced, presumably it would wo
> smart fill prefix reliably. is that possible now?
It's reasonably complete for several documents I'm converting, such as
the transient showcase. Visual fill requires two modes right now:
1. visual-line-mode (usually with visual-fill-column-mode as well)
2. adaptive-wrap-prefix-mode
Updating
This is a small point, but I think I've found a situation where the lack of a
name for a default means there are situations where it can't be used.
Let's say we have Basic.bib with this:
@book{friends,
title = {{{LaTeX}} and Friends},
author = {van Dongen, M.R.C.},
date = {2012},
Hi Bill,
On Thursday, 11 Jan 2024 at 05:25, William Denton wrote:
> The basic citation processor is a proof of concept and shouldn't be
> used for real work, so this is probably never going to result in a
> real problem.
Proof of concept or not, the fact that it exists means people (e.g. me)
ar
32 matches
Mail list logo
