Samuel Wales wrote:
On 3/3/14, Sebastien Vauban sva-n...@mygooglest.com wrote:
[[http://dangerous-place.com][know they are links]].
M-x visible-mode
the whole point is that comments and footnote definitions obscure the
fact that there is a link there.
who wants to run visible-mode all the
hi sebastien,
as i wrote, my preference is for links to be fontified in comments and
inline footnote definitions the same way as everywhere else.
samuel
On 3/4/14, Sebastien Vauban sva-n...@mygooglest.com wrote:
What type of indication do you have in mind?
+1 -- Another user chiming in, broadly in agreement with Gustav,
details below.
Gustav Wikström writes:
Hi, a user signing in. Although not involved in the development of this
piece of software I'm taking the opportunity to chime in anyway.
I'd like to give Nicolas Goaziou my support in
Bastien b...@gnu.org writes:
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Sorry for not being clear. I did try, I didn't get any error. My dummy
entry was:
* TODO [[http://orgmode.org]]
in a block agenda and
* [[http://orgmode.org]]
DEADLINE: 2014-03-01 sam.
in
Gustav Wikström wrote:
About the issue of links in comments (My opinion, for what it's worth):
It's a comment.. Expect it to behave as one. Worst case: copy the link and
paste it in the browser.
Or use `M-x ffap' (find-file-at-point)...
Best regards,
Seb
--
Sebastien Vauban
tldr, and wary of bikeshedding, but a fool so i rush in:
1] currently in maint the awesome package org-mouse.el activates
links in comments. RET does not. Perhaps this could be made more
consistent or optional?
2] currently in maint links are not fontified in comments or
footnote
if and only if it is not desirable to highlight links, then perhaps
they could be un-collapsed so that you
[[http://dangerous-place.com][know they are links]].
Samuel Wales wrote:
if and only if it is not desirable to highlight links, then perhaps
they could be un-collapsed so that you
[[http://dangerous-place.com][know they are links]].
M-x visible-mode
Best regards,
Seb
--
Sebastien Vauban
On 3/3/14, Sebastien Vauban sva-n...@mygooglest.com wrote:
[[http://dangerous-place.com][know they are links]].
M-x visible-mode
the whole point is that comments and footnote definitions obscure the
fact that there is a link there.
who wants to run visible-mode all the time? that would
I'm a user who doesn't much care about link following command behavior,
but Bastien's point about context is important. The behavior of a
command needs to depend upon much more than just syntax.
Two really dramatic examples are region narrowing and outline folding.
When operating on a narrowed
Hello,
Yasushi SHOJI ya...@atmark-techno.com writes:
At Sat, 01 Mar 2014 21:20:18 +0100,
Nicolas Goaziou wrote:
This is not a sufficient reason. We are discussing a minor feature.
Removing it doesn't remove any functionality to Org, as the thing just
saves a few keystrokes, on a good day.
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
And all I got so far was drama.
Please: everyone is showing great respect for your work, it is not
helpful to dismiss our contributions as drama. Your time is highly
valuable and so is ours. I don't think Michael, Yasushi or me would
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Sorry for not being clear. I did try, I didn't get any error. My dummy
entry was:
* TODO [[http://orgmode.org]]
in a block agenda and
* [[http://orgmode.org]]
DEADLINE: 2014-03-01 sam.
in regular agenda.
Both times, I
Bastien b...@gnu.org writes:
Here is my use-case: I often use C-c C-o as a shortcut for C-c C-x
C-n C-c C-o -- that's 2.5 shorter. This is convenient, and I would
need a good reason for removing something that convenient.
This is not a use case. A use case would explain me why (or, better,
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
That said, Org syntax is not the only valid representation of an
org-mode buffer.
It should be, or the whole concept is moot. If Org syntax is only
valid during export, if fontification interprets Org differently, if
users see Org
Bastien b...@gnu.org writes:
Yes. In the meantime, other users' voices can help us step back and
see things differently.
I used to have outcommented (w3m-browse-url ...) links in my init.el
file, and I could evaluate them when I wanted to look-up something
although they were outcommented:
Hi, a user signing in. Although not involved in the development of this
piece of software I'm taking the opportunity to chime in anyway.
I'd like to give Nicolas Goaziou my support in this issue. It makes it much
simpler to understand, use, develop and maintain the software if it is
congruent. A
Another user here, chiming in to support Nicolas's position. From my
perspective orgmode is so vast and complicated that the number one
thing we need (even from a user perspective) is predictability. I'd
rather see minor conveniences removed in favor of a constancy and a
logical interface.
Best,
Hi All,
Yes. In the meantime, other users' voices can help us step back and
see things differently.
(For reference: I have been using org-mode -- for TODO lists and note
taking -- for a few years now, but have not contributed code.)
I imagine myself as a naive user (which does not take too
Hi all
On Sun, Mar 2, 2014 at 4:49 PM, Bastien b...@gnu.org wrote:
In the meantime, other users' voices can help us step back and
see things differently.
May I ask at least Nicolas and Bastien:
When you carefully reread my last post (Thursday)
Hi Nicolas,
At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
Bastien b...@altern.org writes:
If it is not, I suggest to discuss the change before implementing it.
Nobody ever complained about the previous behavior, and both Michael
and me are suppporting it.
I didn't
Hi Nicolas,
At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
Bastien b...@altern.org writes:
If it is not, I suggest to discuss the change before implementing it.
Nobody ever complained about the previous behavior, and both Michael
and me are suppporting it.
I didn't
Hello,
Yasushi SHOJI ya...@atmark-techno.com writes:
However, we humans are not machines nor slave of computers. We tell
computers what we want, or even, we want to make computers think and
do what we are thinking. That's the reason why we, these days, have
*-dwim commands. We don't want
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
I insist on the fact that opening next link on the
same line is arbitrary and not really dwim.
And we insist on keeping the previous behavior, please trust us.
Right now the speedy command `o' is broken. This is a pattern I
use very
Hi again,
Bastien b...@gnu.org writes:
Right now the speedy command `o' is broken. This is a pattern I
use very frequently: use `n' to navigate to the next headline,
then `o' to open the link there.
Forget about this -- some draft code of mine interfered.
Also `org-agenda-open-link' is
Bastien b...@gnu.org writes:
And we insist on keeping the previous behavior, please trust us.
This is not a matter of trust. I asked about use-cases to understand why
this feature was needed, and all I got was because it was here.
Also `org-agenda-open-link' is now broken.
Can you have a
Nicolas Goaziou n.goaz...@gmail.com writes:
Bastien b...@gnu.org writes:
And we insist on keeping the previous behavior, please trust us.
This is not a matter of trust. I asked about use-cases to understand why
this feature was needed, and all I got was because it was here.
More precisely,
Bastien b...@gnu.org writes:
This is not a matter of trust. I asked about use-cases to understand why
this feature was needed, and all I got was because it was here.
More precisely, the answer was: because we use it and find it useful.
Thank you for the precision. Now, what about caring to
Hi Nicolas,
Thanks for your time.
At Sat, 01 Mar 2014 21:20:18 +0100,
Nicolas Goaziou wrote:
Anyway, I don't understand why there is so much fuss about this.
That's because a) the commands have been working
This is not a sufficient reason. We are discussing a minor feature.
Removing
Hello,
Bastien b...@gnu.org writes:
For example, white spaces after an object still belong to an
object.
Well, this is counterintuitive.
So they should belong to the next object? I don't find it more
intuitive. Anyway, it's an internal representation for white spaces so
it doesn't matter
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
So they should belong to the next object? I don't find it more
intuitive. Anyway, it's an internal representation for white spaces so
it doesn't matter here. See next answer.
I've no problem with this internal representation.
That's
Hi Nicolas
On Thu, Feb 27, 2014 at 11:28 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
The only really predictable behaviour is: open the link under point.
Everything else is arguable.
What for me is a conflict between ...
1) There are arguments to change - as you recently did in master
Hi Nicolas,
you just updated `org-open-at-point' without reimplementing the
previous behavior -- is this work in progress?
If it is not, I suggest to discuss the change before implementing it.
Nobody ever complained about the previous behavior, and both Michael
and me are suppporting it.
Thanks
Hello,
Bastien b...@altern.org writes:
you just updated `org-open-at-point' without reimplementing the
previous behavior -- is this work in progress?
No, it isn't. I fixed the bugs we discussed, and one reported on the ML.
If it is not, I suggest to discuss the change before implementing
Hi Nicolas
There is a recent regression that I hope I can use to revive an old
unanswered thread that, as it seems to me, is perfectly related.
On Thu, Oct 3, 2013 at 2:11 PM, Michael Brand
michael.ch.br...@gmail.com wrote:
Hi all
The recent bug report below reminds me of a comparable
Hello,
Michael Brand michael.ch.br...@gmail.com writes:
The above old issue with 3 remains the same on
release_8.2.5h-645-g3f55b45.
The recent regression is from release_8.2.5h-647-gfc9ce86
commit fc9ce86cfc1ecf7e86028027a12875a26500e774
Author: Nicolas Goaziou n.goaz...@gmail.com
Hi Nicolas
On Wed, Feb 26, 2014 at 4:25 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
I do not get any error, i.e, every link is opened in the browser.
With point exactly on all variants of 1, 2 and 3? _On_ is also
important to see the difference of 1 and 2 vs. 3 for the old
issue in
Michael Brand michael.ch.br...@gmail.com writes:
With point exactly on all variants of 1, 2 and 3? _On_ is also
important to see the difference of 1 and 2 vs. 3 for the old
issue in release_8.2.5h-645-g3f55b45, please check that too.
I don't understand. Using C-c C-o on 1 2 or 3 will not
Hi Nicolas
On Wed, Feb 26, 2014 at 4:54 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
I don't understand. Using C-c C-o on 1 2 or 3 will not open any
link since point is not on a link anyway. So you will consistently get
No link found.
Aha, now as I see that you removed the following from
Hello,
Michael Brand michael.ch.br...@gmail.com writes:
What is the benefit of removing the search on the same line?
`org-element-context' returns the context under point, not on the other
side of the line. Your are on a link, C-c C-o opens it, otherwise, it
doesn't. I find it very
Hi Nicolas
On Wed, Feb 26, 2014 at 5:41 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
Michael Brand michael.ch.br...@gmail.com writes:
What is the benefit of removing the search on the same line?
`org-element-context' returns the context under point, not on the other
side of the line.
Hi Michael,
Michael Brand michael.ch.br...@gmail.com writes:
I expect some users to go through the same surprise than me. Maybe
that there will be enough voices to get the searching on the same line
for C-c C-o (org-open-at-point) back.
Count me in -- this is a regression that needs to be
Hi Michael and Nicolas,
Michael Brand michael.ch.br...@gmail.com writes:
And once again thank you for your work in reimplementing more and more
by using org-element.
A quick note on this.
Here are the reasons why we *want* to rewrite some functions using
org-element:
- *bug fixing*: the
Hello,
Bastien b...@gnu.org writes:
Count me in -- this is a regression that needs to be fixed.
Nicolas, any stronger objection than the one your already
expressed?
As I said, the end of line is not a structural unit. Implementing that
feature, which, I must admit, I find cheesy, back will
Bastien b...@gnu.org writes:
Here are the reasons why we *want* to rewrite some functions using
org-element:
I don't know who we is. Apparently, I'm not in.
- *bug fixing*: the rewrite fixes bugs.
- *speed*: the rewrite provides a faster implementation;
- *predictability*: the rewrite
Hi Nicolas,
we was short for we, Org contributors, and it was a request for
comment, so I'm glad you did.
I understand your point very well: structural consistency favors ease
of maintainance and evolutivity. The new export engine is a perfect
example of this: without a clean parser, it would
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
As I said, the end of line is not a structural unit. Implementing that
feature, which, I must admit, I find cheesy, back will be fragile and
confusing.
For example, white spaces after an object still belong to an
object.
Well, this
47 matches
Mail list logo
