On Sat, Nov 20, 2021 at 10:50:40PM +0800, Timothy wrote:
> Hi Thomas (& co.),
[...]
> Thanks. It helps that this list is fairly friendly to begin with :)
Friendly lists are made of friendly people, and there, your contribution
is... special.
> * For example, “:tangle-mode 755” will now produce
Hi Ihor,
Ihor Radchenko writes:
> Hmm. I missed that we promised Org 9.5 to be distributed via old
> channels. I confirm that Org 9.5 is missing from Org ELPA.
Sorry for that. The *tar files were actually built when 9.5 came out,
but somehow uploaded to the wrong directory.
> Bastien, should
Dear Emacsian friends,
This is it, the final stretch until EmacsConf 2021, coming up on
November 27 and 28 less than a week from now! A few weeks ago,
we excitedly shared the EmacsConf 201 program with you. We're now
happy to share the conference schedule with you, i.e. the program
plus each
Hi Nicolas,
Nicolas Goaziou writes:
> While we're at it… maybe a 9.5.1 release is in order? Just sayin'…
Org 9.5.1 is planned to be the last stable version before the final
merge into the Emacs 28 branch, so I will ping the Emacs maintainers
first -- thanks for the reminder!
--
Bastien
Hi Clément,
I've just had a look at your patch, and it seems very reasonable to me.
Hence, I've just pushed it as ebd06c1 :)
> Hi all,
>
> * lisp/org-src.el (org-src-font-lock-fontify-block): Reset the
> modification flag of the temporary fontification buffer after
> fontifying.
>
> Without
Hi Thomas,
Thanks for catching this problem. To me this looks more like a problem with the
worg publishing than an outdated link. I’ve cc’d Bastien as he’s much more
familiar with the Worg publish process than I am.
“Thomas S. Dye” writes:
> The attached patch changes a 404 link to the working
Hello,
Bastien writes:
> Ihor Radchenko writes:
>
>> Bastien, should we package Org 9.5 to Org ELPA?
>
> Done, thanks a lot for the heads up!
While we're at it… maybe a 9.5.1 release is in order? Just sayin'…
Regards,
--
Nicolas Goaziou
Nicolas Goaziou writes:
> I like the idea, thank you for suggesting it.
Great :D
>>#+TEXINFO_DEFFN: t
>
> The chosen UI is rather odd however. I cannot think of another use of
> controlling export thhough "#+keyword: boolean" syntax. Usually, we
> extend the "options" keyword. It could
Timothy writes:
> The parsing of “555” to the integer 555 is done by
> org-babel-parse-header-arguments, and so can’t really be changed. For a simple
> octal notation our best bet is adding non-digit characters so it is left as a
> string, e.g. “o555”.
I don't understand this. Why can't it be
Timothy writes:
> * For example, “:tangle-mode 755” will now produce the warning:
> “1363 is not a valid file mode octal. Did you give the decimal value 755 by
> mistake?”. Maybe it would be worth adding “if so try o755” or similar?
I think that warning will be confusing for users. They
hi, Timothy,
> I’ve just pushed three commits that
> 1. Add “o555” as an octal shorthand
> 2. Perform a simple check that integer modes are valid*
> 3. Make the ls-style regex stricter
> ...
> * For example, “:tangle-mode 755” will now produce the warning:
> “1363 is not a valid file mode
Hello,
"Bruce D'Arcus" writes:
> Subject: [PATCH] oc-basic: Add function to shorten names
>
> * lisp/oc-basic.el (org-cite-basic--shorten-names): new function to
> shorten author names
Applied. Thank you.
Regards,
--
Nicolas Goaziou
What tool do you use to highlight PDF? Do you copy your highlights to a
.org file?
I use org-noter, but it seems the mouse is necessary to work with PDF.
Best regards,
Ypo
Hi All,
A few hours ago I noticed that I’ve made a few very minor mistakes in some of my
recent commit messages for Org. Realistically I don’t think I’m going to stop
making occasional mistake any time soon, eve if they do become rarer. So, I’ve
whipped up a magit hook that looks at the diff and
Hello,
Ihor Radchenko writes:
> I updated the patch. If you have no objections on the new wording, I
> will push it to main.
Thanks for the update, and apologies in advance for being bold, as
I have some additional comments about it.
> * doc/org-manual.org (Emphasis and Monospace): Advice
Timothy,
> Just a quick note (see my long recent reply to Tim where I expand on this
> more),
> but this isn’t new behaviour (isn’t actually affected by my recent changes)
> and
> my concerns are with the viability of the necessary changes rather than
> whether
> this would be good (we are of
Hi Tim,
>> The parsing of “555” to the integer 555 is done by
>> org-babel-parse-header-arguments, and so can’t really be changed.
>
> I don't understand this. Why can't it be changed?
Well, it can't be changed without changing
org-babel-parse-header-arguments, which is quite a major change
Hi Greg,
> i’d push back, even here, on allowing decimal. file modes are bit
> masks. to me, offering a way to set a bit mask via a *decimal* value
> seems a mistake.
Just a quick note (see my long recent reply to Tim where I expand on this more),
but this isn’t new behaviour (isn’t actually
Hi Thomas (& co.),
>> […] I’m thinking either “o555” or “#o555” would be a good improvement over
>> “(identity #o555), but am open to other suggestions.
>
> That’s reasonable. I’d even tend to disallow decimal. In usage, it’s too
> exotic and the potential for someone entering “just a number”
Max Nikulin writes:
> Thank you for contribution. I do not have strong objection any more. I am not
> familiar with babel internals, so I leave further discussion to maintainers.
>
> If you have not signed copyright assignment yet, likely you should do it to
> proceed (I am unsure concerning
On Sat, Nov 20, 2021 at 04:08:16PM +0800, Timothy wrote:
> Hi Tom, Tim, Thomas, and Greg,
[...]
> • a shorthand for octal
> • ls-style
> • chmod-style
> I think this small collection of distinct and simple input methods isn’t
> overly
> clever or complex, and feel that it strikes the right
Hi Tom, Tim, Thomas, and Greg,
Thank you all for your thoughts. I’ll try to respond to all the main points
raised below.
First off, in case it wasn’t clear in my earlier email when I said “#o555 works”
or the like I was being lazy and really meaning “(identity #o555)” works.
The parsing of
The bellowing error often raised when I region select multiple headlines which
contains properties
drawer
#+begin_src org
|*** headline 1
:PROPERTIES:
:kkk: 2
:END:
,*** headline 2
:PROPERTIES:
:kkk: 3
:END:
|
#+end_src
(Here the ~|~ and ~|~ represent the region select two
When I put point on an custom org link:
#+begin_src org
[[pdf:~/Org/Wiki/Computer Technology/Programming/Programming
Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00][Clojure经典实例.pdf: Page
40]]
#+end_src
Then press =[M-: (org-element-context) RET]= to get link element properties. I
On 16/11/2021 14:43, Ihor Radchenko wrote:
Max Nikulin writes:
Better docs and some restriction on defcustom values were discussed earlier:
https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/
Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon,
19 Apr 2021 11:27:07
"Christopher M. Miles" writes:
> The bellowing error often raised when I region select multiple headlines
> which contains properties
> drawer
>
> #+begin_src org
> |*** headline 1
> :PROPERTIES:
> :kkk: 2
> :END:
>
> ,*** headline 2
> :PROPERTIES:
> :kkk: 3
> :END:
> |
>
"Christopher M. Miles" writes:
> When I put point on an custom org link:
>
> #+begin_src org
> [[pdf:~/Org/Wiki/Computer Technology/Programming/Programming
> Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00][Clojure经典实例.pdf: Page
> 40]]
> #+end_src
> ...
> You can see the result
27 matches
Mail list logo
