Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Fraga, Eric
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 because you mean intra-paragraph navigation
as opposed to M-{ and M-} for navigating from paragraph to paragraph?

Maybe auto-fill-mode is what you want?

In any case, the solution may simply be some example org mode hooks
with, say, settings for writing prose and have these in the org mode
manual?

Fundamentally, emacs is challenging because it is both powerful and
completely customizable.  I remember a colleague complaining that Linux
was not friendly because you had too much choice.  Emacs takes that to
another level.  And that's why many of us live in it... 
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48



Re: commit "328c9a1af * bad org.el: Enhance menus" caused error

2020-02-05 Thread stardiviner


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 =orgtbl-aggregate=, seems another package 
=orgtbl-ascii-plot= use
same code to define menu too. Here is its code:

#+begin_src emacs-lisp
;;;###autoload
(defun orgtbl-ascii-plot-bindings ()
  (org-defkey org-mode-map "\C-c\"a"  'orgtbl-ascii-plot)
  (org-defkey org-mode-map "\C-c\"g"  'org-plot/gnuplot)
  (easy-menu-add-item
   org-tbl-menu '("Column")
   ["Ascii plot" orgtbl-ascii-plot t]))

;;;###autoload
(if (functionp 'org-defkey)
(orgtbl-ascii-plot-bindings) ;; org-mode already loaded
  (setq org-load-hook;; org-mode will be loaded later
  (cons 'orgtbl-ascii-plot-bindings
(if (boundp 'org-load-hook)
  org-load-hook
#+end_src

Bastien, might consider add a hook after loaded org menus? Like named
~org-menu-after-loaded-hook~ or something else? So third libraries can define 
menu
entries with function added on the hook. I think those packages will have to
updated with patches?

-- 
[ 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: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Texas Cyberthal
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-tutorial and then log his efforts to learn
Emacs.

Eventually he will need to turn on truncation in Org to display inline
codelike elements properly, but until then he'll need his prose
paragraphs wrapped for him.

Correction:

I started an unmodified Spacemacs to check my memory of its Org
defaults. I was correct about Org recognizing single-space sentences
by default. I was wrong about Org using variable pitch with word
wrapping and without truncation by default. I'll certainly propose
that be changed there.

On the bright side, truncation is easily M-x discoverable with Helm,
and visual line mode is placed in an inferior position to truncation
in the keybinds: SPC-t-l for spacemacs/toggle-truncate-lines and
SPC-t-L for spacemacs/toggle-visual-line-navigation.

Now I'm wondering whether any distro ships an Org whose defaults
permit noobs to write prose paragraphs.

On Thu, Feb 6, 2020 at 10:33 AM Texas Cyberthal
 wrote:
>
> > 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. Visual line mode is annoying
> and unnecessary; Spacemacs users do not need it because its defaults
> offer adequate paragraph navigation.
>
> Org's default should be (truncate-lines nil) with paragraph navigation
> like Spacemacs, so that non-techie noobs can use it for text editing
> out of the box. Requiring them to try to figure out sane defaults for
> basic prose editing by trial and error drives too many away.
>
> To review why Org is so frustrating to new users out of the box, I
> turned on my vanilla Emacs and opened an Org file. I was unable to
> toggle line truncation from M-x completion, so I enabled
> visual-line-mode instead. This wrapped lines as desired, but left
> paragraph navigation broken.
>
> C-a/e org-end-of-line moves point to beginning/end of visual line, as
> the mode name suggests. This is not very useful, because C-n/p
> next-line also moves by visual lines, which in combination with M-f/b
> forward-word allows one to reach any column on the visual line, not
> just the beginning and end points. The visual beginning and ends of
> lines have no logical significance and thus there is no reason to give
> them the extra convenience of dedicated keybinds.
>
> M-a/e org-backward-sentence only works if one remembers to
> double-space after a period to denote the end of a sentence. Noobs are
> unlikely to realize this, and will instead wrongly conclude that it
> only detects paragraphs, since it does recognize a period followed by
> a line break as a sentence. Spacemacs recognizes a single space after
> the period as a sentence. Even if a user trains himself to always
> double-space after the end of a sentence, much of the text he imports
> into Org from other authors will not be formatted correctly.
>
> Most importantly, there is no keybind for next-logical-line, which is
> an important location in a paragraph. And there is no visual cue that
> a line break is visual rather than logical. The next paragraph
> navigation command level operates on paragraphs. C-down/up
> org-forward-paragraph skips multiple adjacent lines as one paragraph,
> treating line breaks in visual line mode the same as those in normal
> fill mode, even though the former are deliberately inserted as
> logically significant demi-paragraphs.
>
> So if one types a stream of consciousness:
>
> #+begin_quote
> Hm maybe i should do x
> or maybe y
> I guess I'll think about it further
> #+end_quote
>
> These demi-paragraphs get obliterated by visual line mode, if the
> lines are long.
>
> And that's assuming the noob knows to enable visual-line-mode in the
> first place!
>
> Ok, I just figured out that M-x trunc completion failed because the
> command is toggle-truncate-lines. That delivers a sane paragraph
> editing experience, except for the sentence detection issue. So
> toggle-truncate-lines needs an alias that starts with "truncat" so
> that noobs can find it, if it's not going to be enabled in Org by
> default.
>
> truncate-lines nil still doesn't result in readable prose in vanilla.
> The fixed pitch font with the continuation marks and the lack of word
> wrapping and the narrow line spacing makes a total mess.
>
> Meanwhile Spacemacs' Org paragraph navigation defaults are perfectly
> sane and pleasant. C-a/e runs mwim-beginning-of-code-or-line. Lines
> are wrapped and demi-paragraphs are preserved.
>
> Why does Org inflict such a frustrating experience on non-techie noobs
> when they attempt to 

Re: How to intersperse commands with their output in RESULTS block?

2020-02-05 Thread Fraga, Eric
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 try
using =script= as a starting point:

#+begin_src shell :results output
  script <

Re: commit "328c9a1af * bad org.el: Enhance menus" caused error

2020-02-05 Thread stardiviner


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 load Org from source code.

Then load package =orgtbl-aggregate=.

#+begin_src emacs-lisp
(use-package orgtbl-aggregate
  :ensure t
  :commands (org-insert-dblock org-insert-dblock:aggregate)
  :config
  ;; add `orgtbl-aggregate' dynamic blocks into list.
  (org-dynamic-block-define "columnview" 'org-insert-dblock:columnview)
  (org-dynamic-block-define "aggregate" 'org-insert-dblock:aggregate)
  (org-dynamic-block-define "invoice" 'org-insert-dblock:invoice)
  (org-dynamic-block-define "join" 'org-insert-dblock:join)
  (org-dynamic-block-define "org-gantt" 'org-insert-dblock:org-gantt)
  (org-dynamic-block-define "propview" 'org-insert-dblock:propview)
  (org-dynamic-block-define "transpose" 'org-insert-dblock:transpose))
#+end_src

Actually, it is because this package contains following code cause this problem:

#+begin_src emacs-lisp
;;;###autoload
(defun org-insert-dblock-bindings ()
  (org-defkey org-mode-map "\C-c\C-xi" 'org-insert-dblock)
  (easy-menu-add-item
   org-org-menu '()
   ["Insert Dynamic Block" org-insert-dblock t] "Agenda Command..."))

;;;###autoload
(if (functionp 'org-defkey)
(org-insert-dblock-bindings) ;; org-mode already loaded
  (setq org-load-hook;; org-mode will be loaded later
(cons 'org-insert-dblock-bindings
  (if (boundp 'org-load-hook)
  org-load-hook
#+end_src

Maybe because I just use =use-package= autoload for =orgtbl-aggregate= instead 
of
fully required? I tested that now by removing ~:commands~ part so that 
use-package
will not load delayed. Still has this error.

-- 
[ 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: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Texas Cyberthal
> 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. Visual line mode is annoying
and unnecessary; Spacemacs users do not need it because its defaults
offer adequate paragraph navigation.

Org's default should be (truncate-lines nil) with paragraph navigation
like Spacemacs, so that non-techie noobs can use it for text editing
out of the box. Requiring them to try to figure out sane defaults for
basic prose editing by trial and error drives too many away.

To review why Org is so frustrating to new users out of the box, I
turned on my vanilla Emacs and opened an Org file. I was unable to
toggle line truncation from M-x completion, so I enabled
visual-line-mode instead. This wrapped lines as desired, but left
paragraph navigation broken.

C-a/e org-end-of-line moves point to beginning/end of visual line, as
the mode name suggests. This is not very useful, because C-n/p
next-line also moves by visual lines, which in combination with M-f/b
forward-word allows one to reach any column on the visual line, not
just the beginning and end points. The visual beginning and ends of
lines have no logical significance and thus there is no reason to give
them the extra convenience of dedicated keybinds.

M-a/e org-backward-sentence only works if one remembers to
double-space after a period to denote the end of a sentence. Noobs are
unlikely to realize this, and will instead wrongly conclude that it
only detects paragraphs, since it does recognize a period followed by
a line break as a sentence. Spacemacs recognizes a single space after
the period as a sentence. Even if a user trains himself to always
double-space after the end of a sentence, much of the text he imports
into Org from other authors will not be formatted correctly.

Most importantly, there is no keybind for next-logical-line, which is
an important location in a paragraph. And there is no visual cue that
a line break is visual rather than logical. The next paragraph
navigation command level operates on paragraphs. C-down/up
org-forward-paragraph skips multiple adjacent lines as one paragraph,
treating line breaks in visual line mode the same as those in normal
fill mode, even though the former are deliberately inserted as
logically significant demi-paragraphs.

So if one types a stream of consciousness:

#+begin_quote
Hm maybe i should do x
or maybe y
I guess I'll think about it further
#+end_quote

These demi-paragraphs get obliterated by visual line mode, if the
lines are long.

And that's assuming the noob knows to enable visual-line-mode in the
first place!

Ok, I just figured out that M-x trunc completion failed because the
command is toggle-truncate-lines. That delivers a sane paragraph
editing experience, except for the sentence detection issue. So
toggle-truncate-lines needs an alias that starts with "truncat" so
that noobs can find it, if it's not going to be enabled in Org by
default.

truncate-lines nil still doesn't result in readable prose in vanilla.
The fixed pitch font with the continuation marks and the lack of word
wrapping and the narrow line spacing makes a total mess.

Meanwhile Spacemacs' Org paragraph navigation defaults are perfectly
sane and pleasant. C-a/e runs mwim-beginning-of-code-or-line. Lines
are wrapped and demi-paragraphs are preserved.

Why does Org inflict such a frustrating experience on non-techie noobs
when they attempt to draft their first raw notes into Org? How can
this possibly be optimal? If the plan is to prevent consumer adoption
of Org as a Personal Info Manager, it's working.

> May I suggest that you propose your changes on the Spacemacs repo.

In this case, I am suggesting Org adopt what Spacemacs already has.

Regarding the assertion that Emacs is doing just fine on noob
friendliness, this is false, as I demonstrated in my most recent post:
https://cyberthal-ghost.nfshost.com/emacs-needs-a-starter-zone-and-org-is-it/

The existence of B2C tech support for Linux but not Emacs demonstrates
that the former is sufficiently noob friendly and the latter isn't.

I don't particularly care whether noob intake is delegated to distros
or vanilla, but splitting the job between the two isn't working.



Re: latex fragments in html export

2020-02-05 Thread Matt Huszagh
Nvm, I found the issue.



make org-insert-dblock:columnview more calendar like?

2020-02-05 Thread Uwe Brauer
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 :Amnu:
<2019-02-15 Fri> 

Which is then converted via  org-insert-dblock:columnview to 


#+BEGIN: columnview :hlines 1 :id local
| TIMESTAMP| ITEM   |
|--+|
|  | Amnu   |
| <2019-02-01 Fri> | First contact  |
| <2019-02-08 Fri> | GramSchmidt and Householder|
| <2019-02-15 Fri> | Finish Householder, start power and QR |
#+END:


Is there any other function, or package which would generate a more
calendar like view?

Thanks and regards

Uwe Brauer 

* 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 :Amnu:




Re: [BUG] Infinite loop in org-agenda-show-new-time

2020-02-05 Thread Matthew Lundin
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 function for a reason, but I don't know
>> what that reason was.
>
> I think this approach is correct is it will move over visible lines.
>
> I've pushed a patch, please let me know if it is fixed.

I'm finding that this patch (19676dce758038749887a057208ea33d9a1fad57)
has the by-product of causing multiple paths to flash in the mini-buffer
if org-agenda-show-outline-path is set to t. I believe that is because
it calls org-agenda-previous-line, which in turn calls
org-agenda-do-context-action.

The effect is even more pronounced if org-agenda-follow-mode is on,
causing a significant slowdown in rescheduling items.

Thanks,

Matt



local toc automatic?

2020-02-05 Thread Samuel Wales
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 that if there are any
entries that are 2 levels below it, a toc should be created 1 level
below it to list them?

* a
#+TOC: headlines 1
** b
** c
#+TOC: headlines 1 local
*** d
*** e

i am proposing to eliminate the need to manually enter the toc for c
in the examlpe above.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.



latex fragments in html export

2020-02-05 Thread Matt Huszagh
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 and
set up debug points in a bunch of functions meant to process latex
fragments, but none of them are being called.

Thanks
Matt



Re: Folding whitespace at the end of a tree

2020-02-05 Thread knoll

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,





How to intersperse commands with their output in RESULTS block?

2020-02-05 Thread Diego Zamboni
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 console
> echo "hi"
hi
> echo "bye"
bye
#+end_src

This works well for my use case - "console" blocks are understood nicely by
Pygmentize as containing both commands and output.

What I would like is to start using org-babel to run the commands and
insert their output in the export, so that I can update the examples
without having to copy-paste from the terminal. So what I would like is to
have something like this:

#+begin_src sh :exports results :wrap "src console"
echo "hi"
echo "bye"
#+end_src

And when I evaluate the block with C-c C-c, I get:

#+results:
#+begin_src console
> echo "hi"
hi
> echo "bye"
bye
#+end_src

Before I start building my own, ob-mode I was wondering if anyone knows of
any existing way to achieve this.

Thanks!
--Diego


Re: attachment: link type export to HTML invalid attach dir

2020-02-05 Thread Nicolas Goaziou
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 clear, I firmly believe Element library should be as
low-level as possible. Ideally (we're not there yet), it should not
depend on any other part of Org. It should be the step (largely) above
"re-search-forward".

So, extending the parser to include knowledge to some other library in
Org is not an option. Element is expected to dumbly stick to Org syntax,
without knowing what it means.

> My suggestion to the link parser would be to have the following properties as 
> the catch-all properties for links:
> - type :: Which type of link protocol applies. E.g. file, http, ftp, 
> attachment, duckduckgo (ex. for a custom link abbreviation to search ddg)
> - raw-path :: The path to use for the particular protocol. Would contain 
> everything in the link following "protocol:"
> - format :: Which format the link has. Plain, bracket or angular bracket

Barring custom link abbreviations, this is already the case.

> - description :: The description part of the link 
> ([[protocol:path][description]])

Description is not meaningful here. This is parsed content.

> - begin, end, post-blank :: The default properties used for all elements. Not 
> sure if contents-begin and contents-end are a part here as well.

They are when the link has contents, i.e., a description.

> As you've stated previously, from a performance perspective maybe it
> will be best to not expand the specific properties and instead let the
> expansion of those be handled in code by the link type owner (e.g.
> org-attach.el for attachment links).

More than performance, this is a design issue.

> Ah yes. Just briefly looking at the docview code. Docview doesn't seem
> to use the parser when extracting information about that "go to page"
> information from the link. Which means docview links doesn't really
> care how the link information is encoded in the parser anyways.

Indeed. However, higher level functions, e.g., org-open-link, do care
about it and ensure that "ol-docview.el" really processes a link.

> Maybe if docview were allowed to encode custom docview information
> into the parsed link in the parser it and others could reused that
> encoded information later? Docview would be able to add
> a ":go-to-page" option, for example. Just a thought.

I'm quite sure this is a wrong way to go.

> Most link types probably won't need custom link properties anyways.
> But could maybe let the parser know stuff by use of higher order
> functions? Or push for being important enough to be included into Org
> and allowed to be known by the parser.

Only syntax changes can go into the parser. Attachment links are regular
links, not something that requires extending Org's syntax. Note that
this is not the case of file links, which have a special syntax, e.g.,
[[./cat.jpg]].

> Ok, got it. Thanks for explaining. I'll admit it hasn't been totally
> clear to me what the best way forward is. After refreshing my
> understanding on links the conclusion I came to was that link
> abbreviations in its current form was not a fitting concept for
> attachment links. Attachments are pretty much similar to file links
> though, so even if my intention isn't to blur the meaning they will
> and should be treated very similar, since functionality is so similar.

Functionality may be familiar, but their syntax is not the same,
therefore, the differences should be handled elsewhere.

> Speaking from the perspective of attachment links, if there were
> a file link type exporter function available that could be used by
> attachment links without code duplication.

Where would live that function? ox.el is not an option since every
exporter treats file links differently.

As suggested already (I think) we could add a phase in ox.el that would
expand attachment links into their file link counterpart automatically.
This would avoid adding specific code in every export back-end. However,
export back-end would miss the opportunity to handle attachment links
specifically. This is one way or the other.

> Yes, and the function that implements that would also need the user
> argument as input. In addition to the link path.

Patch welcome. I see no objection to extending :follow link parameter in
"ol.el".

> Anyways, patch attached that makes org-element not know about
> attachments any longer, and moves most of the responsibility to
> org-attach.el. The exporters still needs to know to use the new
> function inside org-attach.el though.

Thank you. Please apply it. 

Now we can try improving the situation for exporters.

Regards,

-- 
Nicolas Goaziou



Re: [BUG] Infinite loop in org-agenda-show-new-time

2020-02-05 Thread Andrew Hyatt
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:
>
> > 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 function for a reason, but I don't know
> > what that reason was.
>
> I think this approach is correct is it will move over visible lines.
>
> I've pushed a patch, please let me know if it is fixed.
>
> Best,
>
> --
>  Bastien
>


Re: commit "328c9a1af * bad org.el: Enhance menus" caused error

2020-02-05 Thread Bastien
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



Re: org-adapt-indentation default should be nil [legibility 3/6]

2020-02-05 Thread Adam Porter
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 what you mean, either, but you keep mentioning Spacemacs,
which isn't very relevant.

>> without any indentation, headings and entry text on varying levels
>> tends to blend together, making for very poor readability.
>
> If the goal is to read the body text of headings, then deeply
> indenting it is contrary to the goal. If the goal is to see the depth
> of headings, then the bodies should be folded. If folded mode doesn't
> convey sufficient information, the solution is to rewrite the heading
> titles to better summarize the body text.

It is not for you to decide what others should do.  Your preferences are
not mine.  It sounds like you should develop your own "Texas Cyberthal
Emacs starter kit" that has all the settings you think are best.

>> No one is "good at" Emacs and Org when they first come to it.
>
> UI difficulty is exponential, not linear.

Come on, we all know that the Emacs learning curve is a spiral.

> The more initially difficult the Emacs UI is acknowledged to be, the
> more important it is to reduce that difficulty with noob-friendly
> defaults, so that they can eventually reach the point of elitist
> unconcern for noobs.

The issue here is not whether Emacs can generally be improved, but
whether your specific proposals are good ideas.

It's unfriendly of you--and incorrect--to imply that we are elitists
without concern for new users.  Much effort is put into improving
documentation, answering questions, writing explanatory articles, giving
demonstrations, etc.  Some of us even publish code to help others
improve their configs, e.g. https://github.com/alphapapa/alpha-org.  I
suggest that you give those avenues a try, rather than insisting that
your preferences are best for others.

> The problem with aiming software at noobs is ruining the expert
> experience.

That is one problem with software that overemphasizes the experience of
new users.  Another, perhaps more serious, problem is that it inhibits
the development of such expertise.  I feel like some of ESR's writings
are relevant here.

> Changing defaults doesn't ruin expert experience because experts have
> configuration management.

A VCS does not obviate the need to compensate for changes in default
behavior.

> Noob friendly defaults increases the likelihood there is a long term
> for them.  Emacs' biggest barrier to adoption is acclimatization.

You're not quite wrong, but you're missing the point about long-term
users.  What makes software attractive in the long-term is not what
makes it appeal to new users.  Emacs is not called "the editor of a
lifetime" for nothing--nor is notepad.exe called that, even though it is
very easy for new users to use.  Emacs is attractive in the long-term
because of its power, flexibility, and potential for mastery.  There is
a balance to be struck between appealing to new users and empowering the
development of expertise; to an extent, the two goals do conflict.

> I just read a GTD thread in which they all agreed Org was too hard to
> be worth learning, including the guy advocating it:
>
> https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2
>
> To be clear, this is the biggest GTD forum, which Org is the best
> implementation of, and it seems most of them are using digital GTD
> tools.

So what?  Emacs and Org do not need to adapt themselves to users who do
not like them.  They are successful because of what they are.

You seem very concerned about new users, thinking that, unless we make
Emacs/Org very easy for new users to understand, there will be no new
users.  This is obviously not the case.  Emacs is one of the oldest
pieces of software still widely used.  It and Org are gaining new users
every day; the community is more vibrant than ever.  Probably more
people use Emacs and Org today than ever before.

Consider an analogy: Years ago, Mozilla Firefox was the fastest, most
powerful, most popular browser that wasn't imposed on its users.  It was
the obvious victor in the "browser wars," having led the way in
unseating IE and freeing the Web from Microsoft's hegemony.  Then Google
Chrome arose as a challenger, with certain inherent advantages due to
Google's position.  Mozilla then chose to stop leading and start
following.  Every new Firefox release became more like Chrome, with
Mozilla thinking that it could win back users.  But why would a user who
was happy with Chrome want to switch to a poor imitation of it?  Mozilla
thought it could succeed by abandoning what had made it successful--it
thought Firefox would be more popular if it stopped being Firefox.  The
result was continued decline in Firefox's market share and, eventually,
Mozilla's 

Important request, participation in software development study

2020-02-05 Thread ivandarioarroyo
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.

According to 9 investigations, UML is not being used as it should, but the 
developers use their own models, designed by them or by their companies. 
However, these investigations have not included professionals like you, so I 
want to ask you to help me by answering this survey:

If you have a Google account:
https://docs.google.com/forms/d/e/1FAIpQLSdG4bhNWfU3vzSKwG-0j8NuGW47_xmSY1ftF33gaNAZsU25kA/viewform

Reply without logging in:
https://docs.google.com/forms/d/e/1FAIpQLSeNm99cxIyT65-5qR6ZCZoDNeFONTf_ODWbXaSxUskkxbWu4g/viewform

I also ask you to send this survey to other developers that you know and 
respect.

Please help me, I promise that your contributions will be recognized in the 
publications that are possible, therefore, as an optional field I have included 
the name and email. My biggest goal is to unify all non-formal models to create 
a modeling language that is the heritage of the industry, built by all of us. 
If you want to know more, you can write to me at ivan.arr...@uma.es, 
ivandarioarr...@gmail.com or arco...@gmail.com
!!THANKS



commit "328c9a1af * bad org.el: Enhance menus" caused error

2020-02-05 Thread stardiviner


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-insert-dblock-bindings()
  run-hooks(org-load-hook)
  eval-buffer(# nil 
"/home/stardiviner/Code/Emacs/org-mode/lisp/org.el" nil t)  ; Reading at buffer 
position 832102
  load-with-code-conversion("/home/stardiviner/Code/Emacs/org-mode/lisp/org.el" 
"/home/stardiviner/Code/Emacs/org-mode/lisp/org.el" nil t)
  require(org)
  eval-buffer(# nil 
"/home/stardiviner/.config/emacs/elpa/org-20190211/..." nil t)  ; Reading at 
buffer position 1257
  
load-with-code-conversion("/home/stardiviner/.config/emacs/elpa/org-20190211/..."
 "/home/stardiviner/.config/emacs/elpa/org-20190211/..." t t)
  require(org-info nil t)
  (not (require 'org-info nil t))
  (if (not (require 'org-info nil t)) (display-warning 'use-package (format 
"Cannot load %s" 'org-info) :error))
  (prog1 (if (not (require 'org-info nil t)) (display-warning 'use-package 
(format "Cannot load %s" 'org-info) :error)) (let ((elapsed (float-time 
(time-subtract (current-time) now (if (> elapsed 0.1) (message "%s...done 
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading 
package org-info"
  (let ((now (current-time))) (message "%s..." "Loading package org-info") 
(prog1 (if (not (require 'org-info nil t)) (display-warning 'use-package 
(format "Cannot load %s" 'org-info) :error)) (let ((elapsed (float-time 
(time-subtract (current-time) now (if (> elapsed 0.1) (message "%s...done 
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading 
package org-info")
  (condition-case err (let ((now (current-time))) (message "%s..." "Loading 
package org-info") (prog1 (if (not (require 'org-info nil t)) (display-warning 
'use-package (format "Cannot load %s" 'org-info) :error)) (let ((elapsed 
(float-time (time-subtract ... now (if (> elapsed 0.1) (message "%s...done 
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading 
package org-info") ((debug error) (funcall use-package--warning152 :catch 
err)))
  eval-buffer(# nil 
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)  ; Reading at 
buffer position 6453
  
load-with-code-conversion("/home/stardiviner/.config/emacs/init/org-mode/init..."
 "/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)
  require(init-org-hyperlink)
  eval-buffer(# nil 
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)  ; Reading at 
buffer position 518
  
load-with-code-conversion("/home/stardiviner/.config/emacs/init/org-mode/init..."
 "/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)
  require(init-org-mode)
  eval-buffer(# nil "/home/stardiviner/.config/emacs/init.el" 
nil t)  ; Reading at buffer position 3704
  load-with-code-conversion("/home/stardiviner/.config/emacs/init.el" 
"/home/stardiviner/.config/emacs/init.el" t t)
  load("/home/stardiviner/.config/emacs/init" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) t)
  command-line()
  normal-top-level()
#+end_example

-- 
[ 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: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re: [PATCH] ob-sql.el support auto set sql-product in editing sql-mode src block buffer

2020-02-05 Thread stardiviner


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 just add an duplicate code of "postgresql" for 
> alias
> "postgres". Because I found only one exception "postgresql" is "postgres" in
> ~sql-mode~ products alist. Other database names are matched with ~sql-mode~.
>
> So I decided to take the simpler solution. I attached patch in the email 
> attachment.
>
> # 
> ==
>
> BTW, I'm still not good at Elisp, can't write out a good solution for 
> translate
> and matching for database names.
>
> Here is my temporary databases alist:
>
> #+begin_src diff
> modified   lisp/ob-sql.el
> @@ -87,6 +87,52 @@ (defconst org-babel-header-args:sql
>  (database   . :any))
>"SQL-specific header arguments.")
>  
> +(defcustom org-babel-sql-engines-alist nil
> +  "Alist of engine names for :engine header argument.
> +
> +It is an alist data structure: ( . (list of alias names)).
> +Merged with sql-mode's `sql-product-alist'."
> +  :type '(alist :key-type symbol :value-type list)
> +  :group 'org-babel)
> +
> +;;; initialize `org-babel-sql-engines-alist'
> +(dolist (product (mapcar 'car sql-product-alist))
> +  (pcase product
> +(`ansi
> + (add-to-list 'org-babel-sql-engines-alist (cons 'ansi (list 'ansi
> +(`sqlite
> + (add-to-list 'org-babel-sql-engines-alist (cons 'sqlite (list 
> 'sqlite
> +(`mysql
> + (add-to-list 'org-babel-sql-engines-alist (cons 'mysql (list 'mysql
> +(`mariadb
> + (add-to-list 'org-babel-sql-engines-alist (cons 'mariadb (list 'mariadb 
> 'maria
> +(`postgresql
> + (add-to-list 'org-babel-sql-engines-alist (cons 'postgresql (list 
> 'postgresql 'postgres
> +(`oracle
> + (add-to-list 'org-babel-sql-engines-alist (cons 'oracle (list 
> 'oracle
> +(`mssql
> + (add-to-list 'org-babel-sql-engines-alist (cons 'mssql (list 'mssql 
> 'ms
> +(`dbi
> + (add-to-list 'org-babel-sql-engines-alist (cons 'dbi (list 'dbi
> +(`monetdb
> + (add-to-list 'org-babel-sql-engines-alist (cons 'monetdb (list 
> 'monetdb
> +(`sqsh
> + (add-to-list 'org-babel-sql-engines-alist (cons 'sqsh (list 'sqsh
> +(`vertica
> + (add-to-list 'org-babel-sql-engines-alist (cons 'vertica (list 
> 'vertica
> +(`db2
> + (add-to-list 'org-babel-sql-engines-alist (cons 'db2 (list 'db2
> +(`infomix
> + (add-to-list 'org-babel-sql-engines-alist (cons 'infomix (list 
> 'infomix
> +(`ingres
> + (add-to-list 'org-babel-sql-engines-alist (cons 'ingres (list 
> 'ingres
> +(`interbase
> + (add-to-list 'org-babel-sql-engines-alist (cons 'interbase (list 
> 'interbase
> +(`solid
> + (add-to-list 'org-babel-sql-engines-alist (cons 'solid (list 'solid
> +(`sybase
> + (add-to-list 'org-babel-sql-engines-alist (cons 'sybase (list 
> 'sybase))
> +
>  (defun org-babel-expand-body:sql (body params)
>"Expand BODY according to the values of PARAMS."
>(org-babel-sql-expand-vars
>
> #+end_src
>
> I don't know how to write a translation function for alist to be used in 
> function ~org-babel-execute:sql~.
>
> #+begin_src emacs-lisp :eval no
> (defun org-babel-execute:sql (body params)
>   "Execute a block of Sql code with Babel.
> This function is called by `org-babel-execute-src-block'."
>   (let* ((result-params (cdr (assq :result-params params)))
>  (cmdline (cdr (assq :cmdline params)))
>  (dbhost (org-babel-find-db-connection-param params :dbhost))
>  (dbport (org-babel-find-db-connection-param params :dbport))
>  (dbuser (org-babel-find-db-connection-param params :dbuser))
>  (dbpassword (org-babel-find-db-connection-param params :dbpassword))
>  (database (org-babel-find-db-connection-param params :database))
>  (engine (cdr (assq :engine params)))
>  (colnames-p (not (equal "no" (cdr (assq :colnames params)
>  (in-file (org-babel-temp-file "sql-in-"))
>  (out-file (or (cdr (assq :out-file params))
>(org-babel-temp-file "sql-out-")))
>(header-delim "")
>  (command (pcase (intern engine)
> (`dbi (format "dbish --batch %s < %s | sed '%s' > %s"
> (or cmdline "")
> (org-babel-process-file-name in-file)
> "/^+/d;s/^|//;s/(NULL)/ /g;$d"
> (org-babel-process-file-name out-file)))
> (`monetdb (format "mclient -f tab %s < %s > %s"
> (or cmdline "")
> 

Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Adam Porter
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 Spacemacs solved it. Now I know even less about it than
> I did then, because there's no need to know. A brief investigation
> shows Spacemacs sets (line-move-visual t) in prosey text modes, so
> that C-n next-line operates on visual lines. However commands such as
> C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
> default that permits fluid navigation of paragraphs, which is all a
> noob wants to do.
>
> Similarly, I almost never use truncate-lines, to the point that I had
> to websearch to recall what it was called within the last week.

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.

May I suggest that you propose your changes on the Spacemacs repo.




ob-clojure :var header argument not work when src block is noweb called by another src block

2020-02-05 Thread stardiviner


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> 84a1210d836742ca71c776aaebba0e0224af]: 
read-in-wxid
: #'user/files

#+begin_src clojure :noweb yes :results pp
<>
(take 3 files)
#+end_src

#+RESULTS[<2019-08-28 09:12:30> 9bbcd9f779f72bdd9b7bb8fb85aa36bbdfee7e3c]:
: class clojure.lang.Compiler$CompilerExceptionclass 
clojure.lang.Compiler$CompilerExceptionSyntax error compiling at (*Org Src 
Code.org[ clojure ]*:3:16).
: Unable to resolve symbol: cwd in this context


-- 
[ 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: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-05 Thread Adam Porter
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 improve some Emacs defaults; there are active
threads on emacs-devel about it now.

However, the question of to what degree Emacs should target certain
types of users is a wider one, and answering it one way or the other
doesn't necessarily support your proposed changes.

> Probably vets should use legible settings as well. I became accustomed
> to less-legible Org settings, and thought they were superior. But when
> I cleaned up my Spacemacs config, I incidentally restored some default
> legibility tweaks I'd disabled. After a brief exposure, I realized the
> tweaks were superior, and that my preferences had been wrong. Changing
> the defaults can overcome vet inertia and improve their UI.

It's neither the spirit nor practice of Emacs to tell users what
settings they should use.  Emacs exists to empower users to meet their
needs according to their preferences.

It is not for you, nor us, to decide whether certain users are suffering
from "inertia" which we ought to overcome on their behalf for the sake
of improving their UI.  That is for them to decide, not us.  This is
Emacs, not Apple, Inc.

>> Terminals can display colors, underlines, italics, and bold text
>
> Proposed legibility changes don't affect those font aspects.

I was responding to this claim of yours:

>>> Concerns about terminal impact appear to be moot, since terminal
>>> ignores most font settings.

So your claim has been clarified from "terminals ignore most font
settings" to "my proposed changes don't affect the font aspects that
terminals display."

Please quote enough of the message you're replying to so that the
conversation can be easily followed (by me, if no one else).





Re: commit "328c9a1af * bad org.el: Enhance menus" caused error

2020-02-05 Thread stardiviner


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: F09F650D7D674819892591401B5DF1C95AE89AC3
  



New file org-refile.el

2020-02-05 Thread Bastien
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



Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread Nicolas Goaziou
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 library.
>> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
>> and as accurate. I.e., the code operating on headlines is usually
>> distinct from the code handling other elements.
>
> Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of
> my agenda generation time (I have really huge number of headings +
> multiple custom skip functions). I was hoping to use cache for speed
> up. 

Cache will not help you here. `org-up-heading-safe' and
`org-back-to-heading' are faster than `org-element-at-point' + cache.

Moreover, custom skip functions are a pain. They prevent any form of
caching during agenda creation. IMO, Agenda (or its re-implementation)
should do without them.

>> You can parse the full document and get all the :parent properties
>> filled. That's not the job for `org-element-at-point'.
>
> I once tried to do exactly this, but I did not manage to figure out how
> to obtain element at point from full parse tree (from inside an agenda
> skip function). Is it possible?

It is possible but not implemented.

>> Note that `org-element-cache' was disabled a while ago because it could
>> introduce freezes. I think this is related to how this part handles
>> `before-change-functions' and `after-change-functions'. Anyway, YMMV.
>
> I see... I don't know how useful the cache is except my idea about
> using cache to speed up agenda. But I was stuck with the :parent
> property issue and did not play much further since that time.

I once started to implement Agenda-specific caching, but stopped as it
would have entailed rewriting much of the Agenda code. It would have
been a pain. Even switching "org-agenda.el" to lexical binding is
difficult (and isn't done yet).

Some re-implementation of Agenda (e.g., org-super-agenda + org-ql) may
be better wrt caching.



Re: Make code elements in prose unobtrusive [legibility 6/6]

2020-02-05 Thread Russell Adams
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 personal.  ;)
>
> I strongly agree. All of the changes mentioned in these legibility
> threads could be accomplished through theming and Elpa/Melpa packages

I've been monitoring this thread, and I have to agree strongly with the idea of
themes. I think if you feel strongly about the newbie experience, maybe you can
help setup and maintain a single binary Emacs distro with your theme as the
default.

I'm the complete opposite of the original poster in all of these threads. I
avoid applications with variable width fonts. I treasure that my terminals all
have the same fixed width font and it isn't overridden by every document or
application. I find variable fonts to be an aesthetic hassle. I wish I could
read more items on my terminal or in fixed width in Emacs. It's very high speed
and consistent. The modern web is a particular hassle with bright backgrounds
and highly inconsistent and illegible fonts.

However, if that's what makes you happy in Emacs, feel free to customize it that
way. You can always have it your way in your config. ;]


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3



Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread Ihor Radchenko
> `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 because of docstring, though it is
clear from the source code. 

> Luckily, headlines are exactly where you do _not_ need Element library.
> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
> and as accurate. I.e., the code operating on headlines is usually
> distinct from the code handling other elements.

Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of
my agenda generation time (I have really huge number of headings +
multiple custom skip functions). I was hoping to use cache for speed up. 

> You can parse the full document and get all the :parent properties
> filled. That's not the job for `org-element-at-point'.

I once tried to do exactly this, but I did not manage to figure out how
to obtain element at point from full parse tree (from inside an agenda
skip function). Is it possible?

> Note that `org-element-cache' was disabled a while ago because it could
> introduce freezes. I think this is related to how this part handles
> `before-change-functions' and `after-change-functions'. Anyway, YMMV.

I see... I don't know how useful the cache is except my idea about
using cache to speed up agenda. But I was stuck with the :parent
property issue and did not play much further since that time.

Best,
Ihor

Nicolas Goaziou  writes:

> 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 element, i.e., from an element, you
> cannot go up to the headline just following :parent.
>
> Luckily, headlines are exactly where you do _not_ need Element library.
> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
> and as accurate. I.e., the code operating on headlines is usually
> distinct from the code handling other elements.
>
>> 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-element-cache). At least, optionally. 
>
> You can parse the full document and get all the :parent properties
> filled. That's not the job for `org-element-at-point'.
>
>> I was counting on this feature to try speeding up my agenda generation
>> (using org-element-cache).
>
> Note that `org-element-cache' was disabled a while ago because it could
> introduce freezes. I think this is related to how this part handles
> `before-change-functions' and `after-change-functions'. Anyway, YMMV.
>
> Regards,
>
> -- 
> Nicolas Goaziou

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg



Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-05 Thread Texas Cyberthal
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/



Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"

2020-02-05 Thread Bastien
Charles Millar  writes:

> I have not experienced this problem since I reported it.

Thanks for confirming!

-- 
 Bastien



Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread Nicolas Goaziou
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 element, i.e., from an element, you
cannot go up to the headline just following :parent.

Luckily, headlines are exactly where you do _not_ need Element library.
`org-back-to-heading' and `org-up-heading-safe' will always be faster,
and as accurate. I.e., the code operating on headlines is usually
distinct from the code handling other elements.

> 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-element-cache). At least, optionally. 

You can parse the full document and get all the :parent properties
filled. That's not the job for `org-element-at-point'.

> I was counting on this feature to try speeding up my agenda generation
> (using org-element-cache).

Note that `org-element-cache' was disabled a while ago because it could
introduce freezes. I think this is related to how this part handles
`before-change-functions' and `after-change-functions'. Anyway, YMMV.

Regards,

-- 
Nicolas Goaziou



Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"

2020-02-05 Thread Charles Millar

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 770 records in recutils format each with about 20 entries;
over 17,000 lines including line feeds or carriage returns

#+end_src

The following error is produced:

Starting new Ispell process /usr/bin/aspell with en_US dictionary...
executing Sh code block...
Wrote /tmp/babel-k8j93s/ob-input-LL2cYo
Error reading results: (user-error Region is longer than
???org-table-convert-region-max-lines??? (999) lines; not converting)
Code block produced no output.


This bug is quite old -- before I try to digg in, can you confirm it
is still present with latest Org version from the maint branch?

Thanks!



I have not experienced this problem since I reported it.

As I recall at a later date you pointed out that I should have inserted
the header :results file.

Thanks

Charlie Millar




Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]

2020-02-05 Thread Bastien
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



Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]

2020-02-05 Thread Gustavo Barros

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.



Re: Bug: wsl org-open-at-point [9.1.14 (9.1.14-9-g131531-elpa @ /home/boss5/.emacs.d/elpa/org-20181112/)]

2020-02-05 Thread Bastien
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



Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread 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



Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

2020-02-05 Thread 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, done :)

-- 
 Bastien



Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread Ihor Radchenko
> 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-element-cache). At least, optionally. 

I was counting on this feature to try speeding up my agenda generation
(using org-element-cache).

Best,
Ihor


Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>> According to org-element-at-point docstring, "Properties depend on
>> element or object type, but always include :begin, :end, :parent and
>> :post-blank properties.".
>
> Probably the docstring needs to be adapted - Nicolas knows this area
> better than me.
>
> Best,
>
> -- 
>  Bastien

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg



Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

2020-02-05 Thread Fraga, Eric
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 coding, where < and > are logical
operators.  However, for many, these may make more sense as brackets.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf



Release 9.3.3

2020-02-05 Thread Bastien
Hi all,

Org 9.3.3, a bugfix release, is out.

Enjoy!

-- 
 Bastien



Re: Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2020-02-05 Thread Bastien
Hi Ihor,

this is fixed in maint now, thanks!

-- 
 Bastien



Re: Bug: LaTeX output of numbered TODO plain list items lose numbering. [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/27.0.50/lisp/org/)]

2020-02-05 Thread Bastien
Hi Brian,

if you can write a patch for this enhancement, that would be nice.

Thanks,

-- 
 Bastien



Re: Bug: export html with nice urls [9.1.9 (release_9.1.9-65-g5e4542 @ /gnu/store/djza93lqjcndsldf4794bp8mvipd6fz4-emacs-26.3/share/emacs/26.3/lisp/org/)]

2020-02-05 Thread Bastien
Hi Arne,

can you provide a patch for this?

Thanks!

-- 
 Bastien



Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]

2020-02-05 Thread 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 ?> ")<")

should we adapt Org's default syntax?

-- 
 Bastien



Re: Bug: wsl org-open-at-point [9.1.14 (9.1.14-9-g131531-elpa @ /home/boss5/.emacs.d/elpa/org-20181112/)]

2020-02-05 Thread Fabrice Popineau
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 be solved by org-mode.
It is more a problem of setting up WSL such that it meets well
some expectations. Basically, you need an equivalent of xdg-open
which redirects requests to the w32 system.

The suggestion I made to solve the issue is working for me, but as you see,
it is a crude hack: the paths need to be adapted to each individual
setting.

If someone comes up with a cleaner, more general solution, solution,
it should be published somewhere as an example of how to setup things with
WSL.

Fabrice


Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"

2020-02-05 Thread Bastien
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 recutils format each with about 20 entries; 
> over 17,000 lines including line feeds or carriage returns
>
> #+end_src
>
> The following error is produced:
>
> Starting new Ispell process /usr/bin/aspell with en_US dictionary...
> executing Sh code block...
> Wrote /tmp/babel-k8j93s/ob-input-LL2cYo
> Error reading results: (user-error Region is longer than 
> ???org-table-convert-region-max-lines??? (999) lines; not converting)
> Code block produced no output.

This bug is quite old -- before I try to digg in, can you confirm it
is still present with latest Org version from the maint branch?

Thanks!

-- 
 Bastien



Re: Bug: calling org-agenda-list programatically when starting with emacs --daemon [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

2020-02-05 Thread Bastien
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.
> 
>
> Hi.
>
> I usually start emacs with --daemon.
>
> At the end of my dot emacs I have a funct that calls or-agenda-list on a
> thread.
>
> When I call emacsclient  for opening a frame (the first frame) and try
> to visit a buffer (any buffer). I have an opened buffer
> *Backtrace* with this content:
>
> Debugger entered--Lisp error: (error "‘recenter’ing a window that
> does not display current-buffer.")

Fixed, thanks!

-- 
 Bastien