Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On 1/30/18, Allen Li wrote: > It does change org behavior, since the native mark ring > distinguishes local from global, whereas org-mark-ring does not. > With the proposed change, there won't be a single > org-mark-ring-goto, you would have to make sure you call the > right command out of pop-to-mark-command or pop-global-mark. thanks. then i oppose this change. it seems crazy to have to think about whether where you will be going is in the same buffer or not. if that is what you mean. i would be ok with it only if the global mark ring worked like the org mark ring.
Re: [O] non-space, paste, (???) character for inline results
Nico, ah, thanks! not wanting to look gift horses, etc., but i've a question. if i understand the change correctly - (looking-at "\\
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On Tue, Jan 30, 2018 at 3:15 PM, Samuel Wales wrote: > On 1/30/18, Nicolas Goaziou wrote: >> With local ring, you do, not with global one. That is standard Emacs >> behaviour. > > does this constitute a change in org behavior? i'd want the same > behavior as now. it would be confusing to follow a link, then follow > another link in the same buffer, then go back globally, and end up not > in the original place [or even the same buffer]. It does change org behavior, since the native mark ring distinguishes local from global, whereas org-mark-ring does not. With the proposed change, there won't be a single org-mark-ring-goto, you would have to make sure you call the right command out of pop-to-mark-command or pop-global-mark. As a counterpoint, it is not entirely without precedent to implement our own mark ring. xref.el also has its own "marker" ring. Maybe there should be a standard specialized marker ring macro in Emacs, then org and xref (and others) can use it. > > probably i have the wrong end of the stick. but i find that asking > weird questions like this can lead to people being on the same page > where they were not. >
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On 1/30/18, Nicolas Goaziou wrote: > With local ring, you do, not with global one. That is standard Emacs > behaviour. does this constitute a change in org behavior? i'd want the same behavior as now. it would be confusing to follow a link, then follow another link in the same buffer, then go back globally, and end up not in the original place [or even the same buffer]. probably i have the wrong end of the stick. but i find that asking weird questions like this can lead to people being on the same page where they were not.
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Samuel Wales writes: > do we really want "If the last global mark pushed was not in the current > buffer, > also push LOCATION on the global mark ring."? if it was in the > current buffer then we don't go to the exact location? With local ring, you do, not with global one. That is standard Emacs behaviour.
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On 1/30/18, Nicolas Goaziou wrote: > Let me clarify. I just want to replace `org-mark-ring-push' with > `push-mark'. The distinction between local and global mark rings are > taken care of in the latter. Org doesn't need to mess with it. > > I hope that's clearer now. yes, thanks. do we really want "If the last global mark pushed was not in the current buffer, also push LOCATION on the global mark ring."? if it was in the current buffer then we don't go to the exact location?
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Samuel Wales writes: > On 1/30/18, Nicolas Goaziou wrote: >>> org would have to push to both local and global it seems. >> >> `push-mark' would take care of this. So Org wouldn't need to. > > iiuc, i can't agree with you. org pushes marks onto the org mark ring > in various places [and imo even misses at least one place -- going to > outline from agenda]. i assumed org would continue to do so, except > to the local and global mark rings. > > will all those good automatic mark pushing events be removed? i do > not get the point of that. that's potentially a lot of programming > work to put onto the user just to get back the functionality we have > now. > > so i probably misunderstand your meaning. Let me clarify. I just want to replace `org-mark-ring-push' with `push-mark'. The distinction between local and global mark rings are taken care of in the latter. Org doesn't need to mess with it. I hope that's clearer now.
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
minor followup to prev post. here is a place where org does not but ime is useful to push the mark. org does similarly when you follow a link, for example. i believe this should be done to the local and global mark rings. diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 98f6034..d410d3a 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8640,6 +8640,7 @@ displayed Org file fills the frame." (pop-to-buffer-same-window buffer) (when delete-other-windows (delete-other-windows)) (widen) + (org-mark-ring-push) (goto-char pos) (when (derived-mode-p 'org-mode) (org-show-context 'agenda)
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On 1/30/18, Nicolas Goaziou wrote: >> org would have to push to both local and global it seems. > > `push-mark' would take care of this. So Org wouldn't need to. iiuc, i can't agree with you. org pushes marks onto the org mark ring in various places [and imo even misses at least one place -- going to outline from agenda]. i assumed org would continue to do so, except to the local and global mark rings. will all those good automatic mark pushing events be removed? i do not get the point of that. that's potentially a lot of programming work to put onto the user just to get back the functionality we have now. so i probably misunderstand your meaning.
Re: [O] BUG report [Was: computing the size of a tikz to png image during export]
2018-01-30 21:59 GMT+01:00 Nicolas Goaziou : > Hello, > > Fabrice Popineau writes: > > > You should have a look at commit 38be85124551083d269. > > It prevents evaluation of the by-backend form in parameters. > > It doesn't. > > My mistake: it optionaly prevents :-) > It prevents evaluation conditionally, i.e., when an optional argument is > non-nil. The same argument prevents expanding Noweb references because > I think both features are tied. If I'm wrong, we will use a special > value to distinguish the cases, or use another argument. > > Meanwhile, I think this is fixed. > After a quick test, it seems to work ok here. Thanks a lot because I rely heavily on this feature ! Regards, Fabrice
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Hello, Samuel Wales writes: > On 1/29/18, Nicolas Goaziou wrote: >> So, could we simply remove this part of Org and use Emacs facilities, >> with their standard bindings (C-u C- and C-x C-) and behaviour >> instead? > > org would have to push to both local and global it seems. `push-mark' would take care of this. So Org wouldn't need to. > also this from se could be modified to work for global mark ring -- > every ring in emacs should have both next and prev. i never > understood the point of rings in emacs except to save memory. > > (defun se-unpop-to-mark-command () > "Unpop off mark ring. Does nothing if mark ring is empty." > (interactive) > (when mark-ring > (setq mark-ring (cons (copy-marker (mark-marker)) mark-ring)) > (set-marker (mark-marker) (car (last mark-ring)) (current-buffer)) > (when (null (mark t)) (ding)) > (setq mark-ring (nbutlast mark-ring)) > (goto-char (marker-position (car (last mark-ring)) You could suggest it to Emacs developers (i.e., file a bug report.) Regards, -- Nicolas Goaziou
Re: [O] executing org-table TBLFM form changes (resets) language settings
Hello, Rainer Stengele writes: > has anybody an idea? Each time I calculate a time diff in an Org table > I trigger the wrong creation of any org timestamp as the date language > has changed. Full restart of Emacs needed right now :(. Would setting `math-short-weekday-names' help? Regards, -- Nicolas Goaziou
Re: [O] BUG report [Was: computing the size of a tikz to png image during export]
Hello, Fabrice Popineau writes: > You should have a look at commit 38be85124551083d269. > It prevents evaluation of the by-backend form in parameters. It doesn't. It prevents evaluation conditionally, i.e., when an optional argument is non-nil. The same argument prevents expanding Noweb references because I think both features are tied. If I'm wrong, we will use a special value to distinguish the cases, or use another argument. Meanwhile, I think this is fixed. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] non-space, paste, (???) character for inline results
Hello, Greg Minshall writes: > great! except, oh, well, maybe you really meant to respond to this > other set of messages, with subject line > > Re: [O] BUG report [Was: computing the size of a tikz to png image during > export] > --- Both are fixed, actually, so it doesn't matter the way you look at it :) Regards, -- Nicolas Goaziou0x80A93738
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On 1/29/18, Nicolas Goaziou wrote: > So, could we simply remove this part of Org and use Emacs facilities, > with their standard bindings (C-u C- and C-x C-) and behaviour > instead? org would have to push to both local and global it seems. sounds good to me. === note also that for single buffers there is marker-visit.el. also this from se could be modified to work for global mark ring -- every ring in emacs should have both next and prev. i never understood the point of rings in emacs except to save memory. (defun se-unpop-to-mark-command () "Unpop off mark ring. Does nothing if mark ring is empty." (interactive) (when mark-ring (setq mark-ring (cons (copy-marker (mark-marker)) mark-ring)) (set-marker (mark-marker) (car (last mark-ring)) (current-buffer)) (when (null (mark t)) (ding)) (setq mark-ring (nbutlast mark-ring)) (goto-char (marker-position (car (last mark-ring))
Re: [O] executing org-table TBLFM form changes (resets) language settings
Am 29.01.2018 um 08:49 schrieb Rainer Stengele:
Am 26.01.2018 um 10:46 schrieb Rainer Stengele:
Am 25.01.2018 um 20:27 schrieb Nick Dokos:
Rainer Stengele writes:
All,
My current-language-environment is "German".
Having an Org table with a TBLFM attached:
| IM Startzeit | IM Endezeit | Stunden |
delta(x,16) | Anm. |
|---+---+-+-+--|
| [2018-01-22 Mo 19:30] | [2018-01-23 Di 14:30] | 19.00 |
3.00 | |
| | |
| | |
#+TBLFM: $3=24*(date(<$2>)-date(<$1>)); %.2f::$4=$3-16.0; %.2f
entering a new timestamp correctly inserts German dayname abbrevs:
("Do", German for "Thu", English):
| IM Startzeit | IM Endezeit | Stunden |
delta(x,16) | Anm. |
|---+---+-+-+--|
| [2018-01-22 Mo 19:30] | [2018-01-23 Di 14:30] | 19.00 |
3.00 | |
| [2018-01-25 Do 14:19] | |
| | |
#+TBLFM: $3=24*(date(<$2>)-date(<$1>)); %.2f::$4=$3-16.0; %.2f
Executing the TBLFM line with C-c C-c changes (resets) the language
environment to English.
Now inserting a timestamp inserts "Thu" instead of "Do", that is it
uses the English day name abbrevs:
| IM Startzeit | IM Endezeit | Stunden |
delta(x,16) | Anm. |
|---+---+--+--+--|
| [2018-01-22 Mo 19:30] | [2018-01-23 Di 14:30] | 19.00
| 3.00 | |
| [2018-01-25 Thu 14:21]| |
| | |
#+TBLFM: $3=24*(date(<$2>)-date(<$1>)); %.2f::$4=$3-16.0; %.2f
Believe me it took me some time to find out what action in Emacs
changes the whole lang environment.
Is that a bug or is there a language setting in the TBLFM form?
Thanks for any hint.
Regards,
Rainer
I can reproduce this if I start emacs like this:
emacs -q -l ~/src/minimal/min.org.el /tmp/dates.org &
set the language environment inside emacs and then do C-c C-c on the
TBLFM line
and try to add another date.
I cannot reproduce it when invoking emacs like this:
LANG=de_DE.UTF-8 emacs -q -l ~/src/minimal/min.org.el /tmp/dates.org
so it seems you are right that in the first case, something changes
the language
environment.
Hi Nick,
thanks for confirming.
I am running under Windows and cannot apply your environment setting
like this.
Does anyboday have a chance to correct the misbehaviour in the TBLFM
table code that changes the language settings?
I will not be able to do it on my own.
Thank you.
Regards, Rainer
Hi again,
I found out that it is the "date" function that changes the language
settings. TBLFM lines without date calc don't change the behaviour.
May I please ask a calc expert to look into that function and
investigate the unwanted behaviour.
I am also not sure how to easily reset the language setting manually to
the correct one.
Can someone give me a hint please.
Thank you.
Regards, Rainer
Hi again,
has anybody an idea? Each time I calculate a time diff in an Org table I
trigger the wrong creation of any org timestamp as the date language has
changed. Full restart of Emacs needed right now :(.
Regards, Rainer
[O] Prevent auto-fill-mode from filling Property values in drawers
Hello, I have noticed that auto-filling working on long (going past fill-column) values in property drawers. Here's a MWE: = #+TITLE: Test case showing auto-filling happening in Property drawers too * Heading :PROPERTIES: :DESCRIPTION: This is a very long description that will auto fill at the =fill-column=. But this is inside a property drawer, so the auto-filling should be disabled. :END: * COMMENT Local Variables # Local Variables: # fill-column: 70 # eval: (auto-fill-mode 1) # End: = The value of that DESCRIPTION property is in a single line (I believe some email clients auto-fill the text). Basically this is what it should look like in emacs -Q after M-x toggle-truncate-lines: [image: image.png] Now if you hit return at the end of that long description, auto-fill kicks in and turns that into this invalid drawer: = #+TITLE: Test case showing auto-filling happening in Property drawers too * Heading :PROPERTIES: :DESCRIPTION: This is a very long description that will auto fill at the =fill-column=. But this is inside a property drawer, so the auto-filling should be disabled. :END: * COMMENT Local Variables # Local Variables: # fill-column: 70 # eval: (auto-fill-mode 1) # End: = This looks like a bug. Can the auto-filling be disabled in property drawers? I can recreate this issue on both: - Org stable (9.1.6 that's on emacs-26 branch) :: Org version: Org mode version 9.1.6 (release_9.1.6-50-g96b33f @ /home/kmodi/usr_local/apps/6/emacs/emacs-26/share/emacs/26.0.91/lisp/org/) - Org master ::Org mode version 9.1.6 (release_9.1.6-395-g8ecc4c @ /home/kmodi/usr_local/apps/6/emacs/emacs-26/share/emacs/site-lisp/org/) Thanks. -- Kaushal Modi
Re: [O] Orgmode repeater intervals with end date
I was very pleased to find, when browsing the manual for a different reason, the 'orgmode' solution to the problem, which provides daily customization ability and also maintains exportability: `org-clone-subtree-with-timeshift`[1], with which I can easily accomplish my goals and even consolidate my notes-for-that-event-instance. I'm just writing this here because it has totally upgraded my planning experience and I wish I'd known about it sooner! Thanks all! - Tory Footnotes: [1] https://orgmode.org/manual/Structure-editing.html
Re: [O] non-space, paste, (???) character for inline results
Nicolas, great! except, oh, well, maybe you really meant to respond to this other set of messages, with subject line Re: [O] BUG report [Was: computing the size of a tikz to png image during export] --- cheers, Greg
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Same here. Tim Kaushal Modi writes: > On Tue, Jan 30, 2018, 12:07 AM Allen Li wrote: > >> I was not aware Org had its own mark ring, and I see no use for it >> personally when Emacs's mark ring exists. >> > > Same here :) > > So also I wouldn't miss out if that feature is removed, C-u SPC works > great. > >> -- Tim Cross
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Kaushal Modi writes: > On Tue, Jan 30, 2018, 12:07 AM Allen Li wrote: > >> I was not aware Org had its own mark ring, and I see no use for it >> personally when Emacs's mark ring exists. >> > > Same here :) > > So also I wouldn't miss out if that feature is removed, C-u SPC works > great. I was also not aware of this and thus wouldn’t miss it, if removed. Rasmus -- You people at the NSA are becoming my new best friends!
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
On Tue, Jan 30, 2018, 12:07 AM Allen Li wrote: > I was not aware Org had its own mark ring, and I see no use for it > personally when Emacs's mark ring exists. > Same here :) So also I wouldn't miss out if that feature is removed, C-u SPC works great. > -- Kaushal Modi
Re: [O] non-space, paste, (???) character for inline results
Hello,
Greg Minshall writes:
> hi. thanks again for org-mode.
>
> having discovered this variable, i tend to run with
> : #+bind: org-babel-inline-result-wrap "%s"
>
> but, at the same time, i'd often like to put some character(s) before or
> after the result of some particular inline call, e.g., a dollar sign, a
> percent, etc.
>
> i could, i suppose, rebind o-b-i-r-wrap around those calls, but...
>
> if one writes, e.g., $call_foo(), the call_foo() doesn't happen
> (presumably isn't recognized).
>
> i've tried various constructs that might allow the evaluation to be
> recognize the call, but "paste" the result in with no intervening space,
> things like
> : #+macro: null
> : ${{{null}}}call_foo()
> but to no avail. (in the above case, i'm assuming macro expansion
> happens *before* inline calls -- as it should -- so the inline call
> procedure sees, e.g., $call_foo() and, again, doesn't distinguish it.)
>
> does such a construct exist? if not, would it make sense (and be
> possible, given the installed base!) to add some such? (if so, i'd
> probably vote for {{{}}}, the "null" macro which, anyway, currently
> isn't modified -- in my setup, anyway -- during export.)
This is now fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Changing face background for org-columns view
claude fuhrer writes: > I'm using a dark theme (cyberpunk if it matters) with "bright" > foreground color for most of the faces. When I try to use the column > view (C-c C-x C-c, that is org-columns), org-mode sets the background > color for each line to bright yellow (1), whitout changing the > foreground color used.which makes the text almost unreadable. Can I > customise this background color ? Or use another kind of face (for > example slanted ou bold) instead changing the background color ? What about moving the cursor onto a line of an org column and use M-x customize-face and set some attributes of face "org-column"? HTH
[O] non-space, paste, (???) character for inline results
hi. thanks again for org-mode.
having discovered this variable, i tend to run with
: #+bind: org-babel-inline-result-wrap "%s"
but, at the same time, i'd often like to put some character(s) before or
after the result of some particular inline call, e.g., a dollar sign, a
percent, etc.
i could, i suppose, rebind o-b-i-r-wrap around those calls, but...
if one writes, e.g., $call_foo(), the call_foo() doesn't happen
(presumably isn't recognized).
i've tried various constructs that might allow the evaluation to be
recognize the call, but "paste" the result in with no intervening space,
things like
: #+macro: null
: ${{{null}}}call_foo()
but to no avail. (in the above case, i'm assuming macro expansion
happens *before* inline calls -- as it should -- so the inline call
procedure sees, e.g., $call_foo() and, again, doesn't distinguish it.)
does such a construct exist? if not, would it make sense (and be
possible, given the installed base!) to add some such? (if so, i'd
probably vote for {{{}}}, the "null" macro which, anyway, currently
isn't modified -- in my setup, anyway -- during export.)
cheers, Greg
[O] Changing face background for org-columns view
Hi all, I'm using a dark theme (cyberpunk if it matters) with "bright" foreground color for most of the faces. When I try to use the column view (C-c C-x C-c, that is org-columns), org-mode sets the background color for each line to bright yellow (1), whitout changing the foreground color used.which makes the text almost unreadable. Can I customise this background color ? Or use another kind of face (for example slanted ou bold) instead changing the background color ? Thank you in advance for your help. claude (1) If I've understand the output of "describe-face"the background color is given: Defined in ‘org-faces.el’. Family: unspecified Foundry: unspecified Width: unspecified Height: unspecified Weight: unspecified Slant: unspecified Foreground: #00 DistantForeground: unspecified Background: #D8FA3C Underline: unspecified Overline: unspecified Strike-through: unspecified Box: unspecified Inverse: unspecified Stipple: unspecified Font: unspecified Fontset: unspecified Inherit: unspecified
