Re: Quick view
On Sun, Oct 02, 2022 at 11:53:20AM +0300, Andrew Borodin wrote: - Some of the files that ca be successfully rendered in the viewer (e.g. HTML, images*, PDF) show up as plain text/binary dumped as ASCII instead in quick view It's a feature[2]. Quick view shows file in the raw mode to avoid any delays required to get some info of the file. it wouldn't be terribly hard to do that in the background. however, switching to a proper main loop would be more or less a pre-requisite, which might be a somewhat bigger project (as such, it seems fairly easy, but doing it properly would probably require quite some refactoring to avoid nested main loops (which are a reentrance nightmare)). ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.28-rc1
On Mon, Mar 21, 2022 at 09:44:45AM +0300, Andrew Borodin wrote:
mc-wrapper.sh doesn't create a file.
i know, but i'm using my own function (for historical reasons):
mc ()
{
local tf=$(mktemp);
/usr/local/bin/mc -P $tf "$@" && test -r $tf && cd "$(<$tf)";
rm -f $tf
}
... which, *cannot* have ever worked. it's somewhat unsurprising that i
didn't notice, as my kde-based workflows don't rely on it working.
still, it seemed beizarre that i did't notice for a whole two decades,
so i looked around ... and each of my two other machines has a different
working version: one has tf=/tmp/mc-`whoami`/wd$$, which i presume is
the oldest one, and one has tf=$XDG_RUNTIME_DIR/mc-wd-$$. so i suppose
i'm sleepwalking. :'-D
A workaround is to apply `mktemp -u` or even `mktemp -u -t`, but is it
portable?
dunno. but it would be a mediocre idea anyway, and absolutely terrible
without the O_EXCL (because symlink attacks).
but anyway, this is an entirely self-made problem. sorry for the noise.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.28-rc1
On Sun, Mar 20, 2022 at 06:59:32PM +0300, Andrew Borodin wrote:
On Sun, 20 Mar 2022 15:22:14 +0100 Oswald Buddenhagen via mc-devel
wrote:
`mc -P $file` doesn't work any more when the file already exists
(which is of course the case after file=`mktemp`).
Indeed.
A following patch is proposed:
diff --git a/src/main.c b/src/main.c
index 3a33dfb59..a4910349a 100644
--- a/src/main.c
+++ b/src/main.c
@@ -492,6 +492,10 @@ main (int argc, char *argv[])
last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_CREAT | O_TRUNC
| O_EXCL,
S_IRUSR | S_IWUSR);
+
+if (last_wd_fd == -1 && errno == EEXIST)
+last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_TRUNC,
S_IRUSR | S_IWUSR);
+
if (last_wd_fd != -1)
{
ssize_t ret1;
that seems overly complicated - why not just drop the O_EXCL? at least i
can't see an obvious reason for having it in the first place.
anyway, i wonder why i ran into this only recently, given that this
behavior is actually rather ancient. probably has something to do with
me porting the wrapper function from tempfile to mktemp (as debian
started to complain about deprecation), though the replacement itself
couldn't have caused it.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.28-rc1
On Sun, Mar 20, 2022 at 01:15:41PM +0100, Yury V. Zaytsev wrote: TLDR; I would appreciate if you could please test the following tarball on your systems and report any blocker regressions as compared to the previous 4.8.27 release: i tested master instead: find.c: In function ‘find_cmd’: find.c:1837:28: warning: ‘start_dir_len’ may be used uninitialized in this function [-Wmaybe-uninitialized] 1837 | p = name + (size_t) start_dir_len; |^~ find.c:1897:13: note: ‘start_dir_len’ was declared here 1897 | ssize_t start_dir_len; | ^ coord_cache.c: In function ‘mcview_ccache_add_entry’: coord_cache.c:97:5: warning: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Wdeprecated-declarations] 97 | cache->cache[pos] = g_memdup (entry, sizeof (*entry)); | ^ In file included from /usr/include/glib-2.0/glib.h:82, from ../../lib/global.h:66, from coord_cache.c:57: /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here 257 | gpointer g_memdup (gconstpointer mem, | ^~~~ `mc -P $file` doesn't work any more when the file already exists (which is of course the case after file=`mktemp`). ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: change default configuration
On Fri, Jul 27, 2018 at 10:29:28PM +0200, Yury V. Zaytsev wrote: > I fought against it for quite some time, but, in the end, this was not > a fight that I could win. Debian Policy says it should be this way, > thus so it is, and so it will be :-/ > fwiw, this refers to https://www.debian.org/doc/debian-policy/ch-customized-programs.html#editors-and-pagers and the only trace of a "fight" i found quickly was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557126 which is somewhat unspectacular. i also found https://bugs.launchpad.net/ubuntu/+source/mc/+bug/263442 showing that ubuntu was more reasonable about it. anyway, i call bullshit on debian's decision. mcedit is built into mc, and it's an integral part of the mc experience. while mc offers an "escape route" (which it totally wouldn't have to, btw, and then what, debian?), it's absolutely obvious that it should prefer its own solution by default. the chosen interpretation of the policy would also imply that the libreoffice shell must start calligra words just because it's the preferred word processor in the desktop's mime type associations. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: change default configuration
On Fri, Jul 27, 2018 at 05:01:17PM +0300, Sergey Naumov via mc-devel wrote:
>I'm curious whether there is a way to change default configuration
>that is generated when user invokes mc for the first time?
>
according to the manual's FILES section, you can create
$prefix/share/mc/mc.ini.
fwiw, i always found that default setting rather surprising and
counter-productive, too. the vim/emacs/etc. hardliners will find the way
to launch their personal deity, err, preferred editor soon enough, while
average joe (in as far as he uses mc at all) won't appreciate being
dropped into vi by default ("how do i quit that crap?!" was also my
first experience).
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] fix directory search order to be depth-first again
this matches the pre-glib implementation, and is way more natural.
---
src/filemanager/find.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/filemanager/find.c b/src/filemanager/find.c
index e8719c9..2f5db3f 100644
--- a/src/filemanager/find.c
+++ b/src/filemanager/find.c
@@ -871,7 +871,7 @@ push_directory (vfs_path_t * dir)
static inline vfs_path_t *
pop_directory (void)
{
-return (vfs_path_t *) g_queue_pop_tail (_queue);
+return (vfs_path_t *) g_queue_pop_head (_queue);
}
/*
-
*/
--
2.8.3.1.g1cc7b6a
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Transifex and Russian Italian translations
On Mon, Jun 08, 2015 at 12:09:50PM +0200, Marco Ciampa wrote: On Sun, Jun 07, 2015 at 09:29:01PM +0200, Yury V. Zaytsev wrote: Otherwise, shall we at least somehow block people from using Transifex for the languages that are being committed directly to the repository? I do not like the current situation, because it seems that people doing stuff on Transifex are not aware of what's going on the git repository and vice versa. I think it's a really bad scenario when people invest time in doing translations, and their work is just discarded. I have always keeped mc translations in sync in many years. I think that transiflex is a great tool for missing or poor translations. If there is someone (like me) that check periodically translations for completless and for behaviour in the live program (translate - compile - install - test - commit) I think that is invaluable. I do not want to go back to transiflex. If it will be so, I understand and respect your decision, but I'll not continue updating mc in Italian. this is not helpful. what *exactly* is it that makes transifex an obstacle for you? is it not possible to simply use it as a buffer between the local and the remote repository? is this a setup problem or is it inherent in how tfx works? ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
On Thu, May 28, 2015 at 12:46:08AM +0300, Paul Sokolovsky wrote: On Wed, 27 May 2015 22:28:15 +0200 Yury V. Zaytsev y...@shurup.com wrote: For example, one could have set up a script to import Trac tickets into Github Issues. There are many half-way working scripts floating around, but they need testing and fixing. Last time, Savannah import into Trac took quite some effort, but it turned out to be very worthwhile. You again trying to over-complicate. Start from a clean page on github, while invite community to migrate issues from trac to github. Most content on trac from people who gave up on mc long ago. It makes sense to process what active people are interested in and leave old stuff where it is. nonsense. the old infrastructure is going to disappear at some point, and everything on it will be lost. it is entirely irrelevant that many of the people lost interest - most of the issues are still valid, and a lot of time went into discussing solutions. it would be plain stupid to throw this away, never mind the disregard for other people's work. I have couple of my patches accepted into mc (trivial, yes, it's on a non-trivial thing I stuck due to lack of discussion), so pass one criteria I myself proposed. My maintainership program would be: 1. Tear off all the unmaintainable code. see, statements like that make me hope very much that you never get direct write access to the repository. 3. Require patches with good descriptions (including references), try to respond to pull requests quickly with suggestion, close those which weren't got into shape in 1 month as unmaintainable. that's a nice plan, but requires a quite substantial committment to put into action. which brings us back to yury's conclusions. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
On Sat, May 30, 2015 at 02:08:37PM +0300, Paul Sokolovsky wrote: On Sat, 30 May 2015 11:53:58 +0200 Oswald Buddenhagen oswald.buddenha...@gmx.de wrote: On Thu, May 28, 2015 at 12:46:08AM +0300, Paul Sokolovsky wrote: You again trying to over-complicate. Start from a clean page on github, while invite community to migrate issues from trac to github. Most content on trac from people who gave up on mc long ago. It makes sense to process what active people are interested in and leave old stuff where it is. nonsense. the old infrastructure is going to disappear at some point, and everything on it will be lost. it is entirely irrelevant that many of the people lost interest - most of the issues are still valid, and a lot of time went into discussing solutions. it would be plain stupid to throw this away, never mind the disregard for other people's work. I didn't propose to throw it away. I proposed to leave it where it is for now and work on github issues/patches (which are also issues/patches, surprise), while ask help from wider community to migrate issues to github. If/when new maintainers ran out of github issues, they certainly will look into trac themselves, either at individual issues, or en-masse migration. The talk is about smooth start for new maintainers without extraordinary efforts. i think you are being a tad overly optimistic here. just for some perspective: a year ago or so i went through the effort of un-botching the previous import. more than half a decade after the fact. at this rate, there is no reason whatsoever to think that the infra will still be even there when somebody finally feels like doing a migration (midnight-commander.org is owned privately by slavaz). also, the longer you wait, the more work gets duplicated, and the harder it will be to merge the data sets in a useful way. that's why i would expect some serious commitment to a migration from somebody who wants to take over with the blessing of the previous maintainers. 3. Require patches with good descriptions (including references), try to respond to pull requests quickly with suggestion, close those which weren't got into shape in 1 month as unmaintainable. that's a nice plan, but requires a quite substantial committment to put into action. which brings us back to yury's conclusions. So, you started an argument in githib ticket, then came here just to criticize and repeat 'tis not possible? there is no contradiction whatsoever in that. i can review and discuss despite full awareness that i won't be able to put a final stamp of approval under it. Come on, time for productive actions - are *you* ready to be a maintainer? no. exactly because i lack the time (or personal motivation) to make the commitment. it's not like i haven't been tempted during a decade of lurking. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mc is over!? - post by Ilia Maslakov on Russian-speaking IT site
On Sat, May 30, 2015 at 02:47:02PM +0200, Yury V. Zaytsev wrote: Under these circumstances, I can stick my own (very negative) opinion of Github issue tracker somewhere deep down, and accept that the tools are chosen by those people who do the real work. If they like Github issues and they make them productive, so be it. i'll use that as a launchpad for some general musings of state-of-the-art hosting tools i'm aware of. this is an invitation to discussion, and i find it interesting beyond the scope of mc. it's obvious at first sight that the github issue tracker provides much less formal structure than trac. and trac ain't that great to start with (especially on the workflow side, at least as configured for mc (i don't know what would be possible with a current version)). in github, almost everything is done with labels. it's nice and uncomplicated, but simply doesn't scale. on the migration side, it seems that it's impossible to fake issue reporters. incidentally, that's one of the two problems that i fixed last year in mc's issue import to trac because i found it so annoying. most advanced import tool i found: https://github.com/trustmaster/trac2github i find github's code review system terrible; it doesn't encourage the workflow i want (every commit being polished), and it doesn't scale, either. luckily, there is gerrithub.io to alleviate the problem. there is also an open-source clone of github: gitlab. it is really a look-alike, so it has pretty much all downsides of github, with the addition that no gerrit integration exists (yet). on the upside, the issue import is probably better. tool: https://gitlab.com/kevinlee/trac-issues-to-gitlab there is also bitbucket, but the free version is limited to teams of five, whatever that may mean in practice. anyone here has experience with it? yet another fully integrated solution (for own hosting) would be phabricator. no personal experience with it, either. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
new development model?
hi guys, it appears that you moved the primary git repo to github. did i miss the announcement on this list, or did you simply forget to make one? anyway, you updated the home page, but not the various wiki pages, so i have no clue in how far the information as a whole is still current. how do i contribute? as before? via pull requests? ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Execute command on a shell link
On Fri, May 24, 2013 at 01:36:00PM +0200, Marco wrote: usually the command prompt follows the directory of the active panel. But this doesn't work on shell links, it always stays on the local file system. When launching a command the following error pops up: “Cannot execute commands on non-local filesystems” Hitting ctrl-o to get a shell doesn't work either, it doesn't open a shell on the remote host. Is there a way to execute commands on the remote host without opening a dedicated ssh session? the fact that the link uses a remote shell is abstracted away by the VFS layer, so: no. however, i must say that i find the idea to expose the shell through a side channel intriguing. but this is not going to be an easy exercise to start with, and the fact that the synchronization between mc and the (local) shell is now even more broken than in mc = 4.5 doesn't exactly make the challenge smaller. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH 5/5 v2] keyboard input: when an unknown sequence is seen, purge all buffered input
On Thu, Jan 31, 2013 at 11:38:58AM +0100, Denys Vlasenko wrote: Ping... the mc devs are rather insistent on their process and often simply ignore contributions on the list, so you may get a better response when you create trac tickets. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: ctrl mappings don't work
On Sun, Jan 13, 2013 at 06:11:16PM +, frank wrote: [continued bullshit] dude, maybe just give it a rest? i *co-authored* the pty code of a terminal emulator (and in the process studied the code of another, plus a whole bunch of manuals). i certainly know the terminology and semantics. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: ctrl mappings don't work
On Sat, Jan 12, 2013 at 10:35:41AM +, frank wrote: i'm not saying that it makes sense to remap ctrl-h/bs or ctrl-m/ret, just that the offered explanation is bogus. You started with [...] huh? slang/ncurses runs the tty in raw mode... in a thread that clearly and explicitely refers to a graphic terminal issue. what you are not getting is that this is utterly irrelevant. slang/curses and therefore mc are pty clients under X, which makes this equivalent to a real tty hosted directly by a virtual console. consequently i'm talking about the raw mode of ttys/ptys (and NOT the linux-specific KDGKBMODE ioctl), which you clearly didn't get despite my not at all subtle hint. Finally there is no bogus explanation: keys intercepted by the terminal program cannot be redefined by MC or any other text mode application running under the terminal. the thing is that the keys are not intercepted or handled by the terminal at all (that is what would happen in cooked tty mode, where the tty would use these keys for editing functions of the internal buffer). they are just mapped to the same ascii codes as other keys. this means that if mc didn't have the meaning of those codes hard-wired somewhere, it would be perfectly possible to re-bind them. of course this would be of rather limited use, as then enter and backspace wouldn't work the usual way, but that's not the point of my objection. If Marco wants to customise such keys, he will have to convince his rxvt-unicode first. dunno whether this is possible with rxvt, but with xterm he could actually do that, at the cost of making other applications which expect the traditional keybindings not doing what the user expects. the really crazy idea would be linking mc to a terminal emulator (creating a second specialized executable, xmc). this would solve a whole bunch of problems: a) arbitrary key mapping b) clean x selection support (we already have x clipboard support via xclip, but that's only half the deal) c) proper session management integration without jumping through hoops (see https://www.midnight-commander.org/ticket/24) on a vt, a) can be implemented with a different backend, while b) and c) are irrelevant. when subcommands were called, the built-in terminal would host them the usual way. the downside of that is that linux users typically think they have a reason to use a particular terminal emulator (and in some cases they actually have), so they wouldn't like mc forcing a choice on them. consequently, a better solution would be standardized extended tty escape sequences which allow tighter integration of text clients into the windowing system despite the mediating tty emulator. i'm sure some terminals already provide some of these features. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: ctrl mappings don't work
On Thu, Jan 10, 2013 at 11:04:33PM +, frank wrote: huh? slang/ncurses runs the tty in raw mode... Marco's issue concerns rxvt-unicode not the text console. so what? man termios. i'm not saying that it makes sense to remap ctrl-h/bs or ctrl-m/ret, just that the offered explanation is bogus. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: optimising change CWD algorithm in subshell mode
On Sat, Nov 03, 2012 at 11:34:58AM +1100, Dmitry Smirnov wrote: For example if current working directory is /1/2/3/4/5 and we want to change to /1/2/3/4/5/6 MC sends cd /1/2/3/4/5/6 to bash when in reality one would likely to use cd ./6 as long as it is just one hop away from current directory. Is it feasible? i don't like it for two reasons: - using an absolute path is an easy error recovery. mc gets confused often enough by errors while changing cwd (especially since shell activity detection was so utterly screwed up). not being able to just hit enter twice to recover would be a major PITA. - this is fixing the problem at the wrong place, aka a workaround. there is no way in hell that simple processing of a string with a few tens of utf8 characters could legitimately require billions of cpu cycles. my suspicion is that some utterly inefficient shell functions are being invoked via $PS1 or so - that would also explain why there are problems reproducing it. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH 5/5] keyboard input: when an unknown sequence is seen, purge all buffered input
On Mon, Oct 22, 2012 at 04:49:45PM +0200, Denys Vlasenko wrote: 50 milliseconds seem to work well. why don't you use the existing timeout? it exists exactly for this purpose. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reply-To header missing for mailing list(s)
On Thu, Mar 08, 2012 at 05:55:51PM +0100, Alexander Kriegisch wrote: Attn. mailing list admin: Usually mailing lists set the Reply-To header to the list's mailing list yay, flamebait! ;) http://www.unicom.com/pw/reply-to-harmful.html ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [master] [4de95fe] Ticket #1963: use grep instead of awk in iso9660 extfs plugin.
On Wed, Dec 15, 2010 at 09:14:31AM +0300, Andrew Borodin wrote: On Tue, 14 Dec 2010 17:28:11 +0100 Oswald Buddenhagen wrote: or more precisely, you mean @EGREP@ Iconv not yet supported|Unknown charset (without the backslash). No. I mean @GREP@ with backslash'ed OR \|. There is an alternative: @GREP@ with \| or @EGREP@ with | that's what i wrote. ;) that's cleaner and should be more portable than the gnu extensions to basic regular expressions. Is \| a GNU extension in grep? it's kind of implied. the man page merely says In other implementations, basic regular expressions are less powerful. the sed man page is more explicit about it, and i think it's reasonabe to assume that it applies equally to grep. ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Change in mcedit exit dialog
On Sun, Jul 11, 2010 at 02:41:40AM +0100, Norbert Nemec wrote: I just installed 4.7.3 and was very surprised by the change in the exit dialog of mcedit. http://www.midnight-commander.org/ticket/2265 ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: how does skin recognize that UTF-8 is available?
On Thu, May 20, 2010 at 08:53:32AM +0400, Andrew Borodin wrote: On Wed, 19 May 2010 21:45:05 +0200 Janek Kozicki wrote: So I suppose that I would just call for an up-arrow and get either a UTF8 on or a ASCII one. But now I'm troubled. I switched to UTF8 recently and mc is still using ' and , to show the sorting direction. Instead of ↓ and ↑. MC uses a default skin or a skin set in command line (-S option) or a skin set in the ~/.mc/ini file (skin key). You can try use another skin to view non-default sotring symbols. that's the ultimately user-unfriendly solution. the *right* solution would be having a list of skins, ordered by decreasing demands on the charset. mc would automatically use the first skin whose characters are all available (judging by code page - incomplete fonts are a different matter: if someone chooses to use one, he may be required to configure something by hand). ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stable release of mc-4.7.0.3
On Fri, Feb 26, 2010 at 02:38:34PM +0200, Slava Zanko wrote: Major changes since 4.7.0.2. why on earth are you again inflating the version namespace? this looks like a rather regular bugfix release, i.e. 4.7.1. and the what you called 4.7.1 is pretty much a 4.8. a.b.c.d releases are only justified if the release tar balls are messed up somehow or some other kind of release showstopper slipped through. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stable release of mc-4.7.0.3
On Fri, Feb 26, 2010 at 03:42:47PM +0100, Yury V. Zaytsev wrote: I was asked to answer you that what they had in mind in the [epoch].[major].[minor].[release] that's pretty much a guarantee that the epoch will never change. Also, they say that Redhat uses the same versioning scheme for the kernels they support. the linux kernel's versioning scheme is an expression of a two-level generational development model. you may have noticed that this was dropped years ago - the major version is fixed at 2.6. and you never had such a model in the first place, and you'll never have. so why would you introduce such a scheme? Other than that, it's a matter of subjective preferences, I guess. yes, one can also prefer a versioning scheme which converges towards the value of pi. this isn't necessarily sane or even useful, though. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Some keys are not properly recognized in Konsole/xterm
On Thu, Feb 11, 2010 at 08:14:44PM -0500, Thomas Dickey wrote: On Fri, 12 Feb 2010, Oswald Buddenhagen wrote: do in any graphical mail reader), i have to: 1) find out that i can do that at all. the man page doesn't contain the term URL once. 2) write a regexp matching urls See the bottom of the app-defaults file. oh - great. so if i did my initial config now (and not 10 years ago) i'd even have a chance to be clued into the existence and setup of the feature. ;) 3) have some process which leads from a selection to opening a browser. klipper to the rescue! yay! even more regexps! Most people would remember how to use the paste operation (ymmv) you entirely missed the point. it's about reducing the number of manual actions required. you should read some basic literature on usability. right. that's why all graphical muas lack that feature ... ;) hmm - no all. all which have a noteworthy market share (guess why they do). Perhaps all of the ones in front of you at the moment. i'm not aware of any attempts to make mutt graphical. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Some keys are not properly recognized in Konsole/xterm
On Thu, Feb 11, 2010 at 07:03:40PM -0500, Thomas Dickey wrote: On Fri, 12 Feb 2010, Oswald Buddenhagen wrote: anyway, some useful features would be tabs, clickable urls and proper It's been configurable for clickable urls, for highlighting for a few years. i suppose you mean the multi-click options. so let's see. to use it in a way even remotely resembling just clicking urls in emails (like it would do in any graphical mail reader), i have to: 1) find out that i can do that at all. the man page doesn't contain the term URL once. 2) write a regexp matching urls 3) have some process which leads from a selection to opening a browser. klipper to the rescue! yay! even more regexps! or maybe a global shortcut with khotkeys to pop up a new empty browser window i could paste the url into? i can't decide - both options are *so* appealing ... arguably, somewhere between 0) and 1), you lost that user friendliness idea frank was mentioning ... ;) Spawning off a web-brower only seems like a good idea until you see it in action. right. that's why all graphical muas lack that feature ... ;) as far as i'm concerned, it would be sufficient if url hovering and clicking would work only when ctrl is held down. oh, wait - that already pops up a menu which does its best to induce rsi by requiring me to hold down the mouse button while i navigate it. next idea then ... config dialogs (imagine - most people don't like reading man pages). most of gnome's users are subliterate, agreed. i'm sure that to switch gears in your car/bike you always lean down and operate them directly - after all, appropriate controls anywhere near the console are clearly meant for illiterates. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: /#sh:user@host file names with % bug
On Fri, Jan 15, 2010 at 08:32:01PM +0100, Janek Kozicki wrote: 1. create files named efekt_skali__0.15%.png efekt_skali__1.5%.png 2. log in remotely to that host using /#sh:u...@host 3. observe wrong file names: efekt_skali__0.1593cf4fcng efekt_skali__1.593cf4fcng pretty weird, huh? it's not just weird, it is a potentially exploitable security hole. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: function key mapping broken
On Sat, May 16, 2009 at 11:52:35PM +0200, Oswald Buddenhagen wrote: not sure whether this is a configuration backwards compat failure or a wholly new braindamage: bah - even better: this is a slang vs ncurses[w] issue and probably existed forever; the ncurses-based build is broken in that regard. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
function key mapping broken
ev'nin', not sure whether this is a configuration backwards compat failure or a wholly new braindamage: mc suddenly maps f11 f12 to what one might think they are (but never were, because there was no point in it) - and then continues with shift-f1 as f13 and so on. of course that breaks the hotkey mapping which relies on shifted keys at given physical locations instead of arbitrary mappings which simply maximize the number of available keys. this issue is entirely new for me under xterm. in the linux console i observed the same with the german keyboard layout which intelligently took the freedom to map function keys differently than the kernel's built-in layout - that's why i'm using a modified layout for years. maybe somebody tried to work around such an issue and broke things big time? i don't feel like looking through the mess which you call a git history, so i'm just speculating ... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: The status of midnight-commander.org
hello slava co. On Fri, May 08, 2009 at 12:36:41PM +0300, Slava Zanko wrote: Do you consider the opportunity to give us official mc maintainership burden? after having tracked the development for a while i'm pretty sure pavel will not like what is there. your quality standards simply don't match a project as mature as mc. otoh you are fairly productive and it would be a waste to discard that. if it was up to me, i'd start with a fresh cvs = git import and target 4.7 with a *clean* patch series. lots of commit squashing, reformatting, documenting and, uh, generally writing code which isn't a nightmare to read in many places. this basically means that you'd have to play by the usual rules: make complete, atomic patches and go through N draconian review rounds on the mailing list (i really dislike trac for patch review. reviewboard might be an option, but also has the disadvantage of a medium break, i.e. additional effort). this isn't anything new - pavel said that before. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Cocoa front end
On Sun, Feb 22, 2009 at 12:15:55AM +, Derek Wyatt wrote: I was thinking of adding a cocoa front end to MC just for fun, given your c++ background you may prefer to join for example the krusader project (qt/kde based twin panel manager; with qt 4.5 it should run on 64 bit macosx as well). for me personally all graphical nc clones so far failed because of the poor integration with the shell. alt-a, alt-enter, ctrl-shift-j and most of all ctrl-o are absolutely crucial to me. and the speed of F3 F4 ... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
On Fri, Feb 13, 2009 at 08:20:29PM +0200, Pavel Tsekov wrote: You don't become a project member and developer by just waiting for the right moment, appearing on the scene and taking over of everything. would you bet? you may be the best maintainer on earth (you aren't, but wth), but by being unavailable you marginalize your project and thus yourself. so while the new ones might not be official maintainers, they are de-facto maintainers. those who do the work decide, even if my hair stands on end occasionally. to the new ones: get the trac vs. the mailinglist thing sorted. the current situation practically excludes everyone who cannot be bothered to poll your trac often enough, which basically is everyone who has some real experience (and thus has a day job, etc.). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
On Sat, Feb 14, 2009 at 04:38:31PM +0100, Patrick Winnertz wrote: to the new ones: get the trac vs. the mailinglist thing sorted. The plan is to move the trac mails together with git commit messages to an own mailinglist. but you want to continue using mc-devel as well? i don't think the size of the mc project justifies this in any way. even more so that after this initial flurry of activity things will most probably quiet down again (even if this team proves to have a longer half-life period than previous initiatives). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
On Sat, Feb 14, 2009 at 05:43:55PM +0100, Patrick Winnertz wrote: Well.. I would like to have some place to discuss everything. of course. If this is too much it would be worth to move this to a separate mailinglist. yes - *if*. but that's not going to be the case. i cannot imagine that the additional effort resulting from fragmenting the communication channels even more would be in any way justified. but that's not my decision anyway ... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [ae987b9] Reverted the use of bool in favour of gboolean
On Tue, Feb 10, 2009 at 12:49:55PM +0100, Patrick Winnertz wrote:
+++ b/edit/usermap.c
@@ -59,7 +59,7 @@ typedef struct Config {
typedef struct Command {
const char *name;
-bool (*handler) (config_t *cfg, int argc, char *argv[]);
+int (*handler) (config_t *cfg, int argc, char *argv[]);
shouldn't that be gboolean? i mean, reverting for the revert's sake
isn't the goal ...
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [fe95221] Rewrote the shell_escape function in order to make us of GString and g_string_append_c
On Tue, Feb 10, 2009 at 12:49:57PM +0100, Patrick Winnertz wrote: Rewrote the shell_escape function in order to make us of GString and g_string_append_c glib has functions for shell (un-)escaping. did you look at those? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Building 4.6.2
On Thu, Feb 05, 2009 at 08:48:52AM +0100, Jan Engelhardt wrote: On Wednesday 2009-02-04 19:20, Enrico Weigelt wrote: * Patrick Winnertz win...@debian.org schrieb: It seeems that autogen.sh create links instead of copying the files to the correct place. Right, as it should be. This should not be for when a tarball is about to be created, because these symlinks might be invalid on a target system. how about reading some manuals and checking what actually happens? make dist will resolve any symlinks while creating the package, so it is perfectly ok that the developer's checkout has the symlinked versions. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: ticket mail delay
as nobody is picking that up ... On Sat, Jan 31, 2009 at 06:26:46AM +0100, Enrico Weigelt wrote: * Oswald Buddenhagen o...@kde.org schrieb: the typical mail from trac contains: Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C3E4175022D; Fri, 30 Jan 2009 15:17:23 + (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B611B750087 for mc-devel@gnome.org; Mon, 26 Jan 2009 17:00:59 + (GMT) maybe the machine is under too heavy load, so mails lay around that long ;-o i assume you were kidding. otherwise you have quite a lot to learn ... i *think* fixing this is merely a matter of subscribing the tracker address to the mailing list. while this should be done by a list admin, in principle anybody could do it (provided the confirmation mail gets through the moderation queue :D) - only that it would cause some more mail noise. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: ticket mail delay
On Thu, Feb 05, 2009 at 08:45:28PM +0100, Patrick Winnertz wrote: i *think* fixing this is merely a matter of subscribing the tracker address to the mailing list. Well.. this will end in a mail loop... you know that the subscriber can simply disable mail delivery? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Building 4.6.2
On Wed, Feb 04, 2009 at 09:12:03AM +0300, Andrew Borodin wrote: I think this must be fixed and therefor 4.6.2.1 release is needed. jup. make dist-check avoids such bloopers - for the next time. ;) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [80a6897] cleanup: mhl_str_dir_plus_file(): int - size_t (suggested by Andrew Borodin)
On Sun, Feb 01, 2009 at 09:02:10PM +0100, Sergei Trofimovich wrote: +while (...) ...; +size_t fnlen = ...; i should point out that this is C99 and consequently won't compile on many platforms with older compilers. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: updated: [80a6897] cleanup: mhl_str_dir_plus_file(): int - size_t (suggested by Andrew Borodin)
On Sun, Feb 01, 2009 at 11:04:54PM +0200, Sergei Trofimovich wrote: On Sun, 1 Feb 2009 21:15:20 +0100 Oswald Buddenhagen o...@kde.org wrote: On Sun, Feb 01, 2009 at 09:02:10PM +0100, Sergei Trofimovich wrote: +while (...) ...; +size_t fnlen = ...; i should point out that this is C99 and consequently won't compile on many platforms with older compilers. declaring local variable in the middle of function? Which widely available compilers fail to build this? proprietary unix compilers are the unusal suspects. hp aCC being number one, immediately followed by sun studio 11 or so. or the other way round. whatever. I'd like to setup ones to test buildability, or it's just -ansi -pedantic options for gcc? works well enough. This is not the first time we introduce such problems. I agree - we should avoid those if it does not hurt (like 'long long' absence or such). bad example ... afaik, it is needed for 64-bit off_t on 32-bit systems and is thus usually suppressed with -Wno-long-long (also gcc-specific option, obviously). of course literal use of long long still needs to be avoided, but the compiler can't tell. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #25438] Crash when editing a file with a nonexistent syntax file included by ~/.mc/cedit/Syntax
On Fri, Jan 30, 2009 at 09:10:39AM +, Slava Zanko wrote: In the future, please use trac on www.midnight-commander.org such requests are rather pointless. why wasn't the old bug tracker shut down yet, or at least locked for new submissions? why didn't any of the old admins bother to mark the old home page as obsolete and add a link to the new one? otoh, the new home page isn't so much of a home page at all - it is a development hub. while user-oriented information is scarce on the old page, it is non-existant on the new one. i mean, even the wikipedia page tells me more about that program ... ok. enough ranting for now. :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #25438] Crash when editing a file with a nonexistent syntax file included by ~/.mc/cedit/Syntax
On Fri, Jan 30, 2009 at 10:46:48AM +0100, Patrick Winnertz wrote: Am Freitag 30 Januar 2009 10:28:29 schrieb Oswald Buddenhagen: otoh, the new home page isn't so much of a home page at all [...] Yeah.. this is true. If you like I can give you write permissions on the git and you'll can add this informations there? This would be very cool. yeah ... patches welcome. :-D but i'm really not the right guy for that. just a moment ago i rejected blogging about my *paid* work - which won't exactly improve my relationship with our doc team. just so you have an idea. ;} ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
ticket mail delay
hi, the typical mail from trac contains: Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C3E4175022D; Fri, 30 Jan 2009 15:17:23 + (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B611B750087 for mc-devel@gnome.org; Mon, 26 Jan 2009 17:00:59 + (GMT) is every ticket mail moderated manually or what? why on earth? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #145: update m4/* files
On Thu, Jan 15, 2009 at 03:28:34PM +0100, Philipp Thomas wrote: * Oswald Buddenhagen (o...@kde.org) [20090111 23:56]: why? wouldn't AM_GNU_GETTEXT and possibly gettextize take care of everything? AFAIK running gettextize or autoreconf won't remove an existing intl subdir. so ...? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #156: syntax: c/c++: %uld doesnt get highlighted correctly
On Sun, Jan 11, 2009 at 06:47:41PM -, Ticket System wrote: Resolution: duplicate |Keywords: Okay.. Closing it as invalid technical or manual problem? :} ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #145: update m4/* files
On Sun, Jan 11, 2009 at 11:40:27PM +0100, Enrico Weigelt wrote: * MC Ticket System tick...@midnight-commander.org schrieb: actually, it is generally considered bad practice to have generated files under version control at all. anything created by the bootstrap process (autogen.sh) should be purged from the tree. ACK, but that fact might change by the 135_drop_bundled_libintl branch. why? wouldn't AM_GNU_GETTEXT and possibly gettextize take care of everything? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #126: Merge ./lib/ChangeLog with ./ChangeLog
On Sun, Jan 04, 2009 at 08:54:33PM -, Ticket System wrote: This is also an issue which should be fixed in 4.6.2 ( a mostly bugfix release) uhm, either it is a pure bugfix release and gets called 4.6.2 or it contains features (or internal reorganization) and gets called 4.7. looks all like 4.7 to me ... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
On Sun, Jan 04, 2009 at 06:10:06PM +0100, Patrick Winnertz wrote: Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen: fwiw, the suggested backporting workflow is quite a nightmare with git, as all the merging goodies work only with forwardporting. I know but having many many branches with patches inside is also a nightmare.. in order to have a overview. to alleviate that one could have a collector branch to which all halfways ready feature branches (and master) are merged. but from that branch no-one would ever merge; it would be a constant dead end. unless it was decided that all branches are ready at the same time, in which case it *could* be merged. instead, you need to develop on master (the conventional name for the trunk), branch for stabilization of each release, do *all* bugfixing in the current stable branch and merge it back into master each time fixes have been applied. A improvement of the situation atm would be to make master the stable branch and creating one testing branch which is based on master, wouldn't it? you can have just one testing branch from which you constantly merge fixes to master and to which you merge master each time you want all new features for a new stabilization phase. but note the *all*. merging in git is always a wholesale thing (well, in fact, you can stop the merge before the current head of a branch, but you cannot omit changes in between). major new features have to be developed on branches of master, so they can be merged back into master. everything else results in use of cherry-pick, cherry-pick was the tool I wanted to use. that way you give up almost all of the power of git, including showing cool merge history graphs. you could have the same by creating local svn repositories for disconnected development and doing the merging via patches to a conventional central repository. git just doesn't work well for the freebsd model. it is optimized for the linux model, and of that only the main line (the stable series are a little cherry-pick sucker) - for obvious reasons. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
On Sun, Jan 04, 2009 at 09:28:29PM +0100, Patrick Winnertz wrote: ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) delete *the* stable branch, but not the concept of stable branches per se. doing so would mean that once you merged a feature patch to master, you cannot do a bugfix release any more until you make a feature release (*). to keep the option of bugfix releases open (and distributors really want that), one should always make a release branch from master (say, 4.6) and branch for bugfix patches from that branch. then one can make a bugfix release (say, 4.6.3) from the 4.6 branch at any time. the release branch is merged into master (but not the other way round) after each fix. of course that requires upfront planning whether a particular patch needs to go into a possible bugfix release, but given the patch branch process, you have a good start for that (the proposal in your next mail seems reasonable). (*) actually, one can retroactively create a release branch from a past master revision on demand. anyway, that results in a mess, as the need for cherry picking is practically guaranteed in that case. on top of that, the release process as such becomes a mess (if a release branch exists, tag there, otherwise tag on master. think of this, don't forget that, and, oh, if you are religious: pray). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug] symlink directiories are selected on selection
On Mon, Oct 06, 2008 at 12:25:47PM +0200, Maciej Pilichowski wrote: My config is the directory should not be selected when I call global select (for example via pressing alt+*). And this works as expected. But if there is not regular directory but symlinked directory (and valid one) MC when selecting treats such directory as a file -- it selects it. this isn't strictly a bug, it's just unexpected. suppose you have a dangling symlink - should it be marked or not? -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, panic - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #24038] slow starting of mc
Follow-up Comment #1, bug #24038 (project mc): you should attach the strace of such a startup. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24038 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit annoying syntax highlight changes
On Sat, Jun 28, 2008 at 02:33:59PM +0200, Jan Engelhardt wrote: starting with mc 4.6.2, there have been changes to the syntax highlighting, specifically displaying whitespace. http://savannah.gnu.org/bugs/?func=detailitemitem_id=13146 -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, panic - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #23512] save as retains mode
URL: http://savannah.gnu.org/bugs/?23512 Summary: save as retains mode Project: GNU Midnight Commander Submitted by: ossi Submitted on: Saturday 06/07/2008 at 09:54 Category: Editor Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: current (CVS or snapshot) Operating System: GNU/Linux ___ Details: mcedit always saves with the original mode of the file, even when save as is used. this leads to the bizarre situation that even after giving a read-only file a new name, it will be still read-only. in quick-save mode, this makes the file impossible to save after the initial save as. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23512 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #23513] need read-only mode
URL: http://savannah.gnu.org/bugs/?23513 Summary: need read-only mode Project: GNU Midnight Commander Submitted by: ossi Submitted on: Saturday 06/07/2008 at 09:57 Category: Editor Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: current (CVS or snapshot) Operating System: All ___ Details: the editor needs a read-only mode. in this mode, cursor navigation would work as normal, but any attempt to modify the content would pop up a confirmation dialog requesting to switch the mode. the mode would be initialized from the file's access rights. a manual toggle (and possibly a command line switch to be able to use the editor as a viewer) would be provided. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23513 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
syntax highlighting choice improvement
hi, to avoid absurd situations like makefile.c being highlighted as a makefile, i moved the basename-matching rules to the end of the Syntax file. possibly the combined rules should be split into extension-only and filename-only to avoid the critical rules fighting each other, too (e.g., configure.in.c). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, panic - my work here is done. Index: Syntax === RCS file: /sources/mc/mc/syntax/Syntax,v retrieving revision 1.39 diff -u -r1.39 Syntax --- Syntax 2 Nov 2007 14:10:27 - 1.39 +++ Syntax 23 May 2008 16:00:09 - @@ -55,9 +55,6 @@ file ..\*\\.(xml|XML|xsd|XSD|xslt?|XSLT?|dtd|DTD|qpg|qpg.in)$ XML\sdocument (\\?xml\sversion|!DOCTYPE\s) include xml.syntax -file (.\*[Mm]akefile[\\\.A-Za-z0-9]\*|..\*\\.mk|Kbuild)$ Makefile -include makefile.syntax - file ..\*\\.(pp|PP|pas|PAS|dpr|DPR|inc|INC)$ Pascal\sProgram include pascal.syntax @@ -121,12 +123,6 @@ file ..\*\\.(spec|spec\.in)$ RPM\sSpecfile include spec.syntax -file .\*ChangeLog[\\\.A-Za-z0-9_]\*$ GNU\sChangeLog\sFile -include changelog.syntax - -file (..\*\\.m4$|configure\\.in|configure\\.ac) M4\sMacroprocessor\sSource -include m4.syntax - file ..\*\\.(bat|cmd)$ DOS\sBatch include dos.syntax @@ -145,6 +141,15 @@ file ..\*\\.([iI][dD][lL])$ CORBA\sIDL include idl.syntax +file (..\*\\.m4$|configure\\.in|configure\\.ac) M4\sMacroprocessor\sSource +include m4.syntax + +file .\*ChangeLog[\\\.A-Za-z0-9_]\*$ GNU\sChangeLog\sFile +include changelog.syntax + +file (.\*[Mm]akefile[\\\.A-Za-z0-9]\*|..\*\\.mk|Kbuild)$ Makefile +include makefile.syntax + file Don_t_match_me Mail\sfolder ^From\s include mail.syntax ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: syntax highlighting choice improvement
On Fri, May 23, 2008 at 06:04:40PM +0200, Oswald Buddenhagen wrote: possibly the combined rules should be split into extension-only and filename-only to avoid the critical rules fighting each other, too (e.g., configure.in.c). bah, silly example. meant ChangeLog.mk or something. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, panic - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16908] Missing manpage for the binary cons.saver
Follow-up Comment #5, bug #16908 (project mc):
i'm pretty sure i suggested installing cons.saver into ${libexec} a long time
ago. that would solve the problem effectively by removing the program from the
user's view.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?16908
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Various small fixes to 4.6.2-pre1
On Fri, Nov 02, 2007 at 11:42:27AM +0100, Vladimir Nadvornik wrote: On ??tvrtek 01 listopad 2007, Oswald Buddenhagen wrote: On Thu, Nov 01, 2007 at 04:48:02PM +0100, Vladimir Nadvornik wrote: --- mc-4.6.2-pre1/vfs/smbfs.c -result = g_strconcat (my_remote, trailing_asterik ? /* : , 0); +result = g_strconcat (my_remote, trailing_asterik ? /* : , (char *) NULL); the use of NULL is discouraged, at least in c++. it doesn't add value anyway. (char *) 0 is also OK. yes. However the original is not OK, nobody claimed the opposite. ;) anyway, if you google for x null vs. zero, you'll find a helluva lot of bikeshedding over this issue. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Various small fixes to 4.6.2-pre1
On Thu, Nov 01, 2007 at 04:48:02PM +0100, Vladimir Nadvornik wrote: --- mc-4.6.2-pre1/vfs/smbfs.c -result = g_strconcat (my_remote, trailing_asterik ? /* : , 0); +result = g_strconcat (my_remote, trailing_asterik ? /* : , (char *) NULL); the use of NULL is discouraged, at least in c++. it doesn't add value anyway. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: tabs in clipboard, bug?
On Mon, Oct 15, 2007 at 10:59:08AM +0200, Marco Ciampa wrote: I enjoy the way the actual cvs snapshot mc shows the tabs but... RTFA -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #21248] recursively indented lines from x selection/clipboard
Follow-up Comment #1, bug #21248 (project mc): presumably this happens only if you ssh/rsh/telnet to another machine outside x/without x forwarding? shift should be detected on local linux consoles and when $DISPLAY is set - worksforme. the other case is cantfix and therefore wontfix. one could consider a shortcut for disabling autoindent (and auto-re-enabling it after a bulk of text came in), though. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21248 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #17822] consecutive resize events not handled correctly
Follow-up Comment #9, bug #17822 (project mc): when a resize is sent before mc is completely up, it doesn't get the geometry right, either - and yes, this happens about every time an xterm -e mc is restored by session management on my system. so the signal handler should be set up before the initial geometry is queried. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17822 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: GNU Midnight Commander 4.6.2-pre1
On Sat, Sep 29, 2007 at 01:02:12AM -0500, [EMAIL PROTECTED] wrote: Me wrote: On Thu, Sep 27, 2007 at 11:01:27PM -0500, [EMAIL PROTECTED] wrote: But I am not sure if this is a desirable feature, or not. it is On what grounds? https://savannah.gnu.org/bugs/index.php?13146 just mark the text within mcedit before marking it with the mouse. Interesting. (Checking if this really works, or not ... yes it does ... ) Yes, interesting indeed. Is this documented anywhere? no, as it is more a bug that happens to turn out positive. :) i guess anybody who uses selection in mcedit will figure out quite quickly that any type of syntax highlighting disappears from selected text. making use of this observation is kind of a no-brainer for me. I will open a bug report if that is needed, i don't think it is. the respective bug report is still open and documents the shortcomings extensively. And, yes, we know that indentations in a .c or .h file are to be done with the tab key and to do code indentations with the spacebar is considered as incorrect and bad practice. that's *one* way to view it. you may find https://savannah.gnu.org/bugs/index.php?9631 instructive. But since it is incorrect and bad practice to use the space bar, it would seem to me that very few people will do that [...]. how naive. Then I ask, why is it good to copy the -s into another file with a mouse-copy? The tabs of course ought to be copied. Naturally. we are talking about shift-mouse selections. this selects the *actual screen content* - mcedit is completely ignorant of these actions. proper interaction with the x selection/clipboard is another issue - https://savannah.gnu.org/bugs/index.php?13751 3. If you want to introduce new phenomena in the software, then it is good if these things are documented somewhere. oh, really?! ;-) ps: please cut your word count by ~80%. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Moving the MC homepage to www.gnu.org
On Wed, Sep 05, 2007 at 10:44:16PM -0400, Pavel Roskin wrote: That's what the reply all option is for, and it's present in all decent mail clients. actually, *decent* mailers (*) have a list reply option. :) (*) e.g., mutt, kmail, ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Getting ready for a release
On Tue, Sep 04, 2007 at 10:57:42AM +0200, Pavel Tsekov wrote: how are we going to number the new release ? 4.7. no exaggerated humbleness, please. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #13146] make tabs and trailing spaces visible
Follow-up Comment #13, bug #13146 (project mc): that's weird ... i see no such effect (little surprisingly). though with some terminals/color combinations it becomes light blue, too, and thus hardly visible, but i don't think we can do much about that. ___ Reply to this item at: http://savannah.gnu.org/bugs/?13146 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #5104] Move the 'rotatinG dash' toggle from Configuration to Layout
Follow-up Comment #2, patch #5104 (project mc): not really. i mean, the thought is correct, but it just doesn't cut it. i think the options need to be completely re-grouped: Layout... = Appearance... Configuration... = Behavior... one can work from here ... ___ Reply to this item at: http://savannah.gnu.org/patch/?5104 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch #6026] D language syntax file
On Thu, Aug 23, 2007 at 03:40:29PM +, Pavel Tsekov wrote: Shall I add this syntax file to CVS ? why not? look at vim - it is a real syntax file whore (~500 files). :) it's not like this would be a config file format for a game nobody ever heard of ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Allow storing mc configuration in /etc/mc - take 2
On Sat, May 19, 2007 at 05:04:25PM +0300, Pavel Tsekov wrote: I am reposting in case no one noticed the previous message due to the fact that I replied to an old thread. ah, you wanted a reply ... :) From [EMAIL PROTECTED] Sun May 6 15:06:58 2007 Please, review it and let me know whether to commit. as SYSCONFDIR is a constant, it can be concatenated with the file name constants without use of concat_dir_and_file in most places. the AM_CPPFLAGS assignments in the if CONS_SAVER can be made more elgant by use of +=, but that's another story. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #5871] enhance selection in xterms
Follow-up Comment #7, patch #5871 (project mc): re comment #6: we don't - it makes the title too jumpy, imo. ___ Reply to this item at: http://savannah.gnu.org/patch/?5871 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #19721] Aborting a FISH file transfer still causes the FISH layer to consume the whole file
Follow-up Comment #5, bug #19721 (project mc): huh? you actually used ssh for that? i guess that's a fine optimization. but for the general case the chunking should be homegrown (based on dd and printf/read, i guess). ___ Reply to this item at: http://savannah.gnu.org/bugs/?19721 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #19721] Aborting a FISH file transfer still causes the FISH layer to consume the whole file
Follow-up Comment #1, bug #19721 (project mc): no, i think we can do like ssh does, i.e., tunnel multiple virtual connections through one physical connection. this adds some overhead, though (especially cpu-wise, as we have to call dd for every chunk). btw, you might want to look at kde's fishserv.pl, it has some optimizations. never looked at it myself, though. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19721 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #19664] backspace navigation
Follow-up Comment #1, bug #19664 (project mc): ah, somebody wants it windows-compatible. i think that's silly. it does not follow the least surprise principle. additionally, the same function is already available in a consistent way with ctrl-pgup. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19664 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #5871] enhance selection in xterms
Follow-up Comment #5, patch #5871 (project mc): i always found it a bit ugly without the surrounding spaces. otoh, screen real estate is scarce ... fwiw, the delimiter chars can be configured, at least in xterm. one could more heuristics to the terminal (to detect paths, urls, etc.), but it will always suck. the real solution would be having the applications send some new zero-width delimiters to the term. that is a *lot* of work, though, and i certainly don't expect it to happen. ___ Reply to this item at: http://savannah.gnu.org/patch/?5871 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #19651] x selection in editor
Follow-up Comment #2, bug #19651 (project mc): i understood immediately what he means. :-P me: you can configure most *terms to strip trailing whitespace from the selection. without this, i would have freaked out long ago. :) ___ Reply to this item at: http://savannah.gnu.org/bugs/?19651 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Bugs should be reported to [EMAIL PROTECTED]
On Tue, Apr 10, 2007 at 09:10:13AM +1000, Jeremy Dawson wrote: Pavel Tsekov wrote: It would be nice if the device between the computer moniter and the chair could actually think. (quote from a Linux man page) Bugs should be reported to mc-devel@gnome.org If an email to this address is to be replied to in this fashion, it would be preferable if the address was not publicised. i tend to disagree, even if pavel has a tendency of being even more rude than i deem appropriate. ;) http://www.catb.org/~esr/faqs/smart-questions.html -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [BUG+PATCH] Wrong name sort.
On Mon, Mar 05, 2007 at 08:21:41PM +0100, Egmont Koblinger wrote: Perhaps it might make sense to have an option in mc where you can _manually_ choose between strcmp() and strcoll() (but hey, that's what LC_COLLATE is for!), ... in theory. i don't think LC_COLLATE as it stands is a good idea for filenames. some locales ignore punctuation for whatever reason, probably because its defined by the respective dictionary standard. but it's counterproductive to mangle filenames that way, particularly depending on the locale and not some setting explicitly relating to file names. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: File has hard-links. Detach before saving?
On Fri, Oct 27, 2006 at 05:12:00AM +0300, Nerijus Baliunas wrote: now this dialog's default is Yes. But, for example, default Fedora installation has /etc/resolv.conf and /etc/sysconfig/networking/profiles/default/resolv.conf hardlinked. In this case I don't want to detach. So I propose default to be No. i'm strictly opposed. it would make working with cloned source trees harder. and i'm pretty sure that my use case is sort of more common than yours. :-P fwiw, i think the setup you described is totally braindead. it's just a matter of time until some other editor detaches the file. one of the files should be a symlink to the other one. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Fix for password-protected .rar files
On Mon, Jul 24, 2006 at 05:35:33PM +0200, Denis Vlasenko wrote: On Monday 24 July 2006 16:31, Pavel Tsekov wrote: On Mon, 24 Jul 2006, Denis Vlasenko wrote: https://savannah.gnu.org/bugs/?func=detailitemitem_id=16967 Is this option supported on earlier versions of rar which might be still used ? Don't know. :) i think it is. unless i'm totally off, i used it in dos already - and that was *long* ago. Ok, the attached patch quotes some environment variables. -size=$6 +size=$6 this is pointless (just like several other instances are). and no, this does not depend on the contents of the variable. --- mc-4.6.1.org/vfs/extfs/urar.in2005-02-08 08:44:38.0 +0100 +++ mc-4.6.1.extfs/vfs/extfs/urar.in 2006-07-24 17:25:18.0 +0200 -for dir in $PATH; do +for dir in $PATH; do this is plain wrong. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, Jul 20, 2006 at 12:00:58PM +0300, Pavel Tsekov wrote: I hope this explanation helps. If you have questions, please, ask. as i understand it, it is a pure implementation problem and not something fundamental. mc gets the shell's sigchld at any time (just as it does with output), so it should be able to revive the shell at any time as well (a background exit with a potential cwd update should be communicated somehow - no, not with a popup, but maybe changing the prompt's background color until one presses ctrl-o or something). regarding the sigstop before/after pwd question ... i think it doesn't actually matter. sigchld from the shell means it's ready. then we should - purge it's input if we were in panel mode, so it does not start with the next command under us. we do this. you are suggesting that this can't work - why? - get to know it's cwd. given that the cwd should fit in a pipe's buffer (on linux, maxpath is 4k, just as the pipe buffer - i don't expect that relation to violate my assumption on any other system), there is no need to select() on the pipe until the sigchld arrives. so whether we revive the shell first and read the dir afterwards or the other way round should not really matter. regarding /proc, i don't see an actual advantage in using it ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Wed, Jul 19, 2006 at 04:58:16PM +0300, Pavel Tsekov wrote: On Tue, 18 Jul 2006, Oswald Buddenhagen wrote: Shall we keep the prompt in this case ? i think it would be logical. But then we shall face the same problems. I mean it is not different from what we do now. The only difference is that the output will go to the panel directly and no Ctrl+O would be necessary. yup, that's why i said that we have to fix it first in any case. ;) Reading /proc (if mounted) seems appropriate since it is available on most of the popular platforms. in principle yes, but every system has it's own /proc format, which some of are binary. It's more like reading a symlink. At least the current directory is implemented like symlink on the systems I've seen. uhm, indeed, that's generally the case for inodes of any type. this has to be verified per-system, tough. some thoughts regarding idleness detection. the shell can be in three states: idle (just output prompt), busy (after any input until we hit enter or make it declare itself idle again (ctrl-c)) and inactive (after enter in non-inactive state, i.e., executing command). in busy state, ctrl-l has known semantics: it causes all three supported shells to send us a clearscreen followed by a repaint. when we try to submit a command but find the shell in busy state, we can issue ctrl-l and capture the output (i.e., don't display it) and compare it with the prompt we received. if it is equal, we declare that the shell is in fact idle and submit the command. regarding the problem with freebsd, i have to ask again. is this related to http://mail.gnome.org/archives/mc-devel/2002-August/msg00022.html (how i initially assumed)? if no, i have to request more info ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Fri, Jul 14, 2006 at 11:27:27AM +0300, Pavel Tsekov wrote: On Fri, 14 Jul 2006, Oswald Buddenhagen wrote: without the subshell i can't operate mc while the command is executed, i Ok. But it can be as simple as Ctrl-O, execute command, Ctrl-O. There is only an extra Ctrl-O. yes, and i can't use alt-a, alt-enter and ctlr-shift-j. can't use the shell's much better completion, history and line editing, The subshell prompt widget doesn't perform these via the subshell. oh, really? ;) aliases shell functions and whatever cool features a modern unix shell Well yes - but see above. Again Ctrl-O followed by a command should do just fine. and again i can't mix it with functionality provided by the panels. offers, and i can't execute a series of commands without switching off I dont understand this. forget it, it was based on the observation of no subshell at all (mc -u). I am not advertising the removal of the subshell . I just want to remove the ability to execute commands typed at MC's prompt widget trough the subshell (if it isn't clear yet). good. but exactly this integration makes it so valuable for me. otherwise i could just use another xterm/vt/screen. However, if this functionality is to remain we have to define exactly how it is supposed to work and the subshell prompt should definitely go. My opinion is that if we start to impose restrictions on that feature there would alway be a group of confused users since it want behave exactly as they would expect to. But I am open to suggestions. the current implementation is a mc command prompt and a real shell prompt. the mc prompt can inject commands into the shell. disadvantages are that it is strictly one-way and it seems to be somewhat whacky (but i must say, i'm obviously trained enough not to do the stupid things - i didn't have problems with it for ages). the second variant would be embedding the real shell prompt into the panels. this could work by presenting the shell a really tiny pty. to reduce clashes with the emacs keybindings (which are typically used by shells, due to readline usage), mc would have to switch the meanings of ctrl-p/-n with alt-p/-n and probably some more, also to maintain consistency. command injection would happen in pieces, like when pressing alt-a, making a completion, etc. the advantage would be the full bidirectionality of the two views. disadvantages would be the loss of mc's command history window (but honestly, i could not care less, as i'm way faster with ctrl-r in the shell prompt anyway) and the potentially very hard implementation - way more then the current one. the third variant is the nc-like one where there is no real shell prompt at all and the commander pretends to be the interactive shell in both views. again, we would gain equivalence of the two views, would keep mc's history (even with disabled panels), and we would not have to detect whether the shell is idle, as there would be none. however, implementing a feature set comparable with a modern unix shell (think zsh) is an *imense* workload. given features like programmable completion, i think it is actually impossible without completely merging a real shell into mc, or, seen the other way round, making mc that shell's shiny front-end. however, that would easily triple mc's size and annoy all the people who are using one of the roughly three million other shells we did not choose. variant three is technically cleanest, but given the effort and the incredible flaming potential i think it is outright unrealistic. and extending mc's prompt just slightly and offering a castrated pseudo shell prompt doesn't sound exactly desirable to me. personally i'd go with variant two (unless somebody points out a fundamental flaw in the idea (no, i'm not talking about implementation problems)). to even think about that, we need to get the current code working reliably. i'll investigate this myself - however, i won't make *any* promises about the time frame. btw, in any case, i think the mc command prompt should be able to grow to a configurable number of lines (3 by default, maybe). currently working with long paths (which i typically have in my multimedia collection) is outright painful. btw2, we need an alternative to alt-tab for completion, as alt-tab is the sort-of-standard keybinding for switching windows in x and some other well known OSs. i think it would make sense to have it on alt-c (and have changeDir on alt-d - that's way more intuitive anyway. oh, btw, i never used this quick cd - if the prompt is busy, i can either navigate with ctrl-pgup/-pgdn or i simply ctrl-o into the shell). btw3, i just found that we need a function follow symlink (presumably mapped to alt-f) that would, well, guess what, set the current panel on the target of the symlink the panel was on. btw4, i should write fewer btws and file wishes instead. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic
Re: Makeing the subshell reliable
On Fri, Jul 14, 2006 at 08:11:55AM +0300, Pavel Tsekov wrote: * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other The prompt widget or the fact that if the subshell is enabled commands are executed trough the subshell ? Don't get me wrong - I want to keep the prompt widget. What I propose is to handle commands typed at it just as if the subshell is disabled. I cannot see how commands typed at the prompt and executed trough the subshell give MC an advantage over the other file managers. the fact that i can switch the panels on and off at any time - without losing the command's output. Even without the subshell the command output doesn't get lost - just try it. It is taken care of. you snipped way too much of my quote. ;-P without the subshell i can't operate mc while the command is executed, i can't use the shell's much better completion, history and line editing, aliases shell functions and whatever cool features a modern unix shell offers, and i can't execute a series of commands without switching off the panels after each command to verify the result (and don't suggest me the pause after run option - it's getting on my nerves very fast). point is, i tried several other managers (mostly shiny kde programs, because they have a much better vfs than mc), and always went back to mc, because the real shell is right at my fingertips and it's sort-of integrated with the panels (even if it's only one-way, but alt-enter, alt-a ctrl-shift-j are priceless). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote: There are several features which are consistent source of problems: My opinion is that we should remove both features from the subshell. * the subshell prompt retrieval - this one is widely known to be unreliable. could you be more precise about that? do you mean the shell's cwd or the actual prompt string? * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other nice file managers. it's just a pity that it does not work in the other direction as well. the only problem i have is mc permanently mis-detecting that the shell is busy, but that is worked around by ctrl-o enter ctrl-o alt-p enter. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Makeing the subshell reliable
On Thu, Jul 13, 2006 at 09:58:08PM +0300, Pavel Tsekov wrote: On Thu, 13 Jul 2006, Oswald Buddenhagen wrote: On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote: There are several features which are consistent source of problems: My opinion is that we should remove both features from the subshell. * the subshell prompt retrieval - this one is widely known to be unreliable. could you be more precise about that? do you mean the shell's cwd or the actual prompt string? The shell prompt string itself. ok. maybe it would make sense to implement an own bash-compatible PS1 interpreter. trying to make sense of almost arbitrary program output sort of has to fail. * execution of commands typed at MC's prompt widget trough the subshell read my lips: NO WAY IN HELL. ;) this is one of the few actual selling points of mc over all the other The prompt widget or the fact that if the subshell is enabled commands are executed trough the subshell ? Don't get me wrong - I want to keep the prompt widget. What I propose is to handle commands typed at it just as if the subshell is disabled. I cannot see how commands typed at the prompt and executed trough the subshell give MC an advantage over the other file managers. the fact that i can switch the panels on and off at any time - without losing the command's output. what would be really perfect would be what we had in norton commander, where the nc prompt just pretended to be the shell prompt, giving the possibility to freely toggle the panels while constructing a command, having the same history, etc. - however, emulating a typical unix shell's interactive command set is unrealistic, and embedding the real shell's prompt into the panel view seems outright impossible, esp. given the current problems. the only problem i have is mc permanently mis-detecting that the shell is busy, but that is worked around by ctrl-o enter ctrl-o alt-p enter. The problem that I was debugging - it was related to this feature. In short: [...] yes, i remember that discussion pretty well. it's, indeed, no simple problem. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Midnight Commander mod with Colorer-take5 syntax engine
On Thu, Jun 22, 2006 at 05:30:38PM +0400, Igor Russkih wrote: already implemented. I should look for that switch then :) . It's a runtime option in editor's settings dialog. You'll find it easily ;) fwiw, i think this is silly. typical example of over-configurability. if it has to be runtime-switchable (why?), don't put it in the dialog at least. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: utf8 patch for mc, slang 2 version
On Thu, Jun 15, 2006 at 09:45:26AM +1200, Bart Oldeman wrote: On Wed, 14 Jun 2006, Egmont Koblinger wrote: On Tue, Jun 13, 2006 at 07:14:41PM +0200, Tomasz K?oczko wrote: BTW: anyone is working on UFT-8 support for ncurses(w) backend ? I don't think so, and I don't think it is worth it. Maintaining two backends IMHO just causes headaches while it doesn't make mc better. I still can't see why developers do not decide which one to use and drop the other one. Maybe compatibility with older UN*Xes with curses but no slang? that doesn't sound too convincing. With Unicode support maintaining the two will be much harder since AFAIK slang works with UTF-8 while ncurses uses UCS-4. Hence a completely different patch would be required for the two cases. Last time I played with it ncursesw (but not plain ncurses) handled UTF-8 just fine. good. i'm all for killing slang support. why that one? libslang is twice as big as libncursesw. probably because it was meant to be much more than just a display lib. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
On Tue, May 23, 2006 at 03:44:30PM +0300, Pavel Tsekov wrote: I am just posting it to see whether you like the idea. The patch uses the input field's ability to automatically retrieve the last entered text from the history. i'm fine with it. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [RFE][PATCH] Display free space on device in panels
On Fri, May 19, 2006 at 02:29:49PM -0400, Pavel Roskin wrote: Hello! I was originally inspired by the old czech m602 file manager: http://oldgame.legalne.net/big/images/Manazer-M602.00.120.jpg A bit more talky design was used in the DOS Navigator: http://www.dev0.de/pix/dn151lfnbeta3.png Can we avoid any highlighting? I think Far Manager does it right: http://red-bean.com/proski/mc/far.png yes, but i definitely prefer the totals above the mini-status. i think that's what they had in earlier times, too. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Allow storing mc configuration in /etc/mc
On Thu, May 18, 2006 at 04:09:00PM +0300, Pavel Tsekov wrote: On Thu, 18 May 2006, Jindrich Novy wrote: On Wed, 2006-05-17 at 23:36 +0300, Pavel Tsekov wrote: I think the patch is pretty straigth forward. I am not really sure that we want to check both mc_home and mc_home_alt though. Anyway, if noone objects I'll commit this patch. I would keep both checks for a while to not to break mc when someone decides he wants the configs in one place as it used to be (/usr/share/mc). On the other hand we could remove the dual checks after some time when the most of the mc users are aware of the change. I can write a patch for it as well then. I don't want to start a big discussion about it - either way it is acceptable. I just occured to me that it may be confusing for the end user if both paths are checked. you bet it is. for example, suse-packaged kdm has a long track record of confusing the hell out of users with this approach. i'd much prefer a clean switch to sysconfdir, which is presumably what the debian packaging does. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: find in viewer
On Thu, May 18, 2006 at 05:42:45PM +0300, Pavel Tsekov wrote: I guess in the long term the last seach string should be remembered onto persistent storage as for example the file positions. yes. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [BUG] ? mc hangs when $DISPLAY set
On Tue, May 02, 2006 at 11:25:41PM +0200, Enrico Weigelt wrote: What exactly is this X connection for ? for tracking keyboard modifiers ... fun, isn't it? i think mc should only connect to $DISPLAY if $WINDOWID is also set, meaning it was started from within an xterm (many, if not all term emulators set this env var). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16452] mcedit forgets POSIX newline at end of file
Follow-up Comment #5, bug #16452 (project mc): ... except that this patch does not actually handle the Cancel case ... but other than that i'm fine with it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16452 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #16452] mcedit forgets POSIX newline at end of file
Follow-up Comment #1, bug #16452 (project mc): nothing in the quoted paragraph suggests that a newline has to be present. there are two philosophies regarding newlines: newlines as line terminators (requires newline) and newlines as line breaks (separators - no newline required). personally, i also lean towards line termination. however, so far mcedit follows a don't do anything not explicitly requested philosophy (autoindent being the exception) - not necessarily by design, but because it is simpler to implement. but i'd argue that the explicit mode is a good default choice anyway. as far as dos newlines are concerned, i repeatedly found it annoying that mcedit can't deal with them (displaying ^M does not count ;). i think it should handle them transparently - and *possibly* offer a conversion option. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16452 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4162] detach on quick-save
Follow-up Comment #2, patch #4162 (project mc): you put the mc_close() outside an else branch; you'll now close an arbitrary handle if the file is not local; closing -1 is not too nice, either. other than that it looks ok. btw, edit_save_as_cmd() uses mc_open() to fake an mc_stat() - i think it would make sense to change it. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4162 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4970] add label highlighting to c.syntax
Follow-up Comment #3, patch #4970 (project mc): actually, this patch sucks - it breaks the highlighting of the default: labels in switch statements. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4970 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [patch] support xclipboard
On Thu, Mar 16, 2006 at 12:09:20PM +0200, vadim wrote: Patch for support XCLIPBOARD from mc. cool. xclip can not insert into XCLIPBOARD under KDE. try disabling klipper and/or playing with its options. as an option, your code should be able to use PRIMARY instead of CLIPBOARD - that should help with some klipper configurations and sounds like a desirable option in general. your code uses array(s) with variable dimensions, afaics - that's not portable. if mc already uses alloca, that's the way to go. otherwise only malloc or statically sized arrays are left. keep whitespace changes out of your patches. ps: pavel, maybe just run perl -pi -e 's,[ \t]+$,,' `find -type f` over the repo and commit it. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
