Cursor color in "Emacs state" not persistent
York Zhao
gtdplatform at gmail.com
Wed Aug 3 19:27:14 CEST 2011
>>I think that it has the potential to be something beyond Emacs or Vim,
>>something even better than either of those two editors.
I believe combining Emacs and Vi is the king, absolutely better than either
one of them and I actually don't understand why the "Editor war" in the
first place. To me, the answer is simple: Use both.
York
On Wed, Aug 3, 2011 at 12:36 PM, Nikolai Weibull <now at bitwi.se> wrote:
On Wed, Aug 3, 2011 at 18:11, York Zhao <gtdplatform at gmail.com> wrote:
> Previously the "wrong" cursor color remains even after having closed the
> other buffer, but anyways, it is working perfect now. As long as I'm
getting
> the correct cursor color after the inactive buffer becomes active that
> should be more than enough and we shouldn't complain.
>>>The cursor /type/ (box, hollow, bar, etc.), on the other hand,
>>>is fully buffer-local.
> Then should I be using "setq-default" instead of "setq"?
> By the way, after a few days of using Evil I'm pretty happy with it. Evil
> appears to be "cleaner" and more elegant designed than Viper+Vimpulse,
> thanks a lot to your wonderful work Vegard, Frank, Nikolai and all the
> contributors.
I’ve contributed very little, but you’re welcome :-). I agree that
Evil is shaping up to be something very, very nice. It has a much
simpler, much easier to follow, design than Viper(+Vimpulse) and I
think that it has the potential to be something beyond Emacs or Vim,
something even better than either of those two editors.
So, keep up the great work, Vegard! It’s greatly appreciated. I wish
I’d have time to contribute more.
_______________________________________________
implementations-list mailing list
implementations-list at lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ourproject.org/pipermail/implementations-list/attachments/20110803/333c4551/attachment.htm
More information about the implementations-list
mailing list