Richard Stallman [EMAIL PROTECTED] writes:
I don't see why the insertion of the initial scratch message should be
conditional on which buffer happens to be current at that point in the
start-up sequence.
It makes sense to me. If your init file sets up other buffers, Emacs
Or perhaps no change is needed. If you resume a saved session, you
have presumably seen the scratch screen in the previous session.
So maybe it is right that it goes straight back to the status that was
saved, without showing the scratch screen again.
I'd agree with that. I think `desktop'
But since we are trying to make a release happen, reverting a change
(for some minor bug) which turns out to cause more problems than it
fixes seems acceptable to me.
Once in a while, this is the right thing to do. But people seem to be
too quick to propose it, as if it were the
That sounds like a larger change. Is your change a reversion of that
whole previous change, or just an adjustment of it?
The change was a large one. This was tiny, IMO incidental part of it.
I suggest you avoid using the word revert for anything other than
reverting a change,
I don't see why the insertion of the initial scratch message should be
conditional on which buffer happens to be current at that point in the
start-up sequence.
It makes sense to me. If your init file sets up other buffers, Emacs
should let you see them, right?
I think this is not a
2001-11-03 Richard M. Stallman [EMAIL PROTECTED]
(command-line-1): Reorganize display of startup screen,
to simplify the logic. Use a temp buffer for it.
That sounds like a larger change. Is your change a reversion of that
whole previous change, or just an adjustment of it?
Richard Stallman [EMAIL PROTECTED] writes:
In general, people seem to be too quick to propose reverting a
previous change as a solution to a new problem.
It is not unusual that the change to fix one problem causes another.
Reverting the change would bring back the former problem. Once in a
On 3/10/07, Kim F. Storm [EMAIL PROTECTED] wrote:
Also, IMO for 22.1, we should only fix bugs which are regressions
since 21.4. Any bug which was also present in 21.4 should wait for
22.2 or 23.1
I'd like to think you're talking about trivial bugs or bugs that
cannot lead to data loss. A bug
[EMAIL PROTECTED] (Kim F. Storm) writes:
[...]
Also, IMO for 22.1, we should only fix bugs which are regressions
since 21.4. Any bug which was also present in 21.4 should wait for
22.2 or 23.1
FYI, both this bug and the other one I reported about edebug and
`labels' were already present in
Juanma Barranquero [EMAIL PROTECTED] writes:
On 3/10/07, Kim F. Storm [EMAIL PROTECTED] wrote:
Also, IMO for 22.1, we should only fix bugs which are regressions
since 21.4. Any bug which was also present in 21.4 should wait for
22.2 or 23.1
I'd like to think you're talking about trivial
Richard Stallman wrote:
That sounds like a larger change. Is your change a reversion of that
whole previous change, or just an adjustment of it?
The change was a large one. This was tiny, IMO incidental part of it.
It looks to me that you simply decided not to insert the initial
Oliver Scholz wrote:
The initial scratch message (from `initial-scratch-message') is missing
*iff* `desktop-save-mode' is on and at least one file is actually
visited automatically.
I belive this is because command-line-1 only inserts the
initial-scratch-message if the scratch buffer
I belive this is because command-line-1 only inserts the
initial-scratch-message if the scratch buffer is selected. Restoring a
desktop buries the scratch buffer. The following patch would fix this.
It reverts the behaviour to what it was before rev 1.270 of
startup.el.
This
Maybe it is rather intentional than a bug. But I report it anyways,
just in case.
The initial scratch message (from `initial-scratch-message') is missing
*iff* `desktop-save-mode' is on and at least one file is actually
visited automatically.
It is not possible to give a recipe starting
14 matches
Mail list logo
