On Thursday, 6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> Visual line mode is annoying and unnecessary; Spacemacs users do not
> need it because its defaults offer adequate paragraph navigation.
I'm not sure I understand the conflation of visual-line-mode with
paragraph navigation. Is it becaus
Bastien writes:
> Hi,
>
> stardiviner writes:
>
>> BTW, the function ~org-insert-dblock-bindings~ is from package
>> =orgtbl-aggregate=.
>
> I don't know this function and this package.
>
> Can you share the minimal Emacs config with which you reproduce
> the problem?
Besides of package =orgt
Emacs is the tool that allows a non-technical user to bootstrap to
control over his IT environment. Within that, Org is the tool that
allows him to bootstrap to control of Emacs. So Org's defaults should
allow someone with no experience to learn the basic text manipulation
commands in the help-with
On Wednesday, 5 Feb 2020 at 18:25, Diego Zamboni wrote:
> tl;dr: is there a way to have ob-shell (or some similar mode) run commands
> one by one and include the commands, interspersed with their output, in the
> #+RESULTS block?
You haven't said on what type of system but, if Linux, you could tr
Bastien writes:
> Hi,
>
> stardiviner writes:
>
>> BTW, the function ~org-insert-dblock-bindings~ is from package
>> =orgtbl-aggregate=.
>
> I don't know this function and this package.
>
> Can you share the minimal Emacs config with which you reproduce
> the problem?
Start =emacs -q=, and lo
> If I understand correctly, you're arguing that defaults should be changed
> because you don't understand how Emacs works, and since you use Spacemacs,
> you don't even care how it works.
You understand incorrectly. You incorrectly asserted that all users
must learn how visual line mode works.
Nvm, I found the issue.
Usually my tasks I write like this
* Amnu
#+COLUMNS: %TIMESTAMP %25ITEM
** First contact :Amnu:
<2019-02-01 Fri>
** GramSchmidt and Householder:Amnu:
<2019-02-08 Fri>
** Finish Householder, start power and QR :Am
Hi Bastien,
Bastien writes:
>
> Andrew Hyatt writes:
>
>> Removing the (beginning-of-line 1) at the end of the time display
>> code in that function, and substituting (org-agenda-previous-line)
>> seems to fix it. I'm not sure if that's the right approach - the
>> previous code didn't use that
i have been using toc for an entire blog post and then
#+TOC: headlines 1 local
for sections.
this local idea is brilliant. i can make the main toc
non-intimidating, and then provide a toc for sections.
is it possible to do this automatically?
that is, supply only one main toc, and specify
Hello,
Has anyone had success getting the html export to process latex
fragments? It's leaving mine completely alone and I can't figure out
why. Latex babel source blocks work fine. I've set
(setq org-html-with-latex luasvgm)
luasvgm is a process-alist element I defined. I went through ox-html a
Hello Bastien,
I tried it using a minimal .emacs and version 9.3.3. It behaves the same
on a Linux and a Windows installation.
--
Kjell
Am 03.02.2020 um 19:50 schrieb Bastien:
Hi Kjell,
I cannot reproduce this problem. What version of Org are you using?
M-x org-version RET
Thanks,
Hi everyone,
tl;dr: is there a way to have ob-shell (or some similar mode) run commands
one by one and include the commands, interspersed with their output, in the
#+RESULTS block?
I would like to have examples shown with commands, followed by their
output. Something like this:
#+begin_src conso
Hello,
Gustav Wikström writes:
> That was kind of what I was trying to do, by allowing subtyping, so
> that the parser would be more knowledgeable about particular types of
> links, by allowing extended attributes. Maybe not implemented in the
> most extensible way though I'll admit.
Just to be
It is fixed, but now the new time that's supposed to be displayed via
text-properties does not show up.
Let me spend some time and get a small reproducible case, which will help
us test this.
On Tue, Feb 4, 2020 at 6:38 PM Bastien wrote:
> Hi Andrew,
>
> thanks again.
>
> Andrew Hyatt writes:
Hi,
stardiviner writes:
> BTW, the function ~org-insert-dblock-bindings~ is from package
> =orgtbl-aggregate=.
I don't know this function and this package.
Can you share the minimal Emacs config with which you reproduce
the problem?
--
Bastien
Texas Cyberthal writes:
>> the default settings do not put blank lines between headings and
>> their entry text,
>
> I don't know what this means. Plain Emacs behaves the same way
> Spacemacs does in this regard. Insertion of a blank line after a
> heading is voluntary but standrd.
I don't know
Dear Engineers,
When I write this message, I think I am writing to the best software developers
in the world, or to those who are in the process of being one. I write to ask
you a favor. I am a UMA PhD student and I study the use of formal and
non-formal models in the software industry.
Accord
I use magit-bisect on the latest (currently latest commit is "b14a14c9e")
org-mode repo. The commit "328c9a1af * bad org.el: Enhance menus" caused
bellowing error. I confirmed with a minimal Emacs config testing.
#+begin_example
Debugger entered--Lisp error: (void-variable org-org-menu)
org-in
About this patch, patch, what do you think? Nicolas and Bastien.
stardiviner writes:
> I tried to write an alist of all database names. and write an function to used
> to match name to possible names. But I found this solution is a little kind of
> complicated.
>
> Another simple solution is j
Texas Cyberthal writes:
>> visual-line-mode and toggle-truncate-lines are basic Emacs commands
>> that all users should learn early.
>
> Visual lines, logical lines etc is a complicated mess that Spacemacs
> avoids entirely. I recall fiddling with it and never being satisfied,
> until adopting Sp
Here is an example:
#+NAME: read-in-wxid
#+begin_src clojure :var cwd=(file-truename "~/Documents/WeChat/wxid/")
(require '[clojure.java.io :as io])
(def directory (io/file cwd))
(def files (filter #(.isFile %) (file-seq directory)))
#+end_src
#+RESULTS[<2019-08-28 09:12:24> 84a1210d836742ca71
Texas Cyberthal writes:
> Making a vet change a default if he decides he doesn't like a change
> upon upgrading won't drive him away, but Emacs' unfriendly defaults
> are always driving away noobs. Therefore Org's defaults should be
> noob-friendly, not vet-friendly.
There is certainly room to i
BTW, the function ~org-insert-dblock-bindings~ is from package
=orgtbl-aggregate=.
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650
Hi all,
in the master branch, I've moved Org refile variables and functions to
a new org-refile.el file. This may help boost (a tiny bit) the loading
of org.el.
Please report any strange things that may arise.
--
Bastien
Ihor Radchenko writes:
> Thanks for the clarification. I was not sure if it is intended.
> I was mislead about this 2 times because of docstring, though it is
> clear from the source code.
I fixed the docstring. Thank you.
>> Luckily, headlines are exactly where you do _not_ need Element librar
On Tue, Feb 04, 2020 at 09:38:57PM -0600, Matthew Lundin wrote:
> Adam Porter writes:
>
> > There may be improvements to be made, but the defaults shouldn't be set
> > to match the preferences of any one user. Remember that people have
> > been using Org for years, and theming and faces are very
> `org-element-at-point' returns only a partial parse tree. It never goes
> higher than the current top-level element, i.e., from an element, you
> cannot go up to the headline just following :parent.
Thanks for the clarification. I was not sure if it is intended.
I was mislead about this 2 times
I started out arguing against my position and wound up with another blog post:
https://cyberthal-ghost.nfshost.com/emacs-needs-a-starter-zone-and-org-is-it/
Charles Millar writes:
> I have not experienced this problem since I reported it.
Thanks for confirming!
--
Bastien
Hello,
Ihor Radchenko writes:
>> Probably the docstring needs to be adapted - Nicolas knows this area
>> better than me.
>
> Do you mean that :parent property may not always be present?
`org-element-at-point' returns only a partial parse tree. It never goes
higher than the current top-level ele
On 2/5/20 3:11 AM, Bastien wrote:
Hi Charles,
Charles Millar via Emacs-orgmode writes:
In an org file I have a source code block to convert entries into and
generate a recutils file
#+begin_src sh?? :file SomeFile.rec
cat << EOF
# -*- mode: rec -*-
Begin recutils file
Approximately 77
Hi Gustavo,
Gustavo Barros writes:
>> I managed to reproduce this bug, it is fixed in maint now.
>
> I can report this issue is gone with the update to Org 9.3.3.
> Thank you very much!
Thanks for confirming, best,
--
Bastien
Hi Bastien,
On Tue, Feb 04 2020, Bastien wrote:
I managed to reproduce this bug, it is fixed in maint now.
I can report this issue is gone with the update to Org 9.3.3.
Thank you very much!
Best,
Gustavo.
Hi Fabrice,
Fabrice Popineau writes:
> I am not sure that it is an issue that should be solved by
> org-mode.
Thanks for taking the time to answer -- I'll leave this "bug" out of
my radar for now then.
Thanks,
--
Bastien
Ihor Radchenko writes:
>> Probably the docstring needs to be adapted - Nicolas knows this area
>> better than me.
>
> Do you mean that :parent property may not always be present?
I don't know, I hope Nicolas can handle this.
--
Bastien
"Fraga, Eric" writes:
> On Wednesday, 5 Feb 2020 at 09:14, Bastien wrote:
>
> [...]
>
>> Org-mode sets:
>>
>> (modify-syntax-entry ?< "(>")
>> (modify-syntax-entry ?> ")<")
>>
>> should we adapt Org's default syntax?
>
> Difficult to judge but my gut feeling would be to leave as is.
Okay, d
> Probably the docstring needs to be adapted - Nicolas knows this area
> better than me.
Do you mean that :parent property may not always be present?
If so, it is quite disappointing. It would be helpful to be able to find
parent of any element at point (especially, in conjunction with
org-elemen
On Wednesday, 5 Feb 2020 at 09:14, Bastien wrote:
[...]
> Org-mode sets:
>
> (modify-syntax-entry ?< "(>")
> (modify-syntax-entry ?> ")<")
>
> should we adapt Org's default syntax?
Difficult to judge but my gut feeling would be to leave as is. My use
case involves significant amount of cod
Hi all,
Org 9.3.3, a bugfix release, is out.
Enjoy!
--
Bastien
Hi Ihor,
this is fixed in maint now, thanks!
--
Bastien
Hi Brian,
if you can write a patch for this enhancement, that would be nice.
Thanks,
--
Bastien
Hi Arne,
can you provide a patch for this?
Thanks!
--
Bastien
Hi Eric,
"Fraga, Eric" writes:
> I have the following 2 lines in my org-mode-hook to cater for this issue
> which arises when using source blocks.
>
> (modify-syntax-entry ?< ".")
> (modify-syntax-entry ?> ".")
Org-mode sets:
(modify-syntax-entry ?< "(>")
(modify-syntax-entry ?> ")
Le mer. 5 févr. 2020 à 07:25, Bastien a écrit :
> Hi Steve,
>
> thanks for reporting this issue. Can you or Fabrice suggests what
> change should be done in Org, if any? Also, perhaps another solution
> can be found by adapting `org-file-apps'?
>
>
I am not sure that it is an issue that should
Hi Charles,
Charles Millar via Emacs-orgmode writes:
> In an org file I have a source code block to convert entries into and
> generate a recutils file
>
> #+begin_src sh?? :file SomeFile.rec
> cat << EOF
> # -*- mode: rec -*-
>
> Begin recutils file
>
> Approximately 770 records in recuti
Hi,
rrandr...@gmail.com 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 the Org mailing list
47 matches
Mail list logo
