Re: AMC merge patch #2
Hello!
The saga continues, this time with EXTfs and Syntax files updates:
Changes included in patch: (all merged in from AMC version mc-4.1.35-A12pre)
- EXTFS Support for the ESP archiver ('uesp' added where needed)
I have never heard of ESP.
Icon=compressed.xpm is wrong. There is no compressed.xpm in the current
code. If you don't check your changes, somebody else will have to do it
for you.
That's precisely a defect that cannot be found by the end users. You are
adding an obsolete keyword, which has no effect. However, add 100
obsolete keywords, and mc.ext becomes much harder to understand by
developers, let alone users trying to customize it.
- (commented out) support for .deb on dpkg-less systems
(users just need to move # 2 lines up :))
Believe me, 99% of users won't know about that commented piece. The fix
belongs to the udeb script that should be able to fallback to using ar
if dpkg is missing or doesn't work.
- New .syntax files for BAssPasC, Macro-HTML, J(Dis)Asm languages
I only heard of jdisasm of all those. I'm not sure that most *.mac files
are written in Macro-HTML. I think I'll put this to the contrib section
of the website.
- (mostly) Color changes in HTML, LSM, Makefile .syntax files, to make
them (more) readable on blue background
(who the fsck thought that dark brown on dark red is readable?)
I don't remember seeing dark brown on dark red in any highlighted files.
If you mean dark brown on dark blue, that question was raised already, and
the right fix would be to implement macro definitions for colors. Then
you could define the color for comments in one place, and it would affect
all syntax files using that definition.
-context !-- -- brown
- spellcheck
+# modified by A'rpi/ESP-team [EMAIL PROTECTED]
-context ! brightred/orange
Please avoid placing your name everywhere you change something. You are
not the first and hopefully not the last person modifying any given piece
of code. This comment is adding exactly nothing.
If I find this in the release, I won't know what was modified, when and
why. I won't know if any further modifications have been done in that
code. I won't know if I should ask you about all lines below that
comment or only about the next line.
+# Syntax hilight definition file for Midnight Commander / CoolEdit
highlightCooledit
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: AMC merge patch #2
Hi,
The saga continues, this time with EXTfs and Syntax files updates:
Changes included in patch: (all merged in from AMC version mc-4.1.35-A12pre)
- EXTFS Support for the ESP archiver ('uesp' added where needed)
I have never heard of ESP.
Is it enough reason to refuse the patch?
It's an old DOS archived written by me and some others. It was widely used
around '97 under DOS. SInce I have lots of .esp files i've ported the
archiver to linux few years ago and added support for it in mc too.
Icon=compressed.xpm is wrong. There is no compressed.xpm in the current
possible. what is the replacement?
it comes from 4.1.35 where it did exists (probably) at least i copied it
from another archiver's (probably .zip i don't remember) entry.
since i'm using mc on console, i don't see icons so hard to notice if no
such icon...
code. If you don't check your changes, somebody else will have to do it
for you.
That's precisely a defect that cannot be found by the end users. You are
adding an obsolete keyword, which has no effect. However, add 100
obsolete keywords, and mc.ext becomes much harder to understand by
developers, let alone users trying to customize it.
ok
- (commented out) support for .deb on dpkg-less systems
(users just need to move # 2 lines up :))
Believe me, 99% of users won't know about that commented piece. The fix
belongs to the udeb script that should be able to fallback to using ar
if dpkg is missing or doesn't work.
yes it was discussed later (after i sent the patch)
- New .syntax files for BAssPasC, Macro-HTML, J(Dis)Asm languages
I only heard of jdisasm of all those.
great...
I'm not sure that most *.mac files
are written in Macro-HTML. I think I'll put this to the contrib section
of the website.
basspasc is an old assembly extension language for DOS, written by me and
others... (as usual) unless you was interested in asm optimization under DOS
that times it's no wondenr if you don't know it.
macro-html is not a widely known thing, i've wrote it to generate webpages
from templates using basspasc-like syntax macros...
- (mostly) Color changes in HTML, LSM, Makefile .syntax files, to make
them (more) readable on blue background
(who the fsck thought that dark brown on dark red is readable?)
I don't remember seeing dark brown on dark red in any highlighted files.
see the comments (// or /* */) in any .c file... unreadable!
maybe i should buy an LCD/TFT instead of my CRT monitor?
If you mean dark brown on dark blue, that question was raised already, and
the right fix would be to implement macro definitions for colors. Then
you could define the color for comments in one place, and it would affect
all syntax files using that definition.
it would be great!
-context !-- -- brown
- spellcheck
+# modified by A'rpi/ESP-team [EMAIL PROTECTED]
-context ! brightred/orange
Please avoid placing your name everywhere you change something. You are
sorry. i'm used to add comments where i modify in other's files, so i can
easily look up where did i touch it. with cvs it has no much sense it's
right, it's an old (and wrong) habbit...
+# Syntax hilight definition file for Midnight Commander / CoolEdit
highlightCooledit
i've seen 'hi-lite' used at too many places (other editors) while never
meet highlight. also teh meaning of highlight is a bit funny, at least
high light is nothing close to syntax coloring, imho.
what about the other (much more important) patch-set (AMC #1) ?
yes i know that touching the .c files is very very bad and i shouldn't do
that etc...
A'rpi / Astral ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
However, many people beg for its inclusion in Debian. Why? - Gabucino
Because having new software in Debian is good. - Josselin Mouette
Because having good software in Debian is new. - Gabucino
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Usability issue - error dialog
Error dialogs (for example 'File exists' dialog) are displayed in red, and the hotkeys are NOT highlighted, so the user don't know which key to use. One could easily confuse 'Append' (P hotkey) with 'Abort' (A hotkey). Maybe we should display corresponging hotkeys in yellow? Regards -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
[patch] avoid invoking commands with empty argument
mc passes an empty argument () to the EDITOR when creating new file (with F14). It makes vim to list the current dircetory. The nvi doesn't create temporary file, so write command won't work, however if you call nvi without any argument it creates a temp file to save the data in. The same problem occur with some other editors (jed to name one) Patch submitted: https://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1092group_id=3521 -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] avoid invoking commands with empty argument
Hello, Adam!
On Tue, 11 Feb 2003, Adam Byrtek / alpha wrote:
mc passes an empty argument () to the EDITOR when creating new file
(with F14). It makes vim to list the current dircetory. The nvi doesn't
create temporary file, so write command won't work, however if you call
nvi without any argument it creates a temp file to save the data in. The
same problem occur with some other editors (jed to name one)
What is passed to my_system() - NULL or empty string? If it's an empty
string, where does it come from? It's trivial for me to run it in the
debugger, but I assume you did it already.
What happens if EXECUTE_AS_SHELL is set, but command is NULL? I
understand that the shell won't be executed at all. This is how it's
called from view_other_cmd() if output_starts_shell is set.
P.S. Empty string comes from edit_cmd_new(). It should be fine to use
NULL if we take care not to run vfs_file_is_local() on NULL in
execute_with_vfs_arg().
How do you like following patch? Is there any other reason (apart from
running the editor) for replacing with NULL in my_system()?
===
--- cmd.c
+++ cmd.c
@@ -97,7 +97,7 @@ execute_with_vfs_arg (const char *comman
time_t mtime;
/* Simplest case, this file is local */
-if (vfs_file_is_local (filename)) {
+if (!filename || vfs_file_is_local (filename)) {
execute_internal (command, filename);
return;
}
@@ -348,7 +348,7 @@ edit_cmd (void)
void
edit_cmd_new (void)
{
-do_edit ();
+do_edit (NULL);
}
/* Invoked by F5. Copy, default to the other panel. */
===
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] avoid invoking commands with empty argument
On Tue, Feb 11, 2003 at 12:07:50PM -0500, Pavel Roskin wrote: P.S. Empty string comes from edit_cmd_new(). It should be fine to use NULL if we take care not to run vfs_file_is_local() on NULL in execute_with_vfs_arg(). Your patch is better, it sorts things on higher level. I wanted to be sure any other empty string will be converted to NULL in my_system(), but I guess this is not necessary, and could even break things. What happens if EXECUTE_AS_SHELL is set, but command is NULL? I understand that the shell won't be executed at all. This is how it's called from view_other_cmd() if output_starts_shell is set. Strange, this should never happen! This line: if (flags EXECUTE_AS_SHELL) execl (shell, shell, -c, command, NULL); Invokes just a 'shell -c' when no command is given. I've just tested. I've set show_output_starts_shell=1 and started cvs mc with 'mc -u', and after Ctrl-O I saw only this before mc returned to panels: Type exit' to return to the Midnight Commander zsh: string expected after -c Regards -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
hotlist: hotkey duplicates control; patch submitted
A new version of the hotlist patch with hotkey duplicates control is uploaded: http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521 * in new/edit entry/group, an error message is displayed, and the dialog is redisplayed so that the user can change the hotkey * when reading in from the hotlist file, duplicate hotkeys are ignored, a warning (at most one) is displayed, and the hotlist is written back without the duplicates This is the last feature I planned for the hotlist, so the patch is ready. Of course it can be improved, if anyone will have time to go through the new code critically and/or suggest new features, but for now, from my perspective, it is finished. I'm eagerly waiting for it to become part of a next version of mc. -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: AMC merge patch #2
On Tue, Feb 11, 2003 at 03:00:14PM -0500, bulia byak wrote:
Why not apply the same approach here? Especially given that such
additions are very unlikely to break anything else in mc.
On the other side nearly every programmer has written some tools for
his own use, to learn something new, just for fun or to fix some
problems with widely available tools. Often only the creator and some
friends use it.
Do you really think we should put extfs for JSR ('John Smith's
Archiver'), JSOPL ('John Smith's Own Programming Language') syntax
file, vfs for 'John Smith's Personal Filesystem' (JSPF), etc. into
official mc archive???
There must be some selection - and it would fit well into 'contrib'
cvs directory. Arpi, this mail is not to offend you, I also have some
toys created by me I enjoy. I just think there is no point including
things in mc that 99,9% users wouldn't use.
Regards
alpha
ps. When 'contrib' will be created, could sb move 'hp48' and 'bpp'
extfses there? Its an example of (nearly) useless extfs.
--
_.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org)
(_|||_)| |(_|: gg 1802819, pgp 0xB25952C0
|: jid alpha.pl(at)jabber.org
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Usability issue - error dialog
Hello! Error dialogs (for example 'File exists' dialog) are displayed in red, and the hotkeys are NOT highlighted, so the user don't know which key to use. One could easily confuse 'Append' (P hotkey) with 'Abort' (A hotkey). Maybe we should display corresponding hotkeys in yellow? Yes, something needs to be done about it. Right now, there is only one color allocated specifically for error messages. I've added this to the TODO list. The problem is that the current code doesn't scale well. Every time you add a new color, the translations need to be updated (look for print_color_usage in main.c). A better solution would be to move colors to mc.lib and remove the complete listing from the executable. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
