gmane.emacs.vim-emulation

Salam Sahajetra

Widiyana Samudra — 2013-05-08T20:12:16

Assalamualaikum Wr.Wb...

Sebelum dan sesudahnya saya ingin memperkenalkan diri saya,nama saya WIDIYANA SAMUDRA berasal dari Indonesia dan bekerja di London (United Kingdom), ingin berkenalan dengan anda di sana.
Saya ingin menawarkan satu peluang bisnis yang begitu bagus,dan  bagi Anda yang berminat dengan bisnis ... Inilah kesempatan Anda,kapan lagi kalau bukan sekarang bukan.???
Produk ini di namakan (MULITE CLEANSER) kegunaannya untuk mencuci barangan yang sangat berharga sekali seperti batu intan permata yg masih mentah.
Dan pada waktu yang sama perusahaan di tempat saya bekerja membutuhkan MULITE CLEANSER dimana mineral tersbut tersedia dari operator yg di Indonesia.
Jadi bagi anda yang berminat dengan bisnis ini, saya ingin Anda menjadi Agent untuk menjual produk tersebut ke pada perusahaan tempat saya bekerja, (Anda membeli produk tersebut dari operator yang di Indonesia terlebih dahulu dengan harga 500USD(Lima Juta Rupiah) per karton dan dijualnya kembali ke pada perusahaan  di tempat saya bekerja d

Re: Feature feedback: partial search acceptance

aditya siram — 2013-05-03T23:08:28

Perfect! Now what do I do with my evening? :)
-deech


On Fri, May 3, 2013 at 5:51 PM, Michael Markert
<markert.michael< at >gmail.com>wrote:

_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Feature feedback: partial search acceptance

Michael Markert — 2013-05-03T22:51:02

On Sat, May 04 2013 (00:12), Barry OReilly <gundaetiapo< at >gmail.com> wrote: 


No it does not match, but Isearch (and therefore the current default
search of evil) stops here if "abce" does not occur in the buffer
because it matched the previous input "abc".

I liked the idea so I put it into my config:
https://github.com/cofi/dotfiles/commit/13bca2e2503653fb0137a4216535d4505c3cb100

(Popping the mark returns to start, as usual, so C-o or C-x C-SPC)

BUT I don't think RET or even C-g are a good choice for keys. And then
I'm unsure if it should be included into evil.

Michael
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Feature feedback: partial search acceptance

Barry OReilly — 2013-05-03T22:12:35


It sounds like the wrong behavior to me, because "abce" doesn't match
"abc". I probably misunderstood you.
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Feature feedback: partial search acceptance

Leo Alekseyev — 2013-05-03T21:13:40

This would be very useful.  Current default partial search behavior is
annoying.  Make sure, though, that it is easy to jump back to where the
search started if need be.


On Fri, May 3, 2013 at 1:00 PM, aditya siram <aditya.siram< at >gmail.com> wrote:

_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Feature feedback: partial search acceptance

aditya siram — 2013-05-03T20:00:37

I'm working on a patch to evil where searching for a word with '/' allows
me to stop at a partial match.

For example, given:
"The wor^d I am looking for is abcd".
where '^' represents point, if I type '/' 'abce', 'abc' is highlighted.
When I hit RETURN or C-g I want point to go to the beginning of that
partial match and not jump back to where my search started.

Does this seem like a useful idea?
Thanks!
-deech
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Colorscheme

George V. Reilly — 2013-04-26T03:51:54

Both solarized and zenburn are available as Vim colorschemes and Emacs
themes. I imagine you could follow their lead in adapting your colorscheme
to Emacs.

Colorscheme

satshabad khalsa — 2013-04-26T01:06:08

Hi all, I was thinking about making the switch from vim to emacs and use
the evil-mode for editing? Is it possible/easy to port my custom color
scheme to emacs?

Thanks,
Satshabad
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Any existing way to customize derived mode according to its basemode?

Hongxu Chen — 2013-04-25T01:05:41

Thanks for your reply, Frank. And evil is really fabulous:-)


On Wed, Apr 24, 2013 at 10:22 PM, Frank Fischer <
frank-fischer< at >shadow-soft.de> wrote:

_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: is ":norm ..." available?

Michael Markert — 2013-04-24T22:34:38

On Wed, Apr 24 2013 (23:09), Qiming Sun <osirpt.sun< at >gmail.com> wrote: 


It's in evil for over two months: https://bitbucket.org/lyro/evil/issue/251/normal-in-ex-state

It doesn't seem to cover your use case, though. Please create an issue
with the details (what you get vs. what you expect & reproduction
instructions) if that is the case.

Michael
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

is ":norm ..." available?

Qiming Sun — 2013-04-24T21:09:08

Hi all,

I'm just starting to use Evil. In Evil, I didn't find the Vim function
":norm" e.g. :%norm 3J to join every 3 lines for the entire file.
Is it available in Evil now? Or is it a future plan?

Thanks,
Qiming

Re: Any existing way to customize derived mode according to itsbase mode?

Frank Fischer — 2013-04-24T14:22:06

Not that I knew of. Although it should be doable, it's just not
implemented, yet.

Best regards,
Frank

Any existing way to customize derived mode according to its base mode?

Hongxu Chen — 2013-04-23T14:00:03

Hi all,

   Evil mode is really wonderful for most editing issues. But I sometimes
   prefer the default keymaps(emacs state) for other modes for instance, those
   modes that are derived from comint-mode. When I set

     (evil-set-initial-state 'comint-mode 'emacs)

   But when I use gud-mode, the initial state is still `normal'.
   So is there any setting that can make the derived mode inherit the
   base mode?


 Thanks.
 Hongxu Chen

Re: Non editing Evil commands in evil-normal-state-map

Barry OReilly — 2013-04-08T14:47:18

The motivation for the motion keymap makes sense.  What was the motivation
behind the motion state?  Was it based on the observation that some buffers
don't involve text editing, or something else?

On Mon, Apr 8, 2013 at 2:25 AM, Frank Fischer
<frank-fischer< at >shadow-soft.de>wrote:

_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Strange behavior after hibernate

Sanel Zukan — 2013-04-07T21:26:47

Hi all,

Maybe someone can help me to indentify this odd issue I noticed after
recent pull and Fedora upgrade.

I'm using Fedora 18 x86_64 with Emacs 24.2.1 in daemon mode, from
terminal. When I send OS to hibernate state (with 'systemctl
hibernate') and leave terminal open with emacs editing session, after
resume, Evil (sometimes) became confused and almost all shortcuts
get messed up.

For example, in normal mode, 'gg' when pressed for the first time will
go to the first line, but pressed again will invoke emacs 'Goto line:'
command; or maybe pressing '$' will go to the end of the line, but
pressing '0' will do nothing; pressing '0' again will send it to Emacs
but not Evil since Emacs will report 'ESC 0 0 0 0' in command line after
some time.

Evil reload will return mode back to normal operation. Also Emacs
behaves quite normally.

Any idea what is happening? Does Evil has any global timers that could
probably be messed up after resume?

Best,
Sanel

Re: Non editing Evil commands in evil-normal-state-map

Frank Fischer — 2013-04-08T06:25:09

Because they have always been there ;)

I really don't remember, but one important reason is that commands
that are bound in motion state map are available in operator state,
too, an only motions make sense there. The originally motivation for
motion state map was to have a common map for motions to be available
in normal state, visual state and operator state. The "motion state"
itself has been introduced later. Maybe another hierarchy of maps
would be better, never thought about this.

Best regards,
Frank

Non editing Evil commands in evil-normal-state-map

Barry OReilly — 2013-04-05T21:38:26

Modes in which direct editing of text isn't sensical generally initialize
in motion or emacs state.  This means that the evil-normal-state-map is
inactive.  But there are some useful Evil commands in evil-normal-state-map
that don't involve editing text, such as:
  evil-record-macro
  what-cursor-position
  find-file-at-point
  evil-quit
and several others.

These are unavailable in for example Buffer Menu, even though they would
make sense there.

What's the reason behind putting non editing commands in
evil-normal-state-map?
_______________________________________________
implementations-list mailing list
implementations-list< at >lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Re: Strange effect when delete, then inserting a region

Manfred Lotz — 2013-03-31T12:30:00

Hi Frank,
Thanks for answering.


On Sat, 30 Mar 2013 17:30:49 +0000 (UTC)
Frank Fischer <frank-fischer< at >shadow-soft.de> wrote:


Ok, a minimal .emacs with the problem still happening is this:

<----------------------snip---------------------------------------->
(setq inhibit-splash-screen t)

(add-to-list 'load-path "~/.emacs.d/el-get/evil")

;;
;; evil mode
;;
(setq evil-want-fine-undo t)  
(require 'evil)
(evil-mode 1)   

<----------------------snap---------------------------------------->


I do the following:

1. In a terminal window emacs ~/.zshrc.local

2. I mark a couple of linus using V and then the cursor key

3. Deleting those lines using d

4. Go to a different place in the file and type p to insert it here

Instead of inserting I get rubbish. 0^L^Z^A.

The rubbish could look different. 


I tried to track it down further by going back in git history. I a
reset git repository to revision
5c4de55b750c99094ffd50d409b68fac710a8f83 then the error doesn't happen.
If I go to revision c91894e4f401f9e98e

Re: How to replicate the great visual selection search and replace

Frank Fischer — 2013-03-30T17:31:54

It has been implemented from scratch in Evil.

Best regards,
Frank

Re: Strange effect when delete, then inserting a region

Frank Fischer — 2013-03-30T17:30:49

No. It should work and because it is a very common command it seems to
work for others.

Please provide a minimal example how to reproduce this problem. Start
with a clean emacs instance with nothing loaded but evil (simply run
`make emacs` or `make term` in evil's source directory). Then provide
some keystrokes that demonstrate the problem. If you succeed in
providing an example, please consider submitting a bug report [1].

Best regards,
Frank


[1]  https://bitbucket.org/lyro/evil/

Strange effect when delete, then inserting a region

Manfred Lotz — 2013-03-30T13:53:32

Hi there,
Using evil mode I do the following:

1. I mark a couple of lines using V, then delete it using d (which is
evil-delete).

2. Now when inserting this anywhere else using p or P I get this:

p\310^V^A



When I do not delete the original lines, i.e. I do y (evil-yank) then
this does not happen.


Anybody having an idea what's going wrong?