Timothy writes:
> As far as I know the only call for help maintaining Org has been with
> babel packages. Otherwise you would have seen me volunteering :P I'd
> like to do more if I get the opportunity.
I’m currently in the process of enabling myself to contribute. Do we
have a list of
John Kitchin writes:
> 5. I mostly think the citations should be displayed as plain text, i.e.
> not replaced by a numbered overlay, or equivalent. I could see hiding
> the [], but also guess that would be more confusing than beneficial.
As someone who works author-year inline citations into
Tim Cross writes:
> ian martins writes:
>
>> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote:
>>
>> [Noise]
>>
>> Timothy said there were 25 patches without response and the list goes back
>> six months, so we're only talking about 50 emails per year.
> That assumes there is a single
Aloha Kyle,
Done. Thanks.
There are quite a few unmaintained languages in core.
All the best,
Tom
Kyle Meyer writes:
Thomas S. Dye writes:
Aloha Kyle,
Thanks for this. I think the Worg list might be useful to
indicate which languages don't have maintainers. Or, is the
information in
ian martins writes:
> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote:
>
> Responding to essentially just flag you have seen the patch message
> really only adds noise and may even 'drown out' those responses which
> add real 'value' to any discussion. I also doubt that asking people to
>
On Wed, Apr 21, 2021 at 8:35 PM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Great!
> >
> > I just pulled down the branch.
> >
> > This is my first time trying to run off a development branch.
> >
> > I ran make from the root of the repo, and then:
> >
> > emacs -Q -l
On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote:
> Responding to essentially just flag you have seen the patch message
> really only adds noise and may even 'drown out' those responses which
> add real 'value' to any discussion. I also doubt that asking people to
> do this would actually result
Hello,
"Bruce D'Arcus" writes:
> Great!
>
> I just pulled down the branch.
>
> This is my first time trying to run off a development branch.
>
> I ran make from the root of the repo, and then:
>
> emacs -Q -l lisp/org.elc
>
> ... but then get this error:
>
> load-with-code-conversion: Cannot
On Wed, Apr 21, 2021 at 7:34 PM Nicolas Goaziou wrote:
> I just rebased "wip-cite-new" branch, which now includes citation
> syntax, and an interface between external citation processors and the
> rest of Org. I'll throw in a demo at the end of this message. TL;DR:
> search for "Demo time".
Hello,
"Bruce D'Arcus" writes:
> In general (conceptually), if you have one footnote in text, and one
> in a footnote, with a note style, both will be rendered as footnotes.
>
> So in an adapted version from earlier:
>
>
> Text 1 [@cite:@a].
> Text 2[fn:1].
>
> [fn:1] This is [cite:@b].
>
On Wed, Apr 21, 2021 at 7:51 PM Nicolas Goaziou wrote:
>
> Hello,
>
> András Simonyi writes:
>
> > This is a crucial point: when a note CSL style is used, the export has
> > to generate footnotes "around" those citations which are not already
> > in a footnote.
> > Since citeproc-org generates
Hello,
András Simonyi writes:
> This is a crucial point: when a note CSL style is used, the export has
> to generate footnotes "around" those citations which are not already
> in a footnote.
> Since citeproc-org generates only Org fragments, this is very simple
> to do (with anonymous
Hello,
I just rebased "wip-cite-new" branch, which now includes citation
syntax, and an interface between external citation processors and the
rest of Org. I'll throw in a demo at the end of this message. TL;DR:
search for "Demo time".
As a reminder, the full citation syntax is
as it has been a long time my original post is
Message ID
and the content is
===
when you link to a section using toc, you get a link like
https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab
will these links break if somebody copies them and
more below. [note the two samuels.]
On 4/21/21, Samuel Loury wrote:
> advance what heading he will share, so he would have to add CUSTOM_ID
> everywhere, just in case. This sounds like a lot of unnecessary work.
>
> The solution of tec¹ appears to be a new generation of the html ids based
> on
On Tue, Apr 20, 2021 at 4:24 PM John Kitchin
wrote:
> I have used an approach like the one here
> https://endlessparentheses.com/define-context-aware-keys-in-emacs.html
>
> to make context aware key-bindings.
>
> THanks John. That post was very helpful -- really all I was looking for
was
Dear All,
On Sun, 18 Apr 2021 at 15:11, Nicolas Goaziou wrote:
> I am also leaning towards removing the possibility to include Org syntax
> (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly
> useful (you can move the bold part outside of the citation object), and
> yet,
and for completeness from the org-ref point of view, probably all of
them call something like (org-ref-find-bibliography) inside those
functions to get a list of bib sources from a hierarchy of local
definitions in the buffer to env vars, to a default source variable
defined in elisp. I think
A big +1 to everything John said. On this:
On Wed, Apr 21, 2021 at 4:26 PM John Kitchin wrote:
> 4. I tend to have my follow function launch a hydra menu, which provides
> many action choices. I think this is easier than trying to remember a lot of
> different commands that also work at the
>>> - "fontification" is meant to give full access to face selection, what
>>> is really displayed, additional keymaps, all using a single
>>> function.
>>
>>> At the moment, I have no idea about what arguments would be useful.
>>> I think John Kitchin gave ideas about this
On Wed, Apr 21, 2021 at 3:57 PM John Kitchin wrote:
> I guess that the actions I use most often when "opening" a citation are,
> opening the pdf, going to the webpage for it, and then opening the
> bibtex entry (usually to fix capitalization or something). In org-ref
> though, there are a whole
I guess that the actions I use most often when "opening" a citation are,
opening the pdf, going to the webpage for it, and then opening the
bibtex entry (usually to fix capitalization or something). In org-ref
though, there are a whole bunch of other potential actions, like
searching for related
John Kitchin writes:
>> The challenge can be in identifying the most appropriate key bindings.
>> This can depend on the platform you use as well. When I was only using
>> Linux, I used the 'super' key for this and it was great. However, when I
>> also started using a mac, I had to define a
"Bruce D'Arcus" writes:
> I've been thinking about this general issue over the past year, as
> it's a common problem regardless of project, hosting platform, etc.
>
> I do agree in general that situations where submission of ideas and
> patches languish without attention are a problem.
>
> But
Eric S Fraga writes:
> On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote:
>> 1. A patch looks useful to me, but I feel I don't know if it's a good
>
> [...]
>
>>"Thanks for submitting this. I'd use it. Hopefully a maintainer
>>will take a look."
>
> Ian,
>
> I think you will find
> The challenge can be in identifying the most appropriate key bindings.
> This can depend on the platform you use as well. When I was only using
> Linux, I used the 'super' key for this and it was great. However, when I
> also started using a mac, I had to define a new scheme. It can take a
> bit
On Wed, Apr 21, 2021 at 1:08 PM Nicolas Goaziou wrote:
> I will take care about the default back-end (hopefully before the end of
> the week but don't hold your breath), but can only provide guidance for
> the conversion part. I hope there is enough motivated people to give it
> a try.
My lisp
Hello,
Matt Price writes:
> As a user, is there any way I can participate at this point? I'm not in a
> position to contribute code tight now but really do want to have this
> feature as soon as possible. It's going to improve my students' lives quite
> a bit.
Thank you for your interest.
I
Hello,
> The solution of tec¹ appears to be a new generation of the html ids based
> on the heading content rather than apparently randomly generated, making
> the generated link become the same across new generations.
AFAICT, the link you send only contains code, not explanations nor
design.
Hello again.
I forgot to answer this question on your previous message, sorry...
Nicolas Goaziou writes:
> That being said, we can discuss syntax that is not depending upon some
> variable. For example macro names are written with a limited set of
> characters (alphanumeric, dash, underscore).
Hi all,
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
Sorry, I have been busy with other matters and had lost the thread of
the discussion. I'm catching up on the messages...
I have tried the Nicolas'
I've been thinking about this general issue over the past year, as
it's a common problem regardless of project, hosting platform, etc.
I do agree in general that situations where submission of ideas and
patches languish without attention are a problem.
But while I don't think there are any easy
On Wed, Apr 21, 2021 at 9:27 AM Eric S Fraga wrote:
>
> On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote:
> > 1. A patch looks useful to me, but I feel I don't know if it's a good
>
> [...]
>
> >"Thanks for submitting this. I'd use it. Hopefully a maintainer
> >will take a look."
>
On Wed, Apr 21, 2021 at 2:39 AM Dr. Arne Babenhauserheide
wrote:
>
> Jens Lechtenboerger writes:
>
> > On 2021-04-20, Tim Visher wrote:
> >
> >> I guess regardless it sounds like if I were to go to the trouble of
> making
> >> a patch for this it would be good to make sure that it was behind an
On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote:
> 1. A patch looks useful to me, but I feel I don't know if it's a good
[...]
>"Thanks for submitting this. I'd use it. Hopefully a maintainer
>will take a look."
Ian,
I think you will find that a few of us do post answers like
Nicolas Goaziou writes:
[...]
> Samuel Wales writes:
>
>> i was referring to:
>>
>> Message ID <87v9dbelky@gmail.com>
>>
>> in this thread.
>>
>> [and other posts in this thread related to it.]
>
> Unfortunately, I won't have time to look at the whole thread anytime
> soon. However, feel
On 21/04/2021 03:37, Nicolas Goaziou wrote:
Maxim Nikulin writes:
(let ((s (org-sort-remove-invisible
"A wrapping [[https://orgmode.org?a=b=d#e][link]] emphasis/"
I expect "A wrapping link emphasis".
Yet, your expectations are wrong. There is no link in the text above.
Emphasized text
Heinz Tuechler writes:
> Tim Cross wrote on 21.04.2021 11:50:
>> I find bug fixes are applied very quickly. Enhancements and extensions
>> are introduced more conservatively, but I think that is a positive
>> rather than negative aspect of org development. For many users, org is
>> already
Hello,
I just saw your message, and I wonder if there's an "official" channel to
discuss these efforts. I have no experience in theoretical parsing/lexing, but
I'm interested in learning and spending some time on externalizing org-mode
parsing to make it actually available outside of Emacs.
I
Timothy, thanks for raising this. I agree with everything you've said
in this thread. I think it may be a hard problem to solve, but maybe
we can start by just trying to improve. To be clear the problem I'm
talking about is that potential contributors sometimes receive no
response from the list.
Tim Cross wrote on 21.04.2021 11:50:
I find bug fixes are applied very quickly. Enhancements and extensions
are introduced more conservatively, but I think that is a positive
rather than negative aspect of org development. For many users, org is
already very feature rich/complete.
This is my
Jean Louis writes:
> It should be clear that more maintainers and developers with direct
> access are needed for patches to be applied timely.
>
> I am sure that those on emacs-devel mailing list, Emacs developers,
> they could help on that, but maybe some of them do not observe this
> mailing
Hi Nicolas,
On Wed, Apr 21, 2021, at 5:15 PM, Cheong Yiu Fung wrote:
> The first patch implements the changes. I took the liberty to show
> entry of its ancestors
> too (4 in the test case). Many users, I believe, rarely put text there,
> so it does not
> make a difference.
I would like to
It should be clear that more maintainers and developers with direct
access are needed for patches to be applied timely.
I am sure that those on emacs-devel mailing list, Emacs developers,
they could help on that, but maybe some of them do not observe this
mailing list.
Number of not applied
Hi Nicolas,
The first patch implements the changes. I took the liberty to show entry of its
ancestors
too (4 in the test case). Many users, I believe, rarely put text there, so it
does not
make a difference. But when someone write short notes at this location, I think
it serves
as brief
Hello,
Samuel Wales writes:
> i was referring to:
>
> Message ID <87v9dbelky@gmail.com>
>
> in this thread.
>
> [and other posts in this thread related to it.]
Unfortunately, I won't have time to look at the whole thread anytime
soon. However, feel free to explain how "tec's fix" works,
Sébastien Miquel writes:
> On second thought, I'm uneasy about my approach. If tangling fails,
> the user might miss the error message since it is quickly replaced by
> the tangling info. Ideally we should backup all the tangled files and
> restore them all if a single one fails to ensure
Jens Lechtenboerger writes:
> On 2021-04-20, Tim Visher wrote:
>
>> I guess regardless it sounds like if I were to go to the trouble of making
>> a patch for this it would be good to make sure that it was behind an option
>> and probably defaulting to the current HEAD behavior of including the
Hi Tom,
Thank you again for your comments.
Tom Gillespie writes:
I think that the location of condition-case is ok, but I wonder what
would happen if something were to fail before entering that? I think
that only a subset of the files would be tangled, but they would all
have their correct
49 matches
Mail list logo
