Hi Colin,
Colin Baxter writes:
> I notice in https://orgmode.org/manual/Column-width-and-alignment.html
> that a footnote says table centering does not work in emacs but only
> when exported to html.
thanks for reporting this -- this is an old page that the release
process did not delete
On Monday, 3 Feb 2020 at 09:17, Bastien wrote:
> "Fraga, Eric" writes:
>
>> The header line is now 2 characters to the right of where it should be!
>> I have looked at the code briefly but cannot figure out why this would
>> be.
>>
>> I have not seen any difference in behaviour for shrunken
Hi Bram and Ihor,
this should be fixed now in maint and master.
I implemented a different fix, please test it and report
any problem.
Thanks,
--
Bastien
Hi Bastien,
> Yes, you're right, my fix was wrong - I've followed your indication
> and removed the second occurrence of '>.
>
> What happens is this: the template expansion calls org-edit-src-code
> which gets the wrong source block boundaries, thus escaping "#+begin"
> with a comma.
>
>
Hi Andrew,
I have pushed some fixes in this area, if you have a chance to test
Org from the latest maint or master branch, please do so and report
if the problem persists.
Thanks,
--
Bastien
Hi Michael,
> I want to suggest to make `report-org-bug' and alias for the command
> `org-submit-bug-report'. That's the name I expected (considering
> "report-emacs-bug"), also some other Emacs packages name their bug
> reporting command according to this scheme. The additional name would
>
Hi Troy,
> I tracked down an issue trying to load a literate config file.
> org-babel-load-file calls org-babel-tangle-file with lang set to
> "emacs-lisp". This means that it won't tangle any blocks with
> language set to "elisp", which is equivalent. I can't think of an
> easy way to fix this
Hi Bram,
Bram Adams writes:
> I applied the commit, but still encounter the same issue, unless I
> disable `org-src-tab-acts-natively’ or remove ‘> in the org-tempo
> macro.
Yes, you're right, my fix was wrong - I've followed your indication
and removed the second occurrence of '>.
What
"Thomas S. Dye" writes:
> Thanks Eric,
>
> Good to know. I'll try to track down the issue when I find time.
>
> All the best,
> Tom
>
> Fraga, Eric writes:
>
>> On Wednesday, 29 Jan 2020 at 15:22, Thomas S. Dye wrote:
>>> Here is the offending bit, which worked fine last November but
>>> fails
Hi Sébastien,
rey-coyrehourcq writes:
> #+BEGIN_EXPORT markdown
> ...
> #+END_EXPORT
>
> But is it possible using options to :
> - export this block as file using :tangle,
> - on a remote :dir using option for #+BEGIN_EXPORT ?
What did you try exactly, and where does it fail? Can you
Hi Qian,
applied to master, thanks!
--
Bastien
Hi Vladimir,
Vladimir Nikishkin writes:
> #+begin_src plantuml :file test.png :export both
> class "Class1" as c1
> newpage
> class "Class2" as c2
> #+end_src
>
> PlantUML generates two files if given this source. test.png and
> test_001.png
> However, org-babel only shows the first one.
> It
I tracked down an issue trying to load a literate config file.
org-babel-load-file calls org-babel-tangle-file with lang set to
"emacs-lisp". This means that it won't tangle any blocks with language set
to "elisp", which is equivalent. I can't think of an easy way to fix this
since you would need
Hi Kjell,
I cannot reproduce this problem. What version of Org are you using?
M-x org-version RET
Thanks,
--
Bastien
Hi Christian,
Christian Schwarzgruber writes:
> The question is now, is it possible to further reduce the advised
> functions to just one advised function.
I am sorry, I don't understand what change does it imply on Org's
side. Can you explain us a bit more?
Thanks!
--
Bastien
Hi Sébastien,
I cannot reproduce this bug with latest Org version.
If you can, please test with the latest Org version and
report any problem.
Thanks,
--
Bastien
Hi Philipp,
Philipp Middendorf writes:
> I don't have a globally available "java" executable and from the
> source
> code, it appears there is a ":java" parameter for org-babel to specify
> an executable. Looking at the source code, however, it seems that this
> parameter is never actually used
Hi Eric,
"Fraga, Eric" writes:
> If I turn debugging on for table updates (C-c {), when the debugging is
> finished, the original window configuration is not remembered.
>
> Should be simple to fix, but possibly beyond my emacs-lisp-fu.
Fixed, thanks!
--
Bastien
Hi Bastien,
>> Are you referring to commit cad2a6a588?
>
> Yes, this commit.
I applied the commit, but still encounter the same issue, unless I disable
`org-src-tab-acts-natively’ or remove ‘> in the org-tempo macro.
Kind regards,
Bram Adams
Hi Sebastian,
Sebastian Miele writes:
> I told mu4e to replace the characters. Apparently, all non-printable
> characters have been replaced by ASCII periods.
>
> Is there a best practice?
FWIW, I think ASCII periods are fine in this case.
--
Bastien
Hi Bastien,
> this should be fixed now in maint and master.
Thanks for looking into this.
> I implemented a different fix, please test it and report
> any problem.
Are you referring to commit cad2a6a588?
Kind regards,
Bram Adams
Hi Bram,
Bram Adams writes:
> Are you referring to commit cad2a6a588?
Yes, this commit.
--
Bastien
Hi Eric,
"Fraga, Eric" writes:
> The header line is now 2 characters to the right of where it should be!
> I have looked at the code briefly but cannot figure out why this would
> be.
>
> I have not seen any difference in behaviour for shrunken columns.
What is M-x org-version RET ?
Can you
I don't know of a nice Jinja like template for this.
I think what you need is a custom exporter. You can define template
function that is responsible for the latex source. In this function you
would check for the attachment, scale it as you want, and insert the
figure code in the latex source
> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien said:
Bastien> And since is it a good outcome to have more people signing the FSF
Bastien> papers, I recommend requesting contributors to sign the copyright
Bastien> assignment for every >15 lines contributions (significant or not).
Hello,
John Kitchin writes:
> In
> https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input
>
> there was a question about modifying a checkbox export. I wrote an answer
> using a custom translate function in a derived backend, where I could get
In
https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input
there was a question about modifying a checkbox export. I wrote an answer
using a custom translate function in a derived backend, where I could get
the name of the parent list pretty
Robert Pluim writes:
>> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien said:
> Bastien> And since is it a good outcome to have more people signing the
> FSF
> Bastien> papers, I recommend requesting contributors to sign the copyright
> Bastien> assignment for every >15 lines
Thanks Nicolas!
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Mon, Feb 3, 2020 at 11:26 AM Nicolas Goaziou
I came across this inconsistency a while back. I think the problem is
that you should *not* be able to use elisp as a language specifier in
source blocks.
All other language specifiers comply to the pattern of source block
languages being the language major mode name without the '-mode', but
Hi David,
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen. You don't know how to make a good report? See
>
> https://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org mailing list.
>
> I think supporting "#+begin_src elisp" would be confusing
elisp is already supported in all other babel
functions. org-babel-load-file is the only function that makes a
distinction as far as I can tell. And since that function is outlier it
makes sense to document this limitation in its
Hi,
a...@xkqr.org (Christoffer Stjernlöf) writes:
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen. You don't know how to make a good report? See
>
> https://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to
Hi Phillip,
Phillip Lord writes:
> BTW, I am maintaining org-drill at:
>
> https://gitlab.com/phillord/org-drill/
sorry I overlooked this info in my previous email.
Could you send a patch again this page:
https://orgmode.org/worg/org-contrib/org-drill.html
You can clone Worg from here:
Kyle Meyer writes:
>> I'd like to do the honors of making my first push to the repo :) So
>> please let me know if you're fine with me to proceed.
> All good from my end :>
Thanks -- I've pushed to master :D
Hi Kyle,
Thanks for the thorough review as always. An updated patch incorporating
your feedback is at the end of this email.
I'd like to do the honors of making my first push to the repo :) So
please let me know if you're fine with me to proceed. Or, if you have
more comments, they are always
Org intersperses bits of code in prose, such as datestamps, drawers,
keywords, etc. The code distracts when reading the prose. The solution
is to make the code less prominent.
That way it's easy to read the paragraphs of prose without
interruption. If one wants to focus on a code bit, it's still
D writes:
> On 01.02.20 21:32, Marco Wahl wrote:
>> AFAICS org-bullets is released under GPL3. Doesn't this mean that you
>> can use org-bullets as a base for further development if you leave the
>> license intact and also keep the original authors next to your name?
>
> That is correct, I
Code requires less line spacing. It has more whitespace, fewer capital
letters, and no markup such as underlining. Code is read differently
than prose; it requires less sequential scanning.
Prose has big blocks of text with taller capital letters that must be
scanned sequentially. The tall bits
Readable prose requires variable-pitch font. Readable code requires
fixed-pitch font. Org should make it easy to configure the two
separately.
mixed-pitch-mode mostly solves this problem, but only advanced users
know about it.
https://gitlab.com/jabranham/mixed-pitch
Jack Kamm writes:
> Hi Kyle,
>
> Thanks for the thorough review as always. An updated patch incorporating
> your feedback is at the end of this email.
Thanks for the updates.
> I'd like to do the honors of making my first push to the repo :) So
> please let me know if you're fine with me to
#+begin_src elisp
(org-startup-truncated nil)
#+end_src
Line truncation is necessary for code but anathema for prose. Prose
lines need visual wrap as windows resize, so that texts can be
compared easily.
Advanced Org uses such as large tables require line truncation. Tables
are a code-like
#+begin_src elisp
(org-adapt-indentation nil)
#+end_src
Adaptive indentation makes sense when using Org as a plain-text
database. It does not make sense when using Org for longform prose.
In the former case, outline depth is important to reflect properties
such as inheritance. The code elements
Beginners spend a while learning to use Emacs as a simple text editor
before they're able to do anything more advanced. Their ability to
intelligently customize is minimal. Meanwhile experts have automated
dotfile deployment, so defaults are almost irrelevant to them.
Therefore defaults should be
Hello Nicolas, thank you for the reply
> Note that code going into Org proper cannot rely on external libraries,
> e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not
> in its current form. Is it possible to write it without these libraries,
> and without re-inventing the
It strikes me that much of what seems to be required for 'legible' org
would possibly be handled by an org 'theme'. As it is possible to
combine themes, it should be possible to create a 'org pros theme',
which users could add to their existing theme. This theme could adjust
face sizes, colours,
Tim Cross writes:
> All other language specifiers comply to the pattern of source block
> languages being the language major mode name without the '-mode', but
> there is no elisp-mode.
Sorry to be pedantic, but I think shell source blocks are another
exception here. They can use various
Hi,
Thank you for your reply.
I can still reproduce with latest Org: what I did was start emacs with
emacs -q --load empty_init.el, with empty_init.el setting the org
package-archive to http://orgmode.org/elpa/, update org to 9.3.2 then
proceed with the previous steps. The result is the
Texas Cyberthal writes:
> Code requires less line spacing. It has more whitespace, fewer capital
> letters, and no markup such as underlining. Code is read differently
> than prose; it requires less sequential scanning.
Code certainly can have markup like underlining. For example,
I spent some time today trying to get latex babel source blocks to work
for me and discovered that calling `org-babel-execute:latex` ignores the
:headers header if the output file is a png without setting imagemagick
to t. It's easy to see this in the source code: the conditions mentioned
above
Dear Emacs hackers,
Like all of you, I think orgmode is the best way to organise study notes.
I am solving competitive programming questions from Topcoder.com
There are strict guidelines on memory limit of 256MB and time limit of 2sec
for solutions
How do I enforce the same on my orgmode source
Texas Cyberthal writes:
> Beginners spend a while learning to use Emacs as a simple text editor
> before they're able to do anything more advanced. Their ability to
> intelligently customize is minimal. Meanwhile experts have automated
> dotfile deployment, so defaults are almost irrelevant to
This is probably something which would need to be addressed in the
interpreter/compiler of the language you are using rather than within
Emacs or org-mode.
I would suspect that in your case, you are best off tangling the source
blocks to create separate executable scripts/code which you then
Hi Jamie,
I'm copying Łukasz, the author of org-eldoc.el, in case he can have a
look at the issue below.
Thanks,
Jamie Forth writes:
> Using the org-eldoc contrib, visiting a file with a setupfile keyword
> seems to prevent global-eldoc-mode from enabling eldoc in org
> buffers.
>
> Steps to
Well there are exceptions to all rules aren't there?
Yes, strictly speaking, for shell scripts, only 'sh' fits with the
-mode rule. However, that mode is also slightly different from
other language modes in that it supports many shell 'dialects'.
The thing is, the more 'liberal' we are with
Bastien,
the latest on the table header. With emacs -Q and org from a few
minutes ago, I get the following:
[screendump-20200204064315.png]
when I open the file, invoke M-x org-table-header-line-mode RET and
scroll down in the attached org file.
Note also that if I invoke the above command
Texas Cyberthal writes:
> #+begin_src elisp
> (org-adapt-indentation nil)
> #+end_src
>
> Adaptive indentation makes sense when using Org as a plain-text
> database. It does not make sense when using Org for longform prose.
>
> In the former case, outline depth is important to reflect properties
As Tim said, this is really a matter for theming. There are several
themes and example configs available that make Org buffers "pretty".
For example:
https://github.com/kunalb/poet
https://github.com/jonnay/org-beautify-theme
https://lepisma.xyz/2017/10/28/ricing-org-mode/
As well, faces are
Texas Cyberthal writes:
> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src
>
> Line truncation is necessary for code but anathema for prose. Prose
> lines need visual wrap as windows resize, so that texts can be
> compared easily.
>
> Advanced Org uses such as large tables require
Texas Cyberthal writes:
> Readable prose requires variable-pitch font. Readable code requires
> fixed-pitch font. Org should make it easy to configure the two
> separately.
>
> mixed-pitch-mode mostly solves this problem, but only advanced users
> know about it.
>
Nicolas Goaziou writes:
> Note that, at some point, Org will support "seq.el", i.e., when we
> drop support for Emacs 24.
Just a small FYI about seq.el, for those who may not be aware: while
it's a very useful library, it can be quite slow since it uses generics.
For example, here are some
Bastien writes:
> - M-x org-table-electric-header-mode RET will display the first row
> of the table at point in the header line when the first row is not
> visible anymore.
This is great, it's a huge quality-of-life improvement for working with
long tables. Below are some issues I noticed
62 matches
Mail list logo
