Bastien writes:
> Hi Rasmus,
>
> Rasmus writes:
>
>> Do you think org-tempo should try to detect "old" versions of
>> org-structure-template-alist and give a better error if it sees one?
>
> Yes, it definitely should detect old format and fix it.
I don’t remember
Hi,
Aaron Ecay writes:
> Hi Rasmus,
>
> 2018ko maiatzak 7an, Rasmus-ek idatzi zuen:
>
>>
>> They’d already have the "old" behavior if it’s enabled by default in
>> org.el.
>
> Indeed, my suggestion is not an alternative to keeping (what is now
> called) org-tempo turned
Hi,
Bastien writes:
>>> 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?
>
> No.
Aaron Ecay writes:
> AIUI the change was from a cons of (character, template string) to a
> cons of (string, template string). The relevant commit is b56df73.
That’s an irrelevant change as neither of those formats has been
published. The "old" format (9.1 and earlier) is
Hi Nicolas,
Nicolas Goaziou writes:
> It seems nonsensical to let Org handle expansion templates.
Not to me, because Org syntax include default structured templates.
> Dedicated packages do it way better than what we provide, and the
> task is really out of our scope.
Hi Rasmus,
Rasmus writes:
> Do you think org-tempo should try to detect "old" versions of
> org-structure-template-alist and give a better error if it sees one?
Yes, it definitely should detect old format and fix it.
--
Bastien
Hi Aaron,
Aaron Ecay writes:
> Not AFAIK (to both questions). Yasnippet is in GNU ELPA, so the barrier
> to it becoming integrated into emacs (in whatever way) is low (or at
> least, not dominated by questions of copyright assignment).
I think the barrier is pretty high,
Hi Nicolas,
Nicolas Goaziou writes:
> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
>
> - It will break because `org-tempo' is only 99% backward-compatible. So
> anyone having
Hi Aaron,
Aaron Ecay writes:
> Interesting. I didnʼt know about that function. I just tried M-x
> customize-changed RET Org 9.0 RET. That gives an error; it seems to
> only work based on emacs versions and not package versions. Thatʼs
> unfortunate, it would have been
Hi Rasmus,
Rasmus writes:
> There’s tools to mark thinks as obsolete in Emacs should we need to.
One problem is that those tools (I'm thinking of define-obsolote-*)
are more developer-oriented than user-oriented.
E.g. AFAIK there is no "tool" to tell a user that a command
Hi Aaron,
Aaron Ecay writes:
> As a general (idealized) principle, I think user-visible changes should
> be phased in over at least one org major version. I have no problem
> with “intrusive” deprecation warnings, but abrupt changes in behavior
> should be avoided.
I
Hi Rasmus,
Rasmus writes:
>> For org-tempo, Rasmus wrote it so I'm inclined to listen quite
>> carefully at his opinion.
>
> Please don’t.
Done :)
> I have not really made any policy decisions of sort. I only missed
> "
Hi Bernt,
Bernt Hansen writes:
>
> *** Change in the structure template expansion
>
> Org 9.2 comes with a new template expansion mechanism, combining
> ~org-insert-structure-template~ bound to
Hi Rasmus,
2018ko maiatzak 7an, Rasmus-ek idatzi zuen:
>
> They’d already have the "old" behavior if it’s enabled by default in
> org.el.
Indeed, my suggestion is not an alternative to keeping (what is now
called) org-tempo turned on by default indefinitely. It is an
alternative to turning
Hi Rasmus,
2018ko maiatzak 7an, Rasmus-ek idatzi zuen:
> Srecode seems pretty neat, though it might only work in file buffers.
> Other than being shipped with Emacs, does it have any advantage over yas?
> Are there any plans to merge the two or make them more compatible?
Not AFAIK (to both
Hi Aaron,
Thanks for the reply.
Aaron Ecay writes:
> I wouldnʼt call it nagging. The user presses “ something special to happen. The status quo is that nothing at all
> happens. My proposal is to make something special happen. Itʼs
> different than
Carsten Dominik writes:
> On Sat, May 5, 2018 at 8:02 PM Rasmus wrote:
>
>> Nicolas Goaziou writes:
>>
>> > Hello,
>> >
>> > Steve Downey writes:
>> >
>> >> Asking users to accept any breakage in the tool they use to
Aaron Ecay writes:
> 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
> 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
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
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 “
On Sat, May 5, 2018 at 8:02 PM Rasmus wrote:
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > Steve Downey writes:
> >
> >> Asking users to accept any breakage in the tool they use to get work
> done
> >> is a lot. Changes in UI in emacs
On 5 May 2018 at 16:26 PDT, Adrian Bradd wrote:
>> I remember that Magit experimented displaying a message the first
>> time you used a new release; you would silence it only by setting a
>> variable. I don't think this is the case anymore, so it may have
>> failed, though.
>
> I believe this
I remember that Magit experimented displaying a message the
first time
you used a new release; you would silence it only by setting a
variable.
I don't think this is the case anymore, so it may have failed,
though.
I believe this was for the Magit Kickstarter fundraiser. A message
was
Aaron Ecay writes:
>> Expansion templates are a great thing, but this is only sugar for Org,
>> which is totally usable without them. Besides, some facilities are
>> providing it for us. This falls into (2). By design, I'm convinced we
>> should not include them. I also wish
Nicolas Goaziou writes:
> Hello,
>
> Steve Downey writes:
>
>> Asking users to accept any breakage in the tool they use to get work done
>> is a lot. Changes in UI in emacs are opt-in.
>>
>> Even if the change is the right thing to do.
>
> I think some
Tim Cross writes:
> won't that conflict with the key binding for block editing mode?
Isn’t that "C-’". Blocks are "C-c C-,". I used some program to scavenge
for unused bindings in, I think, December last year and we discussed it on
the list. I think the main contenders
Aaron Ecay writes:
> Hi Rasmus,
>
> 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen:
>>> Finally, irrespective of which options are chosen, I think that org-tempo
>>> would be better implemented in terms of a minor mode. This would allow
>>> it to be autoloaded,
Kevin Foley writes:
> Bastien writes:
>
> I have to admit that Bastien's list describes my experience almost
> perfectly. It look me a long time to figure out something that in the end
> seemed very simple. At the time I wasn't familiar with the NEWS file and
Bastien writes:
> Hi Tim,
>
> thanks for your thorough and balanced feedback.
>
> Tim Cross writes:
>
>> There is no solution which will make everyone happy. However, as a long
>> term org user who hopes to continue using org for many more years, I
>> tend
Hello,
Tim Cross writes:
> The C-c , binding is in line with expansion/templates in other modes (at
> least in my configuration), so there is little cognitive overhead when I
> want to expand "something".
`C-c ,' is a keybinding reserved for minor modes. See (info
I guess it is a balancing act. On one level, org's tendency to use
'smart' key bindings in which behaviour/action changes depending on
context is convenient, but on the other hand, I suspect it makes things
more complicated, which usually means harder to get right or maintain.
The C-c , binding
if there is a block there, you probably don't want to create a block.
if it is not there, you probably want to create one.
was my thinking. incorrect?
On 5/4/18, Tim Cross wrote:
>
> won't that conflict with the key binding for block editing mode?
>
> Also, I think C-c ,
won't that conflict with the key binding for block editing mode?
Also, I think C-c , is possibly more in-line with other
template/expansion commands in other modes.
Of course, being emacs, anyone can change it to suit personal
preferences!
Samuel Wales writes:
> is
is there a reason why the binding cannot be c-c '?
On 5/4/18, Bastien wrote:
> Hi Neil,
>
> Neil Jerram writes:
>
>> How can I see and try this famous C-c C-, ? I'm running:
>>
>> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>>
Hi Neil,
Neil Jerram writes:
> How can I see and try this famous C-c C-, ? I'm running:
>
> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
> /home/neil/.emacs.d/elpa/org-20180430/)
The new structure template mechanism will be part of the next major
Org release
William Denton writes:
> On 3 May 2018, Carsten Dominik wrote:
>
>> after initial doubt about this issue, I am now siding with Nicolas on this
>> one. I have started to use C-c C-, , and it works very well. In
>> particular, as Bernt says, the wrapping makes a very big
On 3 May 2018, Carsten Dominik wrote:
after initial doubt about this issue, I am now siding with Nicolas on this
one. I have started to use C-c C-, , and it works very well. In
particular, as Bernt says, the wrapping makes a very big difference, I have
always missed this.
I feel the same.
Dear all,
after initial doubt about this issue, I am now siding with Nicolas on this
one. I have started to use C-c C-, , and it works very well. In
particular, as Bernt says, the wrapping makes a very big difference, I have
always missed this.
Carsten
On Wed, May 2, 2018 at 10:26 PM Bernt
Bernt Hansen writes:
> I am not really for or against enabling org-tempo by default. If it's
> not enabled by default and a clear path is documented for how to achieve
> the same thing in ORG-NEWS using yasnippet or some other expansion
> system then that is perfectly okay with
Hi Rasmus,
2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen:
>> Finally, irrespective of which options are chosen, I think that org-tempo
>> would be better implemented in terms of a minor mode. This would allow
>> it to be autoloaded, turned on/off for different buffer(s) in an emacs
>>
Hi,
I think there is a typo in ORG-NEWS
Bastien writes:
>
> Tim Cross writes:
>
>
>> Consequently, I'm not going to enable org-tempo, instead going for
>> re-training of my fingers to use the new C-c ' binding.
>
> You certainly mean C-c C-, :)
>
Aaron Ecay writes:
> I would also question the decision to change the format of
> org-structure-template-alist. That has caused some errors (in the sense
> of calls to the elisp ‘error’ function) for me because a third
> party-library (ox-reveal) still uses the old format.
Nicolas Goaziou writes:
> Hello,
>
> Rasmus writes:
>
>> FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO
>> it’s not at all intuitive.
>
> You must be kidding. Consider the following snippet:
>
># key: # --
>
>
On Tuesday, 1 May 2018 at 16:49, Aaron Ecay wrote:
[...]
> On the other hand, as an org user breaking changes are inconvenient.
We should be clear that there are two different kinds of changes and
your post had references to both types:
1. changes to the user interface, e.g. what is being
mode@gnu.org>; Jon Snader <j...@irreal.org>
> Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
> templates thru e.g. "<s[TAB]")
>
> Hello,
>
> Steve Downey <sdow...@gmail.com> writes:
>
> > Asking users to accept
Hi Nicolas,
Iʼm very sympathetic to the direction of travel of these changes, and to
the suggestion that you make in your message about using warnings to
advert users to incompatible changes. (As you can read in my message to
the parent thread).
However (with great respect for all that you have
2018ko apirilak 29an, Tim Cross-ek idatzi zuen:
[...]
> I think org itself should provide a very stable core and avoid
> incorporating too many add on enhancements. It should be as stable as
> possible to encourage others to develop and maintain such enhancements
> and extensions.
As someone
Alan Tyree writes:
> [...]
>
> Here is a question: I see specialised snippet packages in the ELPA
> respositories. Is it possible to provide snippets that reproduce the
> existing "Easy Templates", maybe even keep the same key bindings so that
> the change is transparent to the users that are
Hello,
Steve Downey writes:
> Asking users to accept any breakage in the tool they use to get work done
> is a lot. Changes in UI in emacs are opt-in.
>
> Even if the change is the right thing to do.
I think some of you (basically, anyone thinking we should enable
On Sun, 29 Apr 2018 at 23:05:20 +1200, Bastien wrote:
> I may be wrong in thinking disabling this will cause trouble to
> many users. Let's just take a moment to see what users think.
I vote to drop "
>> For many existing users, restoring the old behaviour is just adding a
require to their setup, so it isn't a lot to ask.
Asking users to accept any breakage in the tool they use to get work done
is a lot. Changes in UI in emacs are opt-in.
Even if the change is the right thing to do.
On
On 1 May 2018 at 08:39, Jon Snader wrote:
>
> Tim Cross writes:
>
> [Snip]
>>
>> Personally, I feel the new version should be the default and we should
>> provide an easy way to re-enable the old version for those who wish to
>> continue with what they
I'm a non-technical user, and I've never used ysnippets, but I'm willing to
give it a go with some proper instruction.
I do see the argument of both sides.
Here is a question: I see specialised snippet packages in the ELPA
respositories. Is it possible to provide snippets that reproduce the
Hi all,
I normally am all for adapting to changes, staying on bleeding edges of
emacs, Org, etc.
But FWIW, for this particular change to the "
Tim Cross writes:
[Snip]
Personally, I feel the new version should be the default and we
should
provide an easy way to re-enable the old version for those who
wish to
continue with what they are use to.
We already have this. The problem, as you say, is
how we
;; Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
templates thru e.g. "<s[TAB]")
I don't think anyone disagrees that this change comes at a cost. Change is very
difficult and many people don't like change. The real ques
I don't think anyone disagrees that this change comes at a cost. Change is
very difficult and many people don't like change. The real question is how
do we manage this change to minimise the pain while moving org forward to
make it an even better solution.
Many seem to believe that what is being
Richard Lawrence writes:
Jon Snader writes:
I use the
Same here!
On 01/05/18 08:46, Peter Dewey Ore wrote:
> I second (third?) Richard and Jon. I use appreciate the simplicity.
>
> On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence
> >
> wrote:
>
>
I second (third?) Richard and Jon. I use wrote:
> Jon Snader writes:
>
> I use the
Jon Snader writes:
I use the
Changing the UI to no longer work is a very non-emacsy thing to do. There's
a lot of existing doc and tutorials explaining the org template system, as
well as current users who have trained fingers. Breaking
I should add that one issue with org-tempo is it doesn't seem to be
backwards compatible with old templates. For example packages such as
ob-sql-mode and org-reveal have easy templates based on the old format such
as :
(add-to-list 'org-structure-template-alist
Bastien writes:
> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit - Thinking your stupid
[...]
I have to admit that Bastien's list describes my experience almost
perfectly. It look me a long time to figure out something that
Hello,
Bastien writes:
> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit - Thinking your stupid
[...]
I have an issue with this argument: it can be opposed to virtually any
backward-incompatible change we make. There are
On Sunday, 29 Apr 2018 at 15:22, Bastien wrote:
[...]
> But again, I might be wrong, I just don't want this to be a discussion
> between us two :)
The new system seems more powerful and works better for me as it doesn't
conflict with predictive texting that also uses the TAB key.
I'm am
Bastien writes:
> Hi Nicolas,
>
> Nicolas Goaziou writes:
>
>> You disagreed with me in the first place with commit 71ad7b1. It was my
>> original intent to not load Org Tempo by default.
>
> Sorry if I missed the statement where you explicitely said you
Hi Tim,
thanks for your thorough and balanced feedback.
Tim Cross writes:
> There is no solution which will make everyone happy. However, as a long
> term org user who hopes to continue using org for many more years, I
> tend to come down on the side of whatever will
Hi Tim,
Tim Cross writes:
> Given that Emacs has eww, linking to a web page for NEWS from the menu
> seems to be OK.
I added a new menu entry "Org Browse News" which takes the user to
https://orgmode.org/Changes.html
> However, I just noticed that org-plus-contrib and
Bastien writes:
> Hi Nicolas,
>
> Nicolas Goaziou writes:
>
>> Bastien writes:
>>
>>> Again, I may be wrong in thinking disabling this will cause trouble to
>>> many users. Let's just take a moment to see what users think.
>>
>> It will
Bastien writes:
> "Thomas S. Dye" writes:
>
>> Would it be difficult to add an ORG-NEWS option to the Documentation
>> section of the Org drop-down menu? It's an interesting document.
>
> Yes, I see why this how this could be useful, but there are problems:
>
> -
Hello,
Rasmus writes:
> FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO
> it’s not at all intuitive.
You must be kidding. Consider the following snippet:
# key: Why is using tempo NIH?
Using Tempo is fine. But we're writing a template system on top
Hi Thomas,
"Thomas S. Dye" writes:
> Would it be difficult to add an ORG-NEWS option to the Documentation
> section of the Org drop-down menu? It's an interesting document.
Yes, I see why this how this could be useful, but there are problems:
- ORG-NEWS is not in the ELPA and
Hi Diego,
thanks for your input.
Zamboni writes:
> So, to summarize: I don’t mind having to load org-tempo explicitly,
> but it wold be nice to make the change visible (maybe make ORG-NEWS
> more visible) and to fix the bug I mentioned.
Can you give a recipe on how to
Hi,
Diego Zamboni writes:
> Since a few weeks ago (around 9.1.10-11, maybe?) the “ seems a bit broken - if I try to use it in the middle of a file and
> there is a block of the same type further down in the file, then only
> the opening line of the block is
Hi,
Nicolas Goaziou writes:
> We introduced a new expansion mechanism, recently bound to `C-c C-,'.
> This mechanism is more in line with usual Org functions: it operates on
> regions like, say, `org-insert-drawer'. It is an obvious default
> expansion mechanism.
>
> If
Hi,
> On 29 Apr 2018, at 13:05, Bastien wrote:
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users. Let's just take a moment to see what users think.
Here’s my 2 cents: I’ve only been using org-mode for a few months now, but
almost from the
Bastien writes:
I wish I'd be as optimistic as you are and assume every user
reads
ORG-NEWS! I seriously doubt a majority of users do. Those
installing
Org from ELPA cannot possibly know where to find ORG-NEWS, Org
gives
no indication where it lives: IOW, it's not even because users
are
Hi all,
On 04/29/2018 07:05 AM, Bastien wrote:
Hi Nicolas,
Nicolas Goaziou writes:
Let's just take a moment to see what users think.
I was aware of tempo.el and tempo from postings to the list. However It
was not until I upgraded to version 9.1.12 from 9.1.11
So, user feedback: I'm fine with not enabling by default.
I don't use any of these, but it sounds like the new default expansion
mechanism Nicolas mentioned might suit me if I ever switch from my
homemade insert-block function (which does prompts and regions).
Yours,
Christian
Bastien writes:
Hi Nicolas,
Nicolas Goaziou writes:
> Bastien writes:
>
>> Again, I may be wrong in thinking disabling this will cause trouble to
>> many users. Let's just take a moment to see what users think.
>
> It will case trouble during the time necessary to read
Bastien writes:
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users. Let's just take a moment to see what users think.
It will case trouble during the time necessary to read ORG-NEWS
incompatible changes section or ask the mailing list, and then
Hi Nicolas,
Nicolas Goaziou writes:
> You disagreed with me in the first place with commit 71ad7b1. It was my
> original intent to not load Org Tempo by default.
Sorry if I missed the statement where you explicitely said you thought
org-tempo should not be enabled by
Hello,
Bastien writes:
> You seem to disagree as you just disabled Org tempo in commit 4c13d0a
> ("Do not load Org Tempo by default"), saying:
You disagreed with me in the first place with commit 71ad7b1. It was my
original intent to not load Org Tempo by default.
> I wonder
85 matches
Mail list logo