[O] [org-contacts] How to show avatar image on org headings?

2018-05-06 Thread stardiviner
I want to show org-contacts avatar image on org-headings.
Use overlay, or there is other better methods?

A sample org-contacts snippet looks like this:

* [] John KK
:PROPERTIES:
:AVATAR: john kk.jpg []
:END:

I want to display the image at [] on heading, or replace "john kk.jpg"
with [] image.

BTW, another question, how to get property's value? and how to iterate
on all heading elements then auto display image when open Contacts.org
file?

--
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3



Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

2018-05-06 Thread Tim Cross


> Just as an aside, I have now also learned that emacs also includes
> skeleton.el, which is yet a third template expansion library.  Sigh.

also why we have yasnippets (yet another snippet for emacs).

If lisp languages have a flaw, this is probably it - often, people find
it easier to re-write functionality in a new library rather than
spending time learning the API and underlying philosophy/mindset of a
3rp party. Understandable as we all prefer coding to reading manuals and
APIs! I guess this is also one of the motivations to not implement yet
another template system if it can be avoided.

I have used both tempo and skeleton mode in the past. From memory,
skeleton's strength was with fairly static templates e.g. copyright
notice (though there is a mode for that as well!). Tempo was the one I
used most often, but have to say, writing tempo templates is a bit of a
pain and they are awfully ugly (at least mine were!).

These days, I seem to be using yasnippets most of the time. It isn't
because it is the best template solution, but rather it is because it
seems to be incorporated into many other modes I use and I can often
just install a package which has 80% of the snippets I need for a
specific mode. I suspect it is a bit of a VHS v Betamax situation -
yasnippets may not be the best solution, but it seems to have grabbed
largest market share!

Tim




-- 
Tim Cross



Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

2018-05-06 Thread Aaron Ecay
Hi Rasmus,

2018ko maiatzak 5an, Rasmus-ek idatzi zuen:

> Cool, I at least did not know that one.
> Can you a reproducible way to try it out?
> Without having to make my own templates etc.

I havenʼt done anything with it myself.

You can open up a blank .el file and test out some of emacsʼs built-in
templates.  M-x srecode-minor-mode, and then “C-c / /” will prompt you for
the name of a template to insert.  Entering file:major-mode at the
resulting prompt might be the most interesting one.  Certain keys are
bound to common templates, examples are “C-c / f” for inserting a function
and “C-c / v” for a variable

The template file corresponding to this is located at
$YOUR_EMACS_INSTALL_DIR/etc/srecode/el.srt.

Just as an aside, I have now also learned that emacs also includes
skeleton.el, which is yet a third template expansion library.  Sigh.

-- 
Aaron Ecay



Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

2018-05-06 Thread Aaron Ecay
Hi Rasmus,

2018ko maiatzak 5an, Rasmus-ek idatzi zuen:

> I don’t like it, I’m afraid.  

Iʼm sorry to hear that.

> It’s a bit nagging.

I wouldnʼt call it nagging.  The user presses “ There’s tools to mark thinks as obsolete in Emacs should we need to.

There are tools to mark functions and variables obsolete when they are
used in elisp code.  There is no way of warning a user about non-code
changes to the user experience, like (in this case) a changed key
binding.

> > 
>> One remaining decision to make is: what is the future of org-tempo?  I am
>> sympathetic to the idea that the best place for it eventually would be
>> org-contrib or GNU ELPA, and not org core.
> 
> We don’t have make that decision now, do we?

We donʼt strictly have to.  Obviously one approach to making the
decision is to wait and see whether org-tempo is widely adopted/used,
and remove it from core if not.  But if we* can already decide on
principle that something like org-tempo belongs best in contrib or
ELPA, then we can communicate the relevant info all at once when 9.2
is released, rather than for 9.2: “now add (require 'org-tempo) to
.emacs to keep using 

Re: [O] Orgalist notes

2018-05-06 Thread Eric Abrahamsen

On 05/06/18 10:34 AM, Bernt Hansen wrote:
> Eric Abrahamsen  writes:
>
>> And, as always, thank you! This is fairly heroic work -- I say that
>> after having made an attempt at orgstruct-mode, and run away screaming.
>> And look, no funny indentation!
>>
>> - Yet a list item with a ridiculous amount of text in it does not wrap
>>   into a second list item.
>> - Neither does the second list item, despite having an equivalent amount
>>   of spurious typing in it.
>>
>> - And before I get tired of the experiment, here's the same thing with
>>  a numbered list.
>> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>>   list.
>>
>> No good deed goes unpunished :)
>
> I think you need 2 blank lines between the lists to separate them by
> default - otherwise they are treated as one list and the first bullet
> defines the type of list (and therefore changes your 1. back to -

You're quite right! That did the trick. All seems to be behaving
perfectly now.

Thanks,
Eric



Re: [O] Orgalist notes

2018-05-06 Thread Bernt Hansen
Eric Abrahamsen  writes:

> And, as always, thank you! This is fairly heroic work -- I say that
> after having made an attempt at orgstruct-mode, and run away screaming.
> And look, no funny indentation!
>
> - Yet a list item with a ridiculous amount of text in it does not wrap
>   into a second list item.
> - Neither does the second list item, despite having an equivalent amount
>   of spurious typing in it.
>
> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.
>
> No good deed goes unpunished :)

I think you need 2 blank lines between the lists to separate them by
default - otherwise they are treated as one list and the first bullet
defines the type of list (and therefore changes your 1. back to -

Regards,
Bernt



Re: [O] Orgalist notes

2018-05-06 Thread Nicolas Goaziou
Hello,

Gregor Zattler  writes:

> With org-mode in the load-path, the line breaks happen for all
> lines not only the first one.  But one has to (require 'org) in
> order for M-RET to work.  This is no problem for me, since I work
> with org-mode all the time, but is this intended?

No, it is not intended. Orgalist 1.6 (to be released tomorrow) will
require Org right from the start.

> In my highly customized emacs I get line breaks but M-RET gives
>
> 1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
>hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
>uhguhdsh ghourhg
>
> orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil
>
> This is not the case with bullet lists:
>
> - o ushurgh dusrh gdrhf oudrhesurgh urhrh oughou hortus houtgsh
>   ou houhort rtgshM-RET
> - 
>
>
> Could you give me a hint on how to debug this?

Please use M-x toggle-debug-on-error and report the backtrace here.
Loading an un-compiled Orgalist is better.

Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] Orgalist notes

2018-05-06 Thread Gregor Zattler
Hi Eric, Nicolas,
* Eric Abrahamsen  [2018-05-05; 16:55]:
> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.

with this:
emacs-snapshot -Q  --debug-init  -l 
/home/grfz/.emacs.d/elpa-27.0/orgalist-1.5/orgalist.el   -f compose-mail  
--eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"


I get


1. ha fkj hdhf kjh kdjfh kdjsh gjhdlkj ghkjdsgh dj ljgh kjdh kjhvgfkj
   hdgkjhkjh djhg kjdhf kjhdkjghf kdhödgkhödkj hödj öh ödfkj hökhdgfsjh kjgh dh 
hdgöf h h ö ökhkjhgdöhg jdhf kj ök ökdfj ödfj dfjkj kjg kj kjdökgh ödh öhg   g  
g   

   - no autofill after the second line
   - M-RET gives: setq: Symbol’s function definition is void:
 org-in-regexp



With org-mode in the load-path, the line breaks happen for all
lines not only the first one.  But one has to (require 'org) in
order for M-RET to work.  This is no problem for me, since I work
with org-mode all the time, but is this intended?


In my highly customized emacs I get line breaks but M-RET gives

1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
   hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
   uhguhdsh ghourhg

orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil

This is not the case with bullet lists:

- o ushurgh dusrh gdrhf oudrhesurgh urhrh oughou hortus houtgsh
  ou houhort rtgshM-RET
- 


Could you give me a hint on how to debug this?


Thanks, Gregor




Re: [O] Orgalist notes

2018-05-06 Thread Nicolas Goaziou
Hello,

Eric Abrahamsen  writes:

> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.

I cannot reproduce it. 

More explicitly, I typed "1." at the beginning of a line to start
a numbered list, then filled the item with random characters so Auto
fill could start another line below the first. Eventually, I used
M- and got

   1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
  eiusmod tempor incididunt.
   2. 

I'm using Orgalist 1.5.

Could it be related to another minor mode you're loading?
   
> No good deed goes unpunished :)

Heh.

Thank you for the report.

Regards,

-- 
Nicolas Goaziou