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)
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 =
> 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
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
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,
"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
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,
"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
[ 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
>>
"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
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
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 .
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
> 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
[ 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
>> 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
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
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
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
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
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
> 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
> 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
> 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
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
> 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
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:
>
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
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
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
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:
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
32 matches
Mail list logo
