viper-mode C-[ behavior change in Emacs 24.4

viper-mode C-[ behavior change in Emacs 24.4

[iquiw]

Hi,

I'm using "C-[" key as ESC key in viper-mode, i.e. to escape from
viper insert mode.
It works on Emacs 24.3, but not on Emacs 24.3.92.
Typing "C-[" just displays "ESC-" in minibuffer on Emacs 24.3.92.

I found a workaround, evaluating the following code (from
viper-catch-tty-ESC) gives expected behavior.

```
(let ((esc-binding (viper-uncatch-tty-ESC)))
    (define-key input-decode-map
      [?\e] `(menu-item "" ,esc-binding :filter viper--tty-ESC-filter)))
```

I would like to know proper way to achieve the behavior.

Thanks in advance.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

iquiw <iku.iwasa@gmail.com> writes:

> I'm using "C-[" key as ESC key in viper-mode, i.e. to
> escape from viper insert mode. It works on Emacs
> 24.3, but not on Emacs 24.3.92. Typing "C-[" just
> displays "ESC-" in minibuffer on Emacs 24.3.92.

The same for me, on

GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version
 3.12.2) of 2014-06-06 on barber, modified by Debian

- are you sure it worked on 24.3? (I think 24.3 and
24.3.1 are the same.)

> I found a workaround, evaluating the following code
> (from viper-catch-tty-ESC) gives expected behavior.
>
> ``` (let ((esc-binding (viper-uncatch-tty-ESC)))
> (define-key input-decode-map [?\e] `(menu-item ""
> ,esc-binding :filter viper--tty-ESC-filter))) ```

If you are using the tty, this can be solved as all of
those key issues (e.g., C-m) with the same method.
Check out these files; search for "C-[" and
"C-left-bracket". Won't work in X, of course...

http://user.it.uu.se/~embe8573/conf/remap.inc
http://user.it.uu.se/~embe8573/conf/emacs-init/console-keys.el

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[iquiw]

On Thu, Jul 31, 2014 at 8:50 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
> - are you sure it worked on 24.3? (I think 24.3 and
> 24.3.1 are the same.)

Yes.
"C-[" acts as same as ESC on Emacs 24.3.1, which is executed by "emacs -Q"
on both Windows and NetBSD.

> If you are using the tty, this can be solved as all of
> those key issues (e.g., C-m) with the same method.
> Check out these files; search for "C-[" and
> "C-left-bracket". Won't work in X, of course...
>
> http://user.it.uu.se/~embe8573/conf/remap.inc
> http://user.it.uu.se/~embe8573/conf/emacs-init/console-keys.el

Thanks for the info.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Stefan Monnier]

iquiw <iku.iwasa@gmail.com> writes:
> I'm using "C-[" key as ESC key in viper-mode, i.e. to
> escape from viper insert mode. It works on Emacs
> 24.3, but not on Emacs 24.3.92. Typing "C-[" just
> displays "ESC-" in minibuffer on Emacs 24.3.92.

Rather than ask on gnu.emacs.help to solve the problem for you, I'd urge
you to M-x report-emacs-bug instead, so we can fix it for everyone.


        Stefan

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm using "C-[" key as ESC key in viper-mode, i.e.
>> to escape from viper insert mode. It works on Emacs
>> 24.3, but not on Emacs 24.3.92. Typing "C-[" just
>> displays "ESC-" in minibuffer on Emacs 24.3.92.
>
> Rather than ask on gnu.emacs.help to solve the
> problem for you, I'd urge you to M-x report-emacs-bug
> instead, so we can fix it for everyone.

Isn't it good that he asked on gnu.emacs.help so that
you can tell him it is a bug so that he can report it?
Often it is not clear if something is a bug and most
people are more hesitant reporting bugs (that might not
be bugs, so they would perhaps feel just a bit stupid)
- I agree people should be more liberal reporting
things they find odd as bugs - I mean, what's the worst
thing that can happen? - but as for asking here, people
should never hesitate to do that.

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Stefan Monnier]

> Isn't it good that he asked on gnu.emacs.help so that
> you can tell him it is a bug so that he can report it?

No, it's just a waste of my time.

> Often it is not clear if something is a bug and most

If something used to work and now fails to work in your non-released
piece of software, then you should always report it as a bug.
Of course, we may reply "this is explained in the NEWS file", so double
check the NEWS file first.


        Stefan

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Isn't it good that he asked on gnu.emacs.help so
>> that you can tell him it is a bug so that he can
>> report it?
>
> No, it's just a waste of my time.

Of course *now* the OP knows it is a bug, probably he
didn't know that when he posted, unless he (very
unlikely) was unware of the bug report function.

>> Often it is not clear if something is a bug and most
>
> If something used to work and now fails to work in
> your non-released piece of software, then you should
> always report it as a bug. Of course, we may reply
> "this is explained in the NEWS file", so double check
> the NEWS file first.

Yes, this is better - general guidelines (or
"instructions" downright) what to do - FAQ material (if
it isn't there already).

Question: "Non-released" software, I suppose that
includes the emacs24 (or 24.3+1-4+b1) or

GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2)
 of 2014-06-06 on barber, modified by Debian

because I have the same problem, as said. Do you have
to get it from the stable Debian repositories for it to
be "released"?

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[iquiw]

On Sun, Aug 3, 2014 at 9:20 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Isn't it good that he asked on gnu.emacs.help so
>>> that you can tell him it is a bug so that he can
>>> report it?
>>
>> No, it's just a waste of my time.
>
> Of course *now* the OP knows it is a bug, probably he
> didn't know that when he posted, unless he (very
> unlikely) was unware of the bug report function.

I was not sure whether it was a bug or not.
I will send a report.

Thanks.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
>
> Question: "Non-released" software, I suppose that
> includes the emacs24 (or 24.3+1-4+b1) or
>
> GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2)
>  of 2014-06-06 on barber, modified by Debian

The current released version is 24.3.  Perhaps the extra ".1" at the end
represents a Debian modification, I don't know.

> because I have the same problem, as said. Do you have
> to get it from the stable Debian repositories for it to
> be "released"?

Releases by distributions have nothing directly to do with Emacs
releases.  Some distributions may keep old version of Emacs "current"
for years after they've been superceded, others may use beta versions.
The current release is the one on ftp.gnu.org.

BR,
Robert Thorpe

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> Question: "Non-released" software, I suppose that
>> includes the emacs24 (or 24.3+1-4+b1) or GNU Emacs
>> 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2) of
>> 2014-06-06 on barber, modified by Debian
>
> The current released version is 24.3.

Yeah... so then it is a bug in "non-released" as well
as released software? <:|

> Perhaps the extra ".1" at the end represents a Debian
> modification, I don't know.

What I've heard, it is the "build number", so in terms
of software, 24.3.1 should be identical to any other
24.3.x. But if it is identical, why build it again? I
don't know. Perhaps if something else needs to be
rebuilt and for some reason then Emacs has to be (or
"is") rebuilt as well.

>> because I have the same problem, as said. Do you
>> have to get it from the stable Debian repositories
>> for it to be "released"?
>
> Releases by distributions have nothing directly to do
> with Emacs releases. Some distributions may keep old
> version of Emacs "current" for years after they've
> been superceded, others may use beta versions. The
> current release is the one on ftp.gnu.org.

Well, I think most people use their package managers as
that is one of the huge advantages with (most
distributions of) Linux. Debian has parallel sets of
software depending on how cutting edge, or, at the
other end, how stable the user desires the software to
be. Some five years ago, I used the stable release
until I had a problem with a piece of software that I
couldn't solve. So I got the same software from the
cutting edge branch, and the bug was gone. I have used
that software set ever since and hasn't had a crash (or
even a software failing) for years. So I don't think
the experimental and unstable software is particularly
"life on the edge", on the contrary. Anyway, so
whatever Emacs you can get from your distro's
repositories should be considered "released"? Sounds
logical...

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
...
>
> Well, I think most people use their package managers as
> that is one of the huge advantages with (most
> distributions of) Linux. Debian has parallel sets of
> software depending on how cutting edge, or, at the
> other end, how stable the user desires the software to
> be.

Yes, I use a package manager too.  But I don't always believe it when
the package manager says "stable" or "unstable", and I sometimes don't
believe the version numbers either.  On the stability issue the opinion
of the developers may be completely different.  Of course sometimes the
developers are wrong and the distro writers are right, not often though.

> Anyway, so
> whatever Emacs you can get from your distro's
> repositories should be considered "released"? Sounds
> logical...

No.  Distros do all sorts of wierd things, including sometimes releasing
alphas, betas or even separate builds they've done themselves.  To give
an old example, one time Red Hat released their own version of GCC.
They took the release branch of GCC's version-control repository, fixed
a few little things and released it.  They didn't even do that in an
"unstable" distro.

BR,
Robert Thorpe

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Yes, I use a package manager too. But I don't always
> believe it when the package manager says "stable" or
> "unstable"

Those release names should, I take it, not be applied
to any individual piece of software which they contain
but rather to a group of software that has migrated
there according to some policy. But of course it should
relate to reality in the sense that moste software in
"stable" should be stable.

But as I said, I never had a system or software crash
for years using the "un"stable Debian. Might be I only
use Emacs and zsh and the shell tools, and I upgrade
seldom and only what I need (no fishing expeditions).
Either that or it is just exaggerated as the Debian
people are security freaks: the unstable is actually
very stable to us mere mortals...

> numbers either. On the stability issue the opinion of
> the developers may be completely different. Of course
> sometimes the developers are wrong and the distro
> writers are right, not often though.

Distro writers... :)

>> Anyway, so whatever Emacs you can get from your
>> distro's repositories should be considered
>> "released"? Sounds logical...
>
> No. Distros do all sorts of wierd things, including
> sometimes releasing alphas, betas or even separate
> builds they've done themselves. To give an old
> example, one time Red Hat released their own version
> of GCC. They took the release branch of GCC's
> version-control repository, fixed a few little things
> and released it. They didn't even do that in an
> "unstable" distro.

OK, so we might all be running bastard-Emacs in
complete disarray in a world that is completely
disintegrated. Perhaps it would be easier to just get
Emacs from ftp.gnu.org and then quickly use the package
manager to uninstall the package manager...

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Stefan Monnier]

> of the developers may be completely different.  Of course sometimes the
> developers are wrong and the distro writers are right, not often though.

Indeed, because the "stability" they refer to is different.

Debian's "stable" does not mean that the packages's versions are
considered specially "stable".  It means the distro's packaging is
"stable", i.e. Debian considers that it's done a good job of packaging
those programs: they are built correctly, they have good dependency info
which makes sure upgrading/downgrading does the right thing, the default
configs are usable, the docs and various other files are placed where
Debian expects them to be, ...


        Stefan

Re: viper-mode C-[ behavior change in Emacs 24.4

[York Zhao]

Is there any reason for having to struggle with viper-mode instead of using
Evil? Evil is the most sophisticated Vim emulation layer so far. Give a go
and
I'm sure you will love it.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Debian's "stable" does not mean that the packages's
> versions are considered specially "stable". It means
> the distro's packaging is "stable", i.e. Debian
> considers that it's done a good job of packaging
> those programs: they are built correctly, they have
> good dependency info which makes sure
> upgrading/downgrading does the right thing, the
> default configs are usable, the docs and various
> other files are placed where Debian expects them to
> be, ...

Well, they have formal requirements for what makes up
one or the other release, but there are such for the
software as well because there is some kind of arc
where the software travels from one release to another,
software that behaves can be "frozen" (so not
additional changes will introduce bugs or break
dependencies, I take it), and so on - so I think it in
many ways refer to the software as well (though Debian
of course don't guarantee any software be bug-free,
software the Debian people didn't even write) - for
example, they say that the cutting-edge release be not
used "in production" (I take it with servers and such)
because it isn't safe. Also, if you compare the version
number of the software included in the different
releases, you find that, for example, as for 2012, the
poppler versions were:

    * Debian Stable: 0.12.4 (2 years old)                     
    * Debian Testing/Unstable: 0.16.7 (10 months old)       
    * Current Release: 0.18.4 (2 months old)                
    * Bleeding Edge: 0.19.3 (6 days old)

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Stefan Monnier]

>     * Debian Stable: 0.12.4 (2 years old)
>     * Debian Testing/Unstable: 0.16.7 (10 months old)

That is not an implicit statement by Debian that 0.12.4 is really more
stable than 0.16.7.  Only that 0.12.4 was the version that was chosen
back when "stable" got frozen and that switching to another version
later on within "stable" would be risky because the newer version may
require some other version of some other package, or may have changed
the format of the config file, ...


        Stefan

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That is not an implicit statement by Debian that
> 0.12.4 is really more stable than 0.16.7. Only that
> 0.12.4 was the version that was chosen back when
> "stable" got frozen and that switching to another
> version later on within "stable" would be risky
> because the newer version may require some other
> version of some other package, or may have changed
> the format of the config file, ...

So there is no implication at all with respect to the
software, and when they disencourage from using the
bleeding-edge "in production" (still unclear to me
exactly what that means) they are only referring to the
distribution: the bundling etc. of the software?

I.e., if you were to get by the install phase, and
thereafter only used the software (didn't reinstall or
upgrade it), then that software would be either more or
less or equally stable as the same software in the
stable Debian release, we couldn't tell?

OK, If you say so, I believe you. Like I said, I have
used the bleeding-edge for years without any problems
with stability whatsoever, so what you say isn't
contrary to my experience.

I want the bleeding-edge because I want the bugs and
problems I find and might try to correct or ask for
help to be bugs that haven't been corrected like years
from now, and correspondingly I don't want to wish for
features that likewise have been introduced in the
"bleeding" releases. I just want the most recent stuff.

So then the question is: if not for stable software,
why would anyone want software that can be up to two
years old, just so that the distro itself is stable?

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[John Mastro]

Emanuel Berg <embe8573@student.uu.se> wrote:
> So then the question is: if not for stable software,
> why would anyone want software that can be up to two
> years old, just so that the distro itself is stable?

To minimize the amount of not-strictly-necessary change occurring
beneath their feet. Even if the absolute level of "stability" never
changes, some users don't want to give up the devil they know for the
devil they don't.

Consider backwards incompatibilities in e.g. libraries, which may or
may not count as instability depending on how you look at it but can
certainly force cascading changes even in the absence of defects.

Obviously distributions do sometimes skip or modify problematic
application versions, but my impression is that Stefan is right: what
gets packaged has more to do with their release cycle than a qualitative
judgment about what's "stable" and what isn't.

--
john

Re: viper-mode C-[ behavior change in Emacs 24.4

[Stefan Monnier]

> So then the question is: if not for stable software,
> why would anyone want software that can be up to two
> years old, just so that the distro itself is stable?

I use Debian testing.  Every once in a while "aptitude upgrade" doesn't
work quite right (e.g. recently it switched to systemd which broke my
boot because it hangs waiting for a non-exiting device due to a broken
fstab entry which earlier just caused a harmless error message).

Such problems are unavoidable.  When you're dealing with a large number
of computers, you don't want to deal with those problems one
a regular basis.  Instead, you want to do upgrades "slowly" (e.g. at
most once a year).  Yet if you use Debian testing/unstable and don't
upgrade regularly, you might end up vulnerable to security bugs.
Hence Debian stable which lets you "upgrade" to fix security bugs at any
time without (hopefully) risking breaking your systems.


        Stefan

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

John Mastro <john.b.mastro@gmail.com> writes:

>> So then the question is: if not for stable software,
>> why would anyone want software that can be up to two
>> years old, just so that the distro itself is stable?
>
> To minimize the amount of not-strictly-necessary
> change occurring beneath their feet. Even if the
> absolute level of "stability" never changes, some
> users don't want to give up the devil they know for
> the devil they don't.
>
> Consider backwards incompatibilities in e.g.
> libraries, which may or may not count as instability
> depending on how you look at it but can certainly
> force cascading changes even in the absence of
> defects.

I don't know. It is difficult to visualize the
scenarios (and mentalities) you mention as I am not of
that mentality and the fail-case you mention I don't
think I have experienced.

If it is only what you mention, then why are there so
many releases? Does it take that much to just keep the
distro intact? A bunch of dependencies and man pages?

I always was very much in opposition to the
proliferation (or disintegration) of Linux, which
remind me of the selfsame tendency with respect to
programming languages.

I used to say that a new programming language is not as
bas as a new Linux distribution, as the new programming
language at least truly is something new, while the
Linux distro is just a new packeting of the age-old GNU
and X software. Especially when those distros are
reviewed in for example Linux Magazine: "There is a
black background. The default desktop is KDE, and the
default browser is Firefox
some.meaningless.version.number". Why is there a distro
for that? Why don't just retrieve and install whatever
damn software you want? Honestly, that makes me angry
because it is an insult to the advanced computer user.

But now, I sort of think it is much the same with
programming languages. Making a new language with some
changes in syntax and some other phrasings of the
compiler - it is just as lame. It is just intelligent
people who want to work on intelligent project, instead
I think they should put their intelligence to help
humanity. I think their behavior is the behavior of the
aristocrat. But as for technology, I respect those, of
course, which I cannot say about those Linux
distro-forkers...

> Obviously distributions do sometimes skip or modify
> problematic application versions, but my impression
> is that Stefan is right: what gets packaged has more
> to do with their release cycle than a qualitative
> judgment about what's "stable" and what isn't.

Well - the discussion wasn't about if that cycle is or
isn't governed by spelled-out methods, of course it it.
The discussion was if going through that cycle implies
an increased stability for the software itself, not
just the end result, namely the different releases. But
apparently there is no such implication or actual
consequence to it.

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I use Debian testing. Every once in a while "aptitude
> upgrade" doesn't work quite right (e.g. recently it
> switched to systemd which broke my boot because it
> hangs waiting for a non-exiting device due to a
> broken fstab entry which earlier just caused a
> harmless error message).
>
> Such problems are unavoidable. When you're dealing
> with a large number of computers, you don't want to
> deal with those problems one a regular basis.
> Instead, you want to do upgrades "slowly" (e.g. at
> most once a year). Yet if you use Debian
> testing/unstable and don't upgrade regularly, you
> might end up vulnerable to security bugs. Hence
> Debian stable which lets you "upgrade" to fix
> security bugs at any time without (hopefully) risking
> breaking your systems.

This discussion is to complicated for me. I do 'sudo
aptitude update' (or I have an alias for that) before I
install new software, which I very seldom do. That's
all I do. I don't do the upgrade stuff.

I have

deb http://ftp.se.debian.org/debian/ jessie main non-free contrib
deb-src http://ftp.se.debian.org/debian/ jessie main non-free contrib

in /etc/apt/sources.list

I have never had problems with not being able to boot
or anything like that. On the other hand I don't manage
a network or multiuser system or anything like that. I
just have a Emacs and tmux and zsh and sometimes ssh
and rsync or scp to my school's Solaris. Perhaps it is
the reliance on just a few software parts that protects
me from both software and distro unstability. Everything
just seems super-stable. Am I normal or am I doing
something wrong? :)

-- 
underground experts united

Re: viper-mode C-[ behavior change in Emacs 24.4

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
> I have never had problems with not being able to boot
> or anything like that. On the other hand I don't manage
> a network or multiuser system or anything like that. I
> just have a Emacs and tmux and zsh and sometimes ssh
> and rsync or scp to my school's Solaris. Perhaps it is
> the reliance on just a few software parts that protects
> me from both software and distro unstability. Everything
> just seems super-stable. Am I normal or am I doing
> something wrong? :)

Things have improved over the years.  "Unstable" now means (for Debian)
something that may cause a little hassle every few months.  I'm happy
that I'm living in a world where people don't really understand the need
for "stable" and "testing" releases of distributions.  There are still
some distributions where "unstable" or "testing" means that the distro
is really unstable.  It's not like the old days though, in the past
"testing" could mean "crashes every half an hour".

BR,
Robert Thorpe

Re: viper-mode C-[ behavior change in Emacs 24.4

[iku.iwasa]

On Friday, August 8, 2014 12:39:57 AM UTC+9, York Zhao wrote:
> Is there any reason for having to struggle with viper-mode instead of using
> 
> Evil? Evil is the most sophisticated Vim emulation layer so far. Give a go
> 
> and
> 
> I'm sure you will love it.

For those who are familiar with vim, evil seems the best.

I am not. I prefer nvi, which comes with base distribution of *BSD.
And viper-mode is very close to nvi.
I am happy with viper-mode.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Hans BKK]

>  "in production" (still unclear to me exactly what that means) 

These issues aren't so significant in environments where the user maintains their own system, but critical in organizations where a small staff is responsible for hundreds or thousands of hosts, and users are usually not allowed to modify their system.

"Production" systems are ones that are relied upon for critical operations, those that incur a significant cost if they stop working. These are often set up to run for years without any significant changes in order to minimize downtime and maintenance costs.

Doesn't have to be a multi-user host either, the CEO's personal desktop is usually treated as a critical "production" system.

To distinguish from "testing" machines or other hosts where downtime is NBD.

Marking a release (package, repo or distro) as "stable" usually implies the components-collection has gone through longer (over time) and more thorough (more people and platforms, in combination with more variables) TESTING. Newer releases are by that definition inherently "unstable".

Significant security issues are usually the only exception, their fixes often "backported" to the older releases.

Re: viper-mode C-[ behavior change in Emacs 24.4

[Emanuel Berg]

Hans BKK <hansbkk@gmail.com> writes:

> Doesn't have to be a multi-user host either, the
> CEO's personal desktop is usually treated as a
> critical "production" system.

Then my system is production as well because I don't
consider my work any less critical than that of some
CEO clown selling consumer crap from China to stupid
Westerners. But I'll stick to the bleeding-edge
release, come think of it.

-- 
underground experts united