1 Jun 2010 04:28
1 Jun 2010 05:10
Re: [PATCH] (Or "question"...) isearch-kill-found
Stefan Monnier <monnier <at> iro.umontreal.ca>
2010-06-01 03:10:06 GMT
2010-06-01 03:10:06 GMT
>> Of course I also dislike it because it adds a state. As for simply
>> providing a variable to change the behavior (without a key-binding to
>> change it), that's another solution, indeed. Maybe not a bad one.
> Why is not having a key to toggle the variable better?
Because keys are in very short supply.
> It is the variable that "adds a state", not the toggle key.
No: if the variable never changes, then it doesn't contribute to state.
Stefan
1 Jun 2010 05:13
Re: Window configurations
Stefan Monnier <monnier <at> iro.umontreal.ca>
2010-06-01 03:13:40 GMT
2010-06-01 03:13:40 GMT
> It's a good default rule for some cases like switching to another
> buffer with e.g. `C-x b', for other cases (like killing a buffer
> and finding another buffer to show in its place) a better rule
> would be to not see if that buffer is currently shown.
Even in the kill-buffer case, it's very common for the "prefer
a non-shown buffer" to be a good/better default.
I think the only case where we might want to overlook the fact that
buffer is already displayed is in cases where we "go back to a previous
state", so we'd need to mark that somehow.
Stefan
1 Jun 2010 06:43
RE: [PATCH] (Or "question"...) isearch-kill-found
Drew Adams <drew.adams <at> oracle.com>
2010-06-01 04:43:46 GMT
2010-06-01 04:43:46 GMT
> >> Of course I also dislike it because it adds a state. As for simply > >> providing a variable to change the behavior (without a > >> key-binding to change it), that's another solution, indeed. > >> Maybe not a bad one. > > > Why is not having a key to toggle the variable better? > > Because keys are in very short supply. Not really, for a keymap such as isearch. > > It is the variable that "adds a state", not the toggle key. > > No: if the variable never changes, then it doesn't contribute > to state.If a variable (in the usual programming sense, not in the math sense) never changes, then it's not very variable. Why have a variable in that case?
1 Jun 2010 10:19
1 Jun 2010 10:33
Re: Committing to both branches
David Kastrup <dak <at> gnu.org>
2010-06-01 08:33:02 GMT
2010-06-01 08:33:02 GMT
Juanma Barranquero <lekktu <at> gmail.com> writes: >> Can people *please* stop committing to both emacs-23 and trunk branches? > > Not even with "Backport from trunk" in the summary? Independent commits will likely cause merge conflicts. -- -- David Kastrup
1 Jun 2010 10:58
Re: Composing Hebrew diacriticals
Yair F <yair.f.lists <at> gmail.com>
2010-06-01 08:58:31 GMT
2010-06-01 08:58:31 GMT
On Fri, May 28, 2010 at 3:42 AM, Kenichi Handa <handa <at> m17n.org> wrote: > Then please find why maybe_otf and otf are set to zero by > stepping through the code of ftfont_get_otf which is called > from ftfont_shape. ftfont_get_otf sets otf only if maybe_otf != 0. maybe_otf is initialized from ft_face->face_flags in xftfont_open. For David CLM maybe_otf = 0 because ft_face->face_flags = 2577. For Dejavu Sans maybe_otf = 8 because ft_face->face_flags = 2649.
1 Jun 2010 11:24
Re: Window configurations
martin rudalics <rudalics <at> gmx.at>
2010-06-01 09:24:28 GMT
2010-06-01 09:24:28 GMT
>> The use of `point' for that has not brought many complaints over the >> many years it's been used. Any reason to think it's a bad choice? > > Could that be because people are using winpoint.el instead of > complaining. At least that is what I do. And the rest probably uses `pointback-mode'
1 Jun 2010 11:25
Re: Window configurations
martin rudalics <rudalics <at> gmx.at>
2010-06-01 09:25:36 GMT
2010-06-01 09:25:36 GMT
> Even in the kill-buffer case, it's very common for the "prefer > a non-shown buffer" to be a good/better default. > I think the only case where we might want to overlook the fact that > buffer is already displayed is in cases where we "go back to a previous > state", so we'd need to mark that somehow. As I noted earlier we could easily make this customizable. martin
1 Jun 2010 11:24
Re: Window configurations
martin rudalics <rudalics <at> gmx.at>
2010-06-01 09:24:15 GMT
2010-06-01 09:24:15 GMT
>> (1) All calls to `other-buffer' for determining which buffer to show in >> a window have the second argument nil. So if a buffer is already shown >> in another window it's against some unwritten rule to show it in the >> window in question again. If I follow that rule, then working with two >> windows showing the same buffer remains just as tedious as it is now. > > Yes, the window handling code currently considers that the most likely > thing the user wants is to see a buffer that's not currently shown. > [ I'm not sure if it's careful to distinguish "shown on the current > terminal" from "shown in some other terminal, miles away from here", > which it should. ] It's not that careful. > This seems like a good default rule, so if we/you want to not follow > this rule in some cases, The case at hand was a scenario earlier posted by Juri as ... ------------------------------------------------------------------------ 2. Another example - visit the same buffer in two windows, and put point at different positions of the same buffer. +---------+---------+ | | | | dired 1 | dired 1 | | | | | | | +---------+---------+(Continue reading)
RSS Feed