‘org-test-with-temp-text’ fails weirdly

2020-05-06 Thread Göktuğ Kayaalp
Hello,

I was trying to have spurious indentation removed from Python source
blocks before execution so that such blocks can be indented in Org mode
buffers.  I managed to do so successfully, but some tests keep failing
and I believe it’s the test runner that’s the culprit. With the attached
patch applied, I’ve observed successful execution when manually trying
test cases similar to those in test-ob-python.el, indented or not. But
the following tests fail with ‘(args-out-of-range "return x" 42 43)’
errors:

   FAILED  test-ob-python/colnames-nil-header-argument
   FAILED  test-ob-python/colnames-no-header-argument
   FAILED  test-ob-python/colnames-yes-header-argument

(9 tests fail without this patch, the other 6 is irrelevant and do fail
when I test w/o the patch too, on commit b171ff02f.)

I think the cause is the modifications to the code blocks body (deletion
of spurious indentation from an indented src block), but I’m not sure
how exactly.

This is weird because the in-buffer text doesn’t change.

In any case I’m also proposing the attached patch as a new feature.
Could start a new thread for it if necessary.

P.S.: please keep me in the CC in your replies, I’m not subscribed to
the mailing list.

-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

>From 88ad28dce8e0111c10ca18db5f58d35924112441 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C4=B0=2E=20G=C3=B6ktu=C4=9F=20Kayaalp?= 
Date: Thu, 7 May 2020 03:11:50 +0300
Subject: [PATCH] lisp/ob-python.el: remove spurious indentation before
 evaluation

---
 lisp/ob-python.el | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index dbcfac08d..42bb47f73 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -69,6 +69,24 @@ This will typically be either `python' or `python-mode'."
   :package-version '(Org . "8.0")
   :type 'symbol)
 
+(defun org-babel-python--clean-spurious-indentation (body)
+  (let* ((extra-indentation
+	  (save-match-data
+	(string-match "\\`\\([ \t]+\\)" body)
+	(match-string 1 body)))
+	 (xlen (length extra-indentation)))
+(if (zerop xlen)
+	body
+  (mapconcat
+   (lambda (line) (if (<= (length line) xlen)
+			  line
+			(if (string= extra-indentation
+ (substring line 0 xlen))
+			(substring line xlen)
+			  line)))
+   (split-string body "\n")
+   "\n"
+
 (defun org-babel-execute:python (body params)
   "Execute a block of Python code with Babel.
 This function is called by `org-babel-execute-src-block'."
@@ -84,7 +102,8 @@ This function is called by `org-babel-execute-src-block'."
 	 (preamble (cdr (assq :preamble params)))
  (full-body
 	  (org-babel-expand-body:generic
-	   (concat body (if return-val (format "\nreturn %s" return-val) ""))
+	   (concat (org-babel-python--clean-spurious-indentation body)
+		   (if return-val (format "\nreturn %s" return-val) ""))
 	   params (org-babel-variable-assignments:python params)))
  (result (org-babel-python-evaluate
 		  session full-body result-type result-params preamble)))
-- 
2.17.1



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-18 Thread Göktuğ Kayaalp
On 2018-05-15 21:36 +03, Göktuğ Kayaalp <s...@gkayaalp.com> wrote:
> So, today I've started implementing a version of this that works like
> this:
>
> #+begin_example
>   #+property: edit-bindings /varlist/
>   * heading
>   :properties:
>   :edit_bindings: /varlist/
>   :end:
>   #+header: edit-bindings /varlist/
> #+end_example
>
>
> where scoping is like (x > y meaning x overrides y):
>
>   header line bindings > subtree bindings > #+property bindings before
>   the element
>
> I'll send a complete patch soon.

And here it is.  Please find the patch attached.  I have ran the entire
test suite against this, which completed w/ 6 failures, seemingly
unrelated (they fail on revision 58c9bedfd too); find the list below.  I
have tried to follow apparent conventions in each file w.r.t. the
copyright/authors lines, sorry if I modified them unnecessarily.

6 unexpected results:
   FAILED  test-ob/org-babel-remove-result--results-list
   FAILED  test-org-clock/clocktable/step
   FAILED  test-org/add-planning-info
   FAILED  test-org/clone-with-time-shift
   FAILED  test-org/deadline
   FAILED  test-org/schedule

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

>From b6d2b60730ceed68f46ef839c486e03764defdc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C4=B0=2E=20G=C3=B6ktu=C4=9F=20Kayaalp?= <s...@gkayaalp.com>
Date: Tue, 15 May 2018 20:34:28 +0300
Subject: [PATCH] Implement edit bindings feature

Enable defining local variable bindings to be applied when editing
source code.

* lisp/org-src.el (org-src--apply-edit-bindings)
(org-src--simplify-edit-bindings)
(org-src--parse-edit-bindings)
(org-src--edit-bindings-string)
(org-src--get-edit-bindings-for-subtree)
(org-src--get-edit-bindings-from-header)
(org-src--collect-global-edit-bindings)
(org-src--collect-edit-bindings-for-element): New functions.
(org-src-apply-risky-edit-bindings): New defcustom.
(org-src--edit-element):
* doc/org.texi (Editing source code): Add edit bindings.

* testing/lisp/test-org-src.el (test-org-src/edit-bindings-parser)
(test-org-src/collect-edit-bindings-for-element)
(test-org-src/edit-bindings-precedence-and-application)
(test-org-src/edit-bindings-use-cases): Add relevant tests.
---
 doc/org.texi |  43 +
 etc/ORG-NEWS |  15 +++
 lisp/org-src.el  | 223 +++
 testing/lisp/test-org-src.el | 172 -
 4 files changed, 436 insertions(+), 17 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 6aab1ba4e..c588152fd 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -15364,6 +15364,7 @@ Source code in the dialect of the specified language identifier.
 
 @vindex org-edit-src-auto-save-idle-delay
 @vindex org-edit-src-turn-on-auto-save
+@vindex org-src-apply-risky-edit-bindings
 @kindex C-c '
 @kbd{C-c '} for editing the current code block.  It opens a new major-mode
 edit buffer containing the body of the @samp{src} code block, ready for any
@@ -15421,6 +15422,48 @@ Emacs-Lisp languages.
 ("python" (:background "#E5FFB8"
 @end lisp
 
+It is possible to define local variable bindings for these buffers using the
+@samp{edit-bindings} element header, the @samp{edit-bindings} buffer
+property, or the @samp{EDIT_BINDINGS} entry property.  All three can be used
+together, the bindings from the header override those of the subtree, and
+they both override the bindings from buffer properties.  The syntax is
+similar to that of @code{let} varlists, but a sole symbol means the
+variable's value is copied from the Org mode buffer.  Multiple uses of
+@samp{edit-bindings} headers and buffer properties are supported, and works
+like @code{let*}.  Entry property @samp{EDIT_BINDINGS} can not be repeated.
+Below is an example:
+
+@example
+# -*- fill-column: 65 -*-
+#+PROPERTY: edit-bindings '(fill-column (lexical-binding t))
+
+* Example section
+:PROPERTIES:
+:EDIT_BINDINGS: '((emacs-lisp-docstring-fill-column 60))
+:END:
+
+#+HEADER: edit-bindings '((lexical-binding nil))
+#+BEGIN_SRC elisp
+(defun hello ()
+  (message "Hello world!"))
+#+END_SRC
+
+* Another section
+#+BEGIN_SRC elisp
+(defun hello ()
+  (message "Byes world!"))
+#+END_SRC
+@end example
+
+In this example, when editing the first block, @code{lexical-binding} will be
+@code{nil}, and @code{emacs-lisp-docstring-fill-column} 60.  With the second
+one, they will be @code{t} and the variable's default value, respectively.
+@code{fill-column} will be 65 for both.
+
+Set @code{org-src-apply-risky-edit-bindings} for how risky local variables in
+these bindings are handled.  The default behaviour is to ask to the user
+whether or not to apply them.
+
 @node Exporting code blocks
 @section Exporting code blocks
 @c

Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-15 Thread Göktuğ Kayaalp
On 2018-05-14 18:47 +02, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> (org-element-property :header (org-element-at-point)) => (":foo bar")
[...]
>> I can't find any documentation on Org-mode's internal APIs and how
>> different parts fit together, so I'm having to figure things out reading
>> source code.
>
> See <https://orgmode.org/worg/dev/org-element-api.html>.

Thanks, and sorry.  I've been mostly ignoring Worg up until now, because
I haven't seen the worg/dev/ pages mentioned in the info manual (I'd
expect to see those pages mentioned in the Hacking section BTW, I can
send a patch mentioning them in a "Further resources" subsection there
if you'd like that added).

So, today I've started implementing a version of this that works like
this:

#+begin_example
  #+property: edit-bindings /varlist/
  * heading
  :properties:
  :edit_bindings: /varlist/
  :end:
  #+header: edit-bindings /varlist/
#+end_example


where scoping is like (x > y meaning x overrides y):

  header line bindings > subtree bindings > #+property bindings before
  the element

I'll send a complete patch soon.

Best,

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-14 Thread Göktuğ Kayaalp
On 2018-05-14 14:33 +01, Aaron Ecay <aarone...@gmail.com> wrote:
> Hi Göktuğ,
>
> This patch looks good, thanks.  Of course, for merging to org core it
> will need to be an actual patch and not advice.

Certainly; this is meant as a ‘tangible’ example, and can easily be
turned into a patch if you want to merge this.

> There is also copyright
> assignment to think of.  Do you already have a FSF copyright assignment
> on file?

I have signed the assignment for GNU Emacs, and contributed a couple
patches.  IDK if that can be reused here though, but if not I can do the
paperwork again.

> 2018ko maiatzak 14an, Göktuğ Kayaalp-ek idatzi zuen:
>
> [...]
>
>> One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the
>> explicit quote is not necessary with ATTR_EDIT:
>> 
>> #+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
>> #+ATTR_EDIT: ((lexical-binding t))
>
> That quote is required for the src block version is inherent in the
> design of babel.  For consistency, you could require (or at least permit
> without requiring) a quote in the other case as well.

I guess requiring that would be better given it can cause confusion if
it works one way but not the other.

> I think you could replace the (let (var val)...) form with:
>
> #+begin_src emacs-lisp
>   (pcase-dolist ((or (and (pred symbolp) var
>   (let val (buffer-local-value var source-buffer)))
>  `(,var ,val))
>  varlist)
> (set (make-local-variable var) val))
> #+end_src
>
> This silently skips varlist entries that are of the wrong shape, but it
> would be possible to make it raise an error as in your version.  I like
> the pcase version better because itʼs shorter and has fewer nested
> conditionals, but itʼs ultimately a matter of taste.

Yeah I can integrate this.  I was initially going to use pcase, but I
can't understand how it works for the life of me.  It's one of the two
lisp macros together with loop that I can't get my head around.

So, I will turn this into a patch, make the change regarding the initial
quote, use pcase, and see how Nicolas responds to me about the
#+ATTR_EDIT.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-14 Thread Göktuğ Kayaalp
On 2018-05-14 14:13 +02, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> You shouldn't add another "attr" keyword, which is reserved for export
> back-ends. Actually, every Babel header can be located either on the
> block opening line, e.g.,
>
> #+begin_src emacs-lisp :some-property some-value
>
> or as an affiliated #+header: keyword, e.g.,
>
> #+header: :some-property some-value
> #+begin_src emacs-lisp
>
>
> Note that "#+header:" keywords are supported everywhere, without
> modifying the parser, e.g.,
>
> #+header: :some-property some-value
> A paragraph.

The attr was meant for BEGIN_EXPORT blocks because it seems to me that
an equivalent of ‘org-babel-get-src-block-info’ does not exist for those
blocks, and that function _only_ works with BEGIN_SRC blocks.  Is there
a function available or would I have to write one to do this?

Looking all over the Org manual searching for BEGIN_(LATEX|HTML), I
haven't seen once a header argument used with a block that is not a
BEGIN_SRC block, in neither of the forms.  And none of the ‘org-edit-*’
functions apart from ‘org-edit-src-code’ in org-src.el seem to process
header arguments, and nor does ‘org-src--edit-element’.

I can't find any documentation on Org-mode's internal APIs and how
different parts fit together, so I'm having to figure things out reading
source code.

The following form returns nil for the following examples:

(plist-get :header (cadr (org-element-at-point))) ;=> nil

(cl-remove-if-not #'symbolp (cadr (org-element-at-point)))
  ;=> (:type :begin :end :value :post-blank :post-affiliated :header
   :parent nil)

#+header: :edit-bindings '((lexical-binding t))
#+BEGIN_EXPORT latex
#+END_EXPORT

#+BEGIN_EXPORT latex :edit-bindings '((lexical-binding t))
#+END_EXPORT

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+END_SRC

#+header: :edit-bindings '((lexical-binding t))
#+BEGIN_SRC elisp
#+END_SRC

> Also, for integration in Org mode proper, some testing would be more
> than welcome

If this feature will be included upstream, I can make this into a patch
instead of an advice and add the related docs and tests.  This was meant
as a concrete example of the concept.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-14 Thread Göktuğ Kayaalp
Hello,

Sorry for the silence, I've finally got around to implementing this, and
implemented it as an advice, which supports both an ‘:edit-bindings’
Babel header argument for source code blocks, and an #+ATTR_EDIT:
element property for export blocks, etc.  Find the code below, and
attached an Org mode file to help with testing.

This advice can easily be made into a patch to the
‘org-src--edit-element’ function.

One ‘gotcha’ is that :edit-bindings requires a quoted list whereas the
explicit quote is not necessary with ATTR_EDIT:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+ATTR_EDIT: ((lexical-binding t))

Another problem is that I was not able to define a new element property
named EDIT_BINDINGS, and had to take the shortcut with naming it as an
ATTR_* variable.  Preferably, it'd be EDIT_BINDINGS instead:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t))
#+EDIT_BINDINGS: ((lexical-binding t))

But personally I don't think it's that big of a problem.


The advice:

(define-advice org-src--edit-element
(:around
 (fn datum  args)
 attr-edit)
  "Apply edit-special bindings."
  (let ((attr-edit (org-element-property :attr_edit datum))
(edit-bindings
 (assoc :edit-bindings (caddr (org-babel-get-src-block-info nil 
datum
(source-buffer (current-buffer))
(sub (lambda (varlist source-buffer)
   (let (var val)
 (dolist (form varlist)
   ;; If it's a symbol, inherit from the Org mode buffer.
   (if (symbolp form)
   (setq var form
 val (with-current-buffer source-buffer (eval var)))
 ;; Else, apply the specified value.
 (setq var (car form) val (cadr form)))
   (unless (symbolp var)
 ;; XXX: maybe tell where it is?
 (user-error "Bad varlist at ATTR_EDIT"))
   (set (make-local-variable var) val))

;; Apply function
(apply fn datum args)

;; Apply edit attributes (ATTR_EDIT).
(dolist (attr attr-edit)
  (let ((varlist (car (read-from-string attr
(unless (listp varlist)
  (user-error "Value of ATTR_EDIT must be a varlist."))
(funcall sub varlist source-buffer)))
;; Apply edit bindings (:edit-bindings header argument).
;; These override attr-edit values.
(when edit-bindings
  (funcall sub (cdr edit-bindings) source-buffer

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

# $Id: edit-bindings.org,v 1.2 2018/05/14 05:23:48 g Exp $
#+title: :edit-bindings and #+ATTR_EDIT test file
#+author: Göktuğ Kayaalp

We use the variables ~lexical-binding~, ~truncate-lines~ and
~word-wrap~ for this test/demo.  We assume the first is ~nil~, the
second is set from a file local variable, and for the third we have no
assumptions.

#+BEGIN_SRC elisp :results verbatim
(list lexical-binding truncate-lines word-wrap)
#+END_SRC

#+RESULTS:
: (nil 62 t)

Now we set up the default ~:edit-bindings~ property.

#+PROPERTY: header-args :edit-bindings '((lexical-binding t))

>From now on, we'll do our observations evaluating the forms in source
code blocks via =C-c ' C-M-x=, and evaluating variables via =M-:= in
the edit special buffer.

In edit-special buffer, when editing, we observe that
~lexical-binding~ is set to ~t~:

#+BEGIN_SRC elisp
(eq lexical-binding t)
#+END_SRC

But ~truncate-lines~ is not set:

#+BEGIN_SRC elisp
(eq truncate-lines 62)
#+END_SRC

Copy ~truncate-lines~ over from this file's buffer local variables:

#+BEGIN_SRC elisp :edit-bindings '(truncate-lines)
(list lexical-binding truncate-lines)
#+END_SRC

We observe that now the buffer-wide value is shadoved, and while
truncate lines is passed through, ~lexical-binding~ is not, it's nil.

So we pass both through:

#+BEGIN_SRC elisp :edit-bindings '((lexical-binding t) truncate-lines)
(list (eq truncate-lines 62)
  (eq lexical-binding t))
#+END_SRC

Export blocks can not use header arguments.  Thus we use an element
property called ~ATTR_EDIT~:

#+ATTR_EDIT: ((fill-column 30) truncate-lines)
#+BEGIN_EXPORT latex
Nullam eu ante vel est
convallis dignissim.  Fusce
suscipit, wisi nec facilisis
facilisis, est dui fermentum
leo, quis tempor ligula erat
quis odio.  Nunc porta
vulputate tellus.  Nunc rutrum
turpis sed pede.  Sed
bibendum.
#+END_EXPORT

When we observe the value of ~truncate-lines~, we see that it is 62,
and when we use ~fill-paragraph~, that it wraps according to the new
value of ~fill-column~.

We get an error if we supply a bad varlist, but editing continues
anyways:

#+BEGIN_SRC python :edit-bindings '(("monty" "python"))
print(None)
#+END_SRC

#+ATTR_EDIT: Tea?
#+BEGIN_EXPORT latex
\textit{nope}
#+END_EXPORT

# Local Variables:
# truncate-lines: 62
# End:


Re: [O] Localized org-mode

2018-05-12 Thread Göktuğ Kayaalp
On 2018-05-12 22:24 +03, ST <smn...@gmail.com> 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   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Localized org-mode

2018-05-12 Thread Göktuğ Kayaalp
On 2018-05-12 09:29 +09, Jean-Christophe Helary <brandel...@gmail.com> wrote:
>> On May 12, 2018, at 7:23, Göktuğ Kayaalp <s...@gkayaalp.com> 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   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Localized org-mode

2018-05-11 Thread Göktuğ Kayaalp
On 2018-05-09 21:43 +09, Jean-Christophe Helary <brandel...@gmail.com> wrote:
>> On May 9, 2018, at 21:07, Kaushal Modi <kaushal.m...@gmail.com> wrote:
>> On Wed, May 9, 2018, 8:01 AM Diego Zamboni <di...@zzamboni.org
>> <mailto:di...@zzamboni.org>> wrote:
>> I really don't see the point of trying to localize org keywords. To
>> me, they are like the keywords in any programming language - part of
>> the language. Would you consider translating C or LISP keywords?
>
> There are no practical reasons why that should not be possible. The
> current state of affairs is only due to design constraints when the
> languages were conceived.
>
> 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.  I'd find a fraction of the results if
I was searching for ‘call-with-current-continuation’.  As the small
community of programmers (and the even smaller community of Emacsers
(and as the smaller community of the Org-mode-ers/some-proglang-users
(and as the even smaller community of Org-mode/some-proglang-users users
of some X language as the mother tongue))), we need to communicate, and
we need as much information at our disposal as possible.

The language of programming is English.  I'm completely fine with it.
Being a programmer and not knowing any English has so many disadvantages
that learning it is worthwhile regardless of how much time you've put
into it.  The language of the computers is English too.  Most often,
most software is written in English (even by many non-native speakers)
and maybe translated after the fact, where most of the time (if not all)
the results are sub-par or at most 8/10 (maybe because many terms are
invented in English and require inventing words in other languages which
always sound off).

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.

>> In addition to the trouble of supporting something like this within
>> Emacs, think of the growing ecosystem of tools which support org
>> mode - they would all need to be aware of these localizations. It
>> would be a nightmare to maintain.
>
> Localization, when properly done is never a nightmare to maintain.

I appreciate your efforts on i18n and l10n on Emacs, but unfortunately I
am yet to find a properly localised piece of software, especially in the
FOSS community.  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).


-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-02 Thread Göktuğ Kayaalp
On 2018-05-02 12:16 +02, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Export blocks, like any other element, accept #+header: keyword, e.g.,
>
> #+header: whatever
> #+begin_export latex
>
> ...
> #+end_export
>
> Note that, however, such header arguments are ignored during export.

Thanks.  This means implementing this feature as a header argument
should suffice for all useful cases (though it'll probably become more
clearer when it's implemented and tested).

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-01 Thread Göktuğ Kayaalp
On 2018-05-02 01:12 +03, Göktuğ Kayaalp <s...@gkayaalp.com> wrote:
> Okay, I'll read up on these, both code and manuals.  So we've agreed
> that what we want is a new header argument, ‘:edit-vars’, whose value is
> a form similar to a varlist, where
>
> - a form (var val) means bind var to val in the editing buffer,
>
> - a symbol var means bind var in the editing buffer to the buffer-local
>   value of it in the relevant x.org buffer, as in (setq
>   (make-local-variable var) (with-current-buffer "x.org" var))
>
> Do you confirm?  Also, what do you think about :edit-bindings or
> :edit-locals instead of :edit-vars? :var is a completely different
> thing, and :edit-vars may cause confusion, given the similarity of the
> name.

Also, another question remains: how do we extend this to #+begin_export
blocks?  But that's unclear to me maybe because I don't know in detail
how header arguments work.  Ideally this feature would work for _any
block_ editable by ‘org-edit-special’ (i.e. C-c '), and again ideally
using the same syntax.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-01 Thread Göktuğ Kayaalp
On 2018-05-01 21:53 +01, Aaron Ecay <aarone...@gmail.com> wrote:
> That is excellent news :) If you run into anything you canʼt figure out
> then let us know.

I will probably be able to start working on this next weekend (tho there
is some stuff that can inevitably slow me down this week).  In the mean
time other people can comment both on this and on where to put the
resulting feature.

> But because of the nature of the variable (a lisp list), it can only be
> set once.  So you can have only one of:
> [...]
> But they canʼt be combined.  AFAIR, :var is the only header argument
> that can be meaningfully specified more than once.

Okay, I'll read up on these, both code and manuals.  So we've agreed
that what we want is a new header argument, ‘:edit-vars’, whose value is
a form similar to a varlist, where

- a form (var val) means bind var to val in the editing buffer,

- a symbol var means bind var in the editing buffer to the buffer-local
  value of it in the relevant x.org buffer, as in (setq
  (make-local-variable var) (with-current-buffer "x.org" var))

Do you confirm?  Also, what do you think about :edit-bindings or
:edit-locals instead of :edit-vars? :var is a completely different
thing, and :edit-vars may cause confusion, given the similarity of the
name.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-01 Thread Göktuğ Kayaalp
On 2018-05-01 20:35 +01, Aaron Ecay <aarone...@gmail.com> wrote:
> Thinking about it some more, lexical binding is not a good case for
> this feature, since it has to be set not only in the edit buffer, but
> also when C-c C-c is used in the org-mode buffer to evaluate the src
> block.  The :lexical header arg (which I did not know about) works for
> the latter but not the former.  To complete the picture, Someone™ needs
> to implement a org-babel-edit-prep:emacs-lisp function which looks for
> :lexical yes in the header arguments and sets the value in the edit
> buffer appropriately.

I can (and plan to) take on that task once a design is agreed upon.  I
don't really know much about Org internals, but I think I can figure
out.

> If lexical-binding is the major motivating factor, then maybe the above
> is enough.  My original suggestion was for something like:
>
> #+begin_src emacs-lisp :edit-vars ((fill-column 72) (other-var other-val))
>   ...
> #+end_src
>
> This would set the variables in the edit buffer in the (hopefully)
> obvious way.  It is not implemented yet, though.

I do like that syntax.  A minor addition might be for the case when one
wants to pass the value of a variable local to the org buffer to the
editing buffer:

-*- fill-column: 65; indent-tabs-mode: nil -*-
#+edit-vars: (indent-tabs-mode)
#+begin_src emacs-lisp :edit-vars (fill-column (lexical-binding t))
;; here, when editing, fill-column is 65, lexical binding is t
;; and indent-tabs-mode is nil
#+end_src

> PS Itʼs best to use “reply all” and include the org mode mailing list in
> replies, to make sure everyone following the thread sees all the
> messages.

Whoops! Sorry, yeah, I have been hitting the wrong keybinding for the
last couple of messages I think...

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-01 Thread Göktuğ Kayaalp

BTW I can also implement this as a 3rd party extension instead of as a
core feature, I can see how it's possibly not generic enough for that.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-05-01 Thread Göktuğ Kayaalp
On 2018-05-01 10:43 +02, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> I think this machinery is not necessary.
>
> First add a call to `hack-local-variables-apply' somewhere in
> `org-src--edit-element'.
>
> Then, just use regular file-local variables ,e.g.,
>
> #+begin_src emacs-lisp
> (foo)
> ;; Local Variables:
> ;; fill-column: 99
> ;; End:
> #+end_src

But in my case (which is quite common I think) this would require adding
those local variables sections to each code block.  My Emacs config
alone has upwards of 170 code blocks, which means same three lines
repeated 170 times adding up to extra 510 lines, just for setting one
variable consistently.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] Inheriting some local variables from source code block editing buffers

2018-04-30 Thread Göktuğ Kayaalp
On 2018-04-30 00:09 +02, Bastien <b...@gnu.org> wrote:
> Hi Göktuğ,
>
> thanks for your patch.

You're welcome!

> Kayaalp <s...@gkayaalp.com> writes:
> Do you have other examples on local variables that would be useful to
> pass on when editing code in Org Src buffers?

Currently I only pass on lexical-binding and truncate-lines, and I do
not have another concrete example in my configuration (I do not use
source blocks for anything other than shell and elisp currently).  But I
have listed some hypothetical use cases further down.

> In general, instead of inheriting values from the Org's buffer, I'd
> allow users to set the values independantly -- for example, the cdr
> of elements in `org-babel-load-languages', instead of being `t' all
> the time (because nil makes no sense to me), could contain an alist
> of variables and their local values when editing and... executing.

This might be a better way indeed.  But this setting is then global,
i.e. one can't have the file A.org have lexical-binding on, but B.org
off (which might be necessary for say an older org file that depends on
lexical binding).

> This is: *if* we find cases that seem generic enough.
>
> What do you think?

One case I can think of is to set variables like fill-column when
editing inline LaTeX, HTML,  blocks, and also, those like
c-file-style, where say when writing a paper the author wants to use k
style, but when writing a literate source prefers gnu style.

Maybe a good way to achieve this would be to have the way you suggest to
set defaults for Babel, but allow to define such bindings also in
individual org mode files, either via the local variables or with a
specific #+keyword like:

#+edit_special_bindings: lexical-binding:t
# or
#+edit_special_bindings: c-file-style:gnu fill-column:80

which is better IMO because there is no need to declare separately which
variables to copy, and is more granular.  Also, in this case, a shortcut
syntax for inheriting the buffer local value of a variable can be
useful:

 x.org ===
# -*- fill-column: 65 -*-
#+edit_special_bindings: c-file-style:gnu fill-column*

This can be useful when one needs/wants to keep a consistent style in a
given file.

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



[O] Inheriting some local variables from source code block editing buffers

2018-04-29 Thread Göktuğ Kayaalp
Hello,

when editing a source block, passing some local variables from the
original buffer into the buffer in which the source code is edited might
be useful.  My use case is passing the value of ‘lexical-binding’ when
editing Elisp source code blocks in my literate .emacs so that I don't
mistakenly evaluate code in a non-lexical environment thinking it's the
opposite instead.

I've implemented this with the patch attached to this message, if it's
deemed useful, I can revise it for inclusion upstream (just wanted to
see what you think about the idea with this one).

-- 
İ. Göktuğ Kayaalp   <https://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 850525b8d..248b46462 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -196,6 +196,14 @@ For example, there is no ocaml-mode in Emacs, but the mode to use is
 	   (string "Language name")
 	   (symbol "Major mode"
 
+(defcustom org-src-inherited-local-variables '()
+  "Local variables to be copied into source code editing buffers.
+This variable contains a list of symbols, whose values in the Org
+mode buffer that contains the source block are to be interited by
+the source code editing buffer."
+  :group 'org-edit-structure
+  :type '(repeat symbol))
+
 (defcustom org-src-block-faces nil
   "Alist of faces to be used for source-block.
 Each element is a cell of the format
@@ -947,9 +955,13 @@ name of the sub-editing buffer."
 (unless (and (memq type '(example-block src-block))
 		 (org-src--on-datum-p element))
   (user-error "Not in a source or example block"))
-(let* ((lang
+(let* ((org-buffer (current-buffer))
+   (lang
 	(if (eq type 'src-block) (org-element-property :language element)
 	  "example"))
+   (buffer-name (or edit-buffer-name
+	(org-src--construct-edit-buffer-name
+ (buffer-name) lang)))
 	   (lang-f (and (eq type 'src-block) (org-src--get-lang-mode lang)))
 	   (babel-info (and (eq type 'src-block)
 			(org-babel-get-src-block-info 'light)))
@@ -957,10 +969,7 @@ name of the sub-editing buffer."
   (when (and (eq type 'src-block) (not (functionp lang-f)))
 	(error "No such language mode: %s" lang-f))
   (org-src--edit-element
-   element
-   (or edit-buffer-name
-	   (org-src--construct-edit-buffer-name (buffer-name) lang))
-   lang-f
+   element buffer-name lang-f
(and (null code)
 	(lambda () (org-escape-code-in-region (point-min) (point-max
(and code (org-unescape-code-in-string code)))
@@ -973,6 +982,9 @@ name of the sub-editing buffer."
 	(let ((edit-prep-func (intern (concat "org-babel-edit-prep:" lang
 	  (when (fboundp edit-prep-func)
 	(funcall edit-prep-func babel-info
+  (dolist (localvar org-src-inherited-local-variables)
+(set (make-local-variable localvar)
+ (with-current-buffer org-buffer (eval localvar
   t)))
 
 (defun org-edit-inline-src-code ()


Re: [O] `fill-paragraph' on headings

2017-10-31 Thread Göktuğ Kayaalp
On 2017-10-26 09:50 +01, Eric S Fraga <esfli...@gmail.com> wrote:
> On Wednesday, 25 Oct 2017 at 14:03, Tor wrote:
>> this is a feature request for having the ability to use
>> `fill-paragraph' on headings.  An example from Emacs news:
>
> Semantically, this makes no sense?  How would org know that the line
> that follows a headline is part of the headline or not part of the
> headline?

Sometimes the headline can get too long, and it may be nice to be able
to hard-wrap it.  I believe it'd be possible to use the double-backslash
syntax for marking continuation lines:

* Nullam eu ante vel est convallis dignissim.  Fusce suscipit, wisi\\
  nec facilisis facilisis, est dui fermentum leo, quis tempor ligula\\
  erat quis odio.
Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.

though using word-wrapping to similar effect would probably be
better. (FWIW I'm the one who suggested this on the reddit thread too).

Best.

-- 
İ. Göktuğ Kayaalp   <http://www.gkayaalp.com/>
 024C 30DD 597D 142B 49AC
 40EB 465C D949 B101 2427



Re: [O] How to get the eacute above the e in saute or Saute?

2017-10-12 Thread Göktuğ Kayaalp
On 2017-10-12 17:58 +01, Sharon Kimble <boudic...@skimble.plus.com> wrote:
> Ok, thanks, that works, but how can I assign a keypress to it as I need
> to use it very often, several times each day. Plus I've got a backlog to
> work through too.

See "International" in the Emacs manual, especially "Input Methods" and
"Select Input Method" within it.

-- 
İ. Göktuğ Kayaalp   <http://www.gkayaalp.com/>
024C 30DD 597D 142B 49AC
40EB 465C D949 B101 2427



Re: [O] Is it possible to repeat tasks only a certain amount of times?

2017-09-14 Thread Göktuğ Kayaalp
On 2017-09-13 20:58 +03, Jorge Morais Neto <jorge13...@gmail.com> wrote:
> How about a diary-style sexp entry, with org-class?  That is, something
> like ~<%%(org-class 2017 7 31 2018 3 23 1)>~.  That example would appear
> on the agenda on every Monday between 2017-07-31 and 2018-03-23.

Thanks a lot, this in combination with the hours of the event in the
title (I didn't know that this worked) works nicely in Org Agenda, but
unfortunately such entries do not get exported to ICS, which is
important for me.  It seems to me that my only option ATM is what Eric S
Fraga pointed, but that's rather tedious as things like lessons change
during the year (different classrooms, time changes).

Cheers,
-g.

> Regards

-- 
İ. Göktuğ Kayaalp  http://www.gkayaalp.com/index.html
s...@gkayaalp.comPGP = 024C 30DD 597D 142B 49AC
Plaintext please!  {UTF8}  Fingerprint   40EB 465C D949 B101 2427




[O] Is it possible to repeat tasks only a certain amount of times?

2017-09-13 Thread Göktuğ Kayaalp
Hi,

I have a task with the following timestamp:

<2017-09-18 Pzt 14:25-18:40 +1w>

which represents an event that's going to repeat every week during a
certain period (it's not a TODO item).  With this timestamp however in
my agenda it repeats forever until when I'll finally archive it.
Ideally I'd have sth like the following:

<2017-09-18 Pzt 14:25-18:40 +1w #9>

where the final ‘#9’ means that the event will only repeat _8 times_
(i.e. 9 times with the initial instance).  Is this somehow already
possible, or else would it be plausible to implement this mainstream (I
could try to generate a patch in the coming weeks for this, tho it would
take a while as I'm not very familiar with org's innards and I wont have
lots of free time)?

I have tried the following:

<2017-09-18 Pzt 14:25-18:40 +1w>--

but then the entry appears (unsurprisingly) on my agenda every day,
instead of only on Monday, which I dont want at all (these are lessons
that repeat every certain day of each week of a certain period, and they
are many).

Thanks in advance,

   Göktuğ.

-- 
İ. Göktuğ Kayaalp   http://www.gkayaalp.com/index.html


signature.asc
Description: PGP signature


Re: [O] Issues w/ hacking Org font-lock for variable pitch prose

2015-12-05 Thread Göktuğ Kayaalp
Hello,

On Sat, Dec 05 2015 at 03:05:38 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> 
wrote:
> Hello,
>
> Göktuğ Kayaalp <s...@gkayaalp.com> writes:
>
>> […]
>
> Your code is probably not buggy. You are encountering a cache error.
> Does it happen on a fresh buffer (e.g., open a new buffer, and copy
> contents there, then let your code apply appropriate fontification)?
>

When I  copied the contents of  a file to  a fresh buffer, then  run M-x
org-mode in it, the last heading  and its contents didn’t get fontified,
and I got this error (the last entry was a level-1 entry):

Error during redisplay: (jit-lock-function 9029) signaled (end-of-buffer)

Another  time with  the  last  entry a  level-3,  immediate  child of  a
level-2, last two did not render:

Error during redisplay: (jit-lock-function 9490) signaled (end-of-buffer)
Error during redisplay: (jit-lock-function 9418) signaled (end-of-buffer)
font-lock-default-fontify-region: End of buffer

I had  ‘debug-on-error’ as ‘t’  during these  tests.  In both,  the file
ended with a single final newline.  If  there are more, I do not have an
error.

Best,
-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



[O] Issues w/ hacking Org font-lock for variable pitch prose

2015-11-30 Thread Göktuğ Kayaalp
486) (41403 4 "- " nil nil nil 
41446) (41446 4 "- " nil nil nil 41486) (41486 0 "- " nil nil nil 41655) (41511 
2 "- " nil nil nil 41633) (41556 4 "- " nil nil nil 41633) (41611 6 "- " nil 
nil nil 41633) (41633 2 "- " nil nil nil 41655) (41655 0 "- " nil nil nil 
41809) (41705 2 "- " nil nil nil 41809) (41767 4 "- " nil nil nil 41809)) t)
  org-element--current-element(41809 element item ((41306 0 "- " nil nil nil 
41341) (41341 0 "- " nil nil nil 41486) (41367 2 "- " nil nil nil 41486) (41403 
4 "- " nil nil nil 41446) (41446 4 "- " nil nil nil 41486) (41486 0 "- " nil 
nil nil 41655) (41511 2 "- " nil nil nil 41633) (41556 4 "- " nil nil nil 
41633) (41611 6 "- " nil nil nil 41633) (41633 2 "- " nil nil nil 41655) (41655 
0 "- " nil nil nil 41809) (41705 2 "- " nil nil nil 41809) (41767 4 "- " nil 
nil nil 41809)))
  byte-code("\212\214~\210b\210
\205.\n\205.\306\307!\204.\205.\310\311\".\312\f.1.;\2031.\313\314.1.#\2028.\315.A@.1\"*.2\311\211.3\311.4\f\204m.\316.5\317
 \211.6.7\320.6P.8\321 ,\203c.\322.4\311y\210\323\311w\210\324 
\210\202[..2U\203\237.\325\326.9\203\231.\327\f.1.;\203\216.\313\314.1.#\202\225.\315.A@.1\"*\202\232.\f\"\210\202[.\330\316.5\317
 \211.6.7\320.6P+.2\316#\203\306.\311y\210\323\311w\210\324 
\210\322.4\202[.\fdU\203\322.S\202\323..:\331\f.1.;\203\351.\313\314.1.#\202\360.\315.A@.1\"*\206\366.2b\210\332.:.1.;\203\f.\313\314.1.#\202.\315.A@.1\"*\211.;X\205A.;b\205A.\327.:.1.;\2036.\313\314.1.#\202=.\315.A@.1\"*\211.:)\204\370.:\203Z.m\203T.:.\202Z.:.`.3*\332..1.;\203n.\313\314.1.#\202u.\315.A@.1\"*\206\220.\212\316.5\317
 \211.6.7\320.6P.8\333 
\210,`).<.;.9\203\305.`U\203\251.\325\326.<\"\210\202\305.=\211.=\205\274.\334 
\206\274.\335.=\336 
\")\203\305.\325\337\311\"\210.\204.\340.;\305.4\341.<.1.;\203\343.\313\314.1.#\202\352.\315.A@.1\"*$\211.\327.<.>.1\211.;\203.\342.\311.1.>$\202..A\343.A@.1.>#\240\210.+\210\344.!\210\332..1.;\203-.\313\314.1.#\2024.\315.A@.1\"*.\211.:\204E.;\205M.\345\202M.@9\205M.@).?\211.@X\203\336.d.@U\204\336.@b\210.?\311.A.?.A\203\253.\346.?\347\"\203{.\350\202\330.\346.?\351\"\203\207.\352\202\330.\346.?\353\"\203\223.\354\202\330.\346.?\350\"\203\237.\322\202\330.\346.?\355\"\205\330.\356\202\330.\346.?\352\"\203\267.\352\202\330.\346.?\354\"\203\303.\354\202\330.\346.?\322\"\203\317.\353\202\330.\346.?\356\"\205\330.\356*.4\202\366.?.B>\204\356.\325\326.\"\210\202\366.\331..1.;\203.\313\314.1.#\202.\315.A@.1\"*\357..1.;\203.\313\314.1.#\202#.\315.A@.1\"*.C.D.9\204a.D\205\355.C\205\355.DW\204M.DU\205\355.?\360>?\205\355.CV\204a.CU\205\355.dU\205\355.3\206h.Db\210\311.3.?\316.A.?.A\203\265.\346.?\347\"\203\205.\350\202\342.\346.?\351\"\203\221.\352\202\342.\346.?\353\"\203\235.\354\202\342.\346.?\350\"\203\251.\322\202\342.\346.?\355\"\205\342.\356\202\342.\346.?\352\"\203\301.\352\202\342.\346.?\354\"\203\315.\354\202\342.\346.?\322\"\203\331.\353\202\342.\346.?\356\"\205\342.\356*.4.<.C\211.;*\204\366.\325\326.\"\210*\311.\202\225."
 [pos org-element-use-cache org-element--cache orgstruct-mode cached element 
derived-mode-p org-mode org-element--cache-find nil :begin get-text-property 0 
plist-get t org-get-limited-outline-regexp "^" outline-previous-heading 
planning " .\n" beginning-of-line throw exit :parent re-search-backward 
:contents-begin :end outline-next-heading input-pending-p time-less-p 
current-time interrupt org-element--current-element :structure org-add-props 
plist-put org-element--cache-put plain-text eql headline section plain-list 
item property-drawer node-property table table-row :contents-end (plain-list 
table) property ...] 9)
  org-element--parse-to(41648)
  org-element-at-point()
  org-return()
  call-interactively(org-return nil nil)
  command-execute(org-return)

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



Re: [O] Markup (=, ~) in word?

2015-10-29 Thread Göktuğ Kayaalp
On Thu, Oct 29 2015 at  5:07:55 pm EEST, Rainer M Krug <rai...@krugs.de> wrote:
> Göktuğ Kayaalp <s...@gkayaalp.com> writes:
>
>> On Thu, Oct 29 2015 at  2:21:17 pm EEST, Rainer M Krug <rai...@krugs.de> 
>> wrote:
>>> Matt Price <mopto...@gmail.com> writes:
>>>
>>>> #+BEGIN_VERBATIM
>>>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>>>> #+END_VERBATIM
>>>
>>> The other way round:
>>>
>>> I want the text, e.g. =SITE= as the markup, and not the whole text as
>>> verbatim - sorry for not being clear about what I want.
>>>
>>> Rainer
>>>
>>
>> AFAIK that is  impossible out of the box, Org  does not allow inter-word
>> markup,  as there  is no  escaping in  the syntax.   In the  thread with
>> subject  *Some  projects* on  this  list  they  talk also  about  adding
>> escaping.  You can still add some inline LaTeX for that though, I think,
>> or  maybe you  can  tweak  `org-emphasis-regexp-components', (also,  see
>> [1]):
>
> Thanks a lot for confirming my suspicion,

You're welcome.  Though I'm not that well-versed in Org, I merely use
it, maybe someone will have a suggestion that's less-known.

-gk

>
> Rainer
>
>>
>> ,[ C-h v org-emphasis-regexp-components RET ]
>> | org-emphasis-regexp-components is a variable defined in `org.el'.
>> | Its value is ("('\"{" "-   .,:!?;'\")}\\" "
>> | ,\"'" "." 1)
>> | 
>> | Documentation:
>> | Components used to build the regular expression for emphasis.
>> | This is a list with five entries.  Terminology:  In an emphasis string
>> | like " *strong word* ", we call the initial space PREMATCH, the final
>> | space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
>> | and "trong wor" is the body.  The different components in this variable
>> | specify what is allowed/forbidden in each part:
>> | 
>> | pre  Chars allowed as prematch.  Beginning of line will be allowed 
>> too.
>> | post Chars allowed as postmatch.  End of line will be allowed too.
>> | border   The chars *forbidden* as border characters.
>> | body-regexp  A regexp like "." to match a body character.  Don't use
>> |  non-shy groups here, and don't allow newline here.
>> | newline  The maximum number of newlines allowed in an emphasis exp.
>> | 
>> | You need to reload Org or to restart Emacs after customizing this.
>> | 
>> | [back]
>> `
>>
>>> [...]
>>
>> [1] http://orgmode.org/worg/dev/org-syntax.html#Emphasis_Markers
>>
>> Regards,
>> -gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



Re: [O] Markup (=, ~) in word?

2015-10-29 Thread Göktuğ Kayaalp
On Thu, Oct 29 2015 at  2:21:17 pm EEST, Rainer M Krug <rai...@krugs.de> wrote:
> Matt Price <mopto...@gmail.com> writes:
>
>> #+BEGIN_VERBATIM
>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>> #+END_VERBATIM
>
> The other way round:
>
> I want the text, e.g. =SITE= as the markup, and not the whole text as
> verbatim - sorry for not being clear about what I want.
>
> Rainer
>

AFAIK that is  impossible out of the box, Org  does not allow inter-word
markup,  as there  is no  escaping in  the syntax.   In the  thread with
subject  *Some  projects* on  this  list  they  talk also  about  adding
escaping.  You can still add some inline LaTeX for that though, I think,
or  maybe you  can  tweak  `org-emphasis-regexp-components', (also,  see
[1]):

,[ C-h v org-emphasis-regexp-components RET ]
| org-emphasis-regexp-components is a variable defined in `org.el'.
| Its value is ("   ('\"{" "-   .,:!?;'\")}\\" "
| ,\"'" "." 1)
| 
| Documentation:
| Components used to build the regular expression for emphasis.
| This is a list with five entries.  Terminology:  In an emphasis string
| like " *strong word* ", we call the initial space PREMATCH, the final
| space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
| and "trong wor" is the body.  The different components in this variable
| specify what is allowed/forbidden in each part:
| 
| pre  Chars allowed as prematch.  Beginning of line will be allowed 
too.
| post Chars allowed as postmatch.  End of line will be allowed too.
| border   The chars *forbidden* as border characters.
| body-regexp  A regexp like "." to match a body character.  Don't use
|  non-shy groups here, and don't allow newline here.
| newline  The maximum number of newlines allowed in an emphasis exp.
| 
| You need to reload Org or to restart Emacs after customizing this.
| 
| [back]
`

> [...]

[1] http://orgmode.org/worg/dev/org-syntax.html#Emphasis_Markers

Regards,
-gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



Re: [O] How can I call the exporter from function?

2015-10-26 Thread Göktuğ Kayaalp
On Sun, Oct 25 2015 at 10:19:01 pm EET, joa...@verona.se wrote:
> I want to call the exporter in a certain way, so I don't have to type
> the same options every time.
>
> Basically I want to do first this:
> (re-search-backward "^\\*\\* ")
> (org-mark-subtree)
>
> Then I want to export the marked subtree as odt.

See the  docstring of  `org-odt-export-to-odt'.  Its second  argument is
SUBTREEP, if T, only the subtree under  the point is exported. So a call
like:

   (org-odt-export-to-odt nil t)

Would sort your problem out.

>
> With command keys it becomes something like:
> c-c c-e c-s o o
>
> ... If I remember correctly. In this case I would rather do
>
> m-x my-own-canned-exporter
>
> I tried following the exporting dispatcher function but got lost in the
> wilderness. Does anyone have a suggestion?

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



[O] Bug: `org-timestamp-format' does not return correct time [8.2.10 (8.2.10-41-g42228a-elpa @ /home/gk/.emacs.d/packages/org-20150601/)]

2015-10-21 Thread Göktuğ Kayaalp

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

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


The function `org-timestamp-format' returns bad values:

(org-timestamp-format "<2015-10-07 Wed>" "%d %B %Y")
"30 November -001"
(org-timestamp-format "[2015-10-07 Wed]" "%d %B %Y")
"30 November -001"
(org-timestamp-format "[2015-10-07]" "%d %B %Y")
"30 November -001"
(org-timestamp-format "<2015-10-07>" "%d %B %Y")
"30 November -001"
(org-timestamp-format "2015-10-07" "%d %B %Y")
"30 November -001"
(org-timestamp-format (current-time) "%d %B %Y")
"30 November -001"
(org-timestamp-format (org-parse-time-string "[2015-10-07 Wed]")
  "%d %B %Y")
"30 November -001"


I tried this for my latex export filter, and got the same output for the
timestamp in the second example:

(defun gk-ox-latex-format-inactive-timestamp (text backend info)
  (when (org-export-derived-backend-p backend 'latex)
(org-timestamp-format text "%d %B %Y")))

I get the expected result from this piece of code:

(format-time-string
 "%d %B %Y"
 (apply #'encode-time
(org-parse-time-string
 text)))
"07 November 2015"

I see two commits that affect this function, visible here:

http://orgmode.org/cgit.cgi/org-mode.git/log/?qt=grep=org-timestamp-format=1

One of them adds it, the other one refactors it, without changing the logic.

Emacs  : GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-10 on foutrelis
Package: Org-mode version 8.2.10 (8.2.10-41-g42228a-elpa @ 
/home/gk/.emacs.d/packages/org-20150601/)



Re: [O] Export datetree item subtree with its date, not the file's

2015-10-20 Thread Göktuğ Kayaalp
Hello,

Thanks  for your  response.  As  you suggest,  I switched  to using  the
EXPORT_DATE property.  It works as expected.

Now a little problem  that I have is that I  cannot have timestamps like
«10 September 2015» in my exports, but a literal inactive timestamp.

This is because in  the related capture template, I have  to use `%u' to
add a timestamp, which adds an inactive timestamp, reusing the date that
I entered into  the datetree prompt.  There is the  %<...> directive for
the capture  templates which allows  me to put in  a time format,  as in
`format-time-string',  but it  gets its  value from  `current-time', not
from the date  of the datetree prompt.  Now  I do not know if  this is a
feature or  a bug, but if  I want to  copy over lecture notes  from some
time ago, it's a problem.

-gk

On Sat, Oct 17 2015 at 10:33:08 am EEST, Kyle Meyer <k...@kyleam.com> wrote:
> Hello,
>
> s...@gkayaalp.com (Göktuğ Kayaalp) writes:
>
>> Hi,
>>
>> This is my  first post to this  group, so I'm sorry if  I'm skipping any
>> conventions.
>
> Welcome to the list.  Sorry for the lack of responses to your post.
> It's a high traffic list, and sometimes posts fall through.
>
>> My overall structure is like this:
> [...]
>> #+DATE:
>> * 2015
>> ** 2015-09 September
>> *** 2015-09-16 Wednesday
>>  İtalyanca Dil Uygulamaları I :2015_2016:ITDE2016:
>> [2015-09-16 Wed]
> [...]
>> When  I export-subtree  the bottommost  entry, I  want the  date in  the
>> exported pdf  to be 2015-09-16,  not today,  nor the date  in "#+DATE:",
>> which is  deliberately empty to  not let a wrong  date to appear  in the
>> exported file.
>>
>> I tried  setting a date property  which didn't have an  effect, and also
>> adding a "#+DATE:  [a date...]" under every lecture  note entry heading,
>> in which case the  date of the last entry in the file  got used, so if I
>> exported the notes from 2015-09-16, and the last time I added a note was
>> the 19th, the exported file had the date 2015-09-19.
>
> Have you tried the EXPORT_DATE property?  I believe it'd look something
> like this
>
> * 2015
> ** 2015-09 September
> *** 2015-09-16 Wednesday
> **** İtalyanca Dil Uygulamaları I :2015_2016:ITDE2016:
> :PROPERTIES:
> :EXPORT_DATE: 2015-09-16
> :END:
>
> which you could export using with export scope set to "subtree".
>
> --
> Kyle

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/



[O] Export datetree item subtree with its date, not the file's

2015-10-02 Thread Göktuğ Kayaalp
Hi,

This is my  first post to this  group, so I'm sorry if  I'm skipping any
conventions.  And sorry for the dense subject line,  I didn't want it to
be too long.  Thanks a lot for the hard work on org-mode.

I have  started recently to organise  my lecture notes into  a datetree.
Every now and then I have to  export my notes, usually to pdfs, in order
to share them with friends, or  study/read myself in printed form.  Now,
when I export to pdf an  item, the "\maketitle" header contains the date
from the file's "#+DATE:" thing[1].  I'd like it to contain the date for
the current  item, i.e. if  it is  under the "***  2015-09-16 Wednesday"
heading, the pdf to have "16 Sep 2015".   Now I guess that I can do some
temporary-buffer hack to make this happen, but I wonder if there already
exist a /normal/ way to achieve this.

My overall structure is like this:

# $Id: Italianistica.org,v 1.5 2015/09/30 18:08:27 gk Exp gk $
#+TITLE: Appunti di Italianistica
#+STARTUP: contents
#+OPTIONS: toc:nil tags:nil
#+LaTeX_CLASS: gk-appunto
#+DATE:
* 2015
** 2015-09 September
*** 2015-09-16 Wednesday
 İtalyanca Dil Uygulamaları I :2015_2016:ITDE2016:
[2015-09-16 Wed]

amare \ne voler bene

_amare_ si usa quasi sempre _all'interno di una coppia_

_voler bene_ si usa tra _amici, parenti, ecc._


When  I export-subtree  the bottommost  entry, I  want the  date in  the
exported pdf  to be 2015-09-16,  not today,  nor the date  in "#+DATE:",
which is  deliberately empty to  not let a wrong  date to appear  in the
exported file.

I tried  setting a date property  which didn't have an  effect, and also
adding a "#+DATE:  [a date...]" under every lecture  note entry heading,
in which case the  date of the last entry in the file  got used, so if I
exported the notes from 2015-09-16, and the last time I added a note was
the 19th, the exported file had the date 2015-09-19.

So how can I, if I can at all, achieve what I want without tucking the
tree into a temp buffer, adding the correct #+DATE into it, copying the
org header and exporting?  Is there a standard way to achieve this?

Thanks in advance,
-goktug



[1] Property?  I don't really know what these are called.