[-- Attachment #1: Type: text/plain, Size: 1908 bytes --] Hello, As discussed on this ML a few months ago, I eventually removed OrgStruct minor mode from Org code base. I also removed Radio lists, i.e., sending and receiving Org lists in non-Org buffers, since the two features were pretty much tied. I _did not_ remove `org-list-to-html', `org-list-to-latex' functions, just the sending and receiving mechanism. OrgStruct minor mode has a few replacements already, the most basic one being Outline minor mode. See the ML archives about OrgStruct removal for more information. However, there is, AFAIK, no satisfactory solution for plain lists management in non-Org buffers. Therefore, I implemented Orgalist mode, which really is a mini Org list library for non-Org buffers. Here is an excerpt for the commentary section: This library provides Org mode's plain lists in non-Org buffers. More specifically, it supports syntax for numbered, unnumbered, description items, checkboxes, and counter cookies. Besides, the following features are supported: - Navigation (M-<up>, M-<down>) - Indentation (M-<left>, M-<right>, M-S-<left>, M-S-<right>, TAB) - Re-ordering (M-S-<up>, M-S-<down>) - Item insertion (M-RET) - Toggling checkboxes (C-c C-c) - Cycling bullets (C-c -) - Sorting items (C-c ^) - Filling items (M-q) - Auto filling (when Auto Fill mode is enabled) It also re-introduces radio lists. I didn't test it thoroughly, it doesn't even ship with tests, but I could use it in a Message mode buffer satisfactorily. This was my main use case. Even if considered useful, I don't think it should go into Org core. It could be, however, added to GNU ELPA, or to some repository Bastien just set up. Until we find a proper place for it, I attach the full library to this message. Feedback welcome. Regards, -- Nicolas Goaziou 0x80A93738 [-- Attachment #2: Orgalist minor mode --] [-- Type: application/emacs-lisp, Size: 37198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 706 bytes --] Hi Nicolas, this looks very nice. And it seems to work mostly. I've only tested it in message mode. The mostly is because filling does not work for me, neither auto fill (subsequent lines start at column 1, i.e. not indented) nor M-q being bound to anything orgalist related... The latter may be due to my configuration (*), mind you, but I haven't tracked it down yet: M-q is bound to fill-paragraph when in message mode. I have removed all of my own M-q bindings I have, as far as I can tell. (*) the problem with configuration files that can trace their history back more than 30 years... sigh. Thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.5-269-g144451 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
Hello, Eric S Fraga <esflists@gmail.com> writes: > The mostly is because filling does not work for me, neither auto fill > (subsequent lines start at column 1, i.e. not indented) Auto fill can be tricky to handle because some other minor modes do fancy stuff with `auto-fill-function' (e.g., Yasnippet). In particular, you should make sure that `normal-auto-fill-function' doesn't change once Orgalist is active. What's the value for `auto-fill-function' and `normal-auto-fill-function'? > nor M-q being bound to anything orgalist related... The latter may be > due to my configuration (*), mind you, but I haven't tracked it down > yet: M-q is bound to fill-paragraph when in message mode. I have > removed all of my own M-q bindings I have, as far as I can tell. M-q should be bound to `orgalist-fill-item' when point is within a list. Outside, it should be bound to `fill-paragraph'. Be sure to check you don't do anything suspicious with M-q in your configuration. Regards, -- Nicolas Goaziou 0x80A93738
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --] On Sunday, 31 Dec 2017 at 16:40, Nicolas Goaziou wrote: > What's the value for `auto-fill-function' and > `normal-auto-fill-function'? auto-fill-function is a variable defined in ‘C source code’. Its value is ‘message-do-auto-fill’ normal-auto-fill-function is a variable defined in ‘simple.el’. Its value is ‘message-do-auto-fill’ > M-q should be bound to `orgalist-fill-item' when point is within a list. > Outside, it should be bound to `fill-paragraph'. Be sure to check you > don't do anything suspicious with M-q in your configuration. Well, I've tried to make sure I don't do anything suspicious with respect to M-q. In normal text (within message mode), M-q is bound to fill-paragraph. In a list, M-q is now bound to orgalist-fill-item but obviously if the item has been auto-filled badly, some of the lines in the list are no longer recognised as a list. So the problem is due to auto-fill not working properly. There does seem to be another problem due to some interaction with evil (which I use for all of my writing) but I haven't figured out exactly what is going wrong yet (repeating a 'dw' invocation using '.' deletes to end of buffer). I'll get back to you on this after more experimenting. thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.5-269-g144451 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
Eric S Fraga <esflists@gmail.com> writes: > auto-fill-function is a variable defined in ‘C source code’. > Its value is ‘message-do-auto-fill’ > > normal-auto-fill-function is a variable defined in ‘simple.el’. > Its value is ‘message-do-auto-fill’ [...] > So the problem is due to auto-fill not working properly. Possibly. Could you replace each occurrence of normal-auto-fill-function with (local 'normal-auto-fill-function) in minor mode definition and try again? If it still fails, could you provide an ECM?
[-- Attachment #1: Type: text/plain, Size: 688 bytes --] On Sunday, 31 Dec 2017 at 17:57, Nicolas Goaziou wrote: > Possibly. Could you replace each occurrence of normal-auto-fill-function > with (local 'normal-auto-fill-function) in minor mode definition and try > again? Did this but no change in behaviour. Auto-fill goes to beginning of line; fill paragraph works fine still. > If it still fails, could you provide an ECM? Not sure what kind of ECM you would like? I simply type in a line like this: 2. this is an item that has a lot of text, text that will eventually auto fill onto next line. (join the lines obviously...) thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.5-269-g144451 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #1: Type: text/plain, Size: 303 bytes --] Hello, Eric S Fraga <esflists@gmail.com> writes: > Not sure what kind of ECM you would like? I simply type in a line like > this: > > 2. this is an item that has a lot of text, text that will eventually > auto fill onto next line. I see. Here comes the 2018 release. Regards, -- Nicolas Goaziou [-- Attachment #2: Orgalist minor mode v2 --] [-- Type: application/emacs-lisp, Size: 38078 bytes --]
[-- Attachment #1: Type: text/plain, Size: 295 bytes --] On Monday, 1 Jan 2018 at 11:15, Nicolas Goaziou wrote: > I see. Here comes the 2018 release. Happy new year! 2018 is obviously going to be a good year: this version of orgalist works very well now. Thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.5-269-g144451 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Eric S Fraga <esflists@gmail.com> writes:
>
>> Not sure what kind of ECM you would like? I simply type in a line like
>> this:
>>
>> 2. this is an item that has a lot of text, text that will eventually
>> auto fill onto next line.
>
> I see. Here comes the 2018 release.
Works great for me -- glad to have this back!
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Eric S Fraga <esflists@gmail.com> writes:
>
>> Not sure what kind of ECM you would like? I simply type in a line like
>> this:
>>
>> 2. this is an item that has a lot of text, text that will eventually
>> auto fill onto next line.
>
> I see. Here comes the 2018 release.
Are there any plans to add this to either Org, Org contrib or ELPA?
Thanks,
Rasmus
--
One thing that is clear: it's all down hill from here
Rasmus <rasmus@gmx.us> writes:
> Are there any plans to add this to either Org, Org contrib or ELPA?
No there are no plan for it. I don't think it belongs to Org proper, and
Org contrib is somewhat a dead-end nowadays. It could go to GNU ELPA,
I guess.
ooc, why is org contrib deprecated? i find it useful to just get git and i do not use emacs packages. On 4/8/18, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Rasmus <rasmus@gmx.us> writes: > >> Are there any plans to add this to either Org, Org contrib or ELPA? > > No there are no plan for it. I don't think it belongs to Org proper, and > Org contrib is somewhat a dead-end nowadays. It could go to GNU ELPA, > I guess. > > -- The Kafka Pandemic: <http://thekafkapandemic.blogspot.com> The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time. "You’ve really gotta quit this and get moving, because this is murder by neglect." --- <http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.
Hello,
Samuel Wales <samologist@gmail.com> writes:
> ooc, why is org contrib deprecated? i find it useful to just get git
> and i do not use emacs packages.
contrib/ is an all-or-nothing thing. You cannot properly package
individually libraries, either in an ELPA or in a distribution.
As stated before, IMO, the only viable use for contrib/ is to be used as
an incubator for inclusion in Org.
Packages in contrib/ should be stored somewhere else, it could even be
in an Org ELPA.
Regards,
--
Nicolas Goaziou
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > It cloud even be in an Org ELPA Do You mean can publish package like MELPA separately? - -- [ stardiviner ] don't need to convince with trends. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrK1EgACgkQG13xyVro msOgtwgAoMTgjrRsiK1FQ/bk+vmS5+RVx54ITtPTb2LLf/Kiur+IxixsDJ4mvD/5 Dej6I8kc7tM0QXFvH83j1VqJphBa+D88e5hjYZajyyd6ffeGofX/pfzPUnlw/Vur WwEHi7IivhKO93gMTMVwtcfb8G4aps9s7gXGL7FZ24H7is+KMK2EthH4p03A4x0e L9J4ha2WWblo+gGiBzWjwN5WhjyaT8IDZajoiEurxMHLlPdy7dG+rxs9OlnhC84/ HP/bpajRYt1C4d4HVhqKuEFwOIKbEoSmRb5+xPofM9n6mf7lsXlPEecZbdNzvBou sLKV+XtaXYbyeUkgome5M3DFFbH6RQ== =+YLO -----END PGP SIGNATURE-----
>>> "Nicolas" == Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
Hello
I just saw this mail.
> Hello,
> As discussed on this ML a few months ago, I eventually removed OrgStruct
> minor mode from Org code base.
> I also removed Radio lists, i.e., sending and receiving Org lists in
> non-Org buffers, since the two features were pretty much tied. I _did
> not_ remove `org-list-to-html', `org-list-to-latex' functions, just the
> sending and receiving mechanism.
This is really bad. That is a feature I daily use in latex buffers. Why
did you do this? Is there any substitute for it. With a similar syntax?
If not tons of my latex files which contain radio tables will be
useless.
I really appreciate the work of org mode and that new features are
added. But the philosophy to remove code and syntax causes mayor
headaches and I don't see the benefit of it.
Templates are another example of this philosophy. I still can't use the
actual git master version of orgmode since the old templates have been
removed and the new syntax is not really explained.
Uwe Brauer
[-- Attachment #1: Type: text/plain, Size: 539 bytes --] On Sunday, 8 Apr 2018 at 22:18, Nicolas Goaziou wrote: [...] > As stated before, IMO, the only viable use for contrib/ is to be used as > an incubator for inclusion in Org. > > Packages in contrib/ should be stored somewhere else, it could even be > in an Org ELPA. I would much prefer contrib. ELPA does not work well, in my experience, if you have different systems running different versions of Emacs. Just my 2¢ worth. Feel free to ignore ;-) -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
Hello,
Uwe Brauer <oub@mat.ucm.es> writes:
> This is really bad. That is a feature I daily use in latex buffers. Why
> did you do this? Is there any substitute for it. With a similar syntax?
>
> If not tons of my latex files which contain radio tables will be
> useless.
I removed radio _lists_ not radio _tables_.
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 432 bytes --] On Mon, Apr 9, 2018 at 8:11 AM Eric S Fraga <esflists@gmail.com> wrote: > > I would much prefer contrib. ELPA does not work well, in my experience, > if you have different systems running different versions of Emacs. > Out of curiosity, why is that? Because of few backward-incompatibilities in byte compiled files in newer Emacs versions? If so, it's useful to have major-version specific package-user-dir 's. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 812 bytes --]
[-- Attachment #1: Type: text/plain, Size: 787 bytes --] On Monday, 9 Apr 2018 at 12:18, Kaushal Modi wrote: > On Mon, Apr 9, 2018 at 8:11 AM Eric S Fraga <esflists@gmail.com> wrote: > >> >> I would much prefer contrib. ELPA does not work well, in my experience, >> if you have different systems running different versions of Emacs. >> > > Out of curiosity, why is that? Because of few backward-incompatibilities in > byte compiled files in newer Emacs versions? If so, it's useful to have > major-version specific package-user-dir 's. Yes, because of byte code incompatibilities. Yes, I probably need to set up major version specific directories. Laziness on my part, I guess. Which is why I am happy for my comment to be ignored. ;-) thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #1: Type: text/plain, Size: 820 bytes --] On Mon, Apr 9, 2018 at 8:25 AM Eric S Fraga <esflists@gmail.com> wrote: > > Yes, because of byte code incompatibilities. Yes, I probably need to > set up major version specific directories. Laziness on my part, I > guess. Which is why I am happy for my comment to be ignored. ;-) > OK, but I'll still leave this here in case anyone wants to do that (major version specific elpa dir) :) For emacs 26.x and older: - Put the below in your emacs config *before* (require 'package) For emacs 27.x (and probably newer) i.e. current master: - Put the below in your ~/.emacs.d/early-init.el (setq package-user-dir (let ((elpa-dir-name (format "elpa_%s" emacs-major-version))) ;default = "elpa" (file-name-as-directory (expand-file-name elpa-dir-name user-emacs-directory)))) -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1310 bytes --]
[-- Attachment #1: Type: text/plain, Size: 795 bytes --] On Monday, 9 Apr 2018 at 12:45, Kaushal Modi wrote: > On Mon, Apr 9, 2018 at 8:25 AM Eric S Fraga <esflists@gmail.com> wrote: > >> >> Yes, because of byte code incompatibilities. Yes, I probably need to >> set up major version specific directories. Laziness on my part, I >> guess. Which is why I am happy for my comment to be ignored. ;-) >> > > OK, but I'll still leave this here in case anyone wants to do that (major > version specific elpa dir) :) Thanks for this. Helpful but I have one question: why the difference in placement of the code? I.e. why cannot I have the directory setting in my .emacs in both cases? Does emacs 27 initialise package before I do explicitly? Thanks again, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #1: Type: text/plain, Size: 576 bytes --] On Mon, Apr 9, 2018 at 10:14 AM Eric S Fraga <esflists@gmail.com> wrote: > > Does emacs 27 initialise package before I do > explicitly? > Yes.. there was a tome of discussion on this on emacs-devel. I have saved this link for my reference: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=24acb31c04b4048b85311d794e600ecd7ce60d3b See this new node in Emacs manual: (emacs) Early Init File PS: Why does your email not remain in to: or cc: when I do Reply All? Is it OK if it is left out in the future? I have been adding your email back in manually. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1099 bytes --]
>>> "Nicolas" == Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
> Uwe Brauer <oub@mat.ucm.es> writes:
>> This is really bad. That is a feature I daily use in latex
>> buffers. Why did you do this? Is there any substitute for it. With
>> a similar syntax?
>>
>> If not tons of my latex files which contain radio tables will be
>> useless.
> I removed radio _lists_ not radio _tables_.
Thanks for the clarification and sorry for the noise.
Regards
> Regards,
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --] On Monday, 9 Apr 2018 at 14:19, Kaushal Modi wrote: > On Mon, Apr 9, 2018 at 10:14 AM Eric S Fraga <esflists@gmail.com> wrote: > >> >> Does emacs 27 initialise package before I do >> explicitly? >> > > Yes.. there was a tome of discussion on this on emacs-devel. I have saved > this link for my reference: > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=24acb31c04b4048b85311d794e600ecd7ce60d3b Ah, so in emacs 27, package initialisation happens whether you want it or not... I guess I have to give in and move with the times! Thanks for the link. I do read emacs-devel but not all of it sticks. > PS: Why does your email not remain in to: or cc: when I do Reply All? Is it > OK if it is left out in the future? I have been adding your email back in > manually. Probably because I have told gnus that I am subscribed to the list so it probably adds a Followup-To header. I will read your replies whether you add me or not as I'm subscribed to the list. So no need to add it back! Thanks again, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
Hi Uwe,
Uwe Brauer <oub@mat.ucm.es> writes:
> Templates are another example of this philosophy. I still can't use the
> actual git master version of orgmode since the old templates have been
> removed and the new syntax is not really explained.
Please let me know what you are missing in terms of documentation.
For all of the annoyance of losing the old template system, the data
structure of the new system is surely simpler.
Also let me know about any remaining features that you are missing.
Rasmus
--
Warning: Everything saved will be lost
Eric S Fraga <esflists@gmail.com> writes:
>> Yes.. there was a tome of discussion on this on emacs-devel. I have saved
>> this link for my reference:
>> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=24acb31c04b4048b85311d794e600ecd7ce60d3b
>
> Ah, so in emacs 27, package initialisation happens whether you want it
> or not... I guess I have to give in and move with the times! Thanks
> for the link. I do read emacs-devel but not all of it sticks.
>
I think there is some confusion regarding package initialisation as many
people have used same/similar terms to mean different things. As I
understand it, the packages are initialised to the 'autoload' point
i.e. all the actual code associated with the package is not 'loaded'
into the system, but various entry points are setup so that should you
call a core function, open up an associated file, run an associated
mode, then the package will be loaded. In many respects, not terribly
different from how most emacs 'built-in' packages used to work (many of
which have now been moved out into ELPA packages.
I have also found the 'use-package' package to be extremely useful in
making my setup clearer, further controlling package setup/load and
deferring package loading to get faster startup times.
I wouldn't worry about emacs 27 too much. We are still waiting on emacs
26, so emacs 27 is probably 5+ years away yet!
--
Tim Cross
Rasmus <rasmus@gmx.us> writes:
> Hi Uwe,
>
> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> Templates are another example of this philosophy. I still can't use the
>> actual git master version of orgmode since the old templates have been
>> removed and the new syntax is not really explained.
>
> Please let me know what you are missing in terms of documentation.
>
> For all of the annoyance of losing the old template system, the data
> structure of the new system is surely simpler.
>
> Also let me know about any remaining features that you are missing.
>
[apologies if this has been answered in the extensive earlier threads]
IIUC, multi-letter abbrevs are not allowed. Is that because of tempo?
If it can be done, could we at least have two-letter abbrevs? I did
not use anything longer, but two-letter abbrevs were mnemonically
useful.
Thanks!
--
Nick
[-- Attachment #1: Type: text/plain, Size: 895 bytes --] On Tuesday, 10 Apr 2018 at 07:51, Tim Cross wrote: > I have also found the 'use-package' package to be extremely useful in > making my setup clearer, further controlling package setup/load and > deferring package loading to get faster startup times. Yes, I've heard good thing about use-package. My problem is that my .emacs etc. is a 35 year old mess. I need to start over but of course there is incredible inertia in doing so. > I wouldn't worry about emacs 27 too much. We are still waiting on emacs > 26, so emacs 27 is probably 5+ years away yet! Well, you'll see from my signature that I use v27. I track emacs development for the excitement! The problem is that I have one system where I am still using v25. Anyway, I think this has gone completely off-topic for the org list! thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --] for me, moving to use-package was fairly painless - my init file was only 20+ years worth of accumulated tweaks and configuration! Was well worth the effort though as it also fixed some annoying 'quirks' I had sort of got use to. WRT Emacs 27 - I gave up bleeding edge Emacs a few years back. Prefer the stability and there wasn't much in new versions that justified the regular updates and rebuilds etc. On 10 April 2018 at 15:20, Eric S Fraga <esflists@gmail.com> wrote: > On Tuesday, 10 Apr 2018 at 07:51, Tim Cross wrote: > > I have also found the 'use-package' package to be extremely useful in > > making my setup clearer, further controlling package setup/load and > > deferring package loading to get faster startup times. > > Yes, I've heard good thing about use-package. My problem is that my > .emacs etc. is a 35 year old mess. I need to start over but of course > there is incredible inertia in doing so. > > > I wouldn't worry about emacs 27 too much. We are still waiting on emacs > > 26, so emacs 27 is probably 5+ years away yet! > > Well, you'll see from my signature that I use v27. I track emacs > development for the excitement! The problem is that I have one system > where I am still using v25. > > Anyway, I think this has gone completely off-topic for the org list! > > thanks, > eric > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 2154 bytes --]
[-- Attachment #1: Type: text/plain, Size: 544 bytes --] On Tuesday, 10 Apr 2018 at 15:51, Tim Cross wrote: > WRT Emacs 27 - I gave up bleeding edge Emacs a few years back. Prefer the > stability and there wasn't much in new versions that justified the regular > updates and rebuilds etc. I track via emacs-snapshot (Debian package) which means I don't have to build. I particularly wanted display-line-number-mode in the latest version as it works very well with evil, especially relative numbering for quick movement! -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-347-gd73a5e [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --]
>>> "Rasmus" == Rasmus <rasmus@gmx.us> writes:
> Hi Uwe,
> Uwe Brauer <oub@mat.ucm.es> writes:
>> Templates are another example of this philosophy. I still can't use the
>> actual git master version of orgmode since the old templates have been
>> removed and the new syntax is not really explained.
> Please let me know what you are missing in terms of documentation.
> For all of the annoyance of losing the old template system, the data
> structure of the new system is surely simpler.
Thanks, I will send my problems in the next days. Right now I am
sticking to an old git version from July.
I asked a while ago that I could not insert any template with the new
system but nobody answered.
Do I understand that correctly I have to rewrite my templates or can I
use the old ones?
> Also let me know about any remaining features that you are missing.
> Rasmus
Nick Dokos <ndokos@gmail.com> writes:
> Rasmus <rasmus@gmx.us> writes:
>
>> Hi Uwe,
>>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>>
>>> Templates are another example of this philosophy. I still can't use the
>>> actual git master version of orgmode since the old templates have been
>>> removed and the new syntax is not really explained.
>>
>> Please let me know what you are missing in terms of documentation.
>>
>> For all of the annoyance of losing the old template system, the data
>> structure of the new system is surely simpler.
>>
>> Also let me know about any remaining features that you are missing.
>>
>
> [apologies if this has been answered in the extensive earlier threads]
>
> IIUC, multi-letter abbrevs are not allowed. Is that because of tempo?
> If it can be done, could we at least have two-letter abbrevs? I did
> not use anything longer, but two-letter abbrevs were mnemonically
> useful.
There should not be such a limitation anymore, though.
Strings were not supported initially as the keyboard interface to select
blocks (C-c C-,) could not read more than one character. That limitation
has been removed.
Let me know if you find any other limitations.
Rasmus
--
And I faced endless streams of vendor-approved Ikea furniture. . .
Uwe Brauer <oub@mat.ucm.es> writes:
>>>> "Rasmus" == Rasmus <rasmus@gmx.us> writes:
>
> > Hi Uwe,
> > Uwe Brauer <oub@mat.ucm.es> writes:
>
> >> Templates are another example of this philosophy. I still can't use the
> >> actual git master version of orgmode since the old templates have been
> >> removed and the new syntax is not really explained.
>
> > Please let me know what you are missing in terms of documentation.
>
> > For all of the annoyance of losing the old template system, the data
> > structure of the new system is surely simpler.
>
> Thanks, I will send my problems in the next days. Right now I am
> sticking to an old git version from July.
>
> I asked a while ago that I could not insert any template with the new
> system but nobody answered.
>
> Do I understand that correctly I have to rewrite my templates or can I
> use the old ones?
You can’t have very complicated templates (unless writing them in the
Tempo syntax).
Basically, you control the first line of the block.
So if you want "Rb" to expand to an src R :key val block you’d do something
like
(push ’("Rb" . "src R :key val") ’org-structure-template-alist)
Before the element would be something like
("R" . "#+begin_src R :key val\n?\n\#+end_src")
If you used to have "complicated" templates with e.g. headers, that’s not
possible ATM, but it could be added if there’s a need for it.
If you have a typical example of something you are missing, we could
either enrich the manual with how to add such a block directly with tempo.
Or we could perhaps find a way to define them.
Rasmus
--
Spil noget med Slayer!
Rasmus <rasmus@gmx.us> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Rasmus <rasmus@gmx.us> writes:
>>
>>> Hi Uwe,
>>>
>>> Uwe Brauer <oub@mat.ucm.es> writes:
>>>
>>>> Templates are another example of this philosophy. I still can't use the
>>>> actual git master version of orgmode since the old templates have been
>>>> removed and the new syntax is not really explained.
>>>
>>> Please let me know what you are missing in terms of documentation.
>>>
>>> For all of the annoyance of losing the old template system, the data
>>> structure of the new system is surely simpler.
>>>
>>> Also let me know about any remaining features that you are missing.
>>>
>>
>> [apologies if this has been answered in the extensive earlier threads]
>>
>> IIUC, multi-letter abbrevs are not allowed. Is that because of tempo?
>> If it can be done, could we at least have two-letter abbrevs? I did
>> not use anything longer, but two-letter abbrevs were mnemonically
>> useful.
>
> There should not be such a limitation anymore, though.
>
> Strings were not supported initially as the keyboard interface to select
> blocks (C-c C-,) could not read more than one character. That limitation
> has been removed.
>
Thanks!
--
Nick
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --] Yes, seems no obviously advantage. (Why want to do the same thing like MELPA, right, maybe someday Org-mode ELPA has CI or etc, can be easily integrated???) But if want to outof contrib/, I thinkthis is a thinking too. On 04/09/2018 10:47 AM, stardiviner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> It cloud even be in an Org ELPA > Do You mean can publish package like MELPA separately? > > - -- > [ stardiviner ] don't need to convince with trends. > Blog: https://stardiviner.github.io/ > IRC(freenode): stardiviner > GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAlrK1EgACgkQG13xyVro > msOgtwgAoMTgjrRsiK1FQ/bk+vmS5+RVx54ITtPTb2LLf/Kiur+IxixsDJ4mvD/5 > Dej6I8kc7tM0QXFvH83j1VqJphBa+D88e5hjYZajyyd6ffeGofX/pfzPUnlw/Vur > WwEHi7IivhKO93gMTMVwtcfb8G4aps9s7gXGL7FZ24H7is+KMK2EthH4p03A4x0e > L9J4ha2WWblo+gGiBzWjwN5WhjyaT8IDZajoiEurxMHLlPdy7dG+rxs9OlnhC84/ > HP/bpajRYt1C4d4HVhqKuEFwOIKbEoSmRb5+xPofM9n6mf7lsXlPEecZbdNzvBou > sLKV+XtaXYbyeUkgome5M3DFFbH6RQ== > =+YLO > -----END PGP SIGNATURE----- > [-- Attachment #2: Type: text/html, Size: 2143 bytes --]
Hi Nicolas, orgalist.el works great for me, thanks for writing it. Just out of curiosity, did you consider make this a minor more from within org-list.el (e.g. `org-list-mode')? Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > As stated before, IMO, the only viable use for contrib/ is to be > used as an incubator for inclusion in Org. For now this is what contrib/ is meant to be, but I would not even use it like this today. code.orgmode.org aims at beginning the place to share Org related code, whether it is a contributed package or something to be later included in Org's core. > Packages in contrib/ should be stored somewhere else, it could even > be in an Org ELPA. For now we removed some files one by one, leaving to the authors the choice of where the code should live -- Github or elsewhere. As for orgalist.el: does it live somewhere outside of this list? If not, I suggest adding it on GNU ELPA or creating a repository on code.orgmode.org. We need to do this before Org 9.2 to be able to show users an alternative - we cannot just let them now it has been deleted. Thanks! -- Bastien
Hello, Bastien <bzg@gnu.org> writes: > orgalist.el works great for me, thanks for writing it. You're welcome. > Just out of curiosity, did you consider make this a minor more from > within org-list.el (e.g. `org-list-mode')? I did. But I think features messing with other modes should go outside Org core. > As for orgalist.el: does it live somewhere outside of this list? No, it only leaves in the mailing list archives. > If not, I suggest adding it on GNU ELPA or creating a repository > on code.orgmode.org. I prefer the former, since it is, AFAIU, easier to install from Emacs. I just sent an email to Emacs devels for inclusion in GNU ELPA. Regards, -- Nicolas Goaziou
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> I just sent an email to Emacs devels for inclusion in GNU ELPA.
Great. Let's advertize it in etc/ORG-NEWS when it's available.
--
Bastien