Hello all!
I have been working to increase my frame use with emacs, and have taken the
following from the manual:
(custom-set-variables
'(display-buffer-base-action
'(
(display-buffer-reuse-window display-buffer-pop-up-frame)
Étienne Deparis writes:
>
> I confirm that I've the same variable set in my Emacs config file:
>
> (setq-default auto-fill-function 'do-auto-fill)
>
> Which I take from the Emacs Wiki AutoFill page¹, with the explanation
> of: « If you would like to enable auto fill for all major modes, you
to clarify.
On 5/2/20, Samuel Wales wrote:
> there are a bunch of existing sort-of solutions, but to me the best is
> linking [as you mentioned], using org-id. although that only links to
> entries, and it requires following links. one entry becomes
> canonical. you have to set metadata for
On May 2, 2020 1:57:02 p.m. PDT, Samuel Wales wrote:
... you could
maybe color the one that is in the file itself differently, or keep
all looking equal status to the user.
In my situation it would certainly be fine to have only the canonical/original
subtree editable, as long as any edits to
p.s. presumably the agenda would in some cases want to distinguish
canonical [in the place whwere ther data will be saved] from
non-canonical.
also presumably a few traversing commands would want to recognize such
regions in order tonot follow non-canonical, or to look for infinite
looping, etc.
stating the obvious: org typically stores a forest [files] of trees of
nodes. some things you want to put into it are best expressed more
generally than with trees. i call it [boring name] the tree problem.
there are a bunch of existing sort-of solutions, but to me the best is
linking [as you
Nicolas Goaziou writes:
> I think there are really two paths here: either we only support the
> common denominator between all processors, like, e.g., Pandoc, or we
> handle every possible command, knowing that most of them will not be
> portable anyways.
Yes, I think that is the core issue:
Is there a method I can use to include the same subtree in several different
files, such that editing one instance of that subtree updates the others
automatically? I'm hoping to be able to view the full version of the subtree in
each of the files, without having to follow a link; if what I'm
>>> "AK" == Axel Kielhorn writes:
Hi Alex,
I am not sure my first answer made it, so I apologize for a possible
crossposting.
> Hi Uwe,
>> I have an orgtable with a lot of useful information, I would like to add
>> a column either for TODOS or checkboxes but it seems not work any idea
Hello,
Étienne Deparis writes:
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
> insert-before-markers-and-inherit(nil)
> org-comment-line-break-function(t)
[...]
> I confirm that I've the same variable set in my Emacs config file:
>
> (setq-default
Am 02.05.2020 um 18:34 schrieb Nicolas Goaziou:
It seems you didn't copy the list. I add it again.
No, I think that should be fine. (Perhaps also a fourth one for
author-only. And what about nocite?)
Sorry. I wasn't clear.
There is still full support for styles behind the suggested syntax,
Hello,
I allow myself to revive an old thread, as I encounter today the exact
same problem: Emacs crash in org mode at line ending with the following
backtrace:
Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
insert-before-markers-and-inherit(nil)
It seems you didn't copy the list. I add it again.
> No, I think that should be fine. (Perhaps also a fourth one for
> author-only. And what about nocite?)
Sorry. I wasn't clear.
There is still full support for styles behind the suggested syntax,
e.g., [cite/author: ...], [cite/nocite: ...]
Hello,
"Bruce D'Arcus" writes:
> So to sum up, I expect we will explicitly define three commands:
> default (the one defined in the citation template of the style),
> suppress-author (which need not be explicitly defined in the style,
> since the processor knows how to achieve this), and
On Sat, May 2, 2020 at 9:13 AM Nicolas Goaziou wrote:
> I suggested to support at least "cite", "cite/text" and "cite/paren",
> but it sounds like "cite/paren" is not possible with Citeproc. This
> doesn't matter much, we can limit the supported set to "cite" and
> "cite/text" in Citeproc.
Just
Hello,
Christian Heinrich writes:
> I'm often using empty header titles that only contain tags, such as
>
>> **:foo:
>
> In my case, this is sufficient (for instance for flashcards, where I never
> have to actually have to
> use the agenda etc.). However, since Nicolas's refactoring in
>
Hello,
Richard Lawrence writes:
> If so, then I think Nicolas' proposal to have "cite" mean default and
> make non-default citations available as "cite/xxx" makes sense
> (especially with the other syntax supporting suppress-author, etc.).
>
> If not, then the "cite/xxx" syntax makes less sense
Hi,
I'm often using empty header titles that only contain tags, such as
> **:foo:
In my case, this is sufficient (for instance for flashcards, where I never have
to actually have to
use the agenda etc.). However, since Nicolas's refactoring in
be31a0c4595a6d68b03b5cfbcbcdbf2cd76d2b7f empty
On Sat, May 2, 2020 at 5:51 AM Nicolas Goaziou wrote:
...
> > Does that mean you'll be able to have the same or different processors
> > for different backends? (Like biblatex for latex and citeproc-el for
> > ODT/HTML/etc.; or when you need identical output you can use
> > citeproc-el even for
On 2020-05-02, at 10:12, to...@tuxteam.de wrote:
> On Sat, May 02, 2020 at 09:37:40AM +0200, Marcin Borkowski wrote:
>>
>> On 2020-04-30, at 07:02, Kyle Meyer wrote:
>>
>> > And note that a utility like datefudge or libfaketime is useful for
>> > testing these sorts of things out. For
Hi,
These are a few lines of experimental code to bring dynamic filtering to
the agenda. I think it's not too bad already.
I'd like to invite you to check it out. Just mark the code and do
{M-x eval-region RET}. Then you have the "dynamic filtering" on key "&"
in the agenda. Just type to see
Hello,
Thank you for the feedback.
Denis Maier writes:
> What about using quotes if someone needs this, like so [cite: "common
> prefix; still common prefix"; pre @key post; pre @key2 post; common
> suffix] ?
Then we would have to find a way to escape the quote…
> Does that mean you'll be
Hello,
tbanelwebmin writes:
> There is a last cleanup that can be achieved
> (or not, doesn't really matter):
> simplifying two calls located in org-table.el:
>
> (org-table-to-lisp
> (buffer-substring-no-properties (org-table-begin) (org-table-end)))
>
> to:
>
> (org-table-to-lisp)
Indeed.
Hi Uwe,
> I have an orgtable with a lot of useful information, I would like to add
> a column either for TODOS or checkboxes but it seems not work any idea
> whether such an addon package exist or any change that such a feature
> will be implemented?
I use a different approach.
I store the
On Sat, May 02, 2020 at 09:37:40AM +0200, Marcin Borkowski wrote:
>
> On 2020-04-30, at 07:02, Kyle Meyer wrote:
>
> > And note that a utility like datefudge or libfaketime is useful for
> > testing these sorts of things out. For example:
> >
> > $ datefudge "2020-02-18" emacs [...]
>
>
Le 01/05/2020 à 15:11, Nicolas Goaziou a écrit :
> Indeed. I also realized this, and fixed it a couple of hours ago. You
> will notice I shamelessly used your "\\="© trick! :)
This kind of shamelessness builds great communities :)
> Great. I removed the check and added an entry in ORG-NEWS. It
On 2020-04-30, at 07:02, Kyle Meyer wrote:
> And note that a utility like datefudge or libfaketime is useful for
> testing these sorts of things out. For example:
>
> $ datefudge "2020-02-18" emacs [...]
Shameless plug: I wrote about this use-case of datefudge sime time ago:
27 matches
Mail list logo
