In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Even if size_byte == size, it may contain eight-bit-graphic
>> characters, and decoding such a string is a valid operation.
>> And even if size_byte > size, it may contain only ASCII,
>> eight-bit-graphic, and eight-
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Kim Storm wrote:
>
>Both of us seem to primarily customize one option at a time --
>so it's mostly a matter of how far you have to move the mouse
>to active that changes...
>
> We all seem to usually set one option at a time. There is no nee
>> I think it should not be considered valid to decode a multibyte string,
>> whether the string happens to only contains ASCII (or ASCII+eight-bit-*)
>> or not.
> But, we allow decode-coding-region in a multibyte buffer.
> Then, it's strange not to allow something like this:
> (decode-coding-st
- Original Message -
From: "Kim F. Storm" <[EMAIL PROTECTED]>
> Why don't we simply introduce a "customize-expert" option that is off
> by default, but can be turned on when the user gains more experience.
>
> When off, it can limit the features of the customize interface to
> those featu
It's not a trivial work to change the current code (in
coding.c) to signal an error safely while doing a code
conversion. So, to check if decoding is valid or not, we
have to check all characters in a string in advance, which,
I think, slows down the operation considerably.
Do
What is the reason that we must choose and not have both local and global
actions? Is it to simplify the UI?
I am considering the idea of eliminating one of them in order to
simplify the interface. It seems to be far too complex now.
___
Emac
I think it should not be considered valid to decode a multibyte string,
whether the string happens to only contains ASCII (or ASCII+eight-bit-*)
or not.
But what would it mean, in the other cases?
___
Emacs-devel mailing list
Emacs-devel@gn
Kim Storm wrote:
IMHO, this is _expert_ behaviour.
I think that most novice users will very rarely mix and match setting
some options and saving others.
Rarely, but sometimes. Why confuse them badly if they do? Moreover,
it is not just setting and saving. It is also about looking at
>From my previous message:
I believe that we should introduce a "customize-expert" option, off
by
default, and only enable the all whole buffer buttons if it is on.
I forgot to erase "all".
Meant was:
I believe that we should introduce a "customize-expert" option, off by
default, and o
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Kim Storm wrote:
I wrote, you wrote, Lennart wrote, RMS wrote, bla bla bla :-)
Seriously, we seem to _completely_ disagree what an ordinary (novice) user
would expect from a customization interface.
My claim is that he is familiar with an interface wh
What is the reason that we must choose and not have both
local and global actions? Is it to simplify the UI?
I am considering the idea of eliminating one of them in order to
simplify the interface. It seems to be far too complex now.
Then I repeat: "Getting rid of the but
Kim Storm wrote:
The confusion arises when you have the option to "set but not save"
some options, and later on you do "save" -- that will save all options
including those you only "set".
No, you completely misunderstand. Getting rid of the Save-Set
distinction would _in no way whatsoev
- Original Message -
From: "Luc Teirlinck" <[EMAIL PROTECTED]>
> So I did talk about "setting" _in addition_ to looking at the choices,
> without setting anything. But the point remains that just looking at
> the possible choices for an option, without setting anything, poses a
> danger
>From my previous message:
You completely misunderstand again. I am talking about just _looking_
at items in a "Value Menu", not about setting anything.
Well actually I said:
He may just have wanted to set them, or even more likely, just has
been looking at them.
So I did talk abou
Salut,
Voilà un gros patch contre 1.44.3.
- string-as-multibyte n'est plus utilisé.
- Emacs-21 offre l'héritage entre faces.
- n'utilise pas tuareg-cache si syntax-ppss peut s'utiliser à la place.
- tuareg-font-lock-symbols (un sym-lock pour Emacs).
- correction de tuareg-mode-syntax-table pour q
I lost the CC's im my original reply to Lennart:
Lennart Borgman wrote:
I agree with your points, but is not this the case with most options
dialoges? I myself have often found that I have lost track of what I am
doing in those dialoges in other applications. To be sure to avoid trouble
The button I called RESET TO SAVED in my previous message could also
be called: UNDO EDITS.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
As I mentioned before, several strings in `custom-magic-alist' are
wrong (I previously gave test cases to show that) or too long. There
are several typos in the initial comments. The description of the
`rogue state' is too vague.
I propose the following patch, which I could install if desired:
Eminem Cheers DMX it's for you.Cheats in 1922
<>___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
I give a summary of my proposal to meet some of the objections
leveled against Customize. I personally _only_ have problems with
the whole buffer buttons, but I have tried to take other people's
objections into account (which I understood to be that that the State
button implementation is too unin
Drew Adams wrote:
If you do get rid of the buttons, will you also get rid of the equivalent
menu-bar menu items?
(Meant are the whole buffer buttons, if I understood correctly.)
I believe that for consistency, the equivalent menu-bar items, as well
as the `C-x C-s' binding in Custom buffer
21 matches
Mail list logo
