On 2/12/19 5:37 PM, Nicolas Goaziou wrote:
> Hello,
>
> Scott Randby writes:
>
>> I've been noticing some unusual behavior when I manipulate headlines (Org
>> 9.2).
>>
>> I have the following (or something similar) at the very end of many Org
>> files:
>>
>> * LOCAL VARIABLES
>> # Local
Kyle Meyer writes:
> Paul Eggert writes:
>
>> The old approach required Lisp code to use (current-time)
>> explicitly when calling other primitives, e.g., (float-time
>> (current-time)). The new approach fakes all the primitives,
>> so that Lisp code can now use expressions like plain
Paul Eggert writes:
> The old approach required Lisp code to use (current-time)
> explicitly when calling other primitives, e.g., (float-time
> (current-time)). The new approach fakes all the primitives,
> so that Lisp code can now use expressions like plain (float-time).
Great, thanks! I'll
> `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't
> use in Org.
Mmm ok :).
I proposed it because it is easy to remember if you think you're
modifying a base action by S and also because it's easier to keep C
pressed (versus simply S-l or M-l).
So lets play with minus as a
Carlos Pita writes:
> What about leaving everything as it is now and adding C-c C-x C-S-l to mean
> "force preview", of course with the C-u and C-u C-u variants. This is a bit
> more orthogonal in the sense that the numerical argument controls scope and
> the S modifier controls "forcing". Also,
The old approach required Lisp code to use (current-time)
explicitly when calling other primitives, e.g., (float-time
(current-time)). The new approach fakes all the primitives,
so that Lisp code can now use expressions like plain (float-time).
* testing/org-test.el (org-test-at-time): New macro.
Hello,
Scott Randby writes:
> I've been noticing some unusual behavior when I manipulate headlines (Org
> 9.2).
>
> I have the following (or something similar) at the very end of many Org files:
>
> * LOCAL VARIABLES
> # Local Variables:
> # mode: org
> # coding: utf-8-unix
> # End:
>
> If I
What about leaving everything as it is now and adding C-c C-x C-S-l to mean
"force preview", of course with the C-u and C-u C-u variants. This is a bit
more orthogonal in the sense that the numerical argument controls scope and
the S modifier controls "forcing". Also, it's backwards compatible
Hello,
Carlos Pita writes:
> A last suggestion. Incidentally the toggle returns nil when at least a
> fragment is unpreviewed and non-nil otherwise (as a side effect of
> message). This can be documented and made part of the interface, so
> that something like the following can be put together
On Tue, Feb 12, 2019 at 3:59 PM Carlos Pita
wrote:
> > What do you mean with the "uppercase legacy"? You mean all the current
> documents we already have?
>
> Specifically what motivated this post: collections of snippets that
> have been written with the historical convention in mind. It's easy
Not a big deal, but here is a slightly better fix that avoids adding
some spaces before the closing }.
The difference wrt to the previous one is just:
- (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n"))
- (when (or ingroup intaggroup) (insert " "))
+
Ok, this was easier than I initially thought.
Here is a patch. I've tested it with a number of configurations: a few
grouped tags, many grouped tags, grouped tags that fill the last line
entirely, grouped and ungrouped tags. Notice that even ungrouped tags
are indented by two spaces. This is done
> What do you mean with the "uppercase legacy"? You mean all the current
> documents we already have?
Specifically what motivated this post: collections of snippets that
have been written with the historical convention in mind. It's easy to
convert them but it's not that easy to convert users
What do you mean with the "uppercase legacy"? You mean all the current
documents we already have?
In my case, those will remain with the upper case tags until I need to edit
them.
I guess it would be enough to patch the sites affected by
>
>
Hi there;
Agreed, hiding properties entirely seems overkill and quite limited in
use cases. However, I think this stems from a more general need to
hide properties that are irrelevant to the user—for instance, UIDs
created by ox-icalendar, or other internal properties. As a user, I
see no need
For example, with:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) @xxx(x) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
[x] @xxx}
where [c] and [x] are clearly misaligned.
If I remove the last tag:
#+tags: { @casa(c) @oficina(o) @viaje(v)
> At first I didn't like the lowercase tags for the blocks, but I got used to
> them after a couple of days.
I prefer the lowercase convention hands down. The problem I pointed
out is with the uppercase legacy.
> Someone suggested adding a defcustom option to org-tempo to let the user
> choose
Carlos,
I recently updated to 9.2 and was also confronted with the org-tempo
change.
At first I didn't like the lowercase tags for the blocks, but I got used to
them after a couple of days.
Someone suggested adding a defcustom option to org-tempo to let the user
choose between lower and upper
> Here are two previous threads about the subject:
>
> Last month:
> http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html
> A year ago:
> http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html
Interesting, thanks! Although the issue of mostly uppercase external
Carlos
Here are two previous threads about the subject:
- Last month:
http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html
- A year ago:
http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html
Regards
On Tue, Feb 12, 2019 at 9:51 AM Carlos Pita
> before, didn't they? Is this implying that now lowercase is preferred?
I dug this up from the repo:
org-element: Prefer lower case letters for blocks and keywords
https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0
So the answer is yes. Also the
>>> "NG" == Nicolas Goaziou writes:
> Hello,
> Uwe Brauer writes:
>> In an org file
>>
>> 1. I run org-agenda
>>
>> 2. Then m (for search tags)
>>
>> 3. Then the tag, which is displayed but also an annoying error
>> message which I attach
> It doesn't look
Hi all,
I noticed that the default expansions for org-tempo in 9.2 are
lowercase. I think they followed the uppercase informal convention
before, didn't they? Is this implying that now lowercase is preferred?
Regards
--
Carlos
Hello,
Sebastian Miele writes:
> * lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp,
> org-babel-emacs-lisp-lexical): Factor out the conversion of the
> :lexical source block argument to a form that is appropriate for
> `lexical-binding' and the LEXICAL argument to `eval'.
>
> *
Hello,
Keith David Bershatsky writes:
> A few years ago, I wrote up an answer to my own question on
> Stackoverflow to completely hide the :PROPERTIES: drawer, including
> the line that says :PROPERTIES:. Since then, it has received nearly
> 5,000 views, 11 stars, 17 upvotes on the initial
Hello,
Michaël Cadilhac writes:
> Well, certainly. I may not have had the best discipline in writing
> these, so turning them into patches is a bit painful. Let me know if
> I can make things better. (I believe my FSF paperwork is still
> alright, if need be.)
Thank you! Comments follow.
>
26 matches
Mail list logo
