* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
[not found] <E1LAQV6-0003hq-HV@cvs.savannah.gnu.org>
@ 2008-12-10 15:01 ` Juanma Barranquero
2008-12-10 15:25 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 15:01 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: Emacs Devel
> (decode_options): Do not allow an empty alternate_editor on
> WINDOWSNT.
Why do you force me to use an alternate editor?
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 15:01 ` [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog Juanma Barranquero
@ 2008-12-10 15:25 ` Juanma Barranquero
2008-12-10 15:46 ` Dan Nicolaescu
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 15:25 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: Emacs Devel
OK, so it works on Windows, and you just used most of my patch, but
changed EMACS_DAEMON to WINDOWSNT because you didn't like it.
I like more descriptive defines. So do others.
Can we please go back in time to the moment where arbitrary parts of
Emacs weren't yours just because you said so?
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 15:25 ` Juanma Barranquero
@ 2008-12-10 15:46 ` Dan Nicolaescu
2008-12-10 15:54 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 15:46 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs Devel
"Juanma Barranquero" <lekktu@gmail.com> writes:
> OK, so it works on Windows, and you just used most of my patch, but
> changed EMACS_DAEMON to WINDOWSNT because you didn't like it.
You asked "modify according to your taste". Not only is my taste not to
add unneeded #defines, but the main reason is that there's other code in
src that deals with the daemon that uses just fine #ifdef WINDOWSNT.
Consistency in all directories is important.
> Can we please go back in time to the moment where arbitrary parts of
> Emacs weren't yours just because you said so?
Please STOP this.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 15:46 ` Dan Nicolaescu
@ 2008-12-10 15:54 ` Juanma Barranquero
2008-12-10 16:15 ` Chong Yidong
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 15:54 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: Emacs Devel
On Wed, Dec 10, 2008 at 16:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> You asked "modify according to your taste".
Yes. I also said "please don't delete the EMACS_DAEMON define".
> Not only is my taste not to
> add unneeded #defines, but the main reason is that there's other code in
> src that deals with the daemon that uses just fine #ifdef WINDOWSNT.
> Consistency in all directories is important.
That other code should also use EMACS_DAEMON or similar.
> Please STOP this.
Then please stop acting like this. You revert one of my changes after
I explicitly asked not to do, and "defend yourself" by saying that I
was provoking you... If you don't want me to think that you're acting
arbitrarily, don't do it. Please discuss before taking conflictive
decisions.
And the reason I fixed emacsclient.c on my own is that, as you left
it, it wouldn't even compile; otherwise, I would have brought the
discussion to the list first. I have no interest in fighting you; but
I also don't have the inclination to leave you to impose your view
over the code, when there are alternate POVs to consider.
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 15:54 ` Juanma Barranquero
@ 2008-12-10 16:15 ` Chong Yidong
2008-12-10 16:20 ` Juanma Barranquero
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Chong Yidong @ 2008-12-10 16:15 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Dan Nicolaescu, Emacs Devel
"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Not only is my taste not to add unneeded #defines, but the main
>> reason is that there's other code in src that deals with the daemon
>> that uses just fine #ifdef WINDOWSNT. Consistency in all directories
>> is important.
>
> That other code should also use EMACS_DAEMON or similar.
That depends on the specifics of the situation. Could either you or Dan
point out the places in src that use WINDOWSNT to handle daemon mode, to
give us more information to work with? (The macro should probably be
called HAVE_DAEMON for consistency.)
Another thing to consider: does the Emacs server and daemon work on
Nextstep?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:15 ` Chong Yidong
@ 2008-12-10 16:20 ` Juanma Barranquero
2008-12-10 16:35 ` Chong Yidong
2008-12-10 16:40 ` Jason Rumney
2008-12-10 16:31 ` Dan Nicolaescu
2008-12-10 16:33 ` Harald Hanche-Olsen
2 siblings, 2 replies; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 16:20 UTC (permalink / raw
To: Chong Yidong; +Cc: Dan Nicolaescu, Emacs Devel
On Wed, Dec 10, 2008 at 17:15, Chong Yidong <cyd@stupidchicken.com> wrote:
> (The macro should probably be
> called HAVE_DAEMON for consistency.)
Agreed. But then we should rename NO_SOCKETS_IN_FILE_SYSTEM to
HAVE_SOCKETS_IN_FILE_SYSTEM (and negate every #if(n?)def that uses
it).
> Another thing to consider: does the Emacs server and daemon work on
> Nextstep?
That's a good question.
But the base discussion is whether features should be tested by
feature tests, or lumped together into the WINDOWSNT, DOS_NT,
NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
must not check the Emacs version, but features. The same reasoning
applies to checking HAVE_DAEMON vs. WINDOWSNT.
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:15 ` Chong Yidong
2008-12-10 16:20 ` Juanma Barranquero
@ 2008-12-10 16:31 ` Dan Nicolaescu
2008-12-10 16:33 ` Harald Hanche-Olsen
2 siblings, 0 replies; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 16:31 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Emacs Devel
Chong Yidong <cyd@stupidchicken.com> writes:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
> >> Not only is my taste not to add unneeded #defines, but the main
> >> reason is that there's other code in src that deals with the daemon
> >> that uses just fine #ifdef WINDOWSNT. Consistency in all directories
> >> is important.
> >
> > That other code should also use EMACS_DAEMON or similar.
>
> That depends on the specifics of the situation. Could either you or Dan
> point out the places in src that use WINDOWSNT to handle daemon mode, to
> give us more information to work with?
emacs.c: main uses DOS_NT (which is WINDOWSNT || MSDOS)
emacclient.c is not used in DOS
> Another thing to consider: does the Emacs server and daemon work on
> Nextstep?
Adrian has a patch to make it working on Cocoa (it's only needed because
the daemon does a fork() and continues executing in the child, and the
Cocoa libraries don't work in such a situation). From what I
understood, the patch would no be needed on GNUStep.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:15 ` Chong Yidong
2008-12-10 16:20 ` Juanma Barranquero
2008-12-10 16:31 ` Dan Nicolaescu
@ 2008-12-10 16:33 ` Harald Hanche-Olsen
2 siblings, 0 replies; 21+ messages in thread
From: Harald Hanche-Olsen @ 2008-12-10 16:33 UTC (permalink / raw
To: emacs-devel
+ Chong Yidong <cyd@stupidchicken.com>:
> Another thing to consider: does the Emacs server and daemon work on
> Nextstep?
The answer is yes, on my mac at least.
- Harald
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:20 ` Juanma Barranquero
@ 2008-12-10 16:35 ` Chong Yidong
2008-12-10 16:50 ` Juanma Barranquero
2008-12-10 16:40 ` Jason Rumney
1 sibling, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2008-12-10 16:35 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Dan Nicolaescu, Emacs Devel
"Juanma Barranquero" <lekktu@gmail.com> writes:
> But the base discussion is whether features should be tested by
> feature tests, or lumped together into the WINDOWSNT, DOS_NT,
> NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
> must not check the Emacs version, but features. The same reasoning
> applies to checking HAVE_DAEMON vs. WINDOWSNT.
That's typically true, but again: specifics matter. For instance, if
the majority of the code controlled by the HAVE_DAEMON macro is
platform-dependent anyway, we would simply be replacing
#ifdef WINDOWSNT
...
#endif
with
#ifdef HAVE_DAEMON
#ifdef WINDOWSNT
...
#endif
...
#endif
Which situation pertains in the actual code?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:20 ` Juanma Barranquero
2008-12-10 16:35 ` Chong Yidong
@ 2008-12-10 16:40 ` Jason Rumney
2008-12-10 16:46 ` Juanma Barranquero
2008-12-10 16:55 ` Dan Nicolaescu
1 sibling, 2 replies; 21+ messages in thread
From: Jason Rumney @ 2008-12-10 16:40 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Chong Yidong, Dan Nicolaescu, Emacs Devel
Juanma Barranquero wrote:
> But the base discussion is whether features should be tested by
> feature tests, or lumped together into the WINDOWSNT, DOS_NT,
> NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
> must not check the Emacs version, but features. The same reasoning
> applies to checking HAVE_DAEMON vs. WINDOWSNT.
>
When it is just not possible to support a feature because of the
platform, then I have no problem using the platform constant to
conditionally compile it out. But if it is just a lack of developers on
a particular platform that is preventing the feature from being
implemented, then it is much easier for later developers who wish to
implement it if there is a feature specific constant.
NO_SOCKETS_IN_FILE_SYSTEM is sitting on a blurry line, since although
Windows does not support unix domain sockets, it is conceivable that an
emulation of them using named pipes could be developed in future.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:40 ` Jason Rumney
@ 2008-12-10 16:46 ` Juanma Barranquero
2008-12-10 16:55 ` Dan Nicolaescu
1 sibling, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 16:46 UTC (permalink / raw
To: Jason Rumney; +Cc: Chong Yidong, Dan Nicolaescu, Emacs Devel
On Wed, Dec 10, 2008 at 17:40, Jason Rumney <jasonr@f2s.com> wrote:
> But if it is just a lack of developers on a particular platform that
> is preventing the feature from being implemented, then it is much easier for
> later developers who wish to implement it if there is a feature specific
> constant.
That's my thinking too.
As for the daemon stuff, I already posted once my opinion: if we ever
implement the possibility of hiding Emacs in the tray (or GNU/Linux
equivalent), activating the --daemon option would make sense on
Windows for consistency with non-Windows builds, because although the
implementation is quite different, the user interface (starting Emacs
and making it invisible until requested) is pretty similar. In fact, I
would *love* to have the possibility of running "emacs --daemon" and
having it start "trayed".
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:35 ` Chong Yidong
@ 2008-12-10 16:50 ` Juanma Barranquero
0 siblings, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 16:50 UTC (permalink / raw
To: Chong Yidong; +Cc: Dan Nicolaescu, Emacs Devel
On Wed, Dec 10, 2008 at 17:35, Chong Yidong <cyd@stupidchicken.com> wrote:
> #ifdef WINDOWSNT
> ...
> #endif
>
> with
>
> #ifdef HAVE_DAEMON
> #ifdef WINDOWSNT
> ...
> #endif
> ...
> #endif
>
> Which situation pertains in the actual code?
Currently there's no Windows code to do it, so it is not clear.
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:40 ` Jason Rumney
2008-12-10 16:46 ` Juanma Barranquero
@ 2008-12-10 16:55 ` Dan Nicolaescu
2008-12-10 19:26 ` Lennart Borgman
1 sibling, 1 reply; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 16:55 UTC (permalink / raw
To: Jason Rumney; +Cc: Juanma Barranquero, Chong Yidong, Emacs Devel
Jason Rumney <jasonr@f2s.com> writes:
> Juanma Barranquero wrote:
> > But the base discussion is whether features should be tested by
> > feature tests, or lumped together into the WINDOWSNT, DOS_NT,
> > NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
> > must not check the Emacs version, but features. The same reasoning
> > applies to checking HAVE_DAEMON vs. WINDOWSNT.
> >
>
> When it is just not possible to support a feature because of the
> platform, then I have no problem using the platform constant to
> conditionally compile it out. But if it is just a lack of developers
> on a particular platform that is preventing the feature from being
> implemented, then it is much easier for later developers who wish to
> implement it if there is a feature specific constant.
>
> NO_SOCKETS_IN_FILE_SYSTEM is sitting on a blurry line, since although
> Windows does not support unix domain sockets, it is conceivable that
> an emulation of them using named pipes could be developed in future.
The problem with that is that WINDOWSNT has many many idiosyncrasies,
having a #define for each one of them adds an overhead for the ones of
us working on free systems.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 16:55 ` Dan Nicolaescu
@ 2008-12-10 19:26 ` Lennart Borgman
2008-12-10 19:36 ` Dan Nicolaescu
0 siblings, 1 reply; 21+ messages in thread
From: Lennart Borgman @ 2008-12-10 19:26 UTC (permalink / raw
To: Dan Nicolaescu
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> The problem with that is that WINDOWSNT has many many idiosyncrasies,
> having a #define for each one of them adds an overhead for the ones of
> us working on free systems.
Exactly how does it add overhead? Is it just because there are new
#define names?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 19:26 ` Lennart Borgman
@ 2008-12-10 19:36 ` Dan Nicolaescu
2008-12-10 19:51 ` Lennart Borgman
0 siblings, 1 reply; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 19:36 UTC (permalink / raw
To: Lennart Borgman
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
"Lennart Borgman" <lennart.borgman@gmail.com> writes:
> On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > The problem with that is that WINDOWSNT has many many idiosyncrasies,
> > having a #define for each one of them adds an overhead for the ones of
> > us working on free systems.
>
> Exactly how does it add overhead? Is it just because there are new
> #define names?
Yes. You have to learn or figure out something that you don't otherwise
need.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 19:36 ` Dan Nicolaescu
@ 2008-12-10 19:51 ` Lennart Borgman
2008-12-10 20:03 ` Dan Nicolaescu
0 siblings, 1 reply; 21+ messages in thread
From: Lennart Borgman @ 2008-12-10 19:51 UTC (permalink / raw
To: Dan Nicolaescu
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
> > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
> > > having a #define for each one of them adds an overhead for the ones of
> > > us working on free systems.
> >
> > Exactly how does it add overhead? Is it just because there are new
> > #define names?
>
> Yes. You have to learn or figure out something that you don't otherwise
> need.
Thanks, I see.
But there are tools withing Emacs for doing this, or? Can't we setup a
list of hide-ifdef-env for different platforms?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 19:51 ` Lennart Borgman
@ 2008-12-10 20:03 ` Dan Nicolaescu
2008-12-10 20:18 ` Lennart Borgman
0 siblings, 1 reply; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 20:03 UTC (permalink / raw
To: Lennart Borgman
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
"Lennart Borgman" <lennart.borgman@gmail.com> writes:
> On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> >
> > > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
> > > > having a #define for each one of them adds an overhead for the ones of
> > > > us working on free systems.
> > >
> > > Exactly how does it add overhead? Is it just because there are new
> > > #define names?
> >
> > Yes. You have to learn or figure out something that you don't otherwise
> > need.
>
> Thanks, I see.
>
> But there are tools withing Emacs for doing this, or?
Tools are useful, but they don't solve the problem.
> Can't we setup a list of hide-ifdef-env for different platforms?
That's a separate issue, and IMHO it would be useful to have.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 20:03 ` Dan Nicolaescu
@ 2008-12-10 20:18 ` Lennart Borgman
2008-12-10 20:26 ` Dan Nicolaescu
0 siblings, 1 reply; 21+ messages in thread
From: Lennart Borgman @ 2008-12-10 20:18 UTC (permalink / raw
To: Dan Nicolaescu
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
On Wed, Dec 10, 2008 at 9:03 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
> > On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> > >
> > > > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
> > > > > having a #define for each one of them adds an overhead for the ones of
> > > > > us working on free systems.
> > > >
> > > > Exactly how does it add overhead? Is it just because there are new
> > > > #define names?
> > >
> > > Yes. You have to learn or figure out something that you don't otherwise
> > > need.
> >
> > Thanks, I see.
> >
>
> > Can't we setup a list of hide-ifdef-env for different platforms?
>
> That's a separate issue, and IMHO it would be useful to have.
It is a separate issue too, but wouldn't it at least partly solve the
problem with learning you mentioned above?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 20:18 ` Lennart Borgman
@ 2008-12-10 20:26 ` Dan Nicolaescu
2008-12-10 20:34 ` Lennart Borgman
0 siblings, 1 reply; 21+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 20:26 UTC (permalink / raw
To: Lennart Borgman
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
"Lennart Borgman" <lennart.borgman@gmail.com> writes:
> On Wed, Dec 10, 2008 at 9:03 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> >
> > > On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> > > >
> > > > > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> > > > > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
> > > > > > having a #define for each one of them adds an overhead for the ones of
> > > > > > us working on free systems.
> > > > >
> > > > > Exactly how does it add overhead? Is it just because there are new
> > > > > #define names?
> > > >
> > > > Yes. You have to learn or figure out something that you don't otherwise
> > > > need.
> > >
> > > Thanks, I see.
> > >
> >
> > > Can't we setup a list of hide-ifdef-env for different platforms?
> >
> > That's a separate issue, and IMHO it would be useful to have.
>
> It is a separate issue too, but wouldn't it at least partly solve the
> problem with learning you mentioned above?
"partly solving" is not enough.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
2008-12-10 20:26 ` Dan Nicolaescu
@ 2008-12-10 20:34 ` Lennart Borgman
0 siblings, 0 replies; 21+ messages in thread
From: Lennart Borgman @ 2008-12-10 20:34 UTC (permalink / raw
To: Dan Nicolaescu
Cc: Juanma Barranquero, Chong Yidong, Jason Rumney, Emacs Devel
> "partly solving" is not enough.
I can't help citing VS Naipaul then: "I had replaced the thought about
decay, the idea about the ideal that can be the cause of so much
grief, with the thought about change" -- (my free translation from
Swedish ... ;-)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog
[not found] <E1LAYb6-0004jn-HF@cvs.savannah.gnu.org>
@ 2008-12-10 23:45 ` Juanma Barranquero
0 siblings, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2008-12-10 23:45 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: emacs-devel
On Thu, Dec 11, 2008 at 00:36, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Log message:
> (main): Fix previous change.
At last.
Juanma
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-12-10 23:45 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1LAQV6-0003hq-HV@cvs.savannah.gnu.org>
2008-12-10 15:01 ` [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog Juanma Barranquero
2008-12-10 15:25 ` Juanma Barranquero
2008-12-10 15:46 ` Dan Nicolaescu
2008-12-10 15:54 ` Juanma Barranquero
2008-12-10 16:15 ` Chong Yidong
2008-12-10 16:20 ` Juanma Barranquero
2008-12-10 16:35 ` Chong Yidong
2008-12-10 16:50 ` Juanma Barranquero
2008-12-10 16:40 ` Jason Rumney
2008-12-10 16:46 ` Juanma Barranquero
2008-12-10 16:55 ` Dan Nicolaescu
2008-12-10 19:26 ` Lennart Borgman
2008-12-10 19:36 ` Dan Nicolaescu
2008-12-10 19:51 ` Lennart Borgman
2008-12-10 20:03 ` Dan Nicolaescu
2008-12-10 20:18 ` Lennart Borgman
2008-12-10 20:26 ` Dan Nicolaescu
2008-12-10 20:34 ` Lennart Borgman
2008-12-10 16:31 ` Dan Nicolaescu
2008-12-10 16:33 ` Harald Hanche-Olsen
[not found] <E1LAYb6-0004jn-HF@cvs.savannah.gnu.org>
2008-12-10 23:45 ` Juanma Barranquero
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.