Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 13, 2018, at 7:48, Göktuğ Kayaalp  wrote:
> 
> People/packages can define their own keywords for in buffer settings,
> and again here translations can cause breakage.

That's a design problem, not a l10n problem.

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Link "bracket-types"

[Samuel Wales]

in case op or anybody else is wondering why i pasted random code, this
will show the link location when cursor is over the link.


On 5/10/18, Samuel Wales  wrote:
> (add-hook 'org-mode-hook 'alpha-eldoc-help-echo-mode)
> ;; fixme in elisp we want both link eldoc and elisp eldoc
> (defun hoka-eldoc-help-echo-at-point ()
>   "Eldoc thingy for help-echo text properties."
>   (let ((val (get-text-property (point) 'help-echo)))
> val))
> (defun alpha-eldoc-help-echo-mode ()
>   "Enable eldoc mode with e.g. org links to display in minibuffer
> when cursor is over them.  Call in the relevant buffer.  M-x
> eldoc-mode to turn off."
>   (interactive)
>   (eval-when-compile (require 'eldoc))
>   (setq-local eldoc-documentation-function 'hoka-eldoc-help-echo-at-point)
>   (eldoc-mode))

Re: [O] Localized org-mode

[Göktuğ Kayaalp]

On 2018-05-12 22:24 +03, ST  wrote:
>> Furthermore, in the context of this thread, Org allows drawers with
>> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
>> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
>> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
>> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
>> Same thing with todo keywords, tags, etc.
>
> 1. What about #+TITLE, #+DATE or #+AUTHOR ? What's problem to translate
> those?

People/packages can define their own keywords for in buffer settings,
and again here translations can cause breakage.

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Localized org-mode

[ST]

> Furthermore, in the context of this thread, Org allows drawers with
> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
> Same thing with todo keywords, tags, etc.

1. What about #+TITLE, #+DATE or #+AUTHOR ? What's problem to translate
those?

2. In order to determine reliably what is the language of a particular
document we can introduce #+LANGUAGE which would be English by default.
Others will write #+SPRACHE: Deutsch and then you can use predefined
default mapping of keywords or the local one (overloaded by user) if it
exists in his .emacs.d/org-de-vocabulary.

3. I also prefer English in all my UIs and, for sure, in programming
languages as you, but here I talk about org not as a programming
language but as a _document markup_. Documents that are meant to be
_read as raw source_. There it disturbs, especially if it is a not Latin
letters based language.

[O] ob-sql, quoting SQL wildcards

[Michael Welle]

Hello,

I try to fetch some values from an sqlite database (want to grab some
statistics from Zotero ;)):

#+begin_src sqlite :db zotero.sqlite
select value from itemdatavalues where lower(value) like '%gelesen%';
#+end_src

The SQL wildcards cause trouble:

Evaluate this sqlite code block on your system? (y or n) y
executing Sqlite code block...
Wrote /tmp/tmp_welle/babel-82601NB/ob-input-8260GeN
org-babel-read: End of file during parsing


I guess I have to quote the wildcards. But how?

Regards
hmw

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

[Alain . Cochard]

Gregor Zattler writes on Sat 12 May 2018 10:20:

 > > Did you mean 'emacs -Q' with some git branch?  If so, I don't
 > > know how to do it...
 > 
 > emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ 
 > 
 > which ads git Org to the load-path 
 > 
 > perhaps even
 > 
 > emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ -l
 > /home/cochard/Org/Coch-git/org-mode/lisp/org.el
 > 
 > which even loads Org mode.

Many thanks, Gregor.

With both of your suggestions, the problem is there.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106] | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France| Fax:   +33 (0)3 68 85 01 25 

[O] Proposal: references from code to text.

[ZHUO QL (KDr2)]

Hi all, I just post a proposal for orgmode on my website(generated by orgmode):
http://kdr2.com/tech/emacs/1805-proposal-org-ref-code-to-text.html .
Here is the source of the proposal:
# -*- mode: org; mode: auto-fill; -*-
#+TITLE: Proposal for Orgmode: references from code to text.
#+AUTHOR: KDr2

#+OPTIONS: toc:nil
#+OPTIONS: num:nil

#+BEGIN: inc-file :file "common.inc.org"
#+END:
#+CALL: dynamic-header() :results raw
#+CALL: meta-keywords(kws='("orgmode" "literate programming")) :results raw

# - DATE
<2018-05-12 Sat>


Literate programming is writing out the program logic in a human
language with included (separated by a primitive markup) code snippets
and macros. A preprocessor is used to substitute arbitrary
hierarchies, or rather "interconnected 'webs' of macros", to produce
the compilable source code with one command ("tangle"), and
documentation with another ("weave").

So in a literate programming source file, any chunk is either a block
of code or a block of document in a human language, I'll call them
*code* and *text* below.

In my opinion, code and text should be able to reference each other:

- *Text refers to text* \\
  In the exported/woven documentation, these references act as links,
  make interconnections between relevant topics.
- *Text refers to code* \\
  The links in the exported/woven documentation can also link to a
  line of code if the code blocks are also included in the
  exported/woven documentation.
- *Code refers to code* \\
  That's the most important part of the literate programming. This
  kind of references act as placeholders or something like macro in
  the C-programming language. With it, literate programming provides
  an ability to change the order of the source code from a
  machine-imposed sequence to one convenient to the human mind. 
[[https://en.wikipedia.org/wiki/Literate_programming#Example][Here
  is a simple Example depicts this concept]].
- *Code refers to text* \\
  So far as I know, no literate programming tool has this kind of
  references. However, this kind of references could be very benifical
  too. Many programming languages have a mechanism to support
  embedding documentation(usually as comments) in the source code, AKA
  [[https://en.wikipedia.org/wiki/Docstring][Docstring]]. These embedded 
documentations are widely and conveniently
  used in editor, REPL and IDE. For instance, the docs of any elisp
  function that we can read in Emacs are from the elisp source.

  But in literate programming we seldom embed comments into the code
  blocks, as an impliaction the extracted/tangled code has no docs
  embeded. If we can refer to chunks of text in the code blocks, we
  will have the chance to include these chunks of text as embeded docs
  in the code in the tangling process, which results in
  well-documented source code. This is useful especially while the
  programmer are authoring reusable source code, like libraries or
  frameworks.

Here is the implementation status of these kinds of references of
noweb and Org mode (~->~ means 'has the ability to make reference
to'):

  | tool | text -> text | code -> code | text -> code   | code -> text |
  |--+--+--++--|
  | noweb| No   | Yes  | No | No   |
  | Org mode | Yes, links   | Yes, noweb style | Yes, ~(ref:*)~ | No   |


As we saw, both noweb and Org mode do not implement the reference from
code to text. Could we provide this feature in Org mode -- the best
and widely used literate programming tool?

As a proposal, in Org mode, we can mimic the labels in
code blocks(i.e. text -> code reference), use something like
~(ref:text:)~ as the reference from code to text:

#+BEGIN_SRC org
  ,#+NAME: DOC-OF-ADD
  We use the function add to calculate the sum of two numbers.

  ,#+BEGIN_SRC elisp
  (defun add (x y)
"(ref:text:DOC-OF-ADD)"
(+ x y))
  ,#+END_SRC
#+END_SRC

The Org file above will produce the code below:

#+BEGIN_SRC elisp
  (defun add (x y)
"We use the function add to calculate the sum of two numbers."
(+ x y))
#+END_SRC

- Beside the ~NAME~, we could also support reference via the
  ~CUSTOM_ID~ property or anything else that can locate a text chunk.
- In the tangling process, we should do some kind of transformation of
  the target text, for example, escape the quote mark. A hook may be
  needed to let the user customize the transformation too.

What do you think?

* References
  - https://en.wikipedia.org/wiki/Literate_programming
  - https://en.wikipedia.org/wiki/Noweb
  - https://en.wikipedia.org/wiki/Docstring
  - http://orgmode.org/manual/Extracting-source-code.html#Extracting-source-code
  - http://orgmode.org/manual/Noweb-reference-syntax.html#Noweb-reference-syntax
  - http://orgmode.org/manual/Literal-examples.html#Literal-examples
  - https://orgmode.org/worg/dev/org-syntax.html

* Discuss and Comment
  #+BEGIN: inc-file :file "comment.inc.org

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 12, 2018, at 20:07, Göktuğ Kayaalp  wrote:

> How do you know that if you first learned the translated version?

Because (define eklemek +)

If you run Scheme, you either know or can discover that.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Göktuğ Kayaalp]

On 2018-05-12 09:29 +09, Jean-Christophe Helary  wrote:
>> On May 12, 2018, at 7:23, Göktuğ Kayaalp  wrote:
>>> In Scheme, for ex. you can actually redefine all the language keywords
>>> very easily without any impact on the interpreter.
>> 
>> Practical reason: communication.  I'm a Turkish speaker, suppose I'm
>> monolingual, and I have a problem with the function
>> ‘güncel-devamla-çağır’ in Scheme.
>
> If you have a problem with that function and you use Scheme, you know
> that it is mapped to call-with-current-continuation and you know where
> to look for information. And if you're monolingual, chances are that
> you won't be able to make sense of what you find in English.

How do you know that if you first learned the translated version?  What
do you do if in such a situation you have a long stack trace?  Translate
it before debugging?  Well, in lisp that can be automatic, but even then
I bet it will be popular.  The wikipedia page ‘Non-English-based
programming languages’ is not empty.  And nobody got out of their way to
localise existing languages that allow that to be done easily is telling
(Lisp, Perl).

>> The language of programming is English.
>
> And of course, when 2 Turkish programmers talk about programming they
> shift to English... No, they don't. Keywords are arbitrary
> strings. Try APL and see how "English" applies.

We do, actually, kind of.  We probably use more English words than
Turkish words in that context.

>>  Also, when I need help online, I need the English
>> messages anyways (and translated manuals, if they ever exist, are a joke
>> all the time).
>
> If FOSS activists took as much time fixing manuals as they take for
> fixing code that would not be an issue. l10n is not as good as code
> *because* it is not defined with a higher priority and a better
> consciousness of the linguistic issues, and that is because
> monolingual activists think one language is sufficient (funny how that
> does not apply to programming languages, but they don't seem to be
> conscious of that contradiction...)

There are no «monolingual activists», but just people using the best
available thing.  I myself speak two languages apart form my native
Turkish, learning a third, can read a couple others, and have the desire
to learn more; so I'm no monolingual.  Thing with programming languages
is that them being in one natural language or another does not mean
much; but one programming language may have some features that the other
does not.  And manuals are already insufficent in English itself (very
few projects with good docs exist, one of which is luckily Emacs), let
aside translations.

I guess we're quite off-topic here.

All the best,

-- 
İ. Göktuğ Kayaalp   
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

[Gregor Zattler]

Hi Alain,
* alain.coch...@unistra.fr [2018-05-12; 08:32]:
> I got:
>
> Emacs : GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version
> 3.18.9) of 2016-04-11 on buildvm-25.phx2.fedoraproject.org Package:
> Org mode version 9.1.13 (release_9.1.13-744-g13fb6a @
> /home/cochard/Org/Coch-git/org-mode/lisp/)
>
> Is that the master branch?

Seems so.

> Did you mean 'emacs -Q' with some git branch?  If so, I don't know how
> to do it...

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ 

which ads git Org to the load-path 

perhaps even

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ -l 
/home/cochard/Org/Coch-git/org-mode/lisp/org.el 

which even loads Org mode.

You could write a small file with the necessary settings and load
it also 

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ -l 
/home/cochard/Org/Coch-git/org-mode/lisp/org.el -l /tmp/minimal-exaple.el

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: [O] Link "bracket-types"

[Michael Brand]

Hi Nicolas

Thank you for the patch. I changed it (attached) to something that
preserves org-toggle-link-display and allows more different configs
for more different usages, please see the docstring of
org-link-brackets. I tried it out with org-toggle-link-display and for
org-link-brackets '(0 0), '(1 1) and '(0 2).

Michael


org-link-brackets.diff
Description: Binary data