Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-16 Thread Jean-Christophe Helary



> On Feb 16, 2020, at 17:05, Marcin Borkowski  wrote:
> 
> 
> On 2020-02-16, at 01:46, Jean-Christophe Helary 
>  wrote:
> 
>>> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
>>> 
>>> 
>>> On 2020-02-14, at 21:48, Bastien  wrote:
>>> 
>>>> We have a good reference documentation for creating export backends:
>>>> https://orgmode.org/worg/dev/org-export-reference.html
>>>> 
>>>> But we *badly* need a step by step tutorial on Worg.
>>>> 
>>>> Anyone would like to volunteer for writing such a tutorial?
>>> 
>>> I might try to at least start it, though I'll need some time.  When is
>>> that needed?  (I assume that the sooner, the better, so if there is
>>> anyone who would beat me to it, go on.  I might do some proofreading
>>> then.)
>> 
>> Marcin,
>> 
>> Aren't you supposed to write a book about Emacs already ? ;)
> 
> Yep, point taken.

I'm really not picking on you or anything :) I just realized that I would have 
written *exactly* the same thing in other contexts knowing that my plate is 
already over-full.

> But the tutorial is a much smaller thing, and
> I already did a similar thing (the Emacs Conf 2015 talk on creating
> derived exporters), so much of the work is already done.

And I'd love to read that.


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





Re: Step by step tutorial on Worg on how to create a new export backend

2020-02-15 Thread Jean-Christophe Helary



> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
> 
> 
> On 2020-02-14, at 21:48, Bastien  wrote:
> 
>> We have a good reference documentation for creating export backends:
>> https://orgmode.org/worg/dev/org-export-reference.html
>> 
>> But we *badly* need a step by step tutorial on Worg.
>> 
>> Anyone would like to volunteer for writing such a tutorial?
> 
> I might try to at least start it, though I'll need some time.  When is
> that needed?  (I assume that the sooner, the better, so if there is
> anyone who would beat me to it, go on.  I might do some proofreading
> then.)

Marcin,

Aren't you supposed to write a book about Emacs already ? ;)


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





Re: Format of Effort estimates should be mentioned in its Info node

2020-01-03 Thread Jean-Christophe Helary



> On Jan 4, 2020, at 14:20, Kisaragi Hiu  wrote:
> 
> It didn't work for me because I gave it "10m" which actually means 10 months, 
> I've realized.
> 
> Still, Durations as defined by org-duration.el should be described in the 
> manual like how Timestamps are.

This does look like a potential contribution to the package.

Jean-Christophe Helary

> 
> 2020年1月4日 11:55 差出し人: k...@kyleam.com:
> 
>> Kisaragi Hiu  writes:
>> 
>>> Currently, the Info node about effort estimates does not mention what
>>> format should it be written in. This causes confusion, as a user might
>>> assume that it's the same format as schedulers (10m, 6h, etc.) like I
>>> did.
>>> 
>>> Simply mentioning "Effort estimates need to have the format H:MM"
>>> 
>> 
>> I don't personally use effort estimates, but quickly poking around I see
>> some indication that estimates should work fine with things like 10min
>> rather than 0:10.  In particular org-set-effort has a bit that looks
>> like this:
>> 
>> (org-refresh-property '((effort . identity)
>> (effort-minutes . org-duration-to-minutes))
>> value)
>> 
>> The presence of org-duration-to-minutes hints to some sort of
>> normalization:
>> 
>> (org-duration-to-minutes "10min") ; => 10.0
>> (org-duration-to-minutes "0:10")  ; => 10.0
>> 
>> And it looks like org-agenda-compare-effort uses the effort-minutes text
>> property.  That's presumably why, when I view the entries below in the
>> agenda, org-agenda-filter-by-effort (bound to "_") treats them the same:
>> 
>> * TODO a
>> :PROPERTIES:
>> :Effort:  10min
>> :END:
>> 
>> * TODO b
>> :PROPERTIES:
>> :Effort:   0:10
>> :END:
>> 
>> But that's just one use of effort values, and it sounds like you've hit
>> into cases where the 10min form didn't work as expected.  Could you
>> provide more details?
>> 
>>> (copied from the docstring or org-effort-property, the only*
>>> description of the format I could find) in the Info node would be
>>> enough.
>>> 
>> 
>> Given the above, it seems like org-effort-property's docstring is at
>> least somewhat inaccurate.
>> 
> 
> 

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





Re: using #+ to define faces

2019-12-31 Thread Jean-Christophe Helary



> On Dec 31, 2019, at 18:57, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Jean-Christophe Helary 
> writes:
> 
>> I would like to define faces on a file basis by using #+ but I'm not
>> finding relevant info in the manual.
>> 
>> Is it possible ?
> 
> You may be able to set faces using file-local variables (info
> "(emacs)File Variables"), but I haven't checked.

Thank you Nicolas, I'll check later.


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





using #+ to define faces

2019-12-30 Thread Jean-Christophe Helary
I would like to define faces on a file basis by using #+ but I'm not finding 
relevant info in the manual.

Is it possible ?


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





Re: org 9.2.6 and org 9.1.9

2019-11-26 Thread Jean-Christophe Helary
Thank you Stefan. I'll try to reproduce the issue and then I'll report.

Jean-Christophe

> On Nov 27, 2019, at 12:24, Stefan Monnier  wrote:
> 
>> What should happen is that
>> 1) packages.el should see that I'm trying to install a package that requires
>> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
>> installed and do I really want to do that, etc.
>> 
>> 2) *or* just consider that it's better for me to use 9.2.6 instead of
>> whatever comes with emacs and make sure that the older package is forgotten
>> by emacs.
> 
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
> 
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).
> 
> 
>Stefan



Re: org 9.2.6 and org 9.1.9

2019-11-26 Thread Jean-Christophe Helary



> On Nov 27, 2019, at 11:59, Cook, Malcolm  wrote:
> 
> Tim,
>  
> Yes, it is a bit of dependency hell.

I see 2 solutions here:

1) org is only provided as a built-in package and updated there when necessary
2) org is removed from the built in packages

The current situation is really weird.

Jean-Christophe

>  
> Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x :
>  
>  
> Here's what I do, at the shell:
>  
>   emacs -Q -batch -eval "(progn (require 'package) (add-to-list 
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\;;))  
> (package-initialize) (package-refresh-contents) (package-install 
> 'org-plus-contrib))"
>  
> This assures that org is not already loaded when org is compiled, which I've 
> learned is the source of creating a mess.
>  
> Note: I use org-plus-contrib from melpa instead of org.  If you want just 
> org, 
> you could simply:
>  
>   emacs -Q -batch -eval "(progn (require 'package) 
> (package-initialize) 
> (package-refresh-contents) (package-install 'org-plus-contrib))"
>  
> HTH,
>  
> Malcolm
>  
>  
>  
> From: Emacs-orgmode  On Behalf 
> Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos 
> Cc: Org-mode ; Emacs developers 
> Subject: Re: org 9.2.6 and org 9.1.9
>  
> CAUTION: This email was received from an External Source
>  
> 
> There is a very important rule which must be followed wrt org-mode 
> installation. It is critical that no version of org is already loaded before 
> installing a new version. This can be quite tricky as many of us have org 
> setups which automatically load some org functionality without explicitly 
> opening an org file or agenda view (for example, you might be using an org 
> add-on for email). Situation is worse if we are loading org as part of our 
> init.el.
>  
> I'm also not sure that tweaking the load-path order is sufficient if your 
> installing org via M-x package-install as there is a 'chicken and egg' 
> problem with the initial install. If your init.el file is loading org 
> functionality and you only have the built-in org version installed, that 
> version will be loaded before you run package-install. Probably works if you 
> install via your init.el though.
>  
> I've found the safest thing to do is only use autoload or use-package with 
> deferred loading for org and whenever updating org (I use the 
> org-plus-contrib package from the org elpa repo) only update immediately 
> after a fresh restart of emacs and before doing anything else.  Failing to do 
> this often results in a broken build as you get a set of new org elc files 
> which contains definitions from two different org versions. When the versions 
> are only different in minor version numbers, this mixed build may not even be 
> noticeable, but when major version differences exist, you get the symptom of 
> broken functionality, missing definitions or unbound symbols.
>  
> The situation is made worse by package maintainers specifying the latest org 
> version rather than the version built into Emacs when the bundled version 
> would be sufficient.
>  
> It took me a while to structure my init.el file such that no org 
> functionality was loaded until I used something which depends on it. However, 
> once I did, provided I only update org in a fresh new session, all works 
> flawlessly. I found use-package package really helped with this. 
>  
>  
>  
> On Wed, 27 Nov 2019 at 06:22, Nick Dokos  wrote:
> Jean-Christophe Helary  writes:
> 
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both 
> > installed creates conflicts.
> >
> 
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
> 
> (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
> 
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
> 
>(delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
> 
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
> 
> > Why

Re: org 9.2.6 and org 9.1.9

2019-11-26 Thread Jean-Christophe Helary
Nick, thank you for your reply.

> On Nov 27, 2019, at 4:15, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> org 9.1.9 is a built-in
>> 
>> but org 9.2.6 comes as a dependency to some packages and having both 
>> installed creates conflicts.
>> 
> 
> What conflicts are you seeing?

At one point I was unable to archive subtrees because some function was 
undefined.
I uninstalled 9.2.6 and the issues was fixed.

> I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems:

Obviously you are not the typical user... :)

What should happen is that
1) packages.el should see that I'm trying to install a package that requires 
9.2.6 as a dependency and it should notify me that 9.1.9 is already installed 
and do I really want to do that, etc.

2) *or* just consider that it's better for me to use 9.2.6 instead of whatever 
comes with emacs and make sure that the older package is forgotten by emacs.

But honestly, I think 1) should be the default for any package.


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





org 9.2.6 and org 9.1.9

2019-11-24 Thread Jean-Christophe Helary
org 9.1.9 is a built-in

but org 9.2.6 comes as a dependency to some packages and having both installed 
creates conflicts.

Why does that happen ?

Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues with that 
situation and that's extremely confusing. What is the best way to solve that ?



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





[O] sync a single subtree to a different file

2019-09-30 Thread Jean-Christophe Helary
I'm looking for a way to sync a given subtree to a different file, 
semi-automatically (it at the launch of a command).

Is there something like that in org-mode ?

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





Re: [O] Capture template issue ?

2019-09-19 Thread Jean-Christophe Helary
The issue is systematic.

I have changed my settings to:

 org-hide-leading-stars nil
 org-startup-folded nil 

But that doesn't change anything.

I have quasi systematically the issue I described when the file that will be 
modified by the capture is not visible when I capture, and generally I don't 
have it when it is visible when I do.

Currently, the place where that happens most (?) is when I add captured text in 
a "file+datetree" structure right over a "file+headline" structure.

Jean-Christophe Helary 

> On Sep 17, 2019, at 8:48, Jean-Christophe Helary 
>  wrote:
> 
> I have an issue with my capture templates where if I add an item at the end 
> of list, the item seems to "eat" the following line break and merges with the 
> item that follows:
> 
> * List 1
> ** item 1
> ** item 2
> * List 2
> ** item 3
> ** item 4
> 
> displayed
> 
> * List 1 ...
> * List 2 ...
> 
> I add item 5 to List 1, I should get:
> 
> * List 1
> ** item 1
> ** item 2
> ** item 5
> * List 2 ...
> 
> But instead I get
> 
> * List 1
> ** item 1
> ** item 2
> ** item 5 * List 2 ...
> 
> which makes List 2 disappear for all practical purposes.
> 
> That's pretty systematic, and very annoying.
> 
> Nearly all my templates show a similar behavior.
> 
> This one was:
> 
>  (file+headline "~/org/journal.org" "Dictionnaire")
>   "* %? :%^{tag}:\n")
> 
> I'm using the built-in 9.1.9 version, with an emacs from master built a few 
> days ago, on macos.
> 
> And my org setup is this:
> 
> (setq org-use-speed-commands t
>  org-directory "~/org"
>  org-default-notes-file (concat org-directory "/notes.org")
>  org-refile-targets '((org-agenda-files :maxlevel . 3))
>  org-refile-use-outline-path 'file
>  org-outline-path-complete-in-steps nil
>  org-refile-allow-creating-parent-nodes 'confirm
>  org-startup-indented t
>  org-use-fast-todo-selection t
>  org-return-follows-link t
>  org-link-abbrev-alist '(("message" . "mailto"))
>  org-todo-keywords
>  '((sequence "TODO(t)" "|" "DONE(d)")
>   (sequence "WAIT(w)" "|" "IN-PROGRESS" "|" "CANCELED(c)"))
>  org-agenda-files
>  '("/Users/suzume/org/" "/Users/suzume/Library/Application 
> Support/Notational Data/")
>  org-indirect-buffer-display 'current-window
>  org-modules
>  '(org-bbdb org-bibtex org-docview org-habit org-info org-irc org-mhe 
> org-protocol org-rmail)
>  org-support-shift-select t
>  org-todo-keyword-faces
>  '(("IN-PROGRESS" . "orange") ("WAIT" . "magenta") ("CANCELED" . 
> "darkgreen") ("TODO" . "pink") ("DONE" . "green")))
> 
> 
> Where should I investigate to fix this ?
> 
> 
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
> 
> 
> 

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




[O] Capture template issue ?

2019-09-16 Thread Jean-Christophe Helary
I have an issue with my capture templates where if I add an item at the end of 
list, the item seems to "eat" the following line break and merges with the item 
that follows:

* List 1
** item 1
** item 2
* List 2
** item 3
** item 4

displayed

* List 1 ...
* List 2 ...

I add item 5 to List 1, I should get:

* List 1
** item 1
** item 2
** item 5
* List 2 ...

But instead I get

* List 1
** item 1
** item 2
** item 5 * List 2 ...

which makes List 2 disappear for all practical purposes.

That's pretty systematic, and very annoying.

Nearly all my templates show a similar behavior.

This one was:

   (file+headline "~/org/journal.org" "Dictionnaire")
   "* %? :%^{tag}:\n")

I'm using the built-in 9.1.9 version, with an emacs from master built a few 
days ago, on macos.

And my org setup is this:

(setq org-use-speed-commands t
  org-directory "~/org"
  org-default-notes-file (concat org-directory "/notes.org")
  org-refile-targets '((org-agenda-files :maxlevel . 3))
  org-refile-use-outline-path 'file
  org-outline-path-complete-in-steps nil
  org-refile-allow-creating-parent-nodes 'confirm
  org-startup-indented t
  org-use-fast-todo-selection t
  org-return-follows-link t
  org-link-abbrev-alist '(("message" . "mailto"))
  org-todo-keywords
  '((sequence "TODO(t)" "|" "DONE(d)")
(sequence "WAIT(w)" "|" "IN-PROGRESS" "|" "CANCELED(c)"))
  org-agenda-files
  '("/Users/suzume/org/" "/Users/suzume/Library/Application 
Support/Notational Data/")
  org-indirect-buffer-display 'current-window
  org-modules
  '(org-bbdb org-bibtex org-docview org-habit org-info org-irc org-mhe 
org-protocol org-rmail)
  org-support-shift-select t
  org-todo-keyword-faces
      '(("IN-PROGRESS" . "orange") ("WAIT" . "magenta") ("CANCELED" . 
"darkgreen") ("TODO" . "pink") ("DONE" . "green")))


Where should I investigate to fix this ?


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





Re: [O] org-megaup

2019-08-31 Thread Jean-Christophe Helary
Thank you Nick for the help.

It looks like I some kind of interference between the built-in org-mode and the 
most recent package available in melpa. Everything is fixed now.

> On Aug 31, 2019, at 4:42, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> When I use org-megaup I get a "Invalid function:
>> org-preserve-local-variables" is there a way to fix that ?
>> 
> 
> org-megaup is not defined AFAICT - do you mean `org-metaup'?
> 
> If not, disregard the rest of this message.
> 
> If yes, I don't see any problems, so you might want to provide the
> context (e.g. are trying to move subtrees up, move table rows up or
> move items in a list up?) Check also the value of `org-metaup-hook' to
> see if something weird crept in there.
> 
> If it happens regardless of context, I would edebug the org-metaup
> function and see where the error message comes from - BTW,
> org-preserve-local-variables is a macro, not a function (so that might
> have something to do with it), defined in org-macs.el. If your setup
> is curdled, that might not be loaded, so try `(load-library org-macs)`
> and see if that resolves if: if it does, then you have to figure out
> whether there is something wrong with your setup (if it doesn't load
> that file automatically) or how it got curdled (if it does).
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
> 
> 

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





Re: [O] org-megaup

2019-08-30 Thread Jean-Christophe Helary


> On Aug 31, 2019, at 4:42, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> When I use org-megaup I get a "Invalid function:
>> org-preserve-local-variables" is there a way to fix that ?
>> 
> 
> org-megaup is not defined AFAICT - do you mean `org-metaup'?

Yes, thank you. I'll check everything you wrote this we.

Jean-Christophe

> If not, disregard the rest of this message.
> 
> If yes, I don't see any problems, so you might want to provide the
> context (e.g. are trying to move subtrees up, move table rows up or
> move items in a list up?) Check also the value of `org-metaup-hook' to
> see if something weird crept in there.
> 
> If it happens regardless of context, I would edebug the org-metaup
> function and see where the error message comes from - BTW,
> org-preserve-local-variables is a macro, not a function (so that might
> have something to do with it), defined in org-macs.el. If your setup
> is curdled, that might not be loaded, so try `(load-library org-macs)`
> and see if that resolves if: if it does, then you have to figure out
> whether there is something wrong with your setup (if it doesn't load
> that file automatically) or how it got curdled (if it does).
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler

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




[O] org-megaup

2019-08-29 Thread Jean-Christophe Helary
When I use org-megaup I get a "Invalid function: org-preserve-local-variables" 
is there a way to fix that ?

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





[O] Changing the face of the capture template ?

2019-07-28 Thread Jean-Christophe Helary
Sorry for asking such a beginner question.

I'm using a non monospace font for my daily work and I'd like to have the 
capture template buffer be in monospace. How do I do that ?


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





Re: [O] message:// links

2018-11-10 Thread Jean-Christophe Helary
Thank you Nicolas.

Jean-Christophe 

> On Nov 10, 2018, at 16:28, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Jean-Christophe Helary  writes:
> 
>> I'm pasting a message:// link into an org-mode file but it fails to be
>> recognized as a link that should open in a mail client.
>> 
>> What is a simple way to have org-mode recognize such links ?
> 
> One simple way is to define "message:" as an alias for "mailto:;, which
> is the Org syntax for such links.  This is done with
> `org-link-abbrev-alist' variable, or in-buffer "LINK" keyword:
> 
>  (setq org-link-abbrev-alist '(("message" . "mailto")))
> 
> One drawback is that you cannot write plain links with abbreviations. So
> [[message:f...@bar.baz]] works, but message:@f...@bar.baz does not.
> 
> If that is an issue, you can also define a new link with
> `org-link-set-parameters':
> 
>(org-link-set-parameters "message" 
> :follow (lambda (path) (browse-url (concat "mailto:; path
> 
> HTH,
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

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




[O] message:// links

2018-11-09 Thread Jean-Christophe Helary
I'm pasting a message:// link into an org-mode file but it fails to be 
recognized as a link that should open in a mail client.

What is a simple way to have org-mode recognize such links ?

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





[O] bug#27140: Different key bindings between GUI emacs and terminal emacs

2018-07-07 Thread Jean-Christophe Helary
Sorry, I missed that. Proceed with closing and if there is an issue I'll send a 
report again.

Jean-Christophe 

> On Jul 7, 2018, at 20:12, Nicolas Goaziou  wrote:
> 
> Nicolas Goaziou  writes:
> 
>> I think I fixed it in Org's master branch (aka Org 9.2).
>> 
>> Meanwhile, I think setting `org-use-extra-keys' to a non-nil value
>> should do the trick.
>> 
>> Could you confirm it?
> 
> I'm closing this report. Since there was no answer from the OP, I assume
> the issue is fixed.





Re: [O] info URL « open at point » patch

2018-06-24 Thread Jean-Christophe Helary


> On Jun 24, 2018, at 15:57, Vincent Belaïche  wrote:
> 
> Bonjour tout l'monde !
> I am writing to both Emacs-devel and org-mode list because this concerns
> browsing URL, and Org-mode already has quite some stuff on this.
> Recently I came across this that in an Info file a « file: » protocol
> URL is not opened at point. Please find attached a patch to make it
> known to the Emacs info browser.
> My point was that I have some manual that are only in HTML or PDF, like
> the SVN manual, In have a local copy, and I want to find it through a
> manual index that I written in Texinfo to get an info node with this
> index.

> 

Wouldn't it be shorter and easier to understand/maintain to explicitly describe 
the protocols:

+ ((setq node (Info-get-token (point) 
"\\(?:f\\(?:ile\\|tp\\)\\|https?\\)://"

???

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





Re: [O] Localized org-mode

2018-05-12 Thread Jean-Christophe Helary


> On May 13, 2018, at 7:48, Göktuğ Kayaalp <s...@gkayaalp.com> 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] Localized org-mode

2018-05-12 Thread Jean-Christophe Helary


> On May 12, 2018, at 20:07, Göktuğ Kayaalp <s...@gkayaalp.com> 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

2018-05-11 Thread Jean-Christophe Helary


> On May 12, 2018, at 7:23, Göktuğ Kayaalp <s...@gkayaalp.com> 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.

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.

> 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.

> 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.

And that is a good thing.

>> 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.

Proprietary software has so many issues that most pro-grade software is not 
even localized.

>  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...)


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




Re: [O] Localized org-mode

2018-05-09 Thread Jean-Christophe Helary


> On May 10, 2018, at 0:41, Diego Zamboni <di...@zzamboni.org> wrote:
> 
> 
> On Wed, May 9, 2018 at 3:48 PM, Jean-Christophe Helary <brandel...@gmail.com 
> <mailto:brandel...@gmail.com>> wrote:
> You misquoted me. I was talking about design constraints when C and Lisp were 
> created, which kept language creators from "inventing" proper language 
> localization. I was specifically replying to Diego Zamboni regarding that.
> 
> I don't think it was only those constraints. Imagine if C and LISP had been 
> designed with "keywords in your own language" in mind.

That was not physically possible at the time. It is now. And as I wrote, Scheme 
can do that easily. But that's not the topic of the current thread. Sorry for 
that.

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




Re: [O] Localized org-mode

2018-05-09 Thread Jean-Christophe Helary
You misquoted me. I was talking about design constraints when C and Lisp were 
created, which kept language creators from "inventing" proper language 
localization. I was specifically replying to Diego Zamboni regarding that.

> On May 9, 2018, at 22:25, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 
> Hello,
> 
> Jean-Christophe Helary <brandel...@gmail.com> writes:
> 
>> There are no practical reasons why that should not be possible.
> 
> Yet, I gave some already. Consider the following three documents:


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




Re: [O] Localized org-mode

2018-05-09 Thread Jean-Christophe Helary


> On May 9, 2018, at 21:07, Kaushal Modi <kaushal.m...@gmail.com> wrote:
> 
> Hello all,
> 
> 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.

> 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.

> So much +1 on that! Supporting multi-language keywords will make it difficult 
> for 3rd party Org parsers to adopt them too, resulting in even lesser Org 
> adoption.

Genuine question: how many 3rd party tools do support the org format ?

> I like Nicolas' idea where display properties are used to replace the English 
> keywords with the translation; that way the actual Org source remains 
> untouched. 

What matters is that users find org easy to use in their language. But emacs 
(the main org user) is so far behind in that respect compared to the rest of 
the FLOSS ecosystem that even having one mode that implements some sort of l10n 
would be huge. Although, it would be nice to have that work nicely with already 
existing l10n processes. 


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




[O] 3 manuals fail to export to PO (gnus, idlwave, org)

2018-04-21 Thread Jean-Christophe Helary
'

elisp.texi:167: (po4a::tex)
unmatched end of environment 'html'

modes.texi:2631: (po4a::tex)
unmatched end of environment 'ftable'



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





Re: [O] 3 manuals fail to export to PO (gnus, idlwave, org)

2018-04-21 Thread Jean-Christophe Helary


> On Apr 16, 2018, at 0:00, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> 3 manuals distributed with emacs fail to export to po format when using the 
>> following command:
>> 
>> po4a-gettextize -f texinfo -M utf8 -m name.texi -p name.texi.fr.po
>> 
>> gnus.texi
>> 
>> Use of uninitialized value $newfilepath in string eq at 
>> /opt/local/lib/perl5/5.24/Locale/Po4a/TeX.pm line 961.
>> po4a::tex: Can't find gnus.texi with kpsewhich
> 
> I don't understand what this error message means, in terms of the
> Texinfo sources.  Can you explain, please?  Taken at face value, it
> looks like a bug in TeX.pm, whereby a variable is not initialized.

I just sent the report, my idea is that it's po4a issues but the po4a-devel 
list doesn't respond.

Jean-Christophe 

> 
>> idlwave.texi
>> 
>> idlwave.texi:370: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:1242: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:2964: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3101: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3497: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3559: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:4021: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:4078: (po4a::tex)
>> unmatched end of environment 'html'
> 
> These all seem bogus, because the source looks correct to me.  Here's
> the first instance:
> 
>  @html
>  
>  @end html
> 
> I see nothing wrong here; do you?
> 
> (Maybe you are using an old version of the manual; I looked in what's
> currently on the emacs-26 branch of the Emacs Git repository.)
> 
>> idlwave.texi:4088: (po4a::tex)
>> un-balanced { in 'Whenever an IDL error occurs or a breakpoint is hit, I get'
> 
> Nothing wrong here, either:
> 
>  @enumerate
> 
>  @item @strong{Whenever an IDL error occurs or a breakpoint is hit, I get
>  errors or strange behavior when I try to type anything into some of my
>  IDLWAVE buffers.}
> 
> The Texinfo manual says it's okay to have multi-line text after @item:
> 
> Write the text of the enumerated list in the same way as an itemized
>  list: write a line starting with '@item' at the beginning of each item
>  in the enumeration.  It is ok to have text following the '@item', and
>  the text for an item can continue for several paragraphs.
> 
> Looks like po4a doesn't support this feature of the Texinfo language?
> 
>> org.texi
>> 
>> perl just keeps churning data without outputting anything.
> 
> Hard to do anything with this, without more diagnostic data.
> 
>> A number of other manuals output errors but are properly exported to po:
> 
> These looks bogus as well.  E.g.:
> 
>> cmdargs.texi:726: (po4a::tex)
>> unmatched end of environment 'vtable'
> 
> There's a matching "@vtable @env" on line 674.
> 
> So I submit these problems are bugs in po4a, and the Emacs manuals are
> OK.
> 
> Thanks.

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




Re: [O] Applescript help

2017-11-13 Thread Jean-Christophe Helary


> On Nov 13, 2017, at 17:39, Alan Schmitt <alan.schm...@polytechnique.org> 
> wrote:
> 
> On 2017-11-11 20:06, Jay Iyer <jayiye...@gmail.com> writes:
> 
>> Hi, in my Org workflow, I am trying to use the do-applescript function to
>> hide an active Emacs session.  Can you tell me what I am doing wrong with
>> the following that I think should work but is not?  Thanks. -jay
>> 
>> (do-applescript "tell application \"Finder\" set visible of application
>> process \"Emacs\" to false")
> 
> Don't you need an "end tell"?

"end tell" if it's a block "to" if it's a line:

>> (do-applescript "tell application \"Finder\" to set visible of application 
>> process \"Emacs\" to false")



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




Re: [O] htmlize

2017-10-25 Thread Jean-Christophe Helary
Thank you Jonas !

Jean-Christophe 


> On Oct 25, 2017, at 21:51, Jonas Bernoulli  wrote:
> 
> This was discussed here: https://github.com/hniksic/emacs-htmlize/issues/7.




[O] htmlize

2017-10-24 Thread Jean-Christophe Helary
I tried to export to html and org told me to first install htmlize ( 
https://github.com/hniksic/emacs-htmlize).

I tried to find an emacs-htmlize in the package list, and found nothing, so I 
went to the github page and since  saw it was a seemingly normal el package 
called htmlize I checked again in the packages, found it and installed it 
directly from emacs.

Why doesn't org suggest to use package.el to install htmlize? That would be 
less confusing to users who don't have it installed by default.

Jean-Christophe 





Re: [O] capture templates and ^{prompt}

2017-07-04 Thread Jean-Christophe Helary
Sorry to send this question again:

> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?

Jean-Christophe 


> On Jun 30, 2017, at 20:04, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:
> 
>> 
>> On Jun 30, 2017, at 18:47, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
>> 
>> Jean-Christophe Helary <jean.christophe.hel...@gmail.com> writes:
>> 
>>> * TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n
>>> 
>>> gives
>>> 
>>> * TODO stuff [/]
>>>  
>>> ** TODO %^A stuff 
>>> 
>>> Why is that ?
>> 
>> In a string, backslash needs to be escaped: %\\1
> 
> That's certainly something to add to the documentation:
> 
> %\1 ... %\N   Insert the text entered at the Nth %^{prompt}, where N is a 
> number, starting from 1.
> 
> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?
> 
> Jean-Christophe




Re: [O] capture template and writeroom mode ?

2017-07-03 Thread Jean-Christophe Helary
Thank you Bsstien.

> On Jul 3, 2017, at 12:46, Bastien  wrote:
> 
>> What would be the best way to have writeroom mode called in one
>> given capture template and not the others ?
> 
> I would you a (file+)function to get the location:
> 
>`(file+function "path/to/file" function-finding-location)'
>  A function to find the right location in the file.
> 
>`(function function-finding-location)'
>  Most general way: write your own function which both visits
>  the file and moves point to the right location.
> 
> then tell the function to use writeroom-mode.

I'm already using the file+datetree target so I guess that's not possible, 
unless I define a function that triggers the writeroom mode *and* adds the 
datetree...

 ("j" "Journal" entry (file+datetree "~/org/journal.org")   
  
   "* %^{Titre} [%<%H:%M>]\n%?\n") ;;; :clock-in t :clock-resume t) 
   

Jean-Christophe 


[O] capture template and writeroom mode ?

2017-07-02 Thread Jean-Christophe Helary
What would be the best way to have writeroom mode called in one given capture 
template and not the others ?

Jean-Christophe 


Re: [O] capture templates and ^{prompt}

2017-06-30 Thread Jean-Christophe Helary

> On Jun 30, 2017, at 18:47, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 
> Jean-Christophe Helary <jean.christophe.hel...@gmail.com> writes:
> 
>> * TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n
>> 
>> gives
>> 
>> * TODO stuff [/] 
>>
>> ** TODO %^A stuff 
>> 
>> Why is that ?
> 
> In a string, backslash needs to be escaped: %\\1

That's certainly something to add to the documentation:

%\1 ... %\N Insert the text entered at the Nth %^{prompt}, where N is a 
number, starting from 1.

Are there cases where %\1 ... %\N would be used *outside* of a string in a 
template?

Jean-Christophe



Re: [O] capture templates and ^{prompt}

2017-06-30 Thread Jean-Christophe Helary
* TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n

gives

* TODO stuff [/]

** TODO %^A stuff 

Why is that ?

Jean-Christophe 
   


> On Jun 30, 2017, at 18:21, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:
> 
> Ooops, yes, that was totally under my nose :)
> Thank you very much.
> 
> Jean-Christophe 
> 
>> On Jun 30, 2017, at 18:18, numbch...@gmail.com wrote:
>> 
>> Check out the docstring of variable `org-capture-templates`.
>> There is a doc like this:
>> ```
>> %\1 ... %\N Insert the text entered at the nth %^{prompt}, where N
>>   is a number, starting from 1.




Re: [O] capture templates and ^{prompt}

2017-06-30 Thread Jean-Christophe Helary
Ooops, yes, that was totally under my nose :)
Thank you very much.

Jean-Christophe 

> On Jun 30, 2017, at 18:18, numbch...@gmail.com wrote:
> 
> Check out the docstring of variable `org-capture-templates`.
> There is a doc like this:
> ```
> %\1 ... %\N Insert the text entered at the nth %^{prompt}, where N
>   is a number, starting from 1.


[O] capture templates and ^{prompt}

2017-06-30 Thread Jean-Christophe Helary
I'm looking for a way to use the string acquired by prompt in a second location 
in the template, like:

* TODO %^{prompt} [/] :sometag:\n** TODO (value of ^{prompt} comes here) 
:someothertag:\n

What's the best way to get that "value of ^{prompt}" ?

Jean-Christophe 


Re: [O] keybindings again...

2017-06-30 Thread Jean-Christophe Helary

> On Jun 30, 2017, at 17:14, Nicolas Goaziou  wrote:

>> So, I have a few suggestions to improve that part of the documentation:
>> 1) add a list of preset keys in the manual
>> 2) add a line about speed keys in the compact guide
>> 
>> That's something I could do if the idea is accepted.
> 
> Sure! Improvements to documentation are always welcome.

Ok, I'll put that on my todo list now that I have solved that shortcut issue... 
:)

Jean-Christophe 


Re: [O] keybindings again...

2017-06-30 Thread Jean-Christophe Helary

> On Jun 30, 2017, at 14:27, Nicolas Goaziou  wrote:
> 
>> It would be nice if the org manual mentioned that too, and give
>> alternative keybindings for use in the terminal because that's
>> extremely confusing.
> 
> It does: (info "(org) TTY keys").

The alternative to M-S-RET is C-c C-x M = C-c C-x S-m

Why set an alternative like this when ESC RET S- does exactly the 
same thing and is way shorter/more practical ?

> See also `org-replace-disputed-keys'.

After looking at the "big" manual, I found about speed keys which seem to be a 
much more pragmatic approach to sorting that gui/tty key issue in org-mode. But 
except for a small paragraph and a few items in the tty section I could not 
find any reference to them, and nothing at all in the compact manual.

So, I have a few suggestions to improve that part of the documentation:
1) add a list of preset keys in the manual
2) add a line about speed keys in the compact guide

That's something I could do if the idea is accepted.

Jean-Christophe 

ps: section C3 of the manual has this line about Sacha Chua: "Sacha Chua 
suggested copying some linking code from Planner, and helped make Org pupular 
through her blog." It should be "popular" not "pupular".


Re: [O] keybindings again...

2017-06-30 Thread Jean-Christophe Helary
Eli and Yuri,

Thank you *so much* for the thorough explanations. Now I know.
After having finally understood how git was working I was going back to my list 
of things to do for/with emacs and got frustrated by that shortcut that kept 
not working...

Jean-Christophe 

> On Jun 30, 2017, at 15:17, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.hel...@gmail.com>
>> Do you mean that Shift is not recognized as a modified key by the terminal ?
> 
> No, that's not it.



Re: [O] keybindings again...

2017-06-30 Thread Jean-Christophe Helary

> On Jun 30, 2017, at 14:27, Nicolas Goaziou  wrote:

>> It would be nice if the org manual mentioned that too, and give
>> alternative keybindings for use in the terminal because that's
>> extremely confusing.
> 
> It does: (info "(org) TTY keys").

Thank you for the pointer. Although I don't think I ever used a teletypewriter 
in my life :) Maybe sometimes in the 21st century we'll have to think about a 
change in terminology...

I use the compact manual as a reference for my uses and I find it extremely 
useful for beginners. Would it be possible to insert a few line on that subject 
in there too? Something like "People who use org-mode in a tty terminal should 
refer to section 15.9 of the manual for alternative key bindings."

> See also `org-replace-disputed-keys'.

Thank you.

Jean-Christophe


Re: [O] keybindings again...

2017-06-29 Thread Jean-Christophe Helary

> On Jun 30, 2017, at 11:51, Kaushal Modi <kaushal.m...@gmail.com> wrote:
> 
> On Thu, Jun 29, 2017 at 10:43 PM Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com <mailto:jean.christophe.hel...@gmail.com>> 
> wrote:
> I'm using emacs built from master, emacs -nw, after moving .emacs.el and 
> .emacs.d away, on OSX 10.12.
> 
> 
> I'm trying to assign M-S-RET to org-insert-todo-heading because for some 
> reason it is not assigned by default: every time I hit ESC S-RET I get ESC 
> RET only.
> 
> It's the limitation of the terminal.

Do you mean that Shift is not recognized as a modified key by the terminal ?

> If you do C-h c Esc+Shift+Return, Emacs will detect only Esc+Return. So you 
> will see M-RET in the echo area.
> 
> You probably just need to use some other binding.

It would be nice if the org manual mentioned that too, and give alternative 
keybindings for use in the terminal because that's extremely confusing.

Jean-Christophe Helary 

[O] keybindings again...

2017-06-29 Thread Jean-Christophe Helary
I'm using emacs built from master, emacs -nw, after moving .emacs.el and 
.emacs.d away, on OSX 10.12.


I'm trying to assign M-S-RET to org-insert-todo-heading because for some reason 
it is not assigned by default: every time I hit ESC S-RET I get ESC RET only.

So, I tried things from
http://ergoemacs.org/emacs/keystroke_rep.html

First, this works fine:
(global-set-key (kbd "M-b") 'org-insert-todo-heading)

But this doesn't:
(global-set-key (kbd "M-") 'org-insert-todo-heading)

What I get here is the old M-return = org-insert-heading.

What is the problem here ?

Jean-Christophe 




Re: [O] emacs vs emacs -nw

2017-05-31 Thread Jean-Christophe Helary

> On May 31, 2017, at 20:30, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.hel...@gmail.com>
>> Date: Wed, 31 May 2017 19:41:00 +0900
>> Cc: Org-mode <emacs-orgmode@gnu.org>
>> 
>> Ok, I just tried something else:
>> 
>> (setq  ns-function-modifier 'meta) and what I get is *very* similar to the 
>> issue I have with ESC:
>> 
>> FN-x correctly "calls" M-x
>> FN-left in a level 2 header in org mode triggers beginning-of-buffer and 
>> *not* org-promote-header.
>> 
>> So the problem is not limited to ESC, and maybe not limited to org-mode.
> 
> AFAIR, the remapping of Meta-something to ESC-something happens
> automatically only for characters, not for function keys.  For
> function keys, this remapping must be set somewhere, or it won't
> happen.  You can see in bindings.el how some of these remappings are
> set up.

Yes, I realized after Yuri's comment that the comparison with ESC was a bit 
far-fetched.

Jean-Christophe 


Re: [O] emacs vs emacs -nw

2017-05-31 Thread Jean-Christophe Helary

> On May 31, 2017, at 19:04, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:

>> On X11/GNU/Linux, I get header promotion with Alt+Left but word
>> navigation on Esc Left.
> 
> Now that I think about it, I just tried this:
> 
> (setq  ns-right-command-modifier 'meta)
> 
> And I get the expected behavior in GUI emacs. So it's really an issue about 
> ESC that is not recognized in GUI mode for *some* bindings in org-mode.

Ok, I just tried something else:

(setq  ns-function-modifier 'meta) and what I get is *very* similar to the 
issue I have with ESC:

FN-x correctly "calls" M-x
FN-left in a level 2 header in org mode triggers beginning-of-buffer and *not* 
org-promote-header.

So the problem is not limited to ESC, and maybe not limited to org-mode.

Jean-Christophe



Re: [O] [org] different key binding between GUI emacs and emacs -nw

2017-05-31 Thread Jean-Christophe Helary

> On May 31, 2017, at 19:01, Eric S Fraga  wrote:
> 
> On Wednesday, 31 May 2017 at 02:38, Tim Cross wrote:
>> I'm sure this has been checked, but make sure it isn't the window
>> manager/OS 'stealing' the keys. When I install emacs on any system,
> 
> My own experience over the years is that this is indeed usually the
> culprit, especially for keys such as M-arrows which are often bound to
> functions like changing workspace views.

In this case, M-Left (ESC-left) triggers backward-word instead of the expected 
org-promote-subtree.

It does not seem to me that the OS is stealing anything.

Jean-Christophe


Re: [O] emacs vs emacs -nw

2017-05-31 Thread Jean-Christophe Helary

> On May 31, 2017, at 18:41, Yuri Khan <yuri.v.k...@gmail.com> wrote:
> 
> On Wed, May 31, 2017 at 3:58 PM, Jean-Christophe Helary
> <jean.christophe.hel...@gmail.com> wrote:
> 
>>> Could you provide an example and/or a recipe to demonstrate the issue?
>> 
>> • Open an org file with a few headers and different header levels.
>> • Select a lower level header
>> • Hit M-left
> 
> I believe this last step may be a bit unclear and misleading. Today,
> Meta is not a real key. You only get it via emulation from ESC or a
> modifier key, normally Alt on PCs. I don’t know the convention on Mac.

Ooops, you're right. Indeed.

On my machine I *systematically* use ESC for META.

> On X11/GNU/Linux, I get header promotion with Alt+Left but word
> navigation on Esc Left.

Now that I think about it, I just tried this:

(setq  ns-right-command-modifier 'meta)

And I get the expected behavior in GUI emacs. So it's really an issue about ESC 
that is not recognized in GUI mode for *some* bindings in org-mode.

Jean-Christophe 

> 
>> Expected result:
>> • the header is promoted
>> 
>> Result in GUI Emacs (Aquamacs too)
>> • The cursor jumps to the beginning of the previous word




Re: [O] [org] different key binding between GUI emacs and emacs -nw

2017-05-31 Thread Jean-Christophe Helary
Apologies,

> On May 31, 2017, at 12:51, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:

> This morning I have installed emacs from macport (emacs-app-devel) and I've 
> also built it from the repository (./configure with-ns).
> 
> In the locally build version Esc-Left promotes a header. But Esc-Right does 
> not demote it, it only moves to the next word.

The above it incorrect. I had modified the file before the build. I get the 
same result as I've got so far. Sorry for that.

Jean-Christophe 


Re: [O] [org] different key binding between GUI emacs and emacs -nw

2017-05-30 Thread Jean-Christophe Helary

> On May 31, 2017, at 11:38, Tim Cross  wrote:
> 
> It is certainly a weird issue. 

I couldn't agree more :)

> If there was a problem at the OS, window manager or interface library (i.e. 
> gtk) level, it should affect all bindings. 

That's correct.
Basically, what happens in that in GUI mode, the ESC key is not recognized as 
META in org-mode (only as far as I can tell).

> I should also mention that Ubuntu (well Debian really) install a versino of 
> emacs which is customized and not stock-stnadard emacs. Also, my macOS 
> version of emcs is built using brew install and not brew cask install, so it 
> is built from the git repo and not using the macforosx binaries the cask 
> version uses. 

This morning I have installed emacs from macport (emacs-app-devel) and I've 
also built it from the repository (./configure with-ns).

In the locally build version Esc-Left promotes a header. But Esc-Right does not 
demote it, it only moves to the next word.

Macport emacs shows the same behavior as brew emacs: in GUI, Esc is not 
recognized as Meta.

Weird.

Jean-Christophe 


Re: [O] [org] different key binding between GUI emacs and emacs -nw

2017-05-30 Thread Jean-Christophe Helary

> On May 31, 2017, at 7:28, Tim Cross  wrote:
> 
> Just add my confirmation that I have no issues with GUI bindings on either 
> MacOS Sierra with emacs 25.2 and org 9.0.7 or under Linux with Ubuntu 17.04 
> (same emacs and org versions). 

There were *some* people on help-emacs that could reproduce the issue on GTK+ 
and Xubuntu, I'm not saying it's everybody :)

> What happens if
> 
> 1. You use emacs -q and just load the version of org which is bundled with 
> emacs?

I've checked -Q with the bundled files and I get the same result.

> 2. you use emacs -q and just load latest org from elpa?

I always keep my packages up to date so I guess I have the latest package. I'll 
check.

Jean-Christophe 


[O] [org] different key binding between GUI emacs and emacs -nw

2017-05-30 Thread Jean-Christophe Helary

> On May 30, 2017, at 21:21, Tim Visher <tim.vis...@gmail.com> wrote:
> 
> Sometimes your Terminal application captures these 'extended' bindings.

It is the opposite that's happening. Terminal works fine. It is the GUI that 
does not accept the bindings. And as I wrote, it is not limited to my macOS 
(Emacs.app and Aquamacs show the same behavior) but to other people's GTK+ 
linux or Xubuntu. So it seems that's something that aught to be investigated 
and eventually fixed.

> I've always just accepted that org mode keybindings differ between terminal 
> and gui.

Except that I don't *have* most bindings in GUI. There is probably a rational 
reason what that is happening. I'm fine with helping with the investigation but 
I fear that's an area where I can't do much more than that.

Jean-Christophe

> 
> On Tue, May 30, 2017 at 3:37 AM, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com <mailto:jean.christophe.hel...@gmail.com>> 
> wrote:
> 
> > On May 30, 2017, at 15:51, Nicolas Goaziou <m...@nicolasgoaziou.fr 
> > <mailto:m...@nicolasgoaziou.fr>> wrote:
> >
> >> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html 
> >> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html>
> >>
> >> Let me know if you need extra information.
> >
> > What happens if you replace, e.g.,
> >
> >  (org-defkey org-mode-map [(meta left)]  'org-metaleft)
> >
> > with
> >
> >  (org-defkey org-mode-map (kbd "M-")  'org-metaleft)
> >
> > in "org.el"?
> 
> Nothing changes.
> 
> Jean-Christophe
> 
> 



Re: [O] different key binding between GUI emacs and emacs -nw

2017-05-30 Thread Jean-Christophe Helary

> On May 30, 2017, at 15:51, Nicolas Goaziou  wrote:
> 
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html
>> 
>> Let me know if you need extra information.
> 
> What happens if you replace, e.g.,
> 
>  (org-defkey org-mode-map [(meta left)]  'org-metaleft)
> 
> with
> 
>  (org-defkey org-mode-map (kbd "M-")  'org-metaleft)
> 
> in "org.el"?

Nothing changes.

Jean-Christophe 



[O] different key binding between GUI emacs and emacs -nw

2017-05-30 Thread Jean-Christophe Helary
I've just filed a bug report on emacs and was advised to report it here too.

It's bug#27140.

Basically, when I start GUI emacs (macOS, but also Aquamacs, also reported in 
Xubuntu and GTK+/Linux), I don't get the default org-mode bindings. Only emacs 
-nw gets them.

Even if I start both with -Q, I get the exact same behavior: proper default key 
bindings for org-mode in emacs -nw, some bindings overridden in GUI emacs.

The discussion thread on help-gnu-emacs is here:

http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html

Let me know if you need extra information.

Jean-Christophe 


Re: [O] org compact guide texinfo bug ?

2016-04-08 Thread Jean-Christophe Helary

> 2016/04/09 5:53、Nicolas Goaziou <m...@nicolasgoaziou.fr> のメール:
> 
>> @itemx @key{TAB}
>> 
>> and
>> 
>> @itemx @key{RET}
>> 
>> are not subsequent entries of @item mouse-3 but entries on their own.
>> 
>> They should be coded as @item.
> 
> Fixed. Thank you.

Thank you very much !

Jean-Christophe Helary 


[O] org compact guide texinfo bug ?

2016-04-08 Thread Jean-Christophe Helary
It's my fist message to the list so I hope I'm not missing anything.

In section 10.4 "Commands in the agenda buffer" the View/Go to Org file 
commands are described as:

@tsubheading{View/Go to Org file}
@item mouse-3
@itemx @key{SPC}
Display the original location of the item in another window.
With prefix arg, make sure that the entire entry is made visible in the
outline, not only the heading.
@c
@itemx @key{TAB}
Go to the original location of the item in another window.  Under Emacs
22, @kbd{mouse-1} will also work for this.
@c
@itemx @key{RET}
Go to the original location of the item and delete other windows.
@c

According to the Texinfo documentation:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040itemx.html

It seems like:

@itemx @key{TAB}

and

@itemx @key{RET}

are not subsequent entries of @item mouse-3 but entries on their own.

They should be coded as @item.

Jean-Christophe Helary