Samuel Wales writes:
> btw, the nuclear power plant MUST be painted blue.
FWIW, I strongly disagree.
--
Bastien
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 wrote:
> What type of indication do you have in mind?
Samuel Wales wrote:
> On 3/3/14, Sebastien Vauban 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? tha
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 r
On 3/3/14, Sebastien Vauban 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 defeat the
purpose of lin
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
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]].
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 definitions
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
Bastien writes:
> Hi Nicolas,
>
> Nicolas Goaziou 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 regul
+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
Hi all
On Sun, Mar 2, 2014 at 4:49 PM, Bastien 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)
http://lists.gnu.org/archive/html/emacs-orgmode/2014-02/msg0
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
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,
I
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
Bastien 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:
#+begin_src e
Hi Nicolas,
Nicolas Goaziou 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 differently t
Bastien 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,
where) you
Hi Nicolas,
Nicolas Goaziou 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 could
Hi Nicolas,
Nicolas Goaziou 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
care replying if it
Hello,
Yasushi SHOJI 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.
>
> Ok. If
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.
>
Bastien 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 give m
Nicolas Goaziou writes:
> Bastien 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, the answer was: becaus
Bastien 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 look and
Hi again,
Bastien 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 now broken.
Hi Nicolas,
Nicolas Goaziou 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 frequently: use
Hello,
Yasushi SHOJI 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 to make our users to
Hi Nicolas,
At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
>
> Bastien 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 remove tha
Hi Nicolas,
At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
>
> Bastien 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 remove tha
Hello,
Bastien 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 it.
> Nobody ev
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
Hi Nicolas
On Thu, Feb 27, 2014 at 11:28 AM, Nicolas Goaziou 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 -
org-ope
Hi Nicolas,
Nicolas Goaziou 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 not a problem, it
Hello,
Bastien 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 here. See
Hi Nicolas,
Nicolas Goaziou 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 is counteri
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 woul
Bastien 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 provid
Hello,
Bastien 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 be fr
Hi Michael and Nicolas,
Michael Brand 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 rewrite fixes bugs.
- *spee
Hi Michael,
Michael Brand 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 fixed.
Nicolas, any str
Hi Nicolas
On Wed, Feb 26, 2014 at 5:41 PM, Nicolas Goaziou wrote:
>
> Michael Brand 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, oth
Hello,
Michael Brand 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 predictable.
The "feature" you are m
Hi Nicolas
On Wed, Feb 26, 2014 at 4:54 PM, Nicolas Goaziou 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 the docstri
Michael Brand 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 open any
Hi Nicolas
On Wed, Feb 26, 2014 at 4:25 PM, Nicolas Goaziou 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 release_8.2.5h-
Hello,
Michael Brand 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
> Date: Sun Feb 23 11:35:34 20
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
wrote:
> Hi all
>
> The recent bug report below reminds me of a comparable situation with
> a bug that I w
Hi all
The recent bug report below reminds me of a comparable situation with
a bug that I wanted to report at some time:
#+LINK: link-abbreviation http://www.orgmode.org/#
1) [ ] [[http://www.orgmode.org/#docs]]
2) [[link-abbreviation:docs]]
3) [ ] [[link-abbrevi
49 matches
Mail list logo
